Loading ...
Sorry, an error occurred while loading the content.

RE: [agile-usability] Tricks

Expand Messages
  • Jeff Patton
    Ditto. Incredible advice from both Charlie and David. BLO PICASSO _____ From: Dave Cronin [mailto:dave@cooper.com] Sent: Thursday, September 09, 2004 1:41 PM
    Message 1 of 6 , Sep 10, 2004
    • 0 Attachment

      Ditto.

       

      Incredible advice from both Charlie and David.

       

       

      BLO PICASSO


      From: Dave Cronin [mailto:dave@...]
      Sent: Thursday, September 09, 2004 1:41 PM
      To: agile-usability@yahoogroups.com
      Subject: RE: [agile-usability] Tricks

       

      These are great.

      -d

      > -----Original Message-----
      > From: Charlie Trainor [mailto:charlie.trainor@...]
      > Sent: Wednesday, September 08, 2004 8:58 PM
      > To: agile-usability@yahoogroups.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 National Lampoon's
      > advice to the "fluke of the universe"...
      >
      > 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 behaviour
      > * 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 of iterations)
      > * Talk to the developers and make sure they understand by
      > 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 nothing worse
      > than developing the wrong product)
      > * Rinse and repeat - i.e. do a little bit of this every
      > iteration and shed anything that is no longer important
      > *** Potential pitfall: not keeping up with development.  You
      > may not be able to do the analysis and prototyping fast
      > enough to stay ahead of development.  This will result in a
      > lot of rework and changing direction, which can frustrate the
      > 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 chance to
      > 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 favourite interaction
      > 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 so important. 
      > 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 language.  (And
      > if this seems like a new concept, read Eric Evans' book on
      > Domain-Driven Design.)
      > * If you haven't been given one, create your own paper
      > prototype and show it to the customer and/or interaction
      > 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 the paper
      > prototype", because it is not true.
      >
      > Concrete actions for testers:
      > * Test the paper prototypes, in front of whoever created
      > them.  Work out as many "bugs" and usability problems before
      > anyone starts coding.
      > * Review your test cases for completeness by going through
      > each persona in turn and asking what mischief that persona
      > might get into.
      >
      > - Charlie
      >
      > "And let not the sands of time
      > Get in your lunch." - National Lampoon
      >
      >
      >
      >
      > ------------------------ Yahoo! Groups Sponsor
      > --------------------~-->
      > $9.95 domain names from Yahoo!. Register anything.
      > http://us.click.yahoo.com/J8kdrA/y20IAA/yQLSAA/dpFolB/TM
      > --------------------------------------------------------------
      > ------~->
      >

      > Yahoo! Groups Links
      >
      >
      >

      >
      >


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