Considering user stories, personas and workflow process maps

 

It is important to incorporate future state user experience when defining requirements for a new system or technology. This includes mapping how it integrates with existing workflows.

There are a number of user experience design tools to support this process including personas, user stories and workflow process maps. These tools help an organisation to understand the model of care from the user perspective, how it will be day-to-day and how it will fit in with user workflows.

Workflow process maps should cover both the current state and future state models to identify potential gaps early and support the prioritisation of work.

Personas

Personas are fictional people that represent the users of the system or technology being purchased. Although they are fictional, they are based on the real needs of users to ensure an accurate account of how the system or technology would be used.

How to develop a persona

1. Interview a range of sources to help build an accurate profile or the user.
2. Give your persona a real name for example: ‘Alex’.
3. Include a photo to humanise the persona and bring it to life
4. Write an overarching quote that summarises their experience, for example: “I am overwhelmed by the administrative burden of my role”.
5. Include a short demographic profile, for example: ‘39 years old, male, married with 1 child, Master’s degree in physiotherapy. Alex works full time in a team leader role in the Oncology department.
6. Outline the personas frustration/s, for example: “Alex finds the current electronic Medical Record (eMR) clunky. He spends too much time navigating the eMR, taking time away from patient care. Using the current eMR creates more administrative work due to its lack of interoperability with other systems.”
7. Summarise the personas goal/s, for example: "Alex wants a system that is intuitive, able to access existing data from other systems, reduces duplication of data entry and supports more accurate collection of real time clinical information for better clinical decision making.”
8. Avoid jargon and break down complex information to ensure the persona is easy to read. 

Benefits

The procurement team will benefit from personas, as they are typically built from a range of interviews with various sources and provides representation for each user group.

A well-researched collection of personas allows the procurement team to understand:

• problems experienced by users
• typical user needs and desires,
• the emotional drivers of users, and
• the priorities of users.

Personas help the procurement team overcome biases and focus on the diverse expectations of users. They serve as a mental anchor during a procurement process, especially when prioritising requirements without the full representation of all user types. Having a set of personas on hand ensures all user needs are considered and supports the finalisation of requirements.

Including requirements that address the needs of all user groups helps achieve a good user experience, increasing the likelihood of successful implementation.

User stories

User stories focus on how the user will interact with the functionalities of the system or technology being purchased. They are short, simple descriptions of the system from the perspective of the user and are used to create discussion about a functionality, to help define descriptions of the requirements.  

To develop a user story describe:

• who the user is (based on the persona);
• what they need, want or expect from the system;
• what the benefit is / why it is important;
• acceptance criteria (refers to a list of outcomes that can be used as a checklist for the procurement team to verify).

Suggested format

A simple format to follow is:

As [who], I [need/want/expect], in order to [benefit].

[Insert acceptance criteria].

Complete the user story with a list of acceptance criteria. Pre-defined acceptance criteria ensure the system or technology meets the requirements of each user story.

View our user story examples.

Benefits

User stories help to:

• create discussion on why a system and its specific functionalities are required;
• keep the focus on the outcome of the system being purchased;
• provide an alternative method for the procurement team to consider user needs outside of writing a list of requirements; and
• confirm the delivery of the user requirements through defined acceptance criteria.

Workflow process maps

Workflow process maps are a powerful tool to explore how a new system will be utilised, the impact it will have on users and whether processes will need to be modified or improved to accommodate the new system.

A workflow map is a visual representation of each step taken when completing a task. This can involve action taken, inputs required (i.e. clinical diagnostic data), outputs (i.e. clinical documentation completed) and decision points.

Types of workflow process maps

When defining requirements for a new system, there are many types of process maps that can be utilised, two commonly used process map types are:

1. Flowcharts – for a simple process:

Flowcharts use symbols to represent each process step and decision point, providing a clear overview of how a task is completed from start to finish.

Commonly used symbols

Example flowchart

2. Swim lane chart – for complex processes that involve multiple roles, departments or individuals:

Swim lane charts utilise the same symbols as a flowchart, but they divide process steps into lanes to represent the responsibility of each step across different roles, departments or individuals involved in the workflow. 
Swimlane charts show how team members impact each other, for example when there are delays. They also help to identify any duplication of work across the team.

Example swim lane chart:

Benefits

Workflow process maps are essential for clarifying processes, identifying opportunities to add value and eliminate duplication or unnecessary work.

Clinical may not be aware of the complexity of their workflows or areas of improvement until they are documented. Creating comprehensive maps for all users and shared processes ensures a clear understanding of workflows and how a system or technology should function to support them.

To optimise their value, develop ‘as is’ (before) and ‘to be’ (after) maps with users. This allows them to design improved workflows and suggest ways a new system or technology could streamline workflows.

Insights from these maps can help define new requirements of the new system or technology. A new system or technology should maintain or enhance the current workflow efficiency without adding complexity or extra steps from clinicians.