Loading...

user storiesUser Story Mapping or User Stories is a technique that focuses on flushing out details or use cases that are tangential to the main focus of any online activity.

As an example, when we think of a checkout process, we typically think:

  1. Find an item
  2. Add item to cart
  3. Go to checkout
  4. Purchase

Although this workflow is correct, there are numerous tangential use cases that aren’t reflected here and overlooking those use cases can lead to user issues. 

Say, for example, a user checks out, but then remembers they have a promo code they forgot to apply. Where in the workflow can a user go back and add that? Or, perhaps a user wants to go back and edit their order, or add a new item after they’ve received their order confirmation. That’s also not reflected in the initial check out process. 

When we typically think of a use case, we may think of the critical path, or most direct path, a user might take to complete an action. However, by applying user stories, that path turns into a tree with branches that comprise nuanced use cases that have varying degrees of value that can be added to the interaction.

Although , sticking to the checkout scenario, plugins and modules can take care of some of these use cases for us. There may be additional custom work that needs to be done to accommodate use cases that are unique to a particular build. By applying a user stories technique, we can flush those out in detail and assign a value to each of them, so it can be objectively determined, based on a level of effort, if it makes sense to incorporate that additional work into the initial delivery of the product. 

What does this mean to me as a project owner, though?

As a project owner, there was very likely an initial understanding of how a specific component or process of a build would be put together. There may have also been some discussions surrounding additional functionality based on internal experiences or pain points that should be addressed. 

Those pain points would typically get identified during the discovery process and translated into the build documentation.

The difference with user stories is the introduction of a brainstorming component that can identify numerous off the beaten path use cases. But even more critically, you can identify a scalable product for release, and then release that product in phases depending on how the build of the site goes.

A scalable product is one that has a minimum viable product, typically what is identified in discovery, but also has additional use cases built on top of it. Those additions are then structured in a certain order based on added value, priority, severity so that they can make a certain component or process scalable. We can start small with the essentials and then add the additional layers if the project teams agree it would be valuable and if budget and or time can be recovered elsewhere in the project.

In short, user stories are a holistic way of thinking through various components and processes that can add value to the user experience in a scalable way. Rather than a focus on completing a minimum viable product and improvising based on feedback, the additional layers of utility can be identified and discussed more completely, and then rolled out in a scalable and controlled way.