Translating User Stories into Design Inputs

You’ve spent the time interacting with your stakeholders, discovering what is important to them. Now comes the perilous part – how do you take what you have heard and observed and translate that into the language of engineering – without losing track of the heart of those needs? How do you keep from ending up with features nobody wants and solutions that don’t satisfy?

The answer is to begin the design process by defining user stories for each user group, and then translating the stories primarily into design inputs (i.e. system requirements or product requirements), or secondarily into architecture, plans, or processes. Following this process ensures that the needs of the user(s) and stakeholders are accounted for in the design and a minimum viable product is able to be reached.

USER STORIES

User stories are a concept taken from Agile methodology but are used differently in the context of medical device design. A user story depicts who must complete a certain task and why, based on the user’s workflow and overall goals. They should be identified from the start of the design process to give background and help stakeholders know where decisions and discussions are coming from. User stories don’t need to be technical, explaining in detail how a certain task is performed, but rather the emphasis should be on the motivation behind the user’s task. Is the user under a time constraint? Is there a specific mental model that the user is driven by? These are important questions to ask to uncover the “why” behind a user’s actions.

A typical structure for a user story follows:

“As a [user group], I need [desired feature/functionality of product] so that [the “why” for the need].”

QUICK TIPS FOR CREATING USER STORIES

• Discuss user stories before identifying design inputs so that the product goals are defined to meet the user’s needs from the beginning.
• Remember the entire lifecycle of the product – this may include shipping, disposal, manufacturing, etc. – and be sure to include the people involved at each of those steps in the user stories.
• Don’t put more than one need into a single user story (i.e. “this user needs this, this, and this…” should be 3 different user stories).
• Give yourself time and quantity constraints while writing the initial user needs so it does not become an endless task. Typically, under 40 user stories are sufficient to capture all the needs of the product. At this point, you are trying to document the heart of the needs, not define every aspect of the product’s use.
• Avoid adding the “would be nice” items. Limit yourself to considering items that let you meet the minimum viable product.
• There may be multiple user groups, so separate the user stories based on type of user.

QUESTIONS TO GUIDE USER STORY DISCUSSION

• Who is going to use the product?
• Who are the different stakeholders of the product?
• What are the users’ goals at a high level?
• What are the technical constraints?
• What problem are you trying to solve?
• Where is the product going to be sold/used?

GOOD VS. BAD USER STORY EXAMPLES

As a user, I need a setup wizard so that the setup process is easy and efficient.

This is a bad user story because the need of the user isn’t captured, but rather a solution of implementing a setup wizard is given. It’s possible that a setup wizard is the best solution for this user’s need, but a user story shouldn’t identify a specific solution from the beginning. Perhaps a team freed from this imposed constraint could come up with a solution so intuitive and easy that a setup wizard isn’t even necessary. Instead, consider the real need, which might be something like “As a user, I need to be able to set up the system within X minutes without referencing any other aids so that I can get to using the device quickly.”

As a user, I need the device to be easy to use so that I don’t need to look at the manual.

Again, this is a bad user story because it mainly gets at the user’s feelings, which isn’t the point of a user story. Further, there is no information on why the user doesn’t want to look at the manual. For example, they could have limited time or limited arm availability, which better defines their “why” for needing the device to be easy to use.

As the company, I want the cost of goods sold to be less than $X so that I can achieve Y% return on investment.

This is a good user story that stems from a specific business need of the company creating the device. It is important to remember the company as a potential support user and let their business needs drive their user stories. Note that this user need is an example of a need that is not a good candidate for tracing directly to a system requirement (it does not relate to the safety or efficacy of the system), but rather informs project goals and possible architectures. It is nonetheless important to understand and incorporate, as it forms a very real aspect of the success or failure of the product.

DESIGN INPUTS

Design inputs are what the system must do to help achieve the user’s need, that is, to fulfill the user story. In some cases, the system is the perfect way to accomplish a user’s goals (i.e. pumping a certain rate, achieving a specific temperature, etc.), leading to the generation of system or product requirements. However, in other cases, the goals may be more appropriately covered with other aspects such as a specific architecture or how the project is executed (the plans and processes set in place), so be careful when delegating how each need is fulfilled in the design.

SYSTEM REQUIREMENTS

System requirements (or product requirements) stem directly from user stories and describe what any viable system must do to fulfil the need. A requirement is typically written as follows:

“The system shall… [whatever the system must do in order to fulfill the desired need or task].”

It is important to remember that system requirements should solely address a need that the system can fulfil, rather than a solution that describes how the system should be designed. Requirements are not features or specifications, so avoid the common mistake of jumping to an obvious solution too early and making it a requirement, consequently eliminating all other solutions that could fulfill that need (and possibly fulfill the need in a better way!).

USER STORY → DESIGN INPUT

So, how do you translate user stories into design inputs? First, recognize that it is not always a 1:1 translation between user stories and design inputs. User stories tend to be broad, sometimes resulting in many different requirements that are all necessary to fulfill a single user story.

Keep in mind which user group’s goal you are designing for at any given time. Is it the company? The primary user? By focusing the design on the critical user’s goal, you can minimize testing costs, requirement writing costs, and wasted time. Design inputs are often brainstormed with no background information on what the stakeholders or user desires for the product, which results in a multitude of design inputs being implemented that are not crucial to the user’s or product’s goals.

WHAT HAPPENS WHEN USER STORIES ARE NOT USED IN DESIGN INPUTS?

Many undesirable scenarios may result from not allowing design inputs to be influenced and driven by user stories. These scenarios may include:

• The design ends up with many “cool” features that engineering or marketing liked but nobody uses (because it doesn’t fulfil a need!)
• Excess testing and parts for those unused features, with testing costing exceeding the initial estimates
• Missed opportunities in the marketplace while you perfect something that no one wants
• You lose the opportunity to respond to changes in the user’s expectations, resulting in only incremental product improvements instead of true innovation
• Since there’s no tie back to the user’s actual desires, team members may have divided or different goals for the product, and no means to determine who should ‘win’ (other than office politics…)
• If the team’s assumptions about users are not uncovered up-front, blind spots may remain, resulting in the design not including important aspects that are necessary for safety and effectiveness

SUMMARY

• User stories are essential for generating, filtering and prioritizing design inputs and help better define the product being designed.
• Design inputs are most often system (or product) requirements, but the needs exposed through user stories, business needs and brand identity needs may also be absorbed through architecture, or the plans and processes set in place.
• System (or product) requirements do not give solutions, but rather give a general requirement, that if satisfied – regardless of how – would fulfil the need.
• The translation of user stories to design inputs is not always 1:1. Multiple requirements may be necessary to fulfill one user story.
• Overall, the process of defining user stories, asking questions about the intended user group(s), and identifying the user’s needs helps define the “why” behind each design input, resulting in a minimum viable product.

Tensentric is a team of highly experienced engineers developing a wide range of medical devices and in vitro diagnostic systems. Tensentric has completed over 300 development projects for clients in the medical device and IVD space since the company’s inception in 2009 and is ISO 13485:2016 certified for design and manufacturing.