Agile 2006: From User Story to User Interface: Collaboratively Designing and Testing User Interface – Jeff Patton

Wednesday 09:00-12:30

Abstract

The user interface can be designed from the user story by following a process to define the UI tools to be included, then creating paper prototypes to test the usability, without focusing on the visual design.Â

Summary

The user interface consists of five layers:

  • Strategy – why is the software being built? What’s the usage context? What are the business goals?
  • Scope – tasks for the page
  • Structure, skeleton, and surface – this is where the user interface and prototyping takes place.
  • Understanding the task-centric scope defines the page structure. Tasks should be defined at the role level – i.e. a person engaged in an activity, e.g. shelf stacker. Create personas to represent people the product would serve – this allows focus on specific people in the design. Consider their skills and aptitudes.

When modeling tasks, consider the goal level:

  • Cloud – on going, business level goals, e.g. communication
  • Kite – long term goals, e.g. manage email
  • Sea – tasks that could be accomplished in one setting, e.g. send an email
  • Fish – sub tasks that stitch together to form a task, e.g. enter “to” address
  • Clam – sub tasks that form larger sub-tasks, e.g. look up an email address

Stories should start from sea level – at this level, if a user accomplishes the goal, they will consider themselves successful in doing something. Remember – “if you stay below sea level for too long, you’ll drown”. At this level, there is no UI design decision. As stories are split into small enough items to work on, the design starts to take shape as they become more granular.

A good user story is an example of use. They should follow a format:
As a [type of user]
I want to [perform some task]
So that I can [achieve some goal]

They should describe the goal, not the solution.

When moving towards a UI solution, use Constantine and Lockwood’s “Task Case”.

The next step is to define the UI tools for each of the system responses that will allow it to meet its responsibility to the user. UI tools can be three types:

  • Container – contains and presents information
  • Action – allows execution of an action
  • Actionable container – contains and presents information, and allows it to be acted on through selection or manipulation.

Once we have a list of the UI tools, it’s straightforward to create a basic paper prototype, and test it with real people, get feedback and refine it. This saves the time investment in creating and refining a real prototype.

Recommended further reading
Designing the Design Process – http://www.leaonline.com/doi/abs/10.1207/s15327051hci0502%263_6;jsessionid=ipItXBeszOt5o2aYbZ?cookieSet=1&journalCode=hci

The powerpoint from this session also includes further explanations and useful diagrams.

Agile 2006 – A Story of Stories – David Hussman

Sunday – 13:30-14:15

Abstract

How to collaborate and write effective user stories.

Summary
Requirements gathering has evolved over time into the form of use cases. Good use cases are short, simple, focus on the use cases and stay current through continued collaboration. Bad use cases replace collaboration, are long and expensive to write.

Burying requirements in long documents doesn’t work. People can’t find or estimate them. Testers, developers and customers interpret them differently.

As an alternative, collaborate to write small, short chunks of work as user stories. Write them down on 3×5 cards and post in a common area for easy access. Let the customer say what done means – and write it on the cards as acceptance tests. In a healthy community, everybody writes the stories.

Hold “story jams” to create the stories (think like music jams – let the creativity flow). Use a long table and invite lots of people. Create personas, and walk through a day in their lives. The list of stories doesn’t need to be complete after the story jam.

Good user stories conform to the INVEST acronym:

  • Independent – breaking dependencies increases agility, so that the business can choose the really valuable stories.
  • Negotiable – they can be changed. Build a ubiquitous language, so that everybody knows what the story really means.
  • Valuable – in terms of the customer, or whoever it’s being built for.
  • Estimable – sized appropriately for accurate estimates.
  • Testable – it’s a story smell if they can’t be tested as done.
  • User stories work because they are available, they bring people together, build trust, promote innovation and are humane. Stories are completed only when the customer signs them off.

Key points to put into practice

  • Review user stories against the invest acronym.
  • Create personas and walk through a day in their lives.
  • Don’t focus on completing ALL of the stories in a story jam.

Recommended further reading

Being Jane Malkovitch – the Life of an XP Customer (included in conference materials)

The powerpoint presentation contains photos and examples of personas, story jamming, and further explanations.