How to request a design story
Design stories characterize a problem or frustration that users experience, which may be quite large and involve several pages on the site, or may deal only with an isolated widget or small visual treatment. Design stories result in consultations, wireframes, mock-ups, click-able prototypes, or other visual collateral that will be used to create a feature request(s). Design stories do not result in released code or feature development, but are a step along the way.
Design stories fall somewhere between feature requests and spikes—often there will be research and discovery involved, but features will need to be represented accurately within a design.
To request a design story, include the following information:
-
User story - A user story is a short description of an end user's need. User stories help guide conversation that leads to extracting business and technical requirements and eliminating hidden assumptions. Use this simple template:
As a [specific user/persona/role] I want [desired feature/issue that needs to be solved], so that [benefit from implementing the feature].
Each of these elements is important and has a role in expressing and understanding the captured requirement. For examples and more information about what makes a good user story check out these articles:
-
Acceptance criteria (if any are known yet) - Acceptance criteria complement the narrative: they allow you to describe the conditions that have to be fulfilled so that the story is done. The criteria enrich the story, they make it testable, and they ensure the story can be demoed or released to users.
- User Stories Acceptance Definition and Criteria in Agile Methodologies
- What Characteristics Make Good Agile Acceptance Criteria?
Acceptance criteria may already be known when a design story is created, or they may be part of the discovery process/requirements gathering that occurs with design work. Regardless, acceptance criteria will be needed in order to create a feature request to implement the design. The earlier in the process acceptance criteria are introduced, the better!
If specific acceptance criteria are not known, perhaps there are some questions that you expect the design story to answer, like: "How can this be made more intuitive for users?" or "How can we reduce the amount of time a user spends using this part of the site?" etc.
-
Expected deliverable - What is the expected output of this design story? Will it be a wireframe to assist in gathering requirements? A high-fidelity clickable prototype to be tested with users? A short consultation about fonts, colors, or CSS with a developer who's implementing a fix on the fly?
-
Be sure to apply the label "design story" to your issue when you submit it:
An example of a helpful design story:
As a user composing a story
I want to see the edges of my StoryFrame when I set it
In order to understand what viewers see when they play my MapStory
Acceptance Criteria
- The StoryFrame maintains the same aspect ratio, even when resized
- The user can access and use zoom buttons while setting the StoryFrame
- The edges of the StoryFrame are always visible, and cannot be resized exceed the user's browser width or height
Deliverable: high-fidelity mock-up to discuss technical feasibility with the team and create feature stories