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

RE: [agile-usability] How to write user stories for usability at release and sprint level

Expand Messages
  • Desilets, Alain
    ... I m thinking more about specific usability gotchas that might bight you in a particular user story. I don t think saying something like users must be able
    Message 1 of 83 , May 7, 2008
    • 0 Attachment
      > Thank you Alain - are you saying then that in order to build in
      > usability into user stories it should be for instance incorporated as
      > an acceptance criteria per user story?

      I'm thinking more about specific usability gotchas that might bight you
      in a particular user story. I don't think saying something like "users
      must be able to complete this task in 10 secs or less" is very helpful.
      It's better to talk about things that might cause the implementation to
      be inefficient and tell the dev how to avoid them. The kind of important
      details that developers are likely to overlook.

      But maybe a generic acceptance criteria can be useful, as long as they
      are accompanied by a promise by the Ux specialist to have a conversation
      about how to achieve this.

      > This makes sense to me at sprint
      > level but at release level would it not make sense to have a
      > dedicated user story for 'non-functional' related
      > areas including usability?

      Can you give me an example of what such a story might look like?

      Alain
    • carl myhill
      I m a bit new to Agile but don t really see the problem with this vision thing. I use the Cooper Goal-Directed Design Method. We interview users to learn their
      Message 83 of 83 , Jun 2, 2008
      • 0 Attachment
        I'm a bit new to Agile but don't really see the problem with this
        vision thing. I use the Cooper Goal-Directed Design Method.

        We interview users to learn their goals and understand their tasks and
        we do that up front, perhaps as a sprint rather than anything
        iterative.

        We produce personas, from the interview data, and goals. And we
        produce high level context scenarios, which start making basic
        references to concepts that will exist in the design.

        From the context scenarios we can almost underline the parts which
        indicate user needs.

        Then we take out a whiteboard pen and write a storyboard wireframe
        (which Cooper used to call the Design Vision and now call in
        Interaction Framework). We elaborate a bit on the design hinted at in
        the context scenario and produce a key path scenario, which describes
        in more detail how the user will interact with the design. This whole
        exercise lets us outline the anatomy of the design and to understand
        how to play it.

        When we are happy with that Design Vision, we can jump into iterations
        and do a bit of 'just in time' detailed design.

        The Vision, is the Design Vision. It is justified through
        understanding the users typical day and their typical needs. It
        probably won't change much since it is quite high level.

        I'm not sure where the problem is with a vision like this. perhaps,
        the only drawback is that you have to do a bit of work in front of the
        iterative cycles to get a good understanding of the users and what
        they do to enable you to get this vision pinned down.

        i'd be interested in comments on this.

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