RE: [agile-usability] Re: principles for UI architectures
- i tend to do the following:break up roles/personasthink about context of usagebridge the two togetherconsider percentage usage of a given persona/role for given context/function.helps to see where emphasis needs to be placed.That is, you probably want to pay attention to those aspects of the application that are used 95% of the time by 85% of the users. Versus, for example, the obscure, infrequently needed admin screens for maintaining the list of states/provinces for each country.
-- jon-----Original Message-----Jeff and Josh,
From: Larry Constantine [mailto:lconstantine@...]
Sent: Saturday, July 31, 2004 5:49 PM
Subject: RE: [agile-usability] Re: principles for UI architectures
I hate to jump on two such good friends and colleagues in one positing, but
I think you both might have misunderstood something. First, an interaction
context is not a metaphorical place, its an abstraction of a part of the
user interface. That is, an interaction context is an abstract piece of the
real user interface--such as a window, page, screen, or tab panel--with the
particular realization left unspecified. There is nothing metaphorical about
I agree with Josh that goal-directed design might be improved by a more
explicit incorporation of interaction contexts, but personas, which model
users rather than interfaces or parts of interfaces, are certainly not used
in this manner by most people I know doing what they think is goal-directed
design. Personas in GDD stand in for user roles in usage-centered design.
User roles are just a different slicing-and-dicing of what we need to know
All that said, from an architectural standpoint, there is sometimes a fairly
simple connection between personas and the target user interface
architecture in that, if you are designing to multiple personas, you do want
all the needs of each persona to be supported by a closely coupled
collection of interaction contexts.
--Larry Constantine [mailto:lconstantine@...]
Constantine & Lockwood, Ltd.
58 Kathleen Circle | Rowley, MA 01969
tel: +1 978 948 5012 | fax: +1 978 948 5036 | www.foruse.com
> -----Original Message-----
> From: Joshua Seiden [mailto:joshseiden@...]
> Sent: Saturday, 31 July 2004 7:18 AM
> To: email@example.com
> Subject: RE: [agile-usability] Re: principles for UI architectures
> > > I'm wondering if there
> > > are some principles for UI architectures, similar
> > > modularity in design, that facilitate the
> > > development of the HLD parts, rather than requiring
> > > "full scope" pass up front?
> > > --->
> > > This is an interesting notion that I haven't seen
> mentioned before.
> > > Anyone have any leads on this?
> > >
> > Here's what makes high level design more resilient
> for me:
> > I'm using C&L's Usage-Centered Design. They describe
> an interaction
> > context. An interaction context is a metaphoric
> place you go to do
> > similar tasks.
> Cooper's goal directed design system uses personas in
> this manner. Interaction contexts, as you describe them
> Jeff, don't exist as a named entity in this system, but
> instead are implied by the notion of a primary persona.
> GDD would be improved, I suspect, by stealing this
> notion of interaction contexts.
> Yahoo! Groups Links
- Paul Hodgetts wrote:
> So, I'm wondering what would happen if we just didThe term "all roads lead to Rome" doesn't just mean
> interface work as required by the feature we're
> on. Why can't we approach UI design like we do
> evolutionary code design?
than roman civil engineers started from home. It
anyone carting their goods from their little farm or
crafts shop, chosing the direction away from the
barbarians, would eventually encounter a Roman tax
Agile processes sort features in order of business
A project must finish its primary set of features
before working on a secondary set. For the first few
iterations, only the primary ones get any design
attention, coding attention, or tool support.
Reviewing an iteration�s results assists adding new
User Stories to the stack, and assists resorting the
stack before the next iteration.
Some Agile literature admits a diagnosis of nebulous
or rapidly changing requirements indicates an Extreme
Programming prescription. This sophistry appeases
those with positive experiences converting relatively
motionless requirements into planned designs before
implementing them. But we don�t care if all the
requirements are carved in granite.
Source code supporting the primary features, written
first, experiences the most test runs over its
Finished primary usability designs assist specifying
new secondary usability designs, so their details
reinforce the primary features. All versions lead
users to the features of highest business value.
All roads lead to Rome.
Refactors invest secondary features into the primary
features� code, amplifying the testing pressure that
constrains the primary features.
Implementing features by business priority is a design
> Every once in a while, I found we got into a localWhen tests drive development and make changes safe,
> that needed a little extra work to break out of into
> better larger-scale design, but because everything
> clean and minimal already, even though there was a
> flurry of extra work to adjust for the new
> structure, it
> went smoothly with little risk and impact to the
the search for the set of features that maximizes
users� productivity becomes a simple hill-climbing
algorithm. The Customer always fearlessly picks the
steepest slope from the current location. This
simplifies requirements gathering. While nobody can
agree on the details for low-priority features, the
high-priority ones compel attention. Implementing
those features teaches how to specify the lower value
features, so they support the higher ones.
To avoid rework, XP teams boost user productivity
early and often. The Planning Game sorts User Stories
in order by business value. This is a hill-climbing
algorithm�a search for the maximum productivity boost
from the current position. On hills without secondary
peaks, the shortest path up is always the steepest
path from each point. In the space of programming, a
hill-climbing algorithm encounters no secondary peaks
if all application features can deform continuously.
Simple Design, Merciless Refactoring, and Test-Driven
Development create designs that change smoothly and
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
>I'll just respond to a small part of your post.
>So, I'm wondering what would happen if we just did the
>interface work as required by the feature we're working
>on. Why can't we approach UI design like we do
>evolutionary code design?
>What forces resist evolutionary interface design?
It likely depends on the type of product that you have, but with
applications that people use as part of their core job (i.e. spending
the majority of their workday using the app), changing the user
interface significantly decreases productivity as users try to forget
the old layout and learn the new. The outcry is usually terrific.
We try to design for what is coming in the future so that we don't have
to modify the interface drastically and make our current customers mad.
If we designed for only this release then refactored the interface on
the next release, we wouldn't have any customers left. I think that is
the force that resists evolutionary design. :-)