From: Dave Cronin
Sent: Thursday, September 09, 2004
Subject: RE: [agile-usability]
These are great.
> -----Original Message-----
> From: Charlie Trainor
> Sent: Wednesday, September 08, 2004 8:58 PM
> To: email@example.com
> Subject: RE: [agile-usability] Tricks
> Brian Marick challenged:
> > I'm a fan of concrete actions. What can
a person do
> tomorrow to be a
> > little better at her job? (And how will
she know when her
> attempts to
> > get better are making things worse? What
common pitfalls would she
> > face?)
> Hopefully this doesn't sound too much like
> advice to the "fluke of the
> Concrete actions for customers (aka product
owners) of agile teams:
> * Get an interaction designer involved, and
do the next few
> steps with them
> * Hold a one-hour brainstorming session to
identify 2-5 personas
> * Do paper prototypes (hand-drawn) to try out
> * Try out the paper prototypes on a few end
users (as quickly
> and cheaply as you can - don't videotape,
don't use elaborate
> usability labs, just observe)
> * Do this only for the most critical aspects
of the software (i.e.
> what might get developed in the next couple
> * Talk to the developers and make sure they
> getting them to explain to you how a user
would interact with
> the system; listen to their reaction because
it will be enlightening
> * Talk to the higher-ups (business folks,
executives, etc) to
> make sure you have alignment ('cause there is
> than developing the wrong product)
> * Rinse and repeat - i.e. do a little bit of
> iteration and shed anything that is no longer
> *** Potential pitfall: not keeping up with
> may not be able to do the analysis and
> enough to stay ahead of development.
This will result in a
> lot of rework and changing direction, which can
> development team. If there is an
imbalance, involve the
> developers more in the analysis side, or get
them to do
> investigations and spikes, until you've had a
> clarify the direction. But also be
aware that considerable
> rework is normal when a team is highly
productive - it can be
> a sign that a lot of learning is happening
quickly. You may
> need to remind the developers of that.
> Concrete actions for interaction designers:
> * Do a highly compressed cycle of your
> design methodology between now and the
beginning of the
> developers' next iteration. You don't
have three months to
> spend getting it perfect - just a few
days. Don't worry -
> you'll have plenty of time to change it.
And then change it again.
> * In the same spirit, remind yourself that
you can change.
> You may decide a key persona is actually not
> You may discover new personas.
Similarly, 2 of the 5 key
> tasks may turn out to be misguided. Go
forth with the
> conviction that this is the nature of
discovery, and retain
> your quiet confidence despite people
complaining about you
> not knowing what you are doing.
> * As the developers create software, use it
to do quick and
> dirty usability tests with end users.
Talk to them about
> what should or could change.
> Concrete actions for developers:
> * Make sure you are using the same language
as the customer.
> If you find yourself explaining technical
details, stop and
> force yourself to use the customer's/user's
> if this seems like a new concept, read Eric
Evans' book on
> Domain-Driven Design.)
> * If you haven't been given one, create your
> prototype and show it to the customer and/or
> designer, to see if you understand exactly
how the software
> should behave. Resist the temptation to
say, "I could have
> developed the software in the same time as
> prototype", because it is not true.
> Concrete actions for testers:
> * Test the paper prototypes, in front of
> them. Work out as many "bugs"
and usability problems before
> anyone starts coding.
> * Review your test cases for completeness by
> each persona in turn and asking what mischief
> might get into.
> - Charlie
> "And let not the sands of time
> Get in your lunch." - National Lampoon
> ------------------------ Yahoo! Groups
> $9.95 domain names from Yahoo!. Register anything.
> Yahoo! Groups Links