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

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

Expand Messages
  • William Pietri
    ... This is totally up to the team. It can be a valid business decision to split those up. It can be rank idiocy. When people do split them, it tends to be so
    Message 1 of 4 , May 19, 2008
      carl myhill wrote:
      > 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.

      This is totally up to the team. It can be a valid business decision to
      split those up. It can be rank idiocy.

      When people do split them, it tends to be so that they can get early
      feedback, or get something quickly into production, or because initial
      target audiences care a lot more about new functionality than fancy
      styling or perfectly compliant UI.

      You'll know you're on the "rank idiocy" end of the spectrum when people
      are shipping ugly things that hurt the product's success and never come
      back to fix them. I've heard of people doing that when they have some
      sort of schedule handed down by management; they will meet all of the
      checklist items, but have a terrible user experience. The product will
      succeed in a political sense, but fail in the marketplace.

      If I thought a team didn't properly value good design, I would tell them
      to not split out the design. And by default, I think one should keep
      stories as whole as possible, even though they are small pieces of the
      app. So when in doubt, meet your UI standards. But for people who know
      what they are doing, I think splitting a story into "rough" and "pretty"
      versions can be totally acceptable.

      > I'm wondering
      > how best to deliver the design to developers such that it is
      > sufficiently self explanatory (along with some surrounding
      > conversation).

      I'd say you shouldn't do that. The conversation should be the primary
      means of communication, with just enough documentation to supplement the
      discussion. What the right amount and the right form are depends totally
      on the people communicating and what they're talking about.

      > 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'.

      I'm saying something slightly different. Any artifacts you create for
      yourself, for the purpose of thinking rather than communicating, are
      totally up to you (as long as you don't use them as a reason to be less

      For artifacts that are meant for communication, make them as light as
      you can and still communicate responsibly. That's not quite however you
      like; it's more however works most effectively for you and the people
      you're communicating with.

      > 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?

      Alas, no. Often, the UI isn't (and shouldn't be) well drafted.

      Today, as an example, I took an existing, well-gelled collocated team
      through their first planning game. In 90 minutes, we planned out a
      series of improvements to an existing product. They were all familiar
      enough with the existing product that they needed no visual
      representations of the UI to know what was being discussed. Once they
      get into the iteration, their team (which includes visual designers) may
      just produce the final UI after further discussion while pointing at the
      current stuff.

      In this case, their minimum necessary artifact is no artifact at all.

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

      We all do! The question of how best to do good design on a agile
      projects is definitely an open one. By this time next year you might be
      submitting an experience report for Agile 2009 on how your team makes it

    Your message has been successfully submitted and would be delivered to recipients shortly.