A guide to doing user research for beneficial ownership systems

Part two: What you need to do and when you need to do it

User research is not just about testing your system after it has been built. Instead, you should conduct user research early and at every decision-making and iteration point that affects the design of the BO register and its forms.

There are three main phases to building any high-quality digital service, which can be broadly defined as:

1. gathering requirements;
2. designing and testing a solution;
3. preparing for launch, release, and continuous improvement

User research is essential during every phase, but what you want to learn and who you want to learn from might change throughout. This section outlines what sort of research you need to do during each step of the process.

Phase one: Requirements gathering

When you are at the beginning of developing your register, before building anything or even defining your BO register’s feature requirements, you need to understand user needs and gather your requirements.

In this stage, also known as the Discovery phase, research is one of your most important activities. The goal of research is to learn more about your users, their goals, and what they need from your BO register in order to achieve these. This needs-finding discovery research will help you make decisions on which features you should prioritise.

Ideally, you will have a couple of members of your development team devoted just to research at this phase.

One of the most important goals of the discovery phase is identifying your users

“When designing a government service, always start by learning about the people who will use it. If you do not understand who they are or what they need from your service, you cannot build the right thing.”

— Gov.uk Service Manual

Users of BO registers will normally fall into one of the following three categories: declarants; data users; or administrators.

Declarants

The first users of your system will be the business owners, employees, or agents who need to report BOI on behalf of an entity. A system designed without their needs in mind is very unlikely to be effective.

Remember that the needs of businesses will likely differ depending on a number of factors, and you should try to speak to different types of reporting users, including:

• a range of entity types, especially if their reporting requirements differ;
• businesses of different sizes and ownership complexity;
• foreign business owners or representatives;
• agents or intermediaries who might report on behalf of a business, for example, lawyers, accountants, or trust and company service providers;
• non-profit organisations or foundations;
• third-party software providers used to make declarations;
• future business owners.

Data users

The reason for asking declarants to report information is so that people can use it. Who can use BOI depends on the access granted by your country’s legislation. Who should be using BOI should be informed by the policy goals of your reforms – if you are building a BO register in order to reduce corruption risks in public procurement, you are going to want to talk to procurement teams. Make sure you have a clear picture of why these reforms are being enacted.

Examples of BO data users could include:

• Government:
  • law enforcement;
  • tax authorities;
  • procurement authorities;
  • licensing authorities;
  • competition authorities;
  • anti-corruption authorities;
  • financial intelligence units.
• Civil society:
  • investigative journalists;
  • civil society organisations;
  • business journalists;
  • academics.
• Private sector organisations:
  • anti money-laundering bank compliance officers;
  • other financial institutions;
  • data service providers who create value-added services on top of the data.
• The public.

Administrators

Your users will not just be external – some countries choose to include a stage in the BO declaration process where officials review declarations and approve them, or request additional information.

This means some of the heaviest users of your system might be government employees charged with administering the BO register.

This list is not exhaustive; you should take the time to consider if there is anyone else who will be using your service.

The next step is to identify your research goals

Your research goals will guide the research you conduct with your different user groups. Some recommendations on the types of goals you might want to set during the discovery phase are detailed below. Don’t forget that the answers might differ significantly between different users within the same group, so ensure you speak to a wide range of potential users.

As part of identifying your research goals, it is important to interrogate what assumptions you are making as you go into the project, and ensure that these assumptions are tested through your user research. For example, you might assume that employees of a company know who the company’s beneficial owners are, but this might not be the case.

Declarants

Understanding of the law

How well do the declarants understand their obligations to report BOI, including what information, where, and when to report? Where and how do they learn about compliance obligations? How do they comply with other current compliance obligations with your agency or other government agencies? Do they use agents? Does this differ between different types of declarants?

Business processes

Who will be responsible for making BO declarations on behalf of the organisation? How does that person know how to identify the beneficial owner and any further information they need to declare? How will the correct people know when information has changed and needs to be updated? What software or tools does the user currently use for storing, sharing, or submitting business information? What internal approvals might the declaration need to go through in order to be finalised?

Interactions with existing services

What existing interactions do declarants have with your agency (if any)? What do they like or dislike about these current interactions? What pain points do they have? Do users prefer to interact with your services online only, or would they rather interact in person as well?

Data users

Purpose for wanting access to BOI

What are the goals of using BOI? What type of questions will the users ask? What answers are they hoping to get? At what scale and on what timescale are they asking these questions? How likely are these questions to evolve along their journey using BOI, and what would that change in terms of their needs? Are the users interested in looking at patterns or at specific entities and individuals?

