Re: How to write user stories for usability at release and sprint level
- I'm been following this question about usage and usability design
VERSUS incremental development for quite a while - since Jeff started
up this group, and talking with him, and comparing how he describes
visual designers' work v programmers work, and how I also do and see
I confess that I can't yet see a way out of the conundrum.
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
I don't know what the resolution can be. Certainly, faster more sketchy
ideation period for the visual designers, learn to adjust to surprises
that show up later and learn to work incrementally ... but until and
unless someone shows up with a way to revise UIs inexpensively half-way
through a project, I can't see advocating "do visual design as you go"
as some companies are forcing their visual designers to work.
I will counter with a particular proposal that may buy visual designers
some time ... it's an idea from the old Smalltalk community back in the
early 90s. Namely - have the software designer/programmers design and
code up the system entirely to an API, not a visual interface.
The API defines the services the system needs to support and the
information structures it needs to be able to produce (and absorb).
This is fairly much independent of the visual design, the sequence of
screens, the placement of visual elements. That design can be going to
in parallel, or even a bit behind, since it will simply call upon the
As I wrote, this is what we recommended and occasionally did in the
early 1990s on Smalltalk projects (using the transcript window for all
I/O to start with), and I have found myself doing this with my current
project to replace my website. We have the entire website working with
absolutely no visual design in place. There is (hopefully) nothing the
visual component will ask for that we haven't already tested that the
system can produce. We are, however, a bit more experienced in talking
about what the meaning of certain requests mean in terms of
computational implication. We've recently started on the visual design
and not found any conflicts.
what this means is that the software designer/programmers can code and
test every part of their work independently of the visual design.
I don't know how this would look on a larger project with multiple
The hard part really is finding programmers who are willing to build a
headless system to an API. Most of them insist on a UI for no
particular good reason (and thereafter couple the system too closely to
the UI and get stuck after that).
If anyone else is / has played with this approach, please comment on
cheers - Alistair
- 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.