Re: [agile-usability] How to write user stories for usability at release and sprint level
- Desilets, Alain wrote:
> Not sure it makes sense to have usability as being separate from theI strongly agree with this.
> user story.
Each story is supposed to be a complete, releasable unit of work. That
doesn't mean it has every feature under the sun; often early stories are
very minimal. But it does mean that it should be 100% done. Not "done
except for testing." Not "done except for bug fixing." Not "done except
for polish." When a story is declared done by the team, it should be
If you are working in a context where usability matters, then that 100%
done should include making it well designed and meeting or exceeding
your usability goals. And for stories where usability is important,
people who understand usability should be part of the conversation from
the beginning and all the way through.
That doesn't mean that you can't schedule future stories whose primary
goal is improving the user experience. Sometimes you figure out better
ways only after a story has been in production a while. Sometimes you
intentionally defer usability improvements so that you can release early
and get feedback. Sometimes you want to ship out a relatively bare-bones
product for early adopters before you come back and make it more
approachable for other target audiences.
Even then, though, it is important that be a conscious decision, with
usability experts participating fully.
- 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
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.