RE: [agile-usability] Re: principles for UI architectures

i tend to do the following: break up roles/personas think about context of usage bridge the two together consider percentage usage of a given persona/role for

Message 1 of 12
, Aug 1, 2004

i tend
to do the following:

break
up roles/personas

think
about context of usage

bridge
the two together

consider 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.

I hate to jump on
two such good friends and colleagues in one positing, butI think you both
might have misunderstood something. First, an interactioncontext is not a
metaphorical place, its an abstraction of a part of theuser interface.
That is, an interaction context is an abstract piece of thereal user
interface--such as a window, page, screen, or tab panel--with
theparticular realization left unspecified. There is nothing metaphorical
aboutit.

I agree with Josh that goal-directed design might be
improved by a moreexplicit incorporation of interaction contexts, but
personas, which modelusers rather than interfaces or parts of interfaces,
are certainly not usedin this manner by most people I know doing what they
think is goal-directeddesign. 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 knowabout users.

All that said, from an
architectural standpoint, there is sometimes a fairlysimple connection
between personas and the target user interfacearchitecture in that, if you
are designing to multiple personas, you do wantall the needs of each
persona to be supported by a closely coupledcollection of interaction
contexts.

... The term all roads lead to Rome doesn t just mean than roman civil engineers started from home. It anyone carting their goods from their little farm or

Message 2 of 12
, Aug 1, 2004

Paul Hodgetts wrote:

> 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?

The term "all roads lead to Rome" doesn't just mean
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
collector.

Agile processes sort features in order of business
priority.

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
remaining lifetime.

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
technique.

> Every once in a while, I found we got into a local
> maxima
> that needed a little extra work to break out of into
> a
> better larger-scale design, but because everything
> was
> clean and minimal already, even though there was a
> little
> flurry of extra work to adjust for the new
> structure, it
> went smoothly with little risk and impact to the
> project.

When tests drive development and make changes safe,
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
safely.

... I ll just respond to a small part of your post. It likely depends on the type of product that you have, but with applications that people use as part of

Message 3 of 12
, Aug 4, 2004

>
>
>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?
>
>
>

I'll just respond to a small part of your post.

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. :-)

Lynn Miller
Alias

Your message has been successfully submitted and would be delivered to recipients shortly.