Tue, 07 Sep 2004
Usability tricks
On the
Agile-Usability
list, I asked for tricks:
I'd like to hear some advice to programmers, testers, and
others on agile projects about how they could get a bit
better at those things that the interaction design (etc.)
people are really, really good at.
Those things should be absorbable and try-able without a huge
investment in time.
Dave Cronin (who says he loves
to get mail), responded with this nice list:
Make all decisions within the context of one or more specific user
archetypes (personas, actors, whatever you want to call them)
accomplishing specific things (scenarios, goals, use cases, etc). Express what the user is trying to accomplish in English. For example,
if you have a complex form, first try to describe what is being
specified in sentences. Then use the sequence of sentences to order
fields in the layout and use the nouns and verbs from the sentences to
label fields. Focus on goals, not tasks. Goals are the end result that users want to
achieve-- tasks are the things that get them there. Sometimes being
overly focused on the tasks makes you lose the forest for the trees.
Even if you can't do the bluesky design where you cut out a bunch of
unnecessary tasks, focusing on goals will still help you express things
in a way that a user will understand. Use a grid for layout. Seems obvious, but its amazing how often I see
screens layed-out with no order whatsoever. Look no further than the
front page of the Wall Street Journal or any of a number of other
newspapers for how to fit a ton of information of varying importance
into a compact space. Use color sparingly. A couple colors used judiciously can really make
a screen come alive. Using five colors haphazardly makes you screen look
like salad. Optimize for the common case, accommodate the edge cases Rough out a framework before you try to lay out every button and
field. Work with the big rectangles and push them around until things
start to fit. Test layout with a variety of possible controls, think of
the worst case situation, make sure things degrade gracefully. Then when
it seems like it will work, go ahead and extend your framework by laying
out all the specifics. As you all know, things change all the time. A
solid framework can accommodate these changes, meaning you will rarely
have to restructure your interface after you refactor.
Thanks, Dave.
## Posted at 10:41 in category /agile
[permalink]
[top]
|
|
