• Team for the Alpha stage  

    You’ll work with the same team in the Discovery and Alpha stage. This keeps the existing empathy, context and momentum.   

    You may need to add some roles and capability in the Alpha stage. Such as: 

    • business analyst 
    • technical architect 
    • delivery manager or similar, for example, scrum master. 

    What to do in Alpha 

    At the start of the Alpha stage, you’ll have a good understanding of the user journey and the major stages the user takes. As your knowledge grows, you will continue to work in an agile and iterative way, updating the journey map as you learn and understand more.  

    When the team has some certainty about the journey of users, create a user story map. This will help you define the minimum viable product (MVP). 

    In Alpha stage, you: 

    • take your hypotheses from Discovery and create high-level concepts 
    • continue to develop a vision for the service using your user journey and user story map 
    • create storyboards to see possible solutions 
    • create prototypes to test hypotheses with users, you should explore hypotheses with different kinds of prototypes, including paper and HTML 
    • complete the stage by defining the minimum viable product. 

    Decision register 

    The knowledge kanban board you set up in Discovery is even more important in Alpha. It will help you trace your reasons for solutions and provide evidence to guide what you will build, including: 

    • an explanation of the problem 
    • empathy map 
    • insight map 
    • results of affinity mapping 
    • pain points 
    • hypotheses and concepts for solutions 
    • user feedback and actions 
    • decisions about direction or why work on solutions stopped. 

    The knowledge kanban board should be saved and stored appropriately so it is discoverable to others in your agency and can be used for future reference once Alpha is complete. 

    Service performance  

    In Alpha stage you will need to decide which metrics you use to track performance so that you can meet Criteria 9 – Monitor your service. To do this you should: 

    • have an analyst as part of your team, or available to your team, so you can start working out how you’re going to measure service performance 
    • use your hypotheses to help you define your goals and benefits 
    • develop a measurement plan that starts to define the metrics your service will report on 
    • clearly define the start and end points for your service 
    • engage with stakeholders to raise their awareness of your measurement plan and to decide the process for signing off and publishing the metrics. 

    Activities for each sprint 

    Each sprint, the team should: 

    • hold a short meeting to prioritise user stories  
    • conduct user research with at least 5 to 6 users who are representative of actual users of the service 
    • capture learnings and insights from the research findings 
    • showcase or share back to stakeholders to give them visibility of the prototypes and user research 
    • have a team retrospective to reflect on the sprint and capture improvements. 

    This aligns with Scrum methodology and helps keep the team focused on delivering something of value to users every sprint. 

    Test with different kinds of prototypes 

    Alpha is all about testing a hypothesis with real users. The best way to do this is by building and testing prototypes. Alpha prototypes are like a proof of concept. A prototype will not be functionally complete. It would be wasteful to produce a finished product before making sure it captures the most important and meaningful steps the user takes. Test with users using paper or other low-fidelity prototypes first. This allows you to test assumptions and ideas quickly and cheaply before getting attached to any solutions.  

    Your team will decide which prototypes, if any, will be carried forward. From there you will update the prototypes based on feedback and test again.  

    As you learn from your research, you will move on to testing with more interactive, higher fidelity prototypes. 

    Create a good prototype 

    A good prototype has enough information for users to interact and can be quickly adapted or thrown out. You may choose to re-use some designs or components when you build in the Beta stage but never confuse a prototype with a minimum viable product. 

    It’s strongly recommended that you throw away prototypes that don’t work. Don’t spend too much time building prototypes, as you will build new ones based on user feedback. 

    Low fidelity prototypes 

    Some examples of low-fidelity prototypes include: 

    • storyboards 
    • card sorting. 

    Low fidelity prototypes are an excellent first step as they are inexpensive, can be quickly updated or changed and are disposable. 

    High-fidelity prototypes 

    High-fidelity prototypes provide greater detail on the final product including the design. They’re usually introduced once low fidelity tests have been explored and the team has a stronger idea of how a service will work. 
     
    There are some known downsides to high fidelity prototypes: 

    • users are more likely to comment on superficial parts of a service, like colour, design and layout, rather than the content  
    • they take longer to make and update than low-fidelity prototypes 
    • they may give users a false idea of how the final service will look or perform. 

    Tools to create high-fidelity prototypes 

    There are many tools on the market you can use to build interactive, high-fidelity prototypes. These allow you to sketch in code, using HTML, CSS and JavaScript. Others work like web-builder apps allowing you to drag and drop buttons, images and sequence out a user experience path.  

    Some teams have even used slide decks with basic animation to simulate an online service.  

    Whatever you choose, remember: 

    • show a seamless user journey that results in a positive user experience ‘ 
    • include content and data that looks real 
    • respond with alerts and feedback in the right places 
    • make it look and feel like a real digital service 
    • use familiar design patterns. 

    Don’t support every browser 

    Support a specific browser or version if a group of users or stakeholders depend on it. 

    Users are likely to use the prototype in a controlled environment, such as a user research lab or on a team member’s computer. This means you need to support fewer browsers than a public website. 

    Test for users with accessibility needs

    As part of the user research, test your prototypes with users who have accessibility needs. Test with screen reader software and other assistive technology. 

    Mobile first 

    More users are accessing government services using mobile devices than ever before. If you design and build for mobile first, you can test prototypes in a more realistic context. To design for mobile, you should make a simple screen, with only 1 or 2 things on each page. This means users with larger screens will also have an easier experience. 

    Define the minimum viable product 

    By the end of Alpha, you will have a developed the user story map in depth. The team should agree on a line across the user story map. What is above the line should reflect what is most important for the user and what the team can achieve. This will inform your minimum viable product (MVP). This is the simplest thing you can build that meets the user need. 

    The minimum viable product will scope what gets built in the Beta stage. The research and testing you have been doing in Discovery and Alpha will help you make choices about the technology you will use to build it. 

    Decide if you will continue to Beta

    End your service at Alpha stage 

    You may decide to end your service work in Alpha stage rather than continue into Beta stage. 

    For example, you may find that: 

    • user needs for the service are already being met by another government service or the private sector 
    • it costs too much to build the service based on the number of people who will use it 
    • there’s a better non-digital solution 
    • adapting or developing another service is a better solution. 

  • It’s still a successful Alpha stage if you decide not to move on to Beta because it means you have learned more about the problem, and you won’t waste time and money.

  • Exemptions

    The DTA acknowledge that some agencies may be unable to meet one or more of the criteria set out by the Digital Inclusion Standard due to a range of circumstances. These circumstances may include but are not limited to:

    • legacy technology barriers that cannot be reasonably overcome
    • substantial financial burden caused by changing a service to meet criteria.  

    Exemptions may be granted for one or more of the criteria set out by the Digital Inclusion Standard. This will be assessed on a case-by-case basis. Exemptions must be applied for through the DTA. 

    Further information can be found in the Digital Experience Policy Exemption Guide. 

    Note: Even if your service or website is not covered by the Digital Inclusion Standard, or you receive an exemption, you may still have related obligations under relevant Australian legislation, for example accessibility requirements under the Disability Discrimination Act 1992.

    Off

  • Start a new Alpha stage 

    At the end of Alpha, you may decide to start a new Alpha stage or even Discovery stage because you need to focus on different things.

    For example, you might find a completely different user need that you want to explore through further research. 

  • Start the Beta stage

    At the end of the Alpha stage, you'll have created a basic working system with limited functionality that you can demonstrate to users. It's a good idea to hold a final demonstration to show what you've achieved and explained your vision for the Beta stage.

    At the end of Beta you will have:

    • user stories related to the whole user journey, not individual features
    • an analysis of the user needs research
    • a decision on the metrics and a measurement plan
    • a decision on your minimum viable product
    • a plan and business proposal

    Make sure your timelines, scope and vision match the budget, team, and resources you have for the next stage.

    When you're ready, move on to the Beta stage of the service design and delivery process 

  • Time needed: the length of time Beta takes depends on the scope of your product. If you have the right team in place, it should take a few months. 

  • The team you need in Beta 

    The multidisciplinary team you established in Alpha should stay on in Beta. This keeps the existing empathy, context, and momentum. You might need to bring in different roles and capability during Beta.

    These may include: 

    • web operations expert
    • ethical hacker 
    • data analyst. 

    What to do in Beta 

    In Beta you will take the agreed prototype from the Alpha stage and build a minimum viable product.  

    The main activities in Beta are: 

    • development 
    • design 
    • usability research 
    • accessibility testing 
    • metrics monitoring. 

    Private and public Beta 

    You will release in private Beta, testing in short rounds as you continue to update and iterate. As your team refines the product, feedback rounds will become shorter. Continue running the private Beta until you have a functioning end-to-end service. Once you have a functioning end-to-end service, you can open a public Beta people can use alongside the existing service.

    As real users trial the new service you will continue testing to find ways to improve it. 

    These activities help you: 

    • build your service and plan for its launch 
    • solve any remaining technical or process-related challenges 
    • improve your service by testing it with users and releasing updates. 

    Update artefacts 

    The team will continue to update the artefacts developed in the previous stages. This includes: 

    • vision 
    • user journey 
    • user story map 
    • decision register 
    • prototype. 

    How to work in Beta 

    In Beta the team should build the real thing with the minimum features that support the end-to-end user journey. Make it accessible and secure. Avoid the temptation to build a polished version of your Alpha prototype. 

    During Beta: 

    • make sure the team’s focus switches from experimentation to prioritising the minimum viable product 
    • work as a team on actual user stories – make sure you focus on needs, not wants 
    • define and iterate a workflow, including ‘definition of done’ and other details to help the flow and work through the backlog of items. 

    Use Agile Delivery practices

    Your team should use agile delivery practices, including: 

    • continuous iteration and delivery 
    • test-driven development  
    • automation 
    • incremental design 
    • pair programming. 

    Release a private Beta and public Beta 

    Once you build the minimum viable product you will release it to real users, first as a private Beta and then a public Beta, alongside the current service. Your research will help you find the best way to host the new public Beta. This might be a new subdomain, sub-directory or a domain name. 

    Apply for a new domain name through the gov.au Domain Administration System. 

    Private Beta 

    A private Beta is a Beta that isn’t open to everyone. Don’t launch your service publicly in private Beta, make it invite-only. A private Beta allows you to: 

    • have control over the users who test the Beta service 
    • restrict the volume of transactions that go through the Beta service 
    • start small and get quick feedback before releasing the service out to a wider audience. 

    Public Beta 

    A public Beta is a version of your service that’s available for any member of the public to use. It will exist at the same time as the current available service. This version of the prototype is available to all users, should they choose to use it. 

    Measure performance 

    You need to measure and report on the performance of your service. You will: 

    • put the measurement plan from Alpha into action, this means integrating your APIs, setting up your analytics and so on 
    • test the outcome of the plan with stakeholders 
    • iterate and improve the plan, consider sustainability over time and only collect the information you need. 

    Performance metrics help you understand if your service is meeting user needs and allow you to make decisions based on evidence. During Beta, you will: 

    • capture real performance data for your service 
    • iterate and improve your service through findings 
    • improve your methods to capture data, where needed 
    • plan how you will maintain your data and keep data records tidy. 

    How you know Beta is finished 

    At the end of Beta, you will have: 

    • launched a private Beta service followed by a public end-to-end service 
    • built a working system that can be used in full
    • made a prioritised list of work to be done
    • made a plan for ongoing user research to compliment quantitative data. 

    Make sure you plan how you will meet resourcing needs when the service scales up. 

    Your multidisciplinary team should stay in place when the service goes Live to make sure it continues to be iterated and improved. 

  • Move on to Live stage

    At the end of the Beta, you will have launched a private Beta service followed by a public end-to-end service that can be used in full by users. You can move your service Live when you are sure:

    • the Beta meets user needs and delivers the full end-to-end user journey
    • you can support and keep iterating and improving the service until it’s retired.

    When you're ready, move on the Live stage.

  • Retiring services 

    Retiring existing services involves replacing legacy technology and consolidating existing non-digital channels. This includes responsible archiving of records and websites. 

    You should be aware of policy and legislation changes that may impact how your service works. You will need a content strategy to help you audit and remove content. 

  • Learn how to manage a multi-disciplinary team to design, build and maintain your service. 

  • Multidisciplinary teams make it easier to build services 

    A digitally capable team start working together quickly to build momentum. Team members should have experience working in a multidisciplinary way, or the capability to work in this way. They will need to have the right mindset and skills. They should be open to new ways of thinking and working. 

    A multidisciplinary team has the capability and skills to deliver the service and the authority to make decisions. The team works independently and minimises dependencies that delay delivery. It is usually small, with fewer than 10 members.  

    A multidisciplinary team uses in-depth user research. This helps the team decide what to build and how to deliver it. This means services are: 

    • built using user-centred design – developed in iterations and closely with users 
    • guided by data and testing – they reflect the actual user journey 
    • focused on the end-to-end experience – they are simpler, clearer and faster. 

    Multidisciplinary teams are typically multiskilled and can work across disciplines.

  • Multidisciplinary teams are typically multi-skilled and can work across disciplines.

  • Finding the right capabilities 

    You will need to have specific roles and capabilities in your multidisciplinary team before you start Discovery.  

    Core roles 

    There are 10 core roles to consider when building a multidisciplinary team. The core roles in a multidisciplinary team are consistent from discovery through to Live. 

    The same core roles should be in the team for all 4 stages of the service design and delivery process. Find out more about the function and purpose of these core roles in a multidisciplinary team. 

    Core roles allow you to: 

    • design and deliver a service that is simple, clear and fast 
    • make sure your team has the right capabilities, skills, knowledge and attributes throughout the life of the service. 

    Extended roles 

    An extended role refers to when you may need specialist expertise to join the team for a time. For example, you may need the role of content strategist at the start of designing a service, but not for the whole service. 

    How to structure your team 

    Start with a user-centred approach. Think about what you need to design and deliver to meet user needs. Different types of products and services will determine which of the core roles you need. 

    Put users first 

    Seek to understand user needs.  Build your multidisciplinary team around a problem or service. 

    Understand the roles 

    Understand what the different core roles are and what they do. You can then decide which roles you need in your multidisciplinary team to develop the product or service your agency needs. 

    Decide when you need the roles

    Decide when you need the roles. This will depend on the type of service you’re designing and delivering. Once you decide which core roles you need, they will stay in place for the life of the service. For example, if you are designing and building a service, you will likely need all 10 core roles. If you are designing policy or legislation, you may not need a developer or a technology lead. 

    Roles you'll always need 

    You will always need the core roles of product manager and user researcher, as these are foundational to any service. Try to make sure that your core team is also empowered to make decisions. This will help them move through the service design and delivery process as smoothly as possible. 

  • With a clear understanding of digital roles, you can better decide what you need, when you need them.

  • Alpha stage: testing hypotheses

    Alpha stage is about using prototypes to work out the right thing to build.

  • Beta stage: building and testing the service

    Beta stage is about developing and testing the prototype to check it meets the user needs. 

  • Understanding users and their needs

    The better you understand your users, the more likely you are to design and build a service that works well for them.

    When you include all types of users in your research, you build a service that’s barrier-free for everyone. It’s best to start wide and begin your research with a diverse group of users before narrowing down.  

    Decide who to include in research  

    Brainstorm the different groups of people you need to include in your research by using information from: 

    • existing research and analytics  
    • subject experts and front-line staff 
    • service data and general population statistics 
    • user personas.  

    Consider how many participants you need  

    The research methods you use will determine the number of participants you need. For example, you’ll need: 

    • 4 to 8 participants per round of user research 
    • more than 250 participants for benchmarking.  

    Define your research criteria  

    Depending on your research objectives, your criteria might be: 

    • a particular demographic, for example, women under 30 years of age 
    • a specific user group, for example, small business owners or job centre staff 
    • specific life events, for example, users who have recently moved home or are looking for a job 
    • specific access needs, for example, people who use assistive technology 
    • a specific level of digital skill, for example, users who have basic online skills. 

    Understand your target groups  

    When you've defined the overall criteria, decide which groups you’ll include in each round of research. Consider groups who:

    • regularly use the service 
    • may need the service in future 
    • have problems using the service 
    • work in the service, for example, call centre staff 
    • help others use the service, for example, caseworkers, legal professionals or charity workers. 

    Ask subject experts for information about target groups. They may know about groups that you haven’t included. They may also help you get in touch with people who need extra support to take part in your research.

    Review your participant criteria to make sure they are relevant to your research questions. Do a gap analysis to make sure you don’t miss important groups.  

    Encourage diversity  

    To build a good service, you need to include users with diverse abilities and different access needs. Recruit participants that reflect the population and choose accessible research locations.

    Be careful not to exclude anyone in the way you do research.  

    Find access barriers 

    Regular users of your service will show you what business-as-usual looks like. You’ll see why and how they’re using each of the products in the service.  

    While it’s useful to include your regular users, don’t forget the users who have trouble accessing the service or can’t access it at all. This will help you explore pain points or obstacles that push users out entirely.

    For example, they may find the service too difficult to navigate or they may be unable to access the service using assistive technology.  

    It’s also useful to learn the workarounds used to access your service. For example, you may find that several users require a website translator to read the content in their preferred language. 

    Include all digital skill levels  

    You should research with people who have a mix of digital skills. It is important to speak with people who have a low level of digital literacy to understand their support needs. For example, some users may not be able to leave their homes, may not have a computer or may live in an area with poor internet.  

  • Getting support for user research

    The better you understand your users, the more likely you are to design and build a service that works for them.

    User research is most effective when it's funded from Discovery and continues for the life of the service. 

    It’s especially important to talk to real users at the start of the process. This helps you understand your users and build empathy.   

    User research is everyone’s job 

    The user experience is everyone in the team’s responsibility. Participation in user research helps your team develop empathy for the users and understand their contribution to improving the user experience. This will help them make decisions and use evidence to communicate the benefit of change.  

    They will learn:  

    • what real users need 
    • how real people experience the service 
    • the language people use when talking about the service 
    • how users perceive technology 
    • how users overcome issues with the service. 

    Team members who observe research should take part in analysis sessions to help agree on the findings and any resulting actions. User researchers should also work closely with the rest of the team on design decisions and prototypes.

    How to get buy-in for user research 

    Even if you understand the value of user research you may need to convince others. Getting support to stand up a proper multidisciplinary team with a full-time user researcher can be hard. 

    Create a pitch

    Research underpins the whole service design and delivery process. To start work on a new service, or improve an existing one, you may need to explain the value of user research. By doing user research we reduce risks and increase the certainty of success. 

    Work out the cost of the need 

    Design decisions must be based on user need. Existing research can provide evidence for a new or improved service. Use this to draft problem statements. 

    Quantitative sources like website analytics can help you discover the need for building or improving a service. They can also help you work out a cost to government for not improving a service.

    There are resources you can use to calculate the return on investment and prove the value of a good user experience. 

    Get support  

    You can ask champions and digital subject experts in your agency to help you. You can find champions by talking to other teams who follow the service design and delivery process. They may help you gain support from influential leaders in your agency.  

    You can use case studies to show how user research can improve service outcomes. 

  • Use existing research and data

    There may be research and data about your users and their needs already available to you within your organisation.

    Why use existing research and data?

    Using existing research has these benefits:

    • It can save time and money.
    • It can provide you with evidence of who your users are and their needs in the initial phase of a project.

    This can help gain support in your organisation for:

    • following a user-centred design process
    • allocating budget and resources to a project

    When to use existing research and data

    When creating content, consider all the possible users of your product or service. Existing research and data can help you find out about your users and their needs.

    Existing research and data is a good starting point, but it shouldn’t be relied on as comprehensive. Sometimes sources may be limited or dated. Existing research and data may not address your specific context or problems. It also won’t help the team to develop a deep understanding of, and empathy for, users and their needs.

    Existing research and data shouldn’t replace your own user research. User research is the best way to learn about users and create services that meet their needs.

    Find existing research and data

    Your organisation may already have research and data about users and their needs. There are many sources you can explore. These include:

    Call centre data

    Call centre data can provide information on your users' main frustrations. Call volumes about different issues can help you prioritise usability issues with your product or service.

    Online and phone surveys

    Surveys may have been conducted already. Use them to find user pain points and areas that need improvement.

    Web analytics

    Web analytics involves analysing quantitative data which can help you explore the behaviour of users on your website. The most common source is Google Analytics. Analytics can help you recognise usability problems and user types. Often analytics are set up on a website but the data isn't analysed.

    Search logs

    Search logs have a lot of information about what users want and how they look for it. Information in search logs can provide evidence for usability problems. Logs can highlight when users are struggling with the way information is presented on your site. Looking at search terms can provide guidance on the words people actually use. Identifying these problems in the search logs can provide evidence for usability problems.

    Social media

    Your organisation's social media channels can help you recognise trends in users' perceptions. Your agency may also have social media monitoring set up. Reviewing this gives a broader perspective of user commentary.

    Previous research reports

    Many large organisations will already have conducted user research in the past. This research can help you recognise different user groups and their needs.

    Other organisational reports

    Other reports your organisation creates can also provide information about users. For example, annual reports and strategy documents. These often contain information about user numbers and demographics.

    Engagement teams

    Many organisations have teams that directly engage with users. They are sometimes called client relationship or outreach teams. They can provide valuable insights.

    Find other possible sources

    Desktop research

    There is a wealth of information on the internet that can help you get started. Explore similar products and services that use best practice.

    Consider questions such as:

    • How are other people doing what you are doing?
    • Who else is interested in the topic or user group?
    • What has worked and what hasn't worked?
    • What usability issues have others discovered?

    Providing information on what has worked in similar cases can help you gain support within your organisation.

    Consider looking at these types of resources to get started:

    • usability blogs
    • research papers
    • case studies

    Source information about users

    There may be public information available about your users. Possible sources include:

    Bring your research and data together

    To develop a clear picture of the users, consolidate your research and data. Read or analyse the research you have collected. Decide the following:

    User segments and needs

    Find out who is using your product and service, and if there are clear groups of users with different needs.

    Common interactions

    Find out the user journey and user experience of your service, for example:

    • Why did they need to use the service?
    • What did they plan to do?
    • What did they do?
    • Were they satisfied with the service?

    Gaps in the research

    Decide on research or further exploration that still needs to be done.

  • Planning user research across design and delivery

    As you move through the service design and delivery process, the research you do will change. Learn more about user research in each stage.

    The needs and goals of the users define the service. You will uncover these needs and goals through your research in the Discovery stage and build on them throughout the service design and delivery process. 

    In all stages you will: 

    • do research with a broad range of users, including those with access needs and low digital skills 
    • think about the whole user experience, digital and offline, not just the product you are delivering.

    In Discovery, you will do generative research, making sure you are designing the right thing. Later, you will do evaluative research to make sure you're designing it in the right way.

    User research in Discovery 

    Before you start designing, learn about your users. Watch how users do things now and what problems or barriers they face. This is called contextual qualitative research. It will help you to understand how the service you’re designing can meet user needs. 

    Interview users 

    Interview and observe frontline service staff, if your agency has them.

    This will help you understand: 

    • limitations of the current service 
    • how staff explain and resolve issues
    • undocumented workarounds that people use to get things done. 

    Map the user journey 

    Create a user journey map to understand the user experience completing a task.

    Don’t rely on assumptions the business has made. It’s important to do your own research to understand the user journey. 

    Examine existing data 

    To avoid bias, do your own primary research before looking at the research that exists. Existing research might include analytics, internal workflows and support logs. This can reveal issues and provide measurable evidence to support user behaviour.  

  • Find user research participants

    There are several ways to find research participants. We’ll take you through some of the steps you can use to find and recruit real users.  

    To understand and improve your service, you need to know what current and future users need.

    While it can be useful to speak with subject experts and people who understand how your service functions, these discussions shouldn't replace or be prioritised before user research.  

    Include the right people

    Remember to include all user groups in your research. Including people who:  

    • come from culturally and linguistically diverse backgrounds 
    • have different needs or who require assistive technology  
    • have a disability or chronic illness  
    • have different levels of digital skills  
    • need help to use your service 
    • will use your service in future.  

    Finding participants 

    Recruitment can be a lot of work. It’s good idea to consider resourcing and budget for this process. Recruitment agencies are experienced and are generally able to recruit participants at a reasonable rate. This can be good value for money.  

    To find participants:

    • use a research recruitment agency 
    • work with a professional body, specialist charity or community group 
    • work with specialist sections of other agencies, for example Multicultural Services in Services Australia 
    • invite existing users of your service to take part.  

    You can consider small pay incentives and reimbursements to encourage users to participate.

  • Interview users

    Interviews help you learn more about users, how they use a service and what they need from it.

    Interviews are an important research method throughout the entire service design and delivery process. Use interviews when you want to:

    • learn how your service fits into the users’ life and when they need the service 
    • get a deeper understanding of the user pain points and problems 
    • explore the user perspective.

    Who to include in the interview  

    The interview team  

    A note taker should be present for each session, you may also choose to include an optional observer.

    To stay safe, make sure you have one other person in the room with you apart from the participant. 

  • Consent forms for user research

    How to ensure your users are comfortable and feel safe sharing their experiences.

    A consent form helps users understand how the government will use the information they share. It also gives them confidence they will have control over their information.

    Get informed consent before you research 

    Make sure you have informed consent before you begin the research session. Explain to the participant what the research is about and what it will involve.

    You usually ask the user to complete and sign a consent form to confirm their permission and document their preferences for how we can save and share their information, including video and audio recordings.

    Crafting a consent form 

    Every user research session is different. Think about all the information you may need to capture during the research. Adjust the consent form to reflect this.

    For example, the participant may be sharing artefacts that contain their address and details of disability.

    The most important information you need in a consent form is:

    • who is conducting the research, including the researcher, team and agency 
    • why you are conducting the research 
    • what you will be recording, this should be the participant's choice 
    • what you will do with the information and recording 
    • how long the information will be stored for 
    • how the participant can withdraw their consent, include a contact phone number or email address 
    • a place for the participant to sign and date.

  • Paying incentives for user research

    It’s normal to pay people for their time when they help with research, but sometimes it isn’t appropriate.

    Paying incentives to participants is acceptable in some types of research. You should think about the situation and consider ethical guidelines when deciding if payment or reimbursement is appropriate.  If you do decide to pay incentives, factor them into your research proposal and budget.

    Incentives and reimbursements 

    Reimbursements are made to cover participant costs, such as travel expenses or equipment.

    Incentives are rewards that motivate people to take part in research, for example a gift card for completing a survey.  

    Confirm the incentive is appropriate  

    Before offering an incentive, confirm if the payment is appropriate. This will depend on the user research your doing and the participant's situation. For example, a payment may not be appropriate if it:

    • represents a conflict of interest
    • may become a form of indirect coercion for participants who are vulnerable or disadvantaged. 

    To help you make a decision, check if your agency has a policy on paying incentives and read the National Statement on Ethical Conduct in Human Research.

    Your responsibility  

    You have a responsibility for participants both during and after your research session.

    Think about these questions to help you decide if it is appropriate to pay an incentive:

    • would the participant get involved without the incentive 
    • will an incentive influence the results 
    • does the participant have a relationship to your organisation 
    • is there a power relationship, for example the participant is a supplier or public servant 
    • does the incentive take account of the participant’s socioeconomic situation 
    • could it be seen as coercion if they are from a disadvantaged or vulnerable background 
    • is the incentive appropriate to the participant’s cultural background.

Connect with the digital community

Share, build or learn digital experience and skills with training and events, and collaborate with peers across government.

Join the Digital Profession