Understanding user needs

In designing our solution to the GovTech challenge, we are keeping in mind the Government Design Principles and the Technology Code of Practice. We are aware that developing a successful solution requires properly understanding users and their needs. To achieve this, we have been gathering user requirements to verify our existing assumptions and plans for our tool through face-to-face meetings with our users.

How are we collecting user needs?

In Phase 1 of the GovTech challenge, the main users of our tool are policy makers and other civil servants who contribute to policy making. To conduct our user research, we had to first come up with a list of potential users to contact. Our goal is to understand the needs of all kinds of users who are involved in the policy making process. In forming our list, we tried to include users that are involved at different stages of the policy making process to get a wide overview of user needs. Through our user research we discovered the key roles of the individuals involved at each stage. These individuals include policy makers, government lawyers and Members of Parliament. Among our list of potential users were also those involved in implementing EU legislation and we found it interesting to be able to make a comparison between the EU and UK perspective. We also considered how policy decisions and legislation might be reviewed in hindsight.

Based on our user research, we aimed to derive a user story for each individual by mapping out their user journey to ensure that our end tool will make their job more efficient. We followed a typical user research framework where our aim was to gain an in-depth understanding of their role, responsibilities and tasks within policy development. Based on the resulting user stories, we identified common challenges where we believe our solution will help and developed wireframes to verify these assumptions with our potential users for the second stage of our research.

Challenges in gathering user requirements

It was important to think strategically and prioritise our meetings in such a way that we extract as much meaningful information as possible from our potential users. We came up with a structured framework to ensure that we did not divert away from the important topics during the meetings. This framework included questions about users' roles, goals, steps to achieving these goals and the challenges they face. Asking users “why?” at every stage was crucial to gaining proper insight into their views.

We encountered a vast amount of information regarding needs of potential users in the policy process. At times we found that users with the same or similar roles in government could experience different challenges and hence this led to a more comprehensive view of possible use cases. One of the questions we asked our users was whether they preferred to see extra information (where some may not be relevant) or face the risk of not having all the information but be absolutely sure that this limited information is accurate, for example in terms of which paragraphs represent an ‘obligation’. An interesting finding was that government lawyers preferred to see extra information that they can filter, whereas policy makers only preferred to see the most relevant information first without having to filter through less relevant texts.

From our meetings with policy makers, we concluded that their user journey is not very clear cut or standardised. They acknowledge that there is a theoretical “policy cycle” but the policy development process in practice is not as systematic. Most of the steps in the process are done iteratively and users have expressed that there is a lot of “back and forth” between people and departments. We find that a lot of the answers we receive are “it depends”, which makes it difficult to map out a proper user journey that is generalised enough for each person involved in the policy making process.

We also have to keep in mind that our user base is limited and that relying on a limited number of potential users from each role as the basis for a user story may lead to bias, so our conclusions may not be widely generalisable. This is partly due to the short time frame of Phase 1 which has made it difficult to conduct proper in-depth user research. Ideally, we would have defined user stories based on a wider range of potential users to avoid bias. Despite this, we hope that getting the views of users at different stages of the policy making process will give us a general overview of common problems that can be solved to create “better regulation”.

Currently, there is no tool out there that serves the purpose of this challenge. Hence, some users find it difficult to understand what sort of solution could make their job more efficient when there is no benchmark to compare it to. It is then natural that we receive responses indicating that users are unsure of what to expect from such a tool. To overcome this, we try to help users by providing them with visualisations and wireframes based on our previous assumptions, so we can reach a common understanding about exactly what our users need.

For Phase 1, we only aim to focus on a subset of our potential users’ needs and leave the others for further exploration in Phase 2. We still derive user stories for other potential users but we keep in mind that in Phase 1, we are still trying to assess the potential of our tool as a successful and usable solution. When deciding the user stories to focus on in this Phase, we first gather the potential solutions to each user challenge and narrow down the functionalities of our end tool based on common topics of concern between users and the technical resources available to us.

To find out more about how Suade is revolutionising regulatory reporting and driving innovation in financial services, please get in touch.