Australian Government Architecture
Search

Digital Service Standard v1.0 guides and tools

Notice

The Digital Service Standard v2.0 was released on 4 December 2023. For the 2024-25 Budget process, agencies going through the DCAP Assessment will be required to meet the Digital Service Standard v1.0.

This page outlines guides and tools on how to meet the Digital Service Standard v1.0. Click here for further information on the Standard.

1. Understand user needs

Research to develop a deep knowledge of the users and their context for using the service.

How you can meet the Standard

In Discovery and Alpha stages

During the Discovery stage and Alpha stage the entire team should have spent a lot of time with end users and learned a lot about their needs. You should understand and be able to show evidence to demonstrate the following.

Who are the users?

What about the users' motivations, triggers, contexts are significant for your service?

How can you find the users to invite them to participate in user research? You must include users with varying needs (such as needs arising from disability, cultural diversity, literacy and remoteness).

Consider all the users in the service including end users, users in government who are delivering the service, and key intermediaries (professional and personal networks).

What is the real task(s) that people are trying to achieve when they encounter your service?

What is the ‘job’ people are trying to get done that your service is a part of? You need to describe this in words that real end users would use, not using government terminology.

How are users currently doing the task your service aims to help them do?

Think about all key touch points, for example through journey maps.

What other relevant government and non-government services are also in use at this time?

Where are the pain points in the current experience?

What are the user needs?

What are the opportunities to remove or reduce the pain points? How might we better meet the user needs? Demonstrate this through research, testing and validating possible solutions with prototypes.

Are you designing the right thing?

How have your insights from user research helped you to define your minimum viable product (MVP)?

How does the MVP create value for users and government by better meeting user needs?

In Beta stage

During the Beta stage your understanding of what your users value will have matured through testing design prototypes with them.

By the end of the Beta stage you should be able to show greater depth and diversity of knowledge on all of the points above from Alpha and Beta. You should also be able to show the following.

How has your service been shaped by user needs?

Show how you have made changes in the service and interaction design in response to user research and usability testing.

You can evidence this by showing how the design has changed over time and the appropriate research findings that have driven this change.

How have you tested the system in the users’ context with a full range of users (including users with varying needs)?

You can evidence this with artefacts of research, for example, video clips and outcomes from research analysis.

Are you prepared for ongoing user research?

Show how you plan to continue to test the system with users and the resources for this, for example through an ongoing research plan and budget.

What have you not solved yet?

What the significant design challenges are, for example through key insights, how have you approached them? How do you plan to continue to tackle them?

How will you know if your design is working?

Make sure that research has fed into the metrics you have developed to know that you continue to meet your user needs.

By the time you are ready to go live you should be able to show greater depth of knowledge for all the points above. You should also:

  • show how you are using data from real users to understand which parts of the task users are finding difficult, and how you are designing experiments to reduce friction and increase success for users
  • know how you will measure and monitor your service to ensure it is serving its users well

Further reading

From the UK Government Digital Service blogs:

Helpful resources:

You can learn more about user research by joining the Research and Design Community of Practice.

 

2. Have a multidisciplinary team

Establish a sustainable multidisciplinary team to design, build, operate and iterate the service, led by an experienced product manager with decision-making responsibility.

How you can meet the Standard

This criteria applies through all service design and delivery stages. The composition of the team will change depending on the stage and need.

You must be able to describe your digital delivery team — it should have, or easily get, the following roles, as relevant to your service:

  • service manager
  • product manager
  • delivery manager
  • technical architect
  • service and/or interaction designer(s)
  • content designer
  • user researcher(s)
  • developer
  • web operations engineer
  • performance analyst

