Runners, repeaters and strangers on the internet
Over the last few years, the digital communications team has changed a lot – we are now committed to an Agile project management methodology, we retrospect regularly and plan comprehensively. Fundamentally, our thought process about the way we work has changed, and that, in no small part, came about because of colleagues in St Andrews’ Lean team. One of the tools that the guys from Lean equipped us with was the idea of runners, repeaters and strangers.
Introducing runners, repeaters and strangers
Originally, the ‘runners, repeaters and strangers’ technique was used to improve efficiency in the context of manufacturing. The idea is that all tasks can be separated into one of three broad categories:
- Runners – standard processes which are carried out frequently, are highly predictable, consistant and usually efficient.
- Repeaters – processes which are still predictable but less frequent and less efficient.
- Strangers – processes which are highly customised, rarely occurring and often require a high level of resource to undertake.
By identifying which processes are runners, repeaters and strangers, manufacturers can gain a better understanding of where they should be concentrating their efforts. It’s usually best to design systems around the runners, then consider the repeaters and have a plan with how to deal with strangers.
Runners, repeaters and strangers in digital projects
The idea of runners, repeaters and strangers stuck with us when we started work on our external website project. We have a commitment to user centred design, which means that we need to consider the needs and aims of users when they come to the website when we’re designing pages and content. However, considering that the website is visited by millions of people every year, with a huge number of different needs, this can be a big task!
The approach we take to understand user needs involves writing out user stories for each user group we identity for a section of the website. These user groups could be prospective students, or alumni, or the local community for example. Within each user group, we write out all of the different user stories we can think of, in the following format:
As a…
I want…
So that…
For example:
As a prospective student
I want to know what the entry requirements are for my courses
So that I know what grades I need to achieve in order to get into St Andrews.
Creating these user stories is usually quite an interesting task, but can lead to a large number of user story cards. In order to make them more manageable, we try to group them together into themes. All of the stories about fees and funding might go together, incorporating tuition fees, accommodation fees, scholarships, other financial support and how to pay fees. After all of the stories are grouped together, the digital communications team will sit down with the project stakeholders to work out how important each user story is.
However, one issue comes up again and again – project stakeholders often think that every user story is important! This makes it more difficult for the digital communications team to prioritise the work that needs to be done, and to create a simple, understandable information architecture. This is where runners, repeaters and strangers comes in.
Runner, repeater or stranger?
When we take each user story, we work with the relevant stakeholder to ask how frequently they’d expect this user story to occur. If the answer is that the user story is very common, predictable and often the same answer can be given to multiple users, we suggest that this user story is a runner. We generally think that around 75% of tasks that take place on the University website are those of runners: they include things like ‘As a prospective student from England, I want to find out how much tuition fees are, so that I know how much I will pay for my degree’. Here, the user may change, but the task is repetitive and common. When it comes to designing new products and sections of the University website, we are designing for the runners – the vast majority of users whose tasks we are easily predict and provide a response to.
However, there are still a lot of user stories which don’t fall into the runner category. If stakeholders tell us that a user story is still predictable and they know that there is a standard response to it, but it happens far less frequently than the runner tasks, we suggest that it may be a repeater task. These tasks probably make up another 20% of the tasks that happen on the University website – and they are often similar but more specific versions of a runner task. For example: we’d class ‘As a prospective student who goes to School in America but has a British passport, I want to find out how much tuition fees are, so that I know how much I will pay for my degree’ as a repeater user story. It’s something we know is often asked, but the answer is more complicated than the related runner task outlined above. We usually consider the repeater tasks when planning and building digital projects, but they are usually secondary to the runner tasks.
Finally, there are some user stories which are highly infrequent, complicated, new or unknown. like These are the tasks we call strangers. We generally try not to plan or build new projects based on these users and tasks. An example ‘stranger’ task may be ‘As a prospective student who has dual nationality and an offer of a scholarship, I want to find out how much I will pay in tuition fees, so I can find out how much I will pay for my degree’. The specific nature of this inquiry means that unless we build very niche products, this user is not going to be able to find the information they’re looking for online. In most instances, even if they do find a webpage, they would still need to engage with a member of University staff to get a full answer to their query. We believe that only around 5% of tasks attempted on a University website are strangers.
Here, all three users wanted to find out the same information for the same reason. However, their differing situations mean that for some finding the relevant answer online would be easy, whilst others would likely have to contact the University even if information about their situation was available. This is why we don’t recommend creating web content for every single variation or possibility when it comes to user stories – some tasks are just much more difficult to undertake online.
Benefits of identifying runners, repeaters and strangers
The digital communications team often work with people who are experts in their specific area, and have experienced a wide range of users trying to complete tasks. One of the issues of asking stakeholders to write user stories is that people often create user stories for tasks which happen very infrequently, or where the task is complicated, and these can make it hard to establish how a new product should work for the majority of people. By asking stakeholders to think about how frequent, standard and predictable each user story is, they can start to prioritise which tasks must be available to complete on the new product, and which tasks could be removed from the product entirely. This not only makes it easier for the project team to build the right product in an Agile manner, but also helps us understand the area of the institution we are working with.