• 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.
  • Analysing user research

    How to understand your user research and use insights to build a service that works well for the people who use it

    User research activities produce a lot of raw data. Filtering and organising this data will help you to produce meaningful insights. For example, you may have:

    • written and digital notes 
    • sketches and photos 
    • audio and video recordings.

    Who to involve 

    We recommend inviting everyone on your team to the research analysis.

    When everyone has a chance to be part of the decision, you reduce the risk of researcher bias and limit the individual influence of team members or stakeholders. At a minimum, invite anyone who observed the user research.

    When to analyse 

    You should aim to do analysis as soon as you can after each round of research, while it is still fresh in people’s minds. For every hour of research, aim to spend up to 1 to 2 hours analysing findings.

    Extract observations 

    To extract observations, ask the group to review research notes or recordings. From there, the group should:

    • use a single sticky note to write each observation  
    • provide details of exactly what is said or seen, his should be an unbiased representation of the user, not what they think it means.  
  • Understanding diversity

    When you create content, be mindful that users have diverse needs and abilities.

    Be inclusive

    As government services move onto digital platforms, we need to make sure they work for everyone. There are many diverse user groups in our population. Many have limited access to digital services or are excluded from them.

  • By addressing accessibility and diversity, we can make our content simple and easy to understand.

  • Diverse groups

    Diverse groups include:

    • people with low digital skills or literacy
    • older people or seniors
    • Aboriginal and Torres Strait Islander peoples
    • people from culturally and linguistically diverse backgrounds
    • people with cognitive or physical disability
    • people who are blind or have a vision impairment
    • people who are deaf or have a hearing impairment
    • people living in rural or remote locations
    • people accessing the internet on mobile devices.

    Accessibility

    Accessibility issues impact users across a variety of demographics. Accessibility issues may include:

    • web content that is difficult to understand
    • websites not tailored to screen readers
    • websites that are difficult to navigate using smartphones
    • content too big to download with a low data limit.
  • You can find guidance about accessibility and inclusivity in the Australian Government Style Manual.

  • Include diverse users

    Understanding and being inclusive of diverse user groups should be an ongoing consideration. You need to:

    • develop empathy for diverse users, and their needs and abilities
    • challenge your personal biases and assumptions about diverse user groups
    • make services accessible for diverse users regardless of their abilities and environments
    • recruit and include diverse users when you conduct end-to-end usability testing
    • consider user needs and abilities when conducting research
    • allow the user to switch to non-digital channels if needed.

    Ask about the user need

    Always ask what the user need is and how to meet this need. Be careful not to exclude user groups or make assumptions about what services they might need.

    To encourage and enable users to use digital services successfully, you need to:

    • write in plain English
    • deliver a simple and consistent pathway through government websites
    • give access to translated content and supporting documentation
    • use alternative forms of communication, such as icons, pictures and visual cues.

Connect with the digital community

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