• Alpha stage: testing hypotheses

    Alpha is an experimental stage. It’s an opportunity to use prototypes to work out what to build. 

    In the Alpha stage you test the hypotheses reached during Discovery. As you progress through Alpha, you’ll produce new hypotheses as you learn about the users and service.  

    You’re not validating what users like or dislike. You are finding out how well prototypes meet the actual needs of users.  

  • Beta stage: building and testing the service

    In Beta, the team builds an end-to-end service based on what they learned in Alpha. They keep iterating until it is ready to test in a private Beta release and then a public Beta release.

    In the Beta stage you focus on building the minimum viable product you defined at the end of Alpha. This is the simplest thing you can build that meets the user need. 

  • Live stage: improving the service

    The Live stage is about releasing and improving the new service. You will also retire existing services and products if your new service is replacing something.

    You will keep doing user research and performance analysis to plan improvements. 

    Before you go Live 

    Before you make your service Live, you must make sure: 

    • users can complete the full end-to-end journey 
    • the service meets the user needs found in each of the service design stages 
    • the information stored in the service is secure 
    • you’ve proven your public Beta is functional, complete and performs better than existing services 
    • you have a service transition plan  
    • you have a service integration plan for any existing services that meet a similar user needs to yours 
    • you have redirected the URLs for the old archived service that will be deleted 
    • the service meets all aspect of the Digital Service Standard and will continue to do so until its retirement 
    • you will iterate and improve the service until its retirement. 

    In many cases, a Live service contributes to a wider transformation roadmap. The code, design, infrastructure, and learnings from service delivery can be re-used across your organisation. 

    The team you need in the Live stage 

    You should know the roles you need to run your service, based on your experience of building it. 

    As you iterate and improve different parts of your service, you may find the team size changes along with your need for specialist roles. 

    Don’t disband your service team after you go Live. You need a multidisciplinary team to continuously improve the service and respond to the changing needs of the users over time.

    If the service is handed over to a different team, you will lose the empathy and experience developed through the previous stages. Make sure ‘business as usual’ includes resources allocated to iterating and improving a service so that it remains relevant and useful. 

    After you go Live 

    After you move to the Live stage, keep improving your service based on user feedback, analysis and further user research. If the team needs to work with other teams to support the Live service, make sure you use the same artefacts. Everyone should be working using the same user stories.  

    You should also: 

    • monitor the status of your service 
    • maintain uptime and availability 
    • practice vulnerability and penetration testing 
    • test the service performance 
    • maintain quality assurance 
    • continue to use a combination of qualitative and quantitative data to inform decision making. 

    Repeat each stage 

    You should repeat the service design and delivery stages Discovery, Alpha, Beta and Live for smaller pieces of work as your service continues running. This means you: 

    • keep finding things that need improvement 
    • do research to get the best solutions 
    • iterate and release, then iterate again. 

    Measure performance 

    Continue capturing performance metrics after the service goes Live. This information will help you monitor whether your service is meeting user needs and how user needs are changing. 

    You will need to: 

    • monitor how you capture performance data 
    • manage the appropriate storage and analysis of this information, including keeping data tidy 
    • iterate and improve your methods for measuring performance 
    • only make changes at key intervals to avoid interrupting data that you’ve collected over time, if you do make changes, keep a change log  
    • consider sustainability over time and only collect the information you need, don’t continue collecting data if it is not needed or will not be used 
    • communicate the results of your performance analysis to service stakeholders and decision-makers to keep them informed. 

    Use your findings to understand how to improve your service. Keep testing to make sure your metrics are telling you what you need to know. Understand that some metrics will only get you so far. It’s important to factor regular user research in at appropriate intervals, for example once a year. 

  • Putting people and business at the centre of digital transformation.

    Discover our vision for the future

  • User research

    User research helps you to learn about users and create services that meet their needs.

    The value of user research

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

    • make fewer assumptions about your users and reduce the risk of expensive failures
    • reduce delivery times by building with certainty
    • reduce risks by releasing in increments.

    When to involve users

    You will do user research across the entire service design and delivery process.

    During the Discovery phase, you’ll start to ‘know your user’ and validate initial assumptions made in Criterion 1.

    Have a clear intent 

    You will continue to test and validate your service with users as your knowledge of the problem grows. This allows you to:

    • expand your understanding of users and their needs
    • test new design ideas, content and features
    • understand user problems and how they might be resolved
    • save time by only building what your users need
    • improve the service by responding to user behaviour and feedback. 

  • Managing teams

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

  • The Digital Experience and Life Events Community

    The Digital Experience and Life Events Community is for practitioners interested in all things relating to the digital experience.

    The community brings practitioners together to exchange ideas, showcase their work and explore best practice. It is a safe and inclusive space to share digital experience solutions, improvements and pain points.

    Join the Design and Research - APS Professions Members' Community Platform.

  • Exemptions

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

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

    For services being considered for integration into myGov these circumstances may include, but are not limited to:

    • the users of the service cannot access myGov, are ineligible for a myGov account or where it does not make sense for users to have a myGov account
    • legislative or regulatory barriers preventing the service from being delivered via myGov
    • circumstances where Services Australia has indicated that it is unable to onboard the service onto myGov.

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

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

    Off

  • Next page: Transition approach

  • Criterion 2 – Know your user

    Next page

  • Criterion 3 – Leave no one behind

    Next page

  • Criterion 4 – Connect services

    Next page

  • Criterion 5 – Build trust in design

    Next page

  • Criterion 6 – Don’t reinvent the wheel

    Next page

  • Criterion 7 – Do no harm

    Next page

  • New and/or replacement digital services for individuals suitable for myGov from 1 January 2025

    Any new digital or ICT-enabled proposals coming forward in the 2025-26 Budget that have a public-facing portal must meet the requirements of the Digital Access Standard, as per the Investment Oversight Framework (the IOF). Agencies will be required to demonstrate they have considered the criteria of the Digital Access Standard.

  • Phase 2 – All other public-facing services for individuals as well as those for businesses and providers

    From 1 January 2026, services that meet the following criteria will be required to meet the Digital Access Standard:

    • owned by Australian Government entities
    • informational or transactional
    • authenticated or unauthenticated
    • new or replacement services
    • all public-facing digital services.

  • New and/or replacement digital services (beyond individual services using myGov) from 1 January 2026

    Any new digital or ICT-enabled proposals coming forward in the 2026-27 Budget that have a public-facing portal must meet the requirements of the Digital Access Standard, as per the IOF.

  • Time needed: Discovery usually takes between 6 and 8 weeks, depending on the size and complexity. Every service is different. A bigger problem will mean more time spent at the Discovery stage.

  • Be ready for Discovery

    Before you start, complete all the pre-Discovery steps.

    If you start Discovery before you’re ready, your team may experience obstacles or blockers. For example, an incomplete user research plan may need lengthy ethical reviews and approvals which may take up all the team’s Discovery time.

    Kick-off session

    A kick-off session is the first meeting your team will have. The session formalises the purpose of the team, common goals, objectives and roles.

    Your whole team should be in the kick-off meeting, including subject matter experts, business owners and senior stakeholders.

    Create a shared vision

    In your kick-off meeting you’ll discuss the problem, including existing research and data about the service and the current user experience. You’ll also define:

    • your vision statement and what you will do, you will continue to develop this as you go through each stage
    • what success will look like at the end of Discovery, this includes things you want to understand and the artefacts you need to produce
    • timeframes, milestones and reporting dates for stakeholders.

    Set ground rules

    During the kick-off meeting, your team will discuss how you will work together and create some ground rules. You should include things like:

    • how you will work
    • principles, values and team contracts
    • communication and operation channels
    • where and when you will hold team rituals like stand ups, planning sessions, showcases and retrospectives
    • how you will keep track of the tasks you’re working on, for example you may use a kanban board or Gantt chart.

    Define the user need

    Your team will do research to get a deep understanding of the users and the problems the service aims to solve.

    This will help you discover all kinds of user needs:

    • current experience: what users are experiencing now and the products they use to complete their goal
    • stated needs: the things users explicitly tell you that they need, for example they may need your service to be mobile responsive
    • unstated needs: the things users expect your service to have, for example they may need information that’s easy to understand
    • created needs: what users are forced to do because of policy or the way government works, for example they may have to use different online accounts for different stages of the same service
    • actual goals: what the users are really trying to do when they use the service and its products, for example planning to travel, not just applying for a passport.

  • Learn more about identifying and describing types of user needs on gov.uk.

  • Include all users 

    It’s important to speak to all your users. The research you do in Discovery may include:

    • end users
    • professionals, businesses and intermediaries
    • public servants supporting service delivery and policy.

  • Remember to be inclusive in your research. Include people with a range of abilities and different ages, languages, backgrounds and experiences. 

  • Get the background 

    You will need to understand the existing business processes for this service. You’ll do this by using business process mapping. You may also need to consider: 

    • technology that supports business processes
    • how data flows through the service
    • the policy intent for the service, so you can align this with user needs
    • any obvious technical, legislative or other constraints relating to the service.

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