Digital service standard


Final | January 2022 | v1.0.0 | OFFICIAL - Public | QGCDG

How to use this standard

The Digital service standard must be used to implement the Digital services policy.

This standard provides thirteen (13) criteria that must be met when developing or significantly altering government digital information, products, and services.

  1. Understand user needs
  2. Have a sustainable multi-disciplinary team
  3. Use agile and customer-centred processes
  4. Understand the tools and systems required
  5. Make digital services secure
  6. Build consistent and responsive design
  7. Use open standards and/or common platforms
  8. Make source code open by default
  9. Make digital services accessible
  10. Test the digital service
  11. Measure the performance and improve
  12. Don't forget the non-digital experience
  13. Encourage a shift to the digital channel
  14. Appendix A - Guidance for digital services


This Queensland Government Enterprise Architecture (QGEA) standard provides information for Queensland Government departments and agencies on the mandatory requirements and recommended guidelines to deliver a digital service in the Customer Services Domain.

This document adopts the Australian Government Digital Service Standard but has been modified for Queensland.

All digital services will benefit from following an iteration model:

Identify users of the service and use existing research and data

Plan user research approach

Do contextual user research with target audience

Design for the user journey

Group and prioritise pain points and develop hypotheses about these pain points
Prototype developed and tested  with internal staff and representatives

No public interaction - only used to ensure service design is likely to hit the mark

Feedback loop for improvements
First small live release used to test all the important connections

Select public can access it and provide detailed feedback

Runs in parallel with usual service pathway so users have a choice

Feedback loop for improvements
Publicly available, feedback still sought from citizens to improve

Controlled usage by public groups to test scale and broad adoption

Services, features, and locations rapidly added to gain momentum

Usual service pathway in place for non-pilot groups

Feedback loop for improvements
Strongly vetted services proven in effect

Critical mass of services in place on new platform

Public launch across multiple channels

Any former parallel versions of the service online are turned off

Feedback continues to be gathered to improve the service and platform features


This document is primarily intended for anyone creating digital services owned by Queensland Government entities.


All new or redeveloped high-volume transactional digital services must be assessed to demonstrate compliance with the Queensland Government Digital service standard. The Digital services assessment framework provides departments with guidance for assessing and demonstrating compliance.

Digital service standard criteria

1.    Understand user needs

Understand user (customer) needs. Research to develop a deep knowledge of the users and their context for using the service.

Design, build and improve lifecycle, and the 5 stages of activities with users, full text equivalent follows image

Text equivalent of image

Design, build and improve lifecycle, and the 5 stages of activities with users. Design includes the discovery and alpha stages; build includes the beta/pilot stage and improve includes the live and support/improve stages. Discovery is shown with 2 speech bubbles, representing deep research of user needs and current solution analysis. Alpha stage shows 2 users, representing testing prototypes with users and determining the minimum viable product. Beta stage shows 4 users, representing testing a service more widely with users and embedding success metrics. Live stage shows many users, representing ongoing process of improving the service based on what users need. Support/improve stage also shows many users, representing the need to collect customer feedback, and keep doing user research and performance analysis to plan improvements.

Why it’s in the standard

You need to understand the people who use your service (your users) and what they want to do (their user needs) to build a service that works for them. You need to understand users and their needs from their point of view and not solely through the lens of the project you have been tasked with.

To do this, you will need to really understand what users are trying to do when they encounter your part of the service and you need to design services that address that context. This will often involve understanding things that are not ‘in scope’ or part of your responsibility so that you can design better services.

You will need to understand all aspects (end to end and across channels) of your users’ current experience. Users should include everyone who is involved in the service delivery: end users, public servants delivering the service and other intermediaries who support end users to access the service.

Your user research needs to cover a wide range of users and show that you understand how different user scenarios may impact service design and delivery. You must include from the earliest stages users who may need assistance to interact digitally or are unable to interact digitally at all.

How you can meet the standard

In Discovery and Alpha stages

During the Discovery stage and Alpha stage the team should have spent a time with end users and learned about their needs. The depth of your research should reflect the scale and nature of the digital service.

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 should 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 network).

What is the real task(s) 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 currently?

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 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?

Consider whether a pilot launch can add insight and reduce risk to your digital service.  If the service can be technically constrained, say by a location or a specific cohort of customers, then a pilot launch can help confirm the validity of your measurements and allow final adjustments to the technology and user experience.

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

By the time you are ready to launch publicly 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.

2.    Have a sustainable 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.

Why it’s in the standard

