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:
- gathering requirements;
- designing and testing a solution;
- 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.
Box 1. Conducting research ethically
Ethical research helps ensure the respect and wellbeing of research participants, as well as the integrity, credibility, and impact of the research. For user research to be ethical, you will need to:
- Collect informed consent from participants. Ensure participants (who must not be minors) give informed consent to participate, understanding: the purpose of the research; how long the study will take; how their feedback, personal information, and recordings will be used; the risks and benefits of taking part; and their rights.
- Remember that user participation is voluntary, and it is important to make it clear to participants that there are no negative consequences if they choose not to participate. All participants should be told that they are able to withdraw from or leave the study at any point without feeling an obligation to continue.
- Keep participation confidential. Although you know who the participants are, you must remove all identifying information from your report. You can replace identifying information about participants with pseudonyms or fake identifiers. Store personal information separately from the study data, and implement protocols for handling and storing personal identifiable information to maintain confidentiality and compliance with privacy and data protection laws. If you would like to use interview excerpts or quotes to communicate some findings internally, make sure you have secured informed consent from the participant beforehand and double check they are happy with the chosen quote.
- Finally, your user research should aim to be inclusive. Testing with users who have different accessibility requirements demonstrates a commitment to fairness, equality, and respect for all individuals, ensuring that everyone’s needs and experiences are considered. This is not only a matter of research ethics but is also essential for ensuring your BO register is effective for all users.
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.”
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?
Open Ownership has been carrying out research with data users across various jurisdictions and has developed a framework to help think about BO data use. This provides an overview of BO data use journeys and a common set of needs, which implementers can use as a basis to map the user landscape in their jurisdictions.
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
Box 2. User research and legislation
Digital teams are rarely involved in the development of policy or legislative reform, and beneficial ownership transparency (BOT) is no exception. However, we think a better approach would be to start user research even earlier, before or during the writing of legislation.
This is because the research could uncover important insights that help inform how you structure your legislation, including what information data users need, and thus what you need to have a legal basis to collect, as well as who should be given access to different types of information.
We recognise the challenge in this, given that it is not common practice, but we encourage you to either conduct discovery user research or have a user-centred expert in the room during the legislative process. This will ensure that the legislation is written in a flexible enough way for you to design and implement an effective and user-centred BO register.
If, however, you do have the opportunity to influence the legislative drafting process, try to persuade policy or legal teams to allow as much space as possible for user needs to drive the development of the system. This could involve:
- not including forms or specific technical requirements in legislation – these should have the chance to be shaped by your user research;
- defining the policy intentions behind reforms – for example, “collecting data that helps achieve X”, rather than “collecting A, B, C fields”;
- setting minimum fields that should be collected, and enabling additional information to be collected if judged necessary, even after the legislation is drafted. The one exception to this is personal data, which needs a legal basis for collection.
Of course, all of this is dependent on your legal system and existing legislation. For more information, please see our Guide to drafting effective legislation for beneficial ownership transparency.
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.
Another research method for gathering user requirements are focus groups. We do not recommend this method for conducting user research.
Focus groups are a useful tool for studying groups of people, which is not the setting in which BO registers are used. They are not good at uncovering individual thoughts and feelings. Group dynamics result in dominant or extroverted individuals overshadowing quieter group members, and make it hard to speak up against the default consensus. In addition, some businesses might be competitors to each other, which can generate inaccurate communication of user needs.
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.
Finding
During a field study at a law firm that services large businesses with complex ownership structures, you ask someone to walk you through the journey of filing BOI. Through that process, you realise that there are multiple teams involved: senior partners are interested in compliance with the new legislation, whilst the compliance team does the due diligence to identify the beneficial owners, and the company secretarial team interacts with the register to submit the final information.
Design takeaway
You realise you need to expand your research to cover all of those different teams that interact with the form. You also need to design the system so these teams can collaborate on the filing, and to clearly map the legislation to the system so that even those who aren’t experts in the reforms can use the system.
Finding
You interview the data lead at a competition authority who is interested in using BOI to measure market concentration in the construction industry in your country. You realise that to do this, they will need access to information on the sector that companies are operating in, and to be able to look across the entire dataset to analyse this rather than just looking by company.
Design takeaway
You realise that there may be a whole set of data users who also need to be able to access the entire dataset in bulk and decide to expand your research to talk to other profiles of data users who may need to use data in this way. You realise there are indeed multiple users, from academic research to business journalists, who carry out large-scale analyses that would help advance your policy goals and explore how to provide adequate system features to enable these use cases.
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:
Finding
You ask a business representative to use your prototype form to submit their business information. You watch the person struggle to understand the meaning of some of the field labels in your form.
Design takeaway
You replace those labels with clearer and simpler terms, and test to see if other users find this easier.
Box 3. Real-life example: How user research improved a country’s beneficial ownership form
Sometimes, users won’t tell you exactly what they need, but you can work it out through the questions they ask. One user researcher working on a BO register described an example of when they used the questions asked by users to infer the issues users were having with the system:
We were testing the declaration form that we had built. We had some information up front when people started submitting the information that indicated how the data they submitted would be used – what information would be made public and what wouldn't.
Well, in testing we realised no one noticed. They would ask us later, “What are you going to use this data for?” We had all the text explaining that, but they didn’t see it. Even if it was on the screen when they asked the question!
So we read between the lines: this was a problem. Users need to know what information is shared publicly vs. just being kept for internal purposes. Because of the research conducted, I could ideate a few new solutions, make some new wireframes, and [I] tested them during the next round to see if we saw an improvement in concerns around privacy.
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.
Finding
In your live BO register, the user analytics show a high number of page views and time spent on the pages where users can report discrepancies in ownership information. However, there is a significantly lower number of actual reports submitted compared to the number of users accessing these pages. This suggests that many users leave the page without taking any action.
Insight
This pattern suggests that whilst there is significant interest in reporting discrepancies, users might be finding the process confusing or cumbersome. The high engagement indicates awareness and willingness to report, but the low conversion rate (actual reports submitted) and high bounce rate point to potential usability issues or lack of clarity on how to report.
Actionable steps you take to understand what is causing these issues:
- Implementing a short, optional survey on the reporting pages asking users about their experience and any difficulties they encountered.
- Conducting usability testing sessions with a representative sample of users to observe their interaction with the reporting feature and identify specific stumbling blocks.
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.