SKILLS: User Stories

The best community design improvements come from users themselves in their own words.  User stories ask a short set of fill-in-the-blank questions to define what community members need.

Benefits & Problems Addressed

Eliminate translation biases: Program developers often make assumptions about who users are, what they need and how they would use an ideal product.

Opportunities to talk: In convening a range of users, program developers can form connections & build trust by putting constituents in the middle of the conversation.

Simplicity: For constituents new to a public process, a user story is an accessible first experience. Because of the simplicity, cards can be displayed on a plaza for passersby to fill in.

Tips & Techniques

When to Use: Think about how to use with any product/program or policy design or redesign. Best use with small to medium-sized groups.

Basic components: Use stories basically begin with the following prompt:  As a ________________, I want ________________ for ________________.   This captures the perspective, the requirement and how/why it is important.  Also include a date on the card & other meeting information. You may want space to later mark priority or other sorting information.

Variations:  Variations might include: 

As a ________________, I need ________________, to solve ________________ (this is good for developing services)

For my role as ________________, I can   ________________ to help ________________. (this is good for insight on an ideal use case for the user).

You can add a fourth line to specify "make sure it ____________" to capture what success factors.

Use cases: Use cases could be (1) considering changes to a bus route and stops, (2) developing new summer programs for children, (3) updating the library acquisition list, (4) expanding local volunteer programs, (5) developing criteria for grants (6) updating a city or non-profit's website features (7) ideas on how people would use a new park.

Prompts: In some cases, you may want to have people choose from a user list, for example for transit riders could be (1) daily user (2) occasional useer, (3) student rider, (4) non-rider.

What you want users to have: While the focus is on users, program/project directors can set standards for what users get a well. For example, a city manager may direct a story of "Permit applications can access visual tracking for the review process. Make sure it activates for each account within 24 hours with notification."

Compiling results: In desinging user stories, compose the prompts and input cards with compilation in mind - and for what purposes (e.g., finetuning descriptions of users, prioritizing needs). Because user stories are usually a first step, pre-think how the results will fit into the larger program/product/policy development process.

Hot Buttons: User stories are only one aspect of research needed to properly design complex programs. Users may submit a variety of opposing needs & wants. While user stories provide great information, they may not be robust enough to serve as data 

Resources article on user stories.

Images: Flickr/