Good government services are built quickly and iteratively, based on user needs. Your digital delivery team must be set up in the right way to do this.

They need:

  • a broad mix of skills and roles from the start
  • quick decision-making processes and the ability to change and adapt as the service evolves
  • to be adequately resourced and empowered to deliver the product or service.

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 should be able to describe your digital delivery team—the following roles present an overview of all the different roles that might be needed depending on the complexity of the service. Many product teams' function with just three key roles: developer, user experience/interaction designer and product manager. You will determine the best mix of team roles relevant to your service:

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

The core roles in a multidisciplinary team are consistent from discovery through to launch (live):

  • an individual team member might be responsible for more than one role, especially for smaller projects
  • team members can be Queensland Public Service staff or a combination of staff, contractors and secondees
  • you can also connect with knowledge sharing groups to share ideas, solve problems, connect to peers and work in the open
  • consider seeking capability uplift for existing roles through training/mentoring opportunities.

You should also be able to:

  • show the team principles, vision, rituals, and agile practices
  • 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 understanding of the users' needs
  • show the decision making and approval processes
  • know the stakeholders
  • 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 to the on-going product team.

3. Use agile and customer-centred process

Design and build the service using an agile and customer-centred approach, as appropriate for your project.

Why it’s in the standard

Designing services in a user-centred way means that the services you deliver will be easy to use and convenient for the people who need to use them, helping them to stay in the digital channel.

Designing using agile methods allows you to be more proactive, deliver value early and often, and respond easily to change, both in technology and government policy. Services should be improved frequently to keep pace with changing demands.

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 Launch 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 can support frequent deployments with minimal impact to users (external).

4. Understand the tools and systems required

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

Why it’s in the standard

The technology you choose to build your service must help you respond quickly and regularly to the needs and expectations of users. This criteria makes sure you:

  • consider all the risks and constraints associated with the technology you choose
  • avoid contracts that lock you into particular solutions and limit your ability to make decisions to improve the service
  • build a sustainable system that can be easily managed once launched
  • identify the required infrastructure to successfully and continuously deliver the digital service
  • have a procurement approach that will not restrict, inhibit or limit ongoing and future service delivery
  • consider existing tools and systems and avoid unnecessary fragmentation and/or costs
  • consider appropriate tools and systems already in use in government
  • embed measurement tools at the start of development.

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 on the service
  • arrange for appropriate ongoing technical support and service level agreements for underlying or dependent services

By the time you go live (launch publicly), 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 Launch stage

5. Make digital services secure

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

Why it’s in the standard

People who use government services must have confidence that:

  • any information they provide is confidential and stored appropriately
  • the system they’re using is safe and secure
  • they know how their information will be used by government
  • they can easily retrieve information they provide.

If a service cannot guarantee confidentiality, integrity and availability of the system, people will not use it.

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 Information Security Policy (IS18:2018), 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, identifying 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 the Data Governance Guideline and what existing statistical datasets may be relevant to your service
  • 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
  • Senior Information Risk Owner
  • 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 launch 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.

6. Build consistent and responsive design

Build the service with responsive design methods using the approved design standards and the web writing and style guide for digital content.

Why it’s in the standard

Using responsive design, following common design patterns and style guidance for digital content, and making sure the service is accessible means it will be simpler, clearer and faster for all users. It will also be available on the platforms and devices that users choose.

Consistent design that is responsive to different devices helps you to save time and money by re-using something that already exists that follows better practice and is based on data and user research. This means you can concentrate on the unique things your service needs to do.

Responsive design ensures that users can interact with your service regardless of their device size or type, and browser or device processing power. The service should follow mobile-first design principles, consider users on slow internet connections or with limited download data, work well for both mouse and touch devices, and use front-end technology that works well regardless of device processing power.

Writing and designing content so it is consistent, plain and in the language of your users helps people gain trust and confidence in using different services. By providing information they can easily understand they may be less likely to use alternative sources that could be misleading.

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:

  • 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 more clear 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 2.1 level AA
  • ensure appropriate design, content design and front-end developer support is provided to the team.

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

7.    Use open standards and/or common platforms

Build using open standards and common government platforms where appropriate.

Why it’s in the standard

Using open standards and common government platforms helps you to:

  • meet the needs of your users by building with proven solutions
  • make users’ experience of government more consistent, which generates trust
  • save time and money by reusing things that are already available
  • be more efficient by sharing data appropriately
  • move between different technologies when you need to, avoiding vendor lock-in.

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 to launch publicly you should continue applying government solutions while also:

  • building using 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.

8. Make source code open by default

Make all new source code open by default.

