Process
Hashrocket Guide to Storycarding
At Hashrocket, we begin new projects with an in-depth storycarding session. It's how we turn client vision into development-ready requirements. It allows us to immerse ourselves in the client’s business domain, define the overall interface and functionality of the application, walk through user work-flows, and discover edge cases. In this blog, I’ll talk about what storycarding is and what it takes to start a session off on the right foot.
What is storycarding?
What are the requirements for a storycarding session?
What are the parts of a storycarding session?
1. Discovery
2. Epics
3. User Stories
4. MVP
5. Prioritization
Successful Storycarding
What is storycarding?
Storycarding is a 2-3 day session where we work together with a client to define in detail the requirements of an application. We sit down together in person and talk through the client vision, capturing features in the form of story cards. If a designer participates in the session, they will produce an analogous set of wireframes. Along the way, we’ll challenge ideas, provide our input, and identify concise and measurable goals.
We approach application design from the user’s point of view. Based on conversation, we’ll turn each user-need into a fully fleshed-out feature set. This outside-in technique allows us to build lean and efficient applications by requiring each feature to be justified by its value to a particular user role.
The client will leave the session with an extensive set of stories defining the software’s functionality, ready to begin design and development. This is a snapshot of what the needs of the application are at this point in time. Because the stories are detailed and granular, when requirements change, we can easily adjust specific areas as needed later.
What are the requirements for a storycarding session?
- Time: Depending on the size of the project, we want to dedicate 2 or 3 days to this process.
- Proximity: The most successful storycarding involves everyone being in the same room together, the developers, project manager, and any designers with key client stakeholders. For us, at this initial stage of the project, it is an essential way to build rapport, context, understanding, and collaboration.
- Mindset: We’ll come ready to immerse ourselves in the client business domain, put ourselves in the users' shoes, and collaborate on features. We’ll ask the client to be open to scope challenges and alternative approaches, and to think about a “Minimum Viable Product”.
- Tools: The room will have a big screen on which everyone can see what is being written or drawn on someone’s laptop. The room will also have a whiteboard, so that anyone can get up easily to sketch out what they are thinking. We may have some oversized sticky post-its or easel pads and markers within reach to keep track of key ideas.
What are the parts of a storycarding session?
1. Discovery: Business Context and User Needs
Before we start writing stories, we will have a discovery conversation to understand the big picture around the app, including business goals and target users. We confirm what the app is supposed to do, who its target is, and what core problem it is aiming to solve for that target. We especially want to make sure that we have a deeper understanding users are and how the app will address their needs. By defining the user needs together with the client, we will form the foundation on which we will build the storycarding session.
2. Epics: Connecting User Needs with Functions
Once we understand the goal of the application, then we capture the core functionality needed to achieve that goal in one-line descriptions. The descriptions are written in a way that connects the function with a user need.
Imagine a web app that sells textbooks to college students. One such description for a purchase feature might look something like:
As a student, I want to be able purchase a textbook, so I that I meet the requirements for my class
We’ll put these descriptions up somewhere where we can easily see and reference them later. These are our “Epics” -- descriptions of big function areas of the app -- that are an umbrella over the smaller interactions that make it up.
3. User Stories: Breaking Down Interactions
After we’ve identified our epics, we work together with the client break each one down into individual interactions. These are each step that a user would perform to fully engage with a given part of the app. These become our stories. By writing them together on them with the client, they represent an agreement that we are all on the same page about the functionality of the app. This process forms the core of the storycarding session.
In our textbook app example, some story titles for the “Purchase” epic might include:
Student adds textbook to cart
Student views cart
Student adds payment information
Student submits transaction
Student receives confirmation
Each story is given a description that is also framed in use oriented “Given/When/Then” language (read more about story writing here). The description for the story Student adds textbook to cart might look like:
Given I’m a student
And I’m viewing the details page of a particular textbook
When I click on the “Add To Cart” button
Then I see that the number by the cart icon in the header increments by 1
Using this user-oriented format is important to us for a few reasons:
- It keeps us in the mindset of the user experience -- what exactly they will see and do -- so that we don’t leave any aspects of that experience unexplored.
- It makes the requirements testable, so that the developers can ensure high test-coverage through test-driven development.
- Stakeholders can easily use this story as acceptance criteria. They will be able to walk through the user’s experience of a feature step-by-step to confirm that it is working as envisioned.
Beyond the primary user-flow, we’ll also anticipate other user behaviors and edge cases. We will collaborate on how the app should respond in those situations. An example of a story outside the primary user-flow might be Student exits check-out before completing transaction.
4. MVP: The Simplest Way to Do It
Throughout the process of writing stories, we’ll work to foster an “MVP Mindset”. MVP stands for Minimum Viable Product - the simplest version of the app that achieves the core goal of the product while providing business value.
One way we’ll do that is by looking out for potentially “risky” app interactions. These are features that look simple on the surface, but can end up being time-sinks that outweigh the value they provide. We’ll think about:
- What information is required in order for this interaction to work?
- What is the relative time and effort needed to build the interaction?
- What is the value that it provides to the business or user?
- Is there a simpler way to achieve the goal?
When we identify a risky interaction, we collaborate with the client to determine the simplest solution that still achieves the goal of the feature. We may write stories both around the simple solution as well as the more complex implementation, tagging the latter story as Phase 2. This allows us to focus on the items that are core to the MVP, deferring scope enhancements until after launch.
There may be other feature ideas that come up that don’t build toward the core goal of the product. We make it clear to clients that we will challenge them on scope by asking: can the app stand on its own and provide value without these features? For our example textbook app, here are some stories that we may push back on:
Student adds textbook to favorites list
Student rates textbook
Student leaves a review
While these features will be great for expanding and maturing the app, we could still launch a textbook store without them at first. Depending on how important these stories are to the client, we will either defer the writing of these stories until needed, or tag them as Phase 2.
5. Prioritization: Putting Things in Order
Our 2-3 days of storycarding will typically provide about 6-12 weeks of stories, depending on the scope of the MVP, the number of developers, and the complexity of the work. This may not fully describe the entire product vision, but it could represent an initial phase.
We limit ourselves to that many stories at a time due to the nature of software: anything that can change usually will. In a few months, there are so many implementation decisions made along the way, that requirements written three months ago will no longer be relevant. In storycarding, we can still capture long-term goals, epics, and maybe a few basic story titles as reminders for the future.
After we’ve written the stories, we work with the client to put them in order of importance, which is the order of development. That way, we are always working on the next most important features.
Any scope that is beyond the MVP can be quickly identified and prioritized for after the initial release. If there is a strict budget, we are sure to remind the client that lower priority stories may or may not get done depending on how rapidly we progress through the backlog. The client may not have the budget for everything they want, but this empowers them to focus on what is most important. Because the stories are granular, we can easily re-prioritize or edit them if what is important changes.
We will push for the app to be released as early as possible. This allows the client to build a user base, start generating value, and begin receiving real user feedback sooner rather than later. While that is happening, we can continue to build upon that foundation in priority order, knowing that we can stop work at any point and they client will still have a working application. The client’s risk is minimized, and they have the opportunity to iteratively build towards a tool that users will truly value.
Successful Storycarding
At the end of storycarding, the client will walk away with tangible artifacts: an extensive set of stories defining the software’s functionality, ready to begin design and development.
Intangibly, we'll know that the session has been successful if we have built a foundation of trust, collaboration, and confidence with our client that we will build with their business goals and user's needs in mind. We'll have established a pattern of successful communication that will cary through to how we'll work together on the project.
