User Stories: Why User Perspectives are Essential to User Experiences

To most non-designers, the term ‘User Story’ is unheard of. But within the world of design, user stories are the backbone of a successful implementation. User stories can be defined as self-contained units of work created with the intent to accomplish a specific goal within a product. 

User Story Examples 

A user story is written from the user’s perspective and follows the following format:

As a [user persona], I want to [perform an action] so that [I can accomplish a goal]. 

User stories can be described as an iterative approach towards product development that helps teams bring value to their customers faster. By using this approach, we shift the focus of design documentation from the requirements of the project to the needs of the user. For example: 

As a [Contractor] I want to [Enter time each week against activities and activity types] so that [I can get paid for my work at the end of the month].  

As an [Clinic Admin] I want to [Enter new patient records] so that [I can access a patient file conveniently for future encounters].  

As a [Supplier] I want to [Fill out a Shipping Notice form] so that [I can inform Buyers of when their shipment will arrive]. 

The User Persona 

When reading these user stories, you can see that each story takes on the role of the intended user. This is what designers call a ‘User Persona’.  

A user persona is a semi-fictional character usually based on an existing or ideal customer. Personas are developed within the process of product research and segmentation of user demographics. The exact persona is always specified before the product requirement is created, because the user is the most crucial element within the statement.  

By putting ourselves in the shoes of the user, we can communicate what a user needs from a product and why.  This is important within the design process. And while the action of writing user stories does not take place at the beginning of product development, it remains critical for its success towards the end.  

User Stories and the Design Process 

The design process requires many iterations and listening to potential users is crucial when making changes and improvements. But it is not enough to just listen to the user. As a designer, you must look at the product from the perspective of someone facing the application upfront for the first time. Questions to consider while writing stories include the following: 

• What background knowledge does the user currently have? 

• What knowledge do I need to provide the user within the design with to be successful? 

• What does the user consider to be important when interacting with the product?  

• What are some barriers to success for this specific user?  

• Would the user feel frustrated when using this application?  

The design process seems linear enough at first glance. So, where do user stories fall within this already established guideline? The answer to that is not straightforward, as there is no exact rule in place for when the user stories should be completed, but it is recommended that they are completed prior to development. User stories are usually done after most of the elements of the design have already been established. 

User Scenarios to User Stories 

User stories are easier to read compared to product requirement lists. For example, an application for a user within a warehouse needs an error message to appear when they select more items than listed within inventory. A product requirement list would look like: 

• Feature Name: Error Message 

• Appearance: Rectangular box with icon 

• Reason: Quantities selected are unavailable. 

The user story for that scenario would look like: 

As a [Warehouse Employee] I want [To be informed by a pop-up error message when the product quantity I have selected is unavailable] so that [I know what is within the inventory capacity]  

While both are listing the same information, one is written in a user-friendly format while the other is simply a list of information to skim through about a design. A user can feel important after reading a user story, as they are informed that the designer will always have the user perspective in mind through every stage of the project. 

Mockups and User Stories 

Since user stories are short and easy to write, they can be edited and added to as required. Instead of having to sit down to work on a lengthy list of requirements, the designer can simply write as they go along with their tasks. Since they only consist of 1-2 simple sentences, there is a user story written about every working element within the design.  

Having a functional prototype will make it easier for the designer to develop a story based on what they see within the prototype, whether it is high or low fidelity in design. The product will continue to evolve, and edits will be completed throughout the entire process. 

User stories are critical for the development of an application by providing additional details over and above the visual design. The result of user stories is an itemized list of functionality and features that will be delivered in the development phase.  

Benefits of User Stories 

Developers can look back at their user stories to get a sense of how much of a project has been completed. The client is informed of where they are at and they are then able to prioritize, organize, and scope. Not everything will fit into the first release, and the user stories will help them be aware of what features they can implement.  

Still not convinced that user stories are the way to go? The list below summarizes every benefit of using a user story within your design project. At ConvergentIS, we would argue that user stories:  

• Tend to be easy for anyone to understand 

• Indicate the level of progress for designers and developers 

• Are personalized to the specific user experience 

• Represent deliverables at a bite-sized level 

• Help designers focus on their audience 

• Spark conversations between designers and users