Why it’s in the standard

It’s important to share your source code so others with a similar need can reuse it.

Open source helps to:

  • reduce costs for your project and others’
  • avoid lock-in
  • stop duplication
  • increase transparency
  • add benefits, from improvements by other developers.

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.

9. Make digital services accessible

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

Why it’s in the standard

You need to make sure everyone who needs your service can use it. This includes people with disability and older people, and people who can’t use, or struggle with, digital services.

Your service must be accessible to users regardless of their digital confidence and access to a digital environment. This includes users in remote areas and users with different devices.

You also have a legal requirement to ensure your service is usable and accessible to people with disabilities (see the Disability Discrimination Act 1992). Queensland Government agencies are required to meet the Web Content Accessibility Guidelines (WCAG) 2.1 Level AA, which includes Level A (see mandate in Digital services policy). Conforming to WCAG 2.1 means you also conform with 2.0.

How you can meet the standard

You should have an accessibility plan/s for ensuring new and existing digital services are accessible within timeframes outlined in the digital services assessment framework and the transition plan for the digital services policy. This may be agency-wide or for individual digital services and may be separate or incorporated into other planning processes.

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 AA)
  • 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:

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.

This may include:

  • 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 launch publicly you should be able to show:

  • your service is accessible
  • evidence that your service meets WCAG 2.1 Level AA
  • 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.

10.    Test the digital service

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

Why it’s in the standard

All government services should be clear, simple and easy to use, regardless of the technology your users use, their expertise with the subject matter, or their level of digital skill.

You cannot wait until the service is live to discover problems that stop people from using the service. You need to rigorously and comprehensively test every part of the service during development.

How you can meet the standard

The depth of your testing should reflect the scale and nature of the digital service.

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.

11. Measure performance and improve

Measure and monitor performance against your success measures and key performance indicators (KPIs).

Why it’s in the standard

Every service must aim for continuous improvement. Metrics are an important starting point for discussions about a service’s strengths and weaknesses. By identifying and capturing the right metrics—with the right tools—you can make sure all your decisions to improve the service are supported by data.

Key performance indicators

Services should aim to measure the following KPIs:

  • user satisfaction—to help continually improve the user experience of your service
  • digital take-up—to show how many people are using the service and to help encourage users to choose the digital service
  • completion rate—to show which parts of the service you need to fix
  • cost per transaction—to make your service more cost efficient (where possible).

There will be other metrics your service could measure and monitor to understand how it is performing, such as:

  • error rates
  • time to completion
  • costs, benefits and return on investment
  • content metrics (readability, length).

How you can meet the standard

In Discovery stage

You’ll have started early measurement activity during Discovery stage with your user research.

You will need to consider how you’ll measure your service in more detail as you enter Alpha stage.

By the end of Alpha you should have:

  • explored the data that is already available for an existing service, where it is kept and how you might access and use it, and also shared your own insights
  • collected baseline data for the service operation in all of its channels
  • estimated the number of people you expect to use the service
  • started creating a performance framework outlining your objectives and what metrics your team will use to demonstrate you meet them
  • considered the metrics you will need to measure your KPIs and where the data will come from.

In Beta stage

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

  • which metrics and measurements you will use to monitor your KPIs
  • 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 the public Beta stage, you’ll have been able to test your methods for data collection and validated that the data is accurate.

As you go live you should monitor your service performance data for continuous improvement.

Your data should show:

  • user satisfaction has increased
  • digital take-up is increasing in line with service plans
  • completion rate has been maintained
  • cost per transaction is decreasing in line with service plans.

12. Don't forget the non-digital experience

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

Why it’s in the standard

People often start using a service and have to come back to it later, or switch to a non-digital channel to complete the transaction. We need to make sure users’ transitions between non-digital and digital channels (when they need to happen) are as smooth as possible.

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 launch, 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 a shift to the digital channel

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

Why it’s in the standard

As we build simpler, clearer and faster government services the digital channel will become more convenient for users than non-digital channels like post, phone and shopfronts. Increased digital take-up will mean users can spend less time interacting with government. This will result in greater cost efficiencies for government.

Measuring digital take-up helps you to understand how well your service is being used.

We still need to help users who are unable to use digital channels and provide support to those who need it. But we want to ensure digital channels are used whenever possible and to scale back, or phase out, alternative channels when we can.

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 launch 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.

Appendix A Guidance for digital services

1. Understand user needs

