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

4424Re: [agile-usability] What is the best way to prepare a UI Design for a User Story?

Expand Messages
  • carl myhill
    May 19, 2008
    • 0 Attachment
      Hi 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 work
      > >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.

      That is good to hear - I thought it might play out like that. Big docs
      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.
      >
      > 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.

      I'm with Alan Cooper on this one. If you use tools like CSS to do
      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
      conversation).

      > The other set is for communication. The top representation for this is a
      > 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.

      I'd like to think there must be an in-between step. You've said, i
      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 be
      > 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:

      I like the sound of these ideas!!!

      > http://submissions.agile2008.org/node/5085
      >
      > 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,

      Very much - thanks William. I have a few more growing pains to get through yet!

      Carl
      --
      User Experience Design
      (http://www.userexperiencedesign.co.uk)
    • Show all 4 messages in this topic