Data formats and structure

What types of information are most important to achieving these goals? Do data users need to connect with each other? What sources of information and data analysis tools do they currently use? Do they require access to information on a record-by-record basis, in bulk, or via an application programming interface? How technically suited are they? Do their use cases require constantly updating information, or just a snapshot in time?

Administrators

Business processes and existing services

What tasks are administrators required to do already? Where do their responsibilities for BO declarations fit within those? What is their risk appetite? Do they need to look at all submissions or only a subset? If a subset, what is this based on?

“Ideally, you want user research involved before legislation – the way people write legislation often means you can’t do good service design. For example, legally you have to have a statement with this exact wording, but no real person understands it”

— Anonymous user researcher for a BO register

During the discovery phase, use methods that help you understand your users in depth

Field studies

Whilst all user research methods can lead to valuable insights, field studies are a powerful tool for learning about BO register users.

Field studies involve observing users in their natural environment – visiting them in their offices, for example – to understand how they interact with your current services or, if you already have a BO declaration service in use, to see their processes in interacting with it.

Field studies are invaluable for uncovering unarticulated needs and observing real-world usage patterns and challenges. They provide deep insights into the context in which registries are used, including factors that influence user behaviour and decision making. This method is particularly useful for gaining a comprehensive understanding of complex workflows, environmental constraints, and the socio-cultural dynamics affecting user interactions with the register.

Although field studies will get you valuable, in-depth information, they also require more resources than you might have available.

User interviews

User interviews are one of the most popular user research methods, often used in the discovery phase of a project. This is a relatively simple yet powerful research method, where the interviewer meets with participants one on one to ask them questions about a topic, listen to their responses, and follow up with further questions to learn more. User interviews are very helpful in learning about user needs at the outset of a project and in generating ideas and answers about which way to go. The findings from this research can help you define the strategic direction of your BO register.

Whilst it’s very important to put aside time specifically for research – especially when gathering your requirements – if you are especially pressed for time or resources, you might be able to leverage some existing interactions in order to conduct some light user research. This could also reduce the time commitment required from your users.

At this stage, you might already be conducting some stakeholder workshops with other government departments or businesses. These might be feeding into legislation or be part of wider engagements on the reforms. If so, try to allocate time to have one-on-one or small group discussions with attendees and dive deeper into their needs, experiences, and challenges. Make sure to document these and share the findings with your development team.

Surveys

One popular research method is the survey. This is a set of questions that you can send to a representative sample of your users or potential users. Surveys can be very useful in quickly understanding a large number of people’s views; however, these won’t be very detailed. You can ask open-ended questions in a survey to collect more detailed views, but it will take additional time to code and analyse people's answers.

You could use surveys to validate findings from your interviews. For example, if you found through interviews that some of your users do not understand their obligations to report BOI, you could commission a survey of businesses to see how universal this issue is. A survey of data users could help you get a representative picture of what the most preferred data formats are amongst your user base.

Your discovery research informs how you design your service

It’s all very well to conduct your research, but it’s also important to use it. This article includes useful guidance on how to analyse qualitative data from user research.

Once you have collated the findings from your research, it will be time to use them to inform the design of your services. Discovery research should feed into all of the decisions that you make at this time – for example, who is able to access the system; what information is asked of declarants; how information is asked of them; what collaboration is possible between users; and how information is made available to data users.

Phase two: Design and testing a solution

Once you have completed your discovery phase, you should have a good sense of your users and their needs. This will create the foundation for your next steps: you have come up with a direction for a solution based on your research and can now begin actively designing.

Once you have design concepts or a working product, you can employ research methods to test your solution and see if it is on the right track.

The goal of research during the design evaluation phase is to test the designs to see whether they work for your users, where the designs fail, and what the problems are. In this phase, you should aim to:

• understand users’ experience with the BO register (or design concepts or prototype);
• find out which aspects of the BO register (or designs) need improvement in order to meet users’ needs.

You will want to do this through both qualitative and quantitative means. The goals of testing are to validate conceptual fit; evaluate the usability of the design; and ensure they match user expectations.

Begin testing to refine your concept as soon as you have initial design ideas or low-fidelity wireframes. Then, as you get further in the design and development process, progressively test more refined versions of the system. This step-by-step method ensures continuous improvement, allowing for iterative feedback on the design and functionality of the system.

During this stage, you should have a fairly balanced team, with some focusing on designing and developing solutions, and some on continuing to do research with users and testing designs with them. You should try to have at least one member of your team devoted solely to user research.