You must also be able to:

  • show the team principles, vision, rituals and agile practices (for example, through team charter)
  • demonstrate you have a product manager with the knowledge and power to make day-to-day decisions to improve the service
  • show how team members stay with the service through the stages and how new members will establish empathy with the users
  • show the decision making and approval processes
  • know who the stakeholders are
  • show that the team’s user research activities were developed and overseen by an experienced user researcher and that all team members participated in research
  • demonstrate an understanding of where gaps may emerge in the team structure and how to fill them
  • demonstrate how you plan to share information, work together and troubleshoot issues within the team as well as with key people external to the team
  • explain your plan to transfer knowledge and skills from any external people who work with the team

Guidance related to this criteria

Further reading

 

3. Agile and user-centred process

Design and build the service using the service design and delivery process, taking an agile and user-centred approach.

How you can meet the Standard

This criteria applies through all stages of the service design and delivery process. You should:

  • work in an agile way, based on agile values and principles, and using agile tools and techniques
  • review and iterate your processes to be able to respond to feedback, continue to improve and adapt to change
  • be able to demonstrate how your team uses agile tools and techniques to communicate with each other to increase collaboration and transparency
  • be able to show that your governance is appropriate to the size and scale of your service, and that it is human-centred, based on clear and measurable goals, with a clear focus on managing change and risk in real time

During the Discovery and Alpha stages you would have become comfortable with working collaboratively in very fast feedback loops that are guided by user research. During Alpha you should:

  • test hypotheses and underlying assumptions with several prototypes
  • follow a user-centred approach; include the user in all areas of the prototyping (design, iterations and so on)
  • work out incrementally what is the right thing to build
  • determine the minimum viable product (MVP)

During the Beta stage and through to the Live stage you will be working closely with users. You should be able to:

  • show how the service has responded to user research and usability testing
  • clearly describe the lifecycle of a user story, from user research to production
  • explain the deployment process and how you are able to support frequent deployments with minimal impact to users

Guidance related to this criteria

Further reading

 

4. Understand tools and systems

Understand the tools and systems required to build, host, operate and measure the service and how to adopt, adapt or procure them.

How you can meet the Standard

In Alpha stage

During the Alpha stage you should be thinking about what you need to build the service. You should:

  • review the types of tools and systems already available
  • identify potential development tools and software to build the product
  • identify the appropriate languages, frameworks, and other technical choices that are required to build the service
  • understand who will own the intellectual property
  • understand any data requirements of the service
  • understand the development tool chain required for Beta
  • understand the existing IT systems, data stores and in-flight processes for the service
  • understand any potential external dependencies or integrations that would be required to build the product
  • know the initial and ongoing costs for proposed tools and systems

In Beta stage

During the Beta stage you will be building the service and testing prototypes with users. You should:

  • manage any constraints that the chosen development tools and software have placed on the service
  • have a strong rationale for the technology choices you’ve made, including the languages, frameworks and development tools
  • procure the appropriate tools, systems and contractual arrangements and make sure you are getting value for money
  • have the ability to conduct technical health checks of the service
  • arrange for appropriate ongoing technical support and service level agreements for underlying or dependent services

By the time you go live you should have in place:

  • procedures for ongoing operations, including iterations, maintenance, monitoring, patching and upgrading system components
  • funding to cover the long-term life of the product, including activities such as security accreditation
  • evidence or artefacts that demonstrate you achieved the objective of the criteria for the Live stage

Guidance related to this criteria

Further reading

 

5. Make it secure

Identify the data and information the service will use or create. Put appropriate legal, privacy and security measures in place.

How you can meet the Standard

In Alpha stage

During Alpha stage you’ll have an understanding of the users, data and threats that affect your service. You will have established an appropriate approach to integrate relevant security and privacy measures into your design with minimal user impact.

You should:

  • identify secure and private methods of generating or processing data within or between datastores, the solution and users
  • identify appropriate authentication methods that are as seamless as possible to the user
  • understand to what degree the solution has to comply with the Information Security Manual and Protective Security Policy Framework, and internal agency security policies, and create a plan on how to achieve this
  • conduct a privacy impact assessment
  • conduct a threat and risk assessment, and an Information Security Registered Assessors Program Assessment (IRAP) if appropriate
  • identify potential threats to your service, including potential pathways for insider threats and hackers, and demonstrate an understanding of how to mitigate the identified threats

