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

RE: [agile-usability] Tricks

Expand Messages
  • Charlie Trainor
    ... 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)
    Message 1 of 6 , Sep 8, 2004
    • 0 Attachment
      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
    • Dave Cronin
      These are great. -d
      Message 2 of 6 , Sep 9, 2004
      • 0 Attachment
        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
        >
        >
        >
        >
        >
        >
      • 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 3 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.