Minimum you need to do

  • Identify current and prospective users of the service. Use existing research to understand their needs.
  • Plan a user research approach that suits your project. Gather qualitative and quantitative evidence. Decide how you will analyse and use your insights.
  • Design for the user journey. Group and prioritise pain points and develop hypotheses about these pain points.

Guidance related to this criteria

Further reading

2. Have a sustainable multidisciplinary team

Minimum you need to do

  • Establish a digital delivery team with the right mix of skills and roles, providing for the differing needs of the service design and delivery stages.
  • Create your team by accessing different disciplines, some may cover several roles.
  • Embrace capability development opportunities. Transfer knowledge and skills from any external people who work with the team.

Guidance related to this criteria

Further reading

3. Use agile and customer-centred processes

Minimum you need to do

  • Define the problem or opportunity to address, using evidence, before developing solutions.
  • Set up team practices and processes to collaborate. Work with others to achieve a common vision or goal.
  • Work incrementally starting with the minimum needed to achieve an outcome and building on this.
  • Test and iterate at each step of the way, including ongoing, with very clear and fast feedback loops to improve your digital service.

Guidance related to this criteria

Further reading

4. Understand the tools and systems required

Minimum you need to do

  • Look for opportunities to use ‘common’ or existing tools and systems already in use in government.
  • Build the service with reuse in mind and embed and test measurement tools from the start.
  • Know your initial and ongoing costs and avoid lock-in contracts if procuring.
  • Consider how you will manage and support your service once live.

Guidance related to this criteria

Further reading

5. Make digital services secure

Minimum you need to do

  • Identify data you need to collect and comply with legislation and policy. Assess the level of risk and manage how you store, use and share it. Follow data retention and disposal rules.
  • Consider privacy early and throughout your project. Ensure you meet privacy legal obligations.
  • Embed and integrate security into your service design at the outset. Continue to track and test the security of your service once it is live.

Guidance related to this criteria

Further reading

6. Build consistent and responsive design

Minimum you need to do

  • Follow the whole-of-government content management model.
  • Use the digital design styles and assets in the design system, starting with a mobile first and responsive design.
  • Comply with WCAG 2.1 AA for accessibility.
  • Write using plain language. Aim for a reading age below grade 9 unless there is a clear need for technical language.

Guidance related to this criteria

Further reading

7. Common platforms

Minimum you need to do

  • Look to reuse what’s existing in your agency and across government.
  • Align with the whole of government strategy and technology.
  • Notify Queensland Online when planning a new or significantly redeveloped service to ensure the ecosystem remains linked.

Guidance related to this criteria

Further reading

8. Make source code open by default

Minimum you need to do

  • Assess if and how you can make new source code open and create and implement a plan to do so.

Guidance related to this criteria

Further reading

9. Make digital services accessible

Minimum you need to do

  • Meet level AA of the Web Content Accessibility Guidelines 2.1.
  • Publish content in HTML first and provide an alternative format for non-HTML formats.
  • Make all types of content accessible, including PDFS, Word documents, images, video and audio.
  • Write using plain language. Aim for a reading age below grade 9 unless there is a clear need for technical language.
  • Develop a web content accessibility plan that outlines how services will meet accessibility requirements.
  • Test your design, code and content regularly during development.

Guidance related to this criteria

WCAG and techniques



Easy read documents (examples)


Statistics and user research


Further reading

10. Test the digital service

Minimum you need to do

  • Test the product or service with users.
  • Test the product or service for usability, security, and performance load.
  • Have a business continuity and roll-back plan.

Guidance related to this criteria

Further reading

11. Measure performance and improve

Minimum you need to do

  • Establish success measures for your product or service.
  • Plan how you will measure and monitor the performance of your product or service, including allocation of resources for monitoring and continuous improvement.
  • Implement a process to monitor the performance of your product or service.
  • Use the performance information to improve your product or service.

Guidance related to this criteria

Further reading

12. Don't forget the non-digital experience

Minimum you need to do

  • Understand why users rely on non-digital channels and their digital limitations.
  • Build to make transition to a non-digital channel easy.
  • Plan to shift non-digital users to the digital channel.

Guidance related to this criteria

13. Encourage a shift to the digital service

Minimum you need to do

  • Research with people who aren’t using the digital service. Understand why customers might not want to use your service.
  • Continue to iterate and improve.
  • Tell customers about your digital service. Use non-digital channels to encourage digital take-up.
  • Support the digital service with trained staff.

Guidance related to this criteria


The Queensland Government acknowledges the Digital Transformation Agency for material that has been adapted from the Australian Government’s Digital Transformation Agency Digital Service Standard.

Last Reviewed: 12 August 2022