User research carried out at the requirements gathering stage will produce insights about user needs, which will then be analysed to produce assumptions about what requirements will meet these needs. Research goals for design should be to test these assumptions. Therefore, the type of questions asked at this stage will depend on decisions made previously. Outlined below are example research questions for different user groups.

Declarants

Can declarants complete your form accurately and within a reasonable timeframe? Do they understand the terminology you are using? Can they collaborate with colleagues in order to complete their task if necessary? Do they find the process frustrating or simple? What questions do they have about how the information will be used?

Data users

Can data users find the information they are looking for? Are they able to use this information to complete the tasks they need to? Do they properly understand the information that they are presented with? Is all the information they need available?

Register administrators

Are register administrators able to identify the items they need to take action on? Are they able to take those actions? Are they able to escalate any if necessary?

Usability testing is your tool to understand whether your solution works for your users

Usability testing

Usability tests are a way to conduct evaluative research to validate your design concepts, test your prototypes, and see whether your BO register is on the right track. Your research findings will inform strategies for change and enable your team to implement user feedback, making your BO register much more usable and likely to succeed.

Usability testing is appropriate at any point after the discovery phase. In order to improve and optimise the register, usability testing should be employed at all levels of your BO register’s development – as soon as you have some designs until long after your register’s initial launch. In usability testing, participants think aloud as they interact with a prototype or the live register.

Usability tests are most often moderated, similar to user interviews, where the interviewer meets with participants one on one. However, depending on your resources, unmoderated usability testing is also a potential research method. This would involve recording users interacting with your service without you there to probe or ask questions, and instead analysing the recordings after they are finished.

You can give participants three types of tasks in a usability test: verb-based tasks, scavenger hunt tasks, and interview-based tasks.

• Verb-based: All of the tasks begin with a verb and ask participants to complete a specific action.
  • Example: “Submit your business information.”
• With scavenger hunt tasks, you ask participants to find a specific piece of information. These tasks help evaluate whether users can easily find and understand the content. The tasks almost always begin with the verb "find".
  • Example: “Find the beneficial owners of Usability Systems, Inc."
• With interview-based tasks, at the beginning of the test, you interview participants to get a better idea of how they use the register. You would start by asking the participants specific questions that can give you a good sense of how the register works for users in the real world.
  • Example: “Show me how you usually use the BO register”, or “Show me how you look up a business’s ownership information in the register”.
  • You might also probe participants’ expectations about how a feature should behave or where it should be before asking them to do a task. Example: “If you were looking for business information, where would you expect to find it?”
  • You might also ask participants about their experience near the end of the session. Example: “Please describe your experience with the register”.

Through usability testing, you can validate (or invalidate) your design direction

You can learn to what extent your users are able to accomplish their aims (as well as yours), and what improvements you need to make to your BO register.

Examples of what you might learn through testing:

Testing your designs before you publish them is important: it is better to test before you go live than to find out later that your solutions don’t work for the majority of your users!

Even if you don’t have enough resources to do lots of rounds of testing, you could try to leverage some existing interactions to get some basic testing done, for example, through peer learning and consultations with businesses.

• Peer learning sessions: You might attend some peer learning sessions and conferences with representatives from other countries or sectors who have undergone similar processes. Ask stakeholders to swap forms and fill out each other’s. This way, you can capture real-time feedback on usability, even from a small pool of just two participants.
• Consultations with businesses: Your team might have already planned some time to sensitise businesses or raise awareness about upcoming reforms. Try to find some one-on-one time with representatives from a few businesses to test your solution with them directly.

Sharing your research insights is as important as conducting the research

Communicate your research findings to your entire team and all your senior stakeholders, including those on the BO policy side. This is crucial for strategic alignment, informed decision-making, and any resource allocation, at both the discovery and design testing stages. Video clips of users describing in their own words what their needs are, or how a feature is confusing to them, can be very powerful.

“That’s the selling point of user research – data. If you’re just talking, you’re no different than anyone else. If I say we tested this form with 20 people and 80% of them failed… Generate your own opinion based on that!”

— BO register user researcher

Communicating research findings will ensure buy-in and alignment from the stakeholders on design choices; equip them with the user insights needed to make informed decisions about the BO register or policy changes; and foster a user-centric culture.

Communication of research results must be honest, reliable, and credible. It’s best to make your results as transparent as possible.

To effectively communicate user research findings to senior stakeholders, your presentation must be clear, concise, and focus on actionable insights. Some strategies to consider include the following:

