4424Re: [agile-usability] What is the best way to prepare a UI Design for a User Story?
- May 19 3:06 PMHi William
Thanks for the comprehensive reply.
The invest criteria is helpful -thanks for that. It raises one
question for me which relates to the 'when is done done' question
which I still dont understand.
If I have a story which is to get a bit of functionality working,
like, 'open a new blank document'. There are a couple of ways a
developer can approach it from a UI perspective. They can i, just get
it working functionally; or 2, they can get it working and make it
look like a 'new blank document' in a fancy Vista/Office style. One of
those pieces of work is small and the other is quite a bit bigger.
What is the norm here? Do you expect that, most times, functionality
will be produced subject to an acceptance criteria which is 'meets
platform UI standard'? Or do you allow the earlier Releases to be more
functional and less pretty from a Ui standpoint.
I also asked about what other agile technques there are for chunking
up work. Am I right in thinking User Stories are an alternative to
Feature Cards? Are there other approaches in this space too?
> >The typical pattern I see is that people used to organizing their workThat is good to hear - I thought it might play out like that. Big docs
> >around some large document will start out doing that in parallel,
> >feeding the team bits as needed. Eventually, they get tired of
> >maintaining the parallel document, and let it wither away, using lighter
> >or more fragmentary artifacts to organize their thinking.
dont seem right to me in an Agile context but perhaps that is totally
obvious to you lot.
> I can say that I have seen see two categories of representations.I'm with Alan Cooper on this one. If you use tools like CSS to do
> One set is to aid the designer in thinking about the design. These vary
> a lot, and mainly depend on the background and number of the designers.
> One person I know thinks in HTML and CSS, and so will sketch in it.
> Some use tools like Photoshop, Illustrator, or Visio. Many use physical
> artifacts, like sketchbooks, whiteboards, or paper on walls. I have seen
> neat things done with post-it notes, index cards, and string all pinned
> on giant corkboards.
design work, the constraints of the tool will limit your thinking. You
can design much more freely with a pencil and paper!
This is a bit tangential to what I was asking though. I'm wondering
how best to deliver the design to developers such that it is
sufficiently self explanatory (along with some surrounding
> The other set is for communication. The top representation for this is aI'd like to think there must be an in-between step. You've said, i
> highly optimized, interactive, queryable one with a natural-language
> interface: the designer. They show up and explain things. When questions
> come up, they answer them.
think, i can draw the design however I like and be available to
discuss it. So, should a BA represent a User Story however they like
and just be available for discussion. It worries me that the answer to
my counter question might be 'yes'.
What I'm really asking is what works well. I think you could point to
User Stories that are well drafted. Can you point to a set of well
drafted user stories with accompanying sets of well drafted UI?
> To aid in that, people use all sorts of things. Pair programming can beI like the sound of these ideas!!!
> a great one: the designer and developer sit down together for a couple
> of hours and work on the actual interface jointly. Whiteboards and giant
> post-it pads are also popular. One client clips a small sketch to key
> story cards as they enter the iteration. Others will tape big sheets of
> paper on the wall; sometimes those are prepared in advance by the
> designers, sometimes they are done on the fly. Some put Photoshopped
> samples up on the walls to convey visual style. Others use formal
> stylebooks, often assembled in an agile way. For example:
> http://submissions.agile2008.org/node/5085Very much - thanks William. I have a few more growing pains to get through yet!
> These communication-focused artifacts work best when they are relatively
> lightweight, easily modified, easily broken up to move with the stories,
> and easily discarded at the end of their usefulness. E.g., when the
> story is complete, you erase the whiteboard, rather than trying to keep
> it up to date.
> Because the point is communication, in my experience the form of these
> artifacts can vary quite a bit even from story to story. Once you've
> been working with a team for a while, as a designer you may only need to
> say, "The vendor screens should look just like the client screens we did
> last month." There's no sense preparing an elaborate artifact when you
> can just point at something you've already collaborated on.
> Hoping that helps,
User Experience Design
- << Previous post in topic Next post in topic >>