Re: [agile-usability] What is the best way to prepare a UI Design for a User Story?
- carl myhill wrote:
> If I have a story which is to get a bit of functionality working,This is totally up to the team. It can be a valid business decision to
> 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.
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 wonderingI'd say you shouldn't do that. The conversation should be the primary
> how best to deliver the design to developers such that it is
> sufficiently self explanatory (along with some surrounding
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, iI'm saying something slightly different. Any artifacts you create for
> 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'.
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 toAlas, no. Often, the UI isn't (and shouldn't be) well drafted.
> User Stories that are well drafted. Can you point to a set of well
> drafted user stories with accompanying sets of well drafted UI?
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
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