To support the work in Alpha you should:

  • map the systems, data and responsible agencies
  • understand what user data might be needed or collected by the service
  • understand what existing statistical datasets may be relevant to your service and the Australian Government principles on data integration
  • understand which data you collect is (and isn’t) personal information and how it might be stored, accessed and disseminated
  • involve relevant security professionals throughout the Alpha stage

You should understand the service requirements relating to:

In Beta stage

During the Beta stage you’ll develop a secure system that integrates seamlessly into the proposed solution. It will have appropriate security controls embedded within it to mitigate all identified threats.

You should involve all relevant stakeholders within the project, including:

  • business owners
  • information risk and compliance teams
  • SIRO (Senior Information Risk Owner)
  • IAO (Information Asset Owner)
  • IT security teams
  • internal fraud teams, if appropriate

You should also:

  • address all legal and privacy issues associated with protecting and sharing user data
  • develop an appropriate cookie and privacy policy, and keep it up to date
  • create a solution to test and implement security patches quickly and efficiently
  • demonstrate that effective security controls are in place to protect data used or accessed by the solution
  • integrate into or create relevant security documentation
  • create a risk treatment plan to track risks and mitigations
  • test the security of the solution and address all vulnerabilities discovered

You should build detection and prevention mechanisms into the solution, including:

  • incident response plan
  • logging solution that can fully trace a user as they traverse each part of the system
  • appropriate business rules that check the validity of interactions with the solution

As you go live you should be able to show that you have created a robust secure solution that meets all security, legislative and legal requirements. It should:

  • manage frequent security updates
  • identify malicious or fraudulent activity
  • have appropriate policies in place to respond quickly to security events
  • have the ability to integrate into existing security monitoring solutions
  • allow users to interact securely with the solution with minimal impact on user experience
  • have mitigated all known vulnerabilities in the solution

Further reading

 

6. Consistent and responsive design

Build the service with responsive design methods using common design patterns and the style guide for digital content.

How you can meet the Standard

During Alpha stage you need to consider the design methods and patterns you could apply in your service, and how you can communicate simply and clearly with your users. You should show that you:

  • understand how you will use responsive design for platform independence
  • understand how you will use existing design patterns to make the service consistent
  • create simpler and clearer information by understanding the language of your users, using plain language by default, and applying contemporary online writing methods
  • follow accessibility better practice and are planning how your public prototype will meet WCAG level 2.1
  • ensure appropriate design, content design and front-end developer support is provided to the team

As you develop through Beta stage and progress to Live stage, you should be applying these principles and design methods and will be expected to show them in your service.

Guidance related to this criteria

Further reading

 

7. Use open standards and common platforms

Build using open standards and common government platforms where appropriate.

How you can meet the Standard

During Alpha stage you should understand what open standards and common platforms can be used for your service. You should:

  • build using the open standards of HTML, CSS and JavaScript to develop prototypes
  • follow government better practice and standards in the design of the service
  • identify tools, systems, processes that can be adopted or reused from other services
  • search for similar solutions in other jurisdictions

During Beta stage and as you go live you should continue applying government solutions while also:

  • building using the Open Web Platform standards
  • avoiding lock-in to any proprietary solutions where an open standard is available
  • addressing any common user needs in a way that is consistent with the rest of government

Guidance related to this criteria

Australian Government ICT Policy, Guides and Procurement

Further reading

 

8. Make source code open

Make all new source code open by default.

How you can meet the Standard

Final code will not be produced in Alpha stage, however you should still be thinking about how you can share what you create. During the Alpha stage, you’ll need to:

  • show that you have considered a plan to release it under a licence that is suitable for your service
  • consider publishing the source code on a platform with wide adoption in the open source community, such as GitHub.

During Beta stage you’ll have developed further working code and should be ready to share your code in a repository. By the time you go live you should be able to show:

  • how you are making new source code open and reusable, for example, storing in repositories, releasing code under licence, using APIs
  • you have provided a plan or guidance for contributors
  • how you’re handling updates and bug fixes to the code

