Re: [agile-usability] Re: How to write user stories for usability at release and sprint level
- Hi, Alistair. Good to hear from you.
> I confess that I can't yet see a way out of the conundrum.As somebody who has much more experience in under-the-hood design than
> Visual designers really do benefit from wide-band ideation, exploring
> lots of ideas early and concurrently and leaving ideas on the table for
> cross-pollination. The sketchboard and cartooning discussions show this
> Software designers/programmers these days tend to get the base idea
> pretty quickly and program incrementally, changing the architecture as
> they go.
as visual designer, I may be wildly off base here. But this is also an
area that I've been researching, and here's my take.
My pre-agile approach as a software designer was to take the same path
as a lot of people on the user experience side are comfortable with:
lots of research, lots of planning, lots of sketching out alternatives,
and wanting to settle on one before starting to code.
The number one factor for me in getting comfortable with working
differently was learning how to safely change my designs later. That let
me do my designs when I had the most information available. There were a
variety of technical practices that made this possible, including
test-driven development, refactoring, once-and-only-once orientation,
and frequent, easy releases.
Now, I still do plenty of sketching of architectural possibilities, but
I do them on a ongoing basis, considering possible paths and
destinations. It reminds me of the way a big-city taxi driver doesn't
plan a single route, but keeps the options alive in his head, so that
when he hits traffic, he'll instantly change plans.
I think on the design side, things have lagged behind. Not because of
any fault of designers, mind you. I think it's partly because
plan-driven methods caused a lot more pain for developers than
designers, so they had more incentive to switch. And partly because one
of the big agile methods, Extreme Programming, was mainly programmer
created. But I think a big driver is that developers can make their own
software tools, and so there are more and better software tools for
solving developer problems than designer problems.
Still, at least in the web world, I think things have improved a fair bit.
The rise of CSS has been a huge help. The good agile designers I know
are just as fanatical about organizing and refactoring their CSS as
developers are about continuously improving technical architecture. And
they do it for the same reason: reducing the cost of change. Early web
frameworks were very page-focused, which pushed against the kind of
reuse that eases agility. Now there are better options for componentized
UIs, so that the same visual component may appear in may places but is
only coded once.
And coming back to your other point, headless systems that provide API
for UI, Ajax-ish approaches and better in-browser tools have made that
easier. It's not that one builds a whole back-end system first and then
puts on a UI, naturally. But people do tend to end up with a more slowly
evolving back-end system and a more quickly evolving front-end
interface. In the projects I keep an eye on, this has drastically
reduced the cost of design change, and led to a lot more lightweight
prototyping and design exploration than I saw at the beginning of the
So the way I see out of this is more of the same: new practices,
improved tools, better collaboration, and more experience making agile
- 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.