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
Interactiondesign.org article on user stories.
https://www.interaction-design.org/literature/article/user-stories-capturing-the-user-s-perspective-quickly-and-simply
Images: Flickr/visualpun.ch