Guidance related to this criteria

Choose an open source licence

Further reading

 

9. Make it accessible

Ensure the service is accessible and inclusive of all users regardless of their ability and environment.

How you can meet the Standard

In Discovery stage

During the Discovery stage you will have developed a good understanding of how your users may access your service. To make sure everyone will be able to use your service you need to show:

  • the type of environments users may access the service in, including with different browsers and desktop and mobile devices, and when connections are slower and there may be limited data (for example, through user stories)
  • diversity in research recruitment and targeted users, including people from different cultural backgrounds and people with disability
  • consideration of situational and environmental limitations that affect a user’s ability to access the product
  • the plan to meet accessibility requirements in the design of the product (for example, how it will meet WCAG 2.1
  • what digital assistance might be needed to support users (for example, web chat, telephone assistance, face-to-face, clear instructions, checklists, and so on)

In Alpha stage

During the Alpha stage, you should be able to show:

In Beta stage

During the Beta stage you will be developing your service and you must make sure accessibility requirements and needs of all your users are being met.

You will need to show:

  • iteration in the design and content of your service to meet accessibility requirements and improve usability for people with disability
  • non-digital access and support for people unable to use, or struggling with, the digital service
  • end-to-end user journeys, including assisted digital journeys, and demonstrate that they work and how you tested them
  • how you’ve included cultural and linguistically diverse communities in your design
  • a plan to include translation for non-English speaking audiences, as appropriate
  • you have testing environments, systems and approaches for non-digital parts of the service, including assisted digital routes (for example, a testing plan)
  • how the service will perform under expected loads, including assisted digital routes
  • strong understanding of the environments your users may access the service in, for example which browsers, desktop and mobile devices they will use, and which remote locations; you might use user stories and a journey map to show this
  • definition of supported browsers and devices, and how they are accommodated
  • any barriers to the digital service and its content on mobile devices, and plans to address them
  • the design requirements for users using a mobile device and other identified environments (for example, design specifications)
  • how you have tested for the users’ ability to complete all digital transactions on supported devices and platforms
  • detail of users’ interactions with the product during testing
  • a demonstration your service in a live-like environment
  • the majority of users can access the service in their environment

As you go live you will need to show:

  • your service is accessible
  • evidence that your service meets WCAG Level 2.1
  • evidence of usability testing, including users with low level digital skills, people with disability, and people from different cultural and linguistic backgrounds
  • a run through of how you’ve designed and tested for users of assistive technologies based on user research, usability testing and analytics
  • ongoing testing plans for accessibility so that your users can continue to access the service

Guidance related to this criteria

Further reading

 

10. Test the service

Test the service from end to end, in an environment that replicates the live version.

How you can meet the Standard

During Alpha stage you should be testing your prototypes with users.

As you move into Beta stage and then onto Live stage, you need to be able to show:

  • the steps required to achieve an end-to-end service delivery outcome for the user
  • the testing environment; using test plans, real world scenarios and user stories
  • the deployment environment
  • ability to create new environments quickly and easily
  • that your service can perform under expected loads with suitable scale contingencies
  • you understand the systems you need and the testing environments for non-digital parts of the service
  • that users can seamlessly move between channels as required
  • how you explored integrating automated testing into the deployment process
  • you have a business continuity plan and a roll-back option

Further reading

 

11. Measure performance

Measure the performance of your service and understand what outcomes it is delivering. Report results to your stakeholders openly and regularly to encourage continuous improvement.

How you can meet the Standard

In Discovery

During Discovery stage, you’ll have started early measurement activity by:

  • collecting a baseline of what is measured now and why
  • exploring what data is already available, where it’s kept and how you might access it
  • outlining key questions on what you want to know, and how you might get the answer.

In Alpha

In Alpha you will need to consider how you will measure your service in more detail. By the end of Alpha you should have:

  • explored what data is already available, where it’s kept and how you might access it
  • combined this existing data with your own insights from research
  • collected a baseline of what is measured now and why
  • collected baseline data for service operation in all its channels
  • started creating a performance framework outlining your goals and what metrics your team will use to demonstrate whether you meet them.

In this performance framework you should:

  • be able to explain your assumptions
  • be transparent about any statistics
  • be able to explain the rationale for the performance indicators you’ve chosen.

In Beta

By the end of Beta you will be able to show:

  • which metrics and measurements you will use to monitor your performance
  • the baseline measures and the benchmarks for success
  • which tools you use for analysis and web analytics in Beta (and Alpha if appropriate)
  • what you have learned from qualitative and quantitative data (for example, key evidence).

During public Beta you will have been able to test your methods for data collection and validated that the data is accurate.

As you go live you should be able to show past performance data and improvement to the service based on its findings.

Your data should show:

  • how and where the service is delivering value
  • the outcomes the service is experiencing
  • completion rate has improved (in the instance of an existing service being redesigned) or been maintained (in the instance of a new service now moving from Beta to Live)
  • cost per transaction is decreasing in line with service plans
  • usage rate is increasing in line with service plans.

Further reading

 

12. Don't forget the non-digital experience

Ensure that people who use the digital service can also use the other available channels if needed, without repetition or confusion.

How you can meet the Standard

During Discovery stage and Alpha stage you should have developed a good understanding of where users will go for the service you are building. You should understand what proportion of users rely on non-digital channels, wholly or in part, and have a plan for how you will address this in your build.

During Alpha you should show you understand:

  • all the touchpoints in users’ journeys, their contexts of use, and the digital limitations affecting different groups of users
  • existing channels and how they interact with the service and with each other
  • the channels required to support all groups of users of the service, and where a user may need to change channels
  • if there are any repeat transactions by users over different channels
  • the interactions occurring between the channels that deliver and capture user transactions

During the Beta stage you will apply the knowledge gained in Alpha to design a service that works with the other channels, as appropriate.

By the end of Beta and going live, you should:

  • detail the channels required to support all groups of users of the service
  • understand the non-digital service channels and have a plan to move users to the digital channel where appropriate
  • have developed and tested the service so that a user can change channels without repeating themselves

 

13. Encourage everyone to use the digital service

Encourage users to choose the digital service and consolidate or phase out existing alternative channels where appropriate.

How you can meet the Standard

In Discovery and Alpha stages

Your user research will give you a good understanding of where people want to access your service and their levels of digital skill. Through the Discovery stage and Alpha stage you need to understand:

  • the users’ journeys and how they interact with your service, digitally or otherwise
  • existing alternative channels and how users currently interact with them
  • what percentage of users access digital and non-digital channels
  • how you will increase digital take-up and what targets you will set

In Beta stage

As you continue developing your service and start testing it with users in Beta stage, you should:

  • be increasing digital take-up; revising your targets and considering relevant performance metrics
  • have a plan of how to move users to the digital channel where possible, including a communications plan to promote the service
  • have agreed analytics/metrics for the volume of usage across channels
  • understand the full impact of retiring any potentially redundant services and channels

As you progress your service to Live stage you will need to show:

  • how you’ve revised the targets you made in the Beta stage to increase the number of users (including users we need to assist) of your digital service
  • what you’ve learned from testing different approaches to encourage users (including users we need to assist) to choose the digital service over non-digital alternatives, and which ones you’ll use in the Live stage
  • your retirement strategy for any redundant services and channels
  • that your service load capacity is scalable to meet increased digital take-up
  • how you will promote your service and encourage people to use it, including how your messaging will appear in places where the users will see it

Guidance related to this criteria

GOV.UK Service Manual - Encouraging people to use your digital service

Was this information helpful?

Do not include any personal information. We are unable to respond to comments or feedback. If you would like a response, please email, or phone us. Our details are on the AGA contact page www.architecture.digital.gov.au/contact-us.