• Summarise key findings: Start with a clear, concise summary of the most critical insights. Senior stakeholders often have limited time, so highlight the most impactful information upfront.
• Connect to policy goals: Link your findings to the broader objectives of the BO policy. Explain how understanding user needs and addressing them in the register can drive successful adoption of the policy, such as increasing compliance.
• Show real user stories: Include participant video clips and direct quotes (with consent, and without personal identifying information, such as names). Real user stories can be powerful in making the findings relatable and emphasising the human aspect of user research.
• Recommend actions: Don’t just present problems; offer solutions. Clearly outline recommended actions based on your findings, and explain how these actions can address the identified issues or opportunities.
• Prioritise recommendations: If you have multiple recommendations, prioritise them based on their potential impact and feasibility. This helps stakeholders focus on what’s most important.
• Prepare to answer questions: Be ready to dive deeper into your data and research methodology if asked. Senior stakeholders may have questions that require you to justify your findings and recommendations.
• Follow up: After the presentation, provide a written summary and be available for further discussions. Sometimes, questions or ideas arise after stakeholders have had time to reflect on the information presented.
• Measure and report back: When possible, measure the outcomes of implemented changes based on your research and report back. This demonstrates the value of user research and supports future investment in it.

Effective communication involves tailoring your message to your audience’s interests and needs; focusing on actionable insights; and linking the value of these insights to achieving the BO policy’s goals.

Phase three: Preparing for launch, release, and continuous improvement

Once you have a tool that meets both user expectations and legal requirements, and has passed any internal controls, you are ready to launch! But remember, after launching the register, you need to continue to listen to users and improve your service. We recommend ongoing listening methods for continuous research and improvement.

The goals of post-launch research are to understand how well your register is performing in real-world conditions; assess how well it continues to meet user needs; identify opportunities for improvement; and make changes as needed. In this phase, you should aim to:

• observe how users interact with the BO register in real-world conditions;
• obtain feedback on which elements of the register are and are not working well;
• identify problems and opportunities for improvement in user experience.

As long as the register remains operational, continuous feedback collection and user research are vital for iterative improvement to keep your register useful, impactful, and relevant to users over time. As user needs evolve and the business landscape changes, the BO system should adapt and grow. Regular post-launch assessments will inform ongoing updates and feature developments, ensuring the BO system remains effective.

Once again, insights from the discovery phase about users’ goals and needs will be a useful reference to assess whether your system actually enables these goals to be fulfilled. Similarly, it will be important to monitor whether improvement decisions you made based on the design and testing phase have produced the intended impact on users’ experiences, and in a sustainable way. Therefore, the type of questions asked at this stage will again depend on decisions made during previous phases.

However, research is not the main focus of the team post-release. Whilst it is still very important, you might find that you can reduce the amount of research the team does at this stage – especially if you have conducted thorough research during the previous phases. You might find that one part-time researcher suffices now rather than having multiple full-time dedicated researchers on your development team.

User analytics

One thing that can also be very useful at this stage is to collect user analytics.

User analytics give you insight into how your register is actually being used. You can use analytics tools, like Google Analytics, to passively collect large amounts of data about users’ interactions with the BO register. Then, you can analyse this data to better understand user engagement and sentiment, and identify any problems with the register. Note: as these are post-launch activities, you will have to make sure that analytics are implemented before you go live.

User analytics reveal how your users are actually interacting with your BO register in real-world conditions. You could use analytics to understand which sections of your form users spend the most time on, potentially highlighting areas that are difficult to understand. You could also use analytics to measure which types of searches your users conduct most often, helping you to prioritise what type of data your users rely on the most and thus where you should spend the most time focusing.

Be careful though – whilst user analytics are great for understanding what your users are doing, they don’t reveal why they are doing it, which could mean you draw the wrong conclusions. For example, are your users using a particular search parameter a lot because that is the most important data for them, or because the search doesn’t work very well and they need to spend a lot of time adjusting their parameters to get the right information? In order to understand this, combining analytics with interviews or other qualitative methods can enable a more thorough understanding of how your users interact with your register.

Any post-launch training sessions and educational workshops about the importance of BOT and the BO register provide opportunities for user research. You can distribute surveys or even allocate time for one-on-one user interviews to gather data for post-launch assessment of the BO register. Keep in mind that the data should be collected before you demonstrate, deliver training content, or give instructions regarding the BO register. This will ensure you get fresh insights on the real user experience with the system.

Next page: Conclusion