Since December 2020, the Mission Platform team has been carrying out user research across the Ministry of Defence (MOD). The Mission Platform team’s aim is to deliver the next generation of cloud, productivity and collaboration capabilities for the MOD. Our initial project phase (known as a Discovery) aimed to understand and gather evidence about what users across the MOD need from future cloud services. Cloud services and networks are vital to the daily tasks of people working in the MOD for communicating, storage, and document access in a way that’s inclusive and accessible across Defence.
Government Digital Service (GDS) approach to user research
My team was made up of myself and a fellow user researcher, a designer, a technical manager and a subject matter expert. In line with GOV.UK practice, we carried out the Discovery by gathering feedback through common user research methods, including interviews, meetings, workshops and a survey.
This type of research is known as qualitative research. It involves collecting and analysing data that can’t be directly measured and quantified, such as behaviours, emotions, and opinions. This helps us understand experiences, wider problems and how it affects those within it. Topics can have multiple layers and cannot always be easily explained through quantitative methods (such as analytics).
To supplement this qualitative data, we also sought evidence to reinforce what it told us. For instance, if an interviewee explained that a policy or process had caused a delay or other blocker, or required a workaround, we asked for data or documentation to support this. This enabled us to develop case studies and show the impact and potential benefits of changes, along with proposals on how future cloud services can help the MOD be at the cutting edge of development.
We grouped our findings, user needs and pain points into themes related to:
- classifications - working at and between the OFFICIAL, SECRET and ABOVE SECRET classifications
- data - exploiting data to make insights, applications and tools, or exploiting data for intelligence analysis
- deployed - serving in deployed environments, for example Royal Navy ships on patrol
- enabling tools and services - the tools and services that allow users to do their job such as software, networks and hardware
- interoperability and collaboration - being able to communicate with and work with allies and partners, and share data and files
- systems policy and network management - ownership of the network, setting its policies, guarding network security and managing supplier relationships
We uncovered a wealth of information, and what emerged included key needs that must be fulfilled in these areas to enable users to get on with their jobs. We also found that there is often a balance – or tension – between the need to follow policies these themes relate to and the need to crack on with the job in hand.
Policies within the themes set boundaries that are designed to keep MOD systems and networks secure and functional (among other things). They often clash with the speed and desire to get the job done. The result is that users either must wait to go through the proper processes, which can lead to delays or even cancellation of plans, or users manage the risk themselves and go ahead.
Visualising our research through personas
One of our key outputs was the development of personas. Personas are ways to describe how groups of people tend to behave in certain situations or context. It’s important to note these are created to highlight pain points, user needs, key quotes and goals, along with typical job roles. As these are all key user research outputs, personas are a good way to hang findings together.
Personas come from the Latin word for mask, and it’s a good way of thinking about them – personas are not who individuals are at their core, but the mask they wear in certain situations or context. Individuals may ‘wear’ multiple personas across the day or even simultaneously, depending on the situation.
We find them useful in user research as a way of bringing together how problems and solutions affect people – we never want to lose track that it is ultimately people at the heart of what we’re trying to understand and for whom we will make improvements.
Our personas had a high correlation with job roles and because of this it helped us to not only understand users but also how they relate with each other.
In the diagram above, we use personas to illustrate the relationship between someone who owns the network – such as a chief technical officer (CTO) – and how what they provide enables others to either create tools, insights and programs that others can use. Deployed personas are the most dependent as they don’t create the network they rely on and are ultimately at the receiving end of what others up the chain have produced.
The hierarchy is just one way that personas help us understand problems and communicate our findings to others in a way that is simple and digestible. We also show how personas can illustrate attitudes. In this case cloud ‘Ambassador’ and ‘Cynic’ can span multiple roles and show how their views feed into decision making.
It’s worth noting that these personas are created only from the evidence we gathered during the Discovery. While we suspect that there are others, such as those around cyber security, as our research did not uncover them, we avoided putting in assumptions or unsupported evidence. We know that there are others out there, and have plans so that future research will uncover those.
The team is now presenting its findings to its key audiences and working with teams in related areas to ensure that findings are shared and fed into relevant projects. Personas are a useful way of tying together findings into a simple format that simplifies communicating user research to audiences not familiar with user research. These personas have been vital in helping communicate our outputs to a range of audiences and I recommend that user researchers consider the value of personas as a communication tool when deciding whether to create them or not.