Wednesday, December 19, 2007

How do you feel about stories?

Using stories in the design process ...

"What is your opinion of “stories” which some web development shops write? A Ruby on Rails development shop I have worked with writes a “story” about every piece of functionality they intend to develop. They use those stories to ensure all customer objectives are met. They’re similar to use cases (maybe identical!)... functionality represented as a sequence of simple steps in writing.

We believe in interface-first driven development, but when the UI or feature needs some further explanation we write a story.

A story is usually a paragraph or two. Sometimes it’s 5 bullet points. It’s not an in depth dissection of a feature, or a technical discussion of what needs to be implemented. It’s not a functional specification. It’s simply a general idea of what the feature is about and why it’s valuable.

For example, we’re working on some stuff for Backpack right now. One of the areas we’re looking at is making it more obvious someone changed a page since your last visit to that page. The story might go like this:

Right now it’s tough to know if a Backpack page has been changed since the last time you’ve seen it. If I’m sharing a page with Bob, and Bob adds a new to-do list or a note to the page, it should be clear to me the page has changed next time I visit that page.

This story may be enough to explain why the mockup we design has a yellow strip at the top saying “Bob changed this page. See the changes.”

The story serves to add some context. It doesn’t need to say exactly how to solve the problem, it doesn’t need to refer to specific design elements, and it’s not technical. It’s just a statement of why something is a hassle (“don’t know the page changed”) and a general idea of how we can make it better (“make it clear the page changed”)."    (Continued via 37signals)    [Usability Resources]

0 Comments:

Post a Comment

<< Home

<< Home
.