-
Introducing the Digital Service Standard
The Digital Service Standard supports this vision by promoting consistency across digital services and ensuring services:
- are accessible
- are secure
- are transparent
- meet the needs of people and business.
Version 2.0 of the Digital Service Standard has reduced the number of criteria to 10, compared to 13 criteria of the former version released in 2016. The changes reflect the government’s increased level of digital maturity and adoption of trust and protection principles that have increased in the years since 2016. The updated Digital Service Standard strengthens inclusion and accessibility requirements, so no one is left behind when accessing government’s digital services.
The Digital Service Standard is part of a suite of standards and guidance that sits within the Digital Experience Policy. The Digital Experience Policy supports a whole-of-government focus on improving the experience for people and business interacting digitally with government information and services. The Digital Experience Policy includes a suite of standards and guidance that supports agencies to deliver cohesive and consistent digital experiences, including the Digital Inclusion Standard, the Digital Performance Standard and the Digital Access Standard.
Off -
-
-
Disclaimer and copyright
Disclaimer
The purpose of this website is to publish Commonwealth government agencies’ (Source Agencies) content regarding the Australian federal government’s digital transformation policies, strategies and programs (Source Agencies’ Content). Note: the term Source Agencies refers to any and all Commonwealth government agencies, including the Digital Transformation Agency, and joint ventures between Commonwealth government agencies.
The Source Agencies' Content is published on digital.gov.au to be made available to the public and government agencies in one location.
While the Digital Transformation Agency (DTA) is the host of this website, the Source Agencies’ Content is not prepared by the DTA and does not represent any view, endorsement or recommendation of the Source Agencies’ Content by the DTA or Commonwealth, nor does the publication of the Source Agencies’ Content on this website indicate that any particular course of action will be taken by the DTA, the Commonwealth or the Source Agencies.
The Source Agencies’ Content may be updated from time to time. Users are therefore encouraged to return to this website or the Source Agencies’ own websites as required to view changes to the Source Agencies’ Content.
While the currency of the Source Agencies’ Content on this website is monitored, and DTA endeavours to confirm the currency of the Source Agencies’ Content, neither the DTA nor the Commonwealth guarantee the currency, accuracy, reliability or completeness of the Source Agencies’ Content or any linked site.
The DTA and Commonwealth do not accept any legal liability whatsoever arising from or connected to the Source Agencies’ Content or any reliance placed by users upon the Source Agencies’ Content.
Links to external websites
Links to any external websites are provided for the user’s convenience and informational purposes only and the Commonwealth accepts no responsibility or legal liability for material contained in any website or material that is linked to this website.
Security of this website
While a range of security controls are applied to protect this website from unauthorised access, users should be aware that the World Wide Web is an unsecured public network that gives rise to the risk that:
- the user’s transactions are being viewed, intercepted or modified by third parties; and
- files which the user downloads may contain computer viruses, disabling codes, worms or other devices or defects.
Users are encouraged to take appropriate and adequate precautions to prevent damage to their computer system, software or data. See how by visiting Stay Smart Online.
The DTA and Commonwealth accepts no liability whatsoever for any interference with or damage to a user’s computer system, software or data occurring in connection with or relating to this website, its use or the viewing or downloading of any Source Agencies’ Content or visits to external websites from links on this website.
If contributing any questions or comments, users are encouraged to:
- protect their personal privacy and that of others by not including personal information about themselves or others (such as names, email addresses, private addresses or phone numbers);
- post material that is relevant to the topics and issues being discussed, particularly if seeking a response;
- represent their own views and not impersonate or falsely represent any other person.
No spam
The contact forms that may be available on this website are for the benefit of users only. Any unsolicited electronic messages received via any contact form on this website or published contact address may be referred to the Australian Communications and Media Authority or other authorities for prosecution.
The Commonwealth has strict guidelines on discrimination and intimidation. No response will be given to, or content accepted, which is irrelevant, pornographic, discriminatory, hateful or threatening, and actions which may offend, insult, humiliate or intimidate. Users who perpetrate such actions may be removed or blocked from accessing this website, and may be reported to law enforcement agencies for investigation. See also the section titled “Identification of users” below.
Visiting this website
When an individual user looks at this website, the DTA’s server makes a record of the user’s visit and logs the following information about the user:
- their server address
- their domain name
- the date and time of the visit to this website
- the pages accessed and documents downloaded
- the previous site visited
- the type of browser used.
This information is collected to facilitate website and system administration, including to monitor and seek to prevent security breaches, and to facilitate enhancement of the website.
Identification of users
The DTA does not attempt to identify users or their browsing activities except in the unlikely event of a criminal investigation, for example if a law enforcement agency has issued a warrant to inspect server logs.
For more information on the use and disclosure of user’s information in relation to this website, please visit our Privacy Statement.
As noted in the section titled “Links to external websites” above, external sites or content that is linked to or from this website, are not under our control and users are advised to view their privacy statements separately.
Copyright
With the exception of the Commonwealth Coat of Arms and where otherwise noted, all material presented on this site is provided under the latest Creative Commons Attribution licence.
The details of the relevant licence conditions and the full legal code for the licence are available on the Creative Commons website.
Use of the Coat of Arms
Guidelines for use of the Coat of Arms are published by the Department of Prime Minister and Cabinet.
Attribution
Anyone using this material should note that it includes public sector information licensed under the UK Open Government Licence v2.0 and v3.0.
-
As government service delivery and digital services mature, the DTA will review the Digital Service Standard and make improvements in line with agency application and feedback.
-
Communicate the benefits of service design and delivery
Understand and communicate the value of using agile processes to build digital services.
The service design and delivery process puts people and businesses at the centre of government service delivery. Communicating the value of service design and delivery is the best way to make sure teams and decision makers in your agency understand the process and get onboard.
Meet the Digital Service Standard
The Digital Service Standard guides teams to create and maintain digital services that are:
- user-friendly
- inclusive
- adaptable
- measurable.
You’ll need to follow the service design and delivery process to meet the Digital Service Standard requirements.
The 4 stages of service design and delivery
Government traditionally creates services in response to policy needs. This means user needs go undiscovered until after a service is released. Service design and delivery changes this by starting the process with the user in mind.
- Discovery stage – the team gain a deep understanding of the user needs and develop a hypothesis to solve the problems
- Alpha stage – the team builds prototypes to test the hypotheses identified in the Discovery stage
- Beta stage – the team builds and tests the solution they validated in the Alpha stage
- Live stage – the team maintains and continuously improves the service.
-
Own the whole user experience
A service may have multiple products built by different teams – you need a service manager who understands and owns the whole user experience across all products.
We know people struggle to get things done with government because services are disconnected. This means we need to work across government to do the hard work to make it simple for users.
Instead of expecting people to know how government is structured, we need to look at the user experience and understand how they get from point A to point B.
This includes the products and touchpoints owned by other parts of government.
-
To get a task done, a user might need to deal with different parts of government or third-party suppliers. To build the right service we need a senior service manager who can take responsibility for the whole user experience.
-
Government services and products
Services are a group of transactions, activities or information that help someone do something, like being able to drive, buy a house or become a teacher.
When people use commercial services, they choose a service that meets their needs. Government services are different. The user doesn’t get to shop around, their only option is to use the service government designs. This is why it’s important to design government services that are simple and easy to understand.
Services use products
A service is made up of a series of smaller products designed to meet user needs.
For example, to help a user meet their goal of being able to drive, a service might include these products:- details on what you need to learn to drive – an information product
- an online driving knowledge test – a web application product
- booking a driving test – a calendar booking product
- getting a driving license – a process that creates a physical card
- paying your annual fee – an online payment product.
-
If products are owned by different parts of government that are working in different ways, it can make it harder for the user to do what they need to do. This is why we need service managers that own the whole experience.
-
User experience and user journeys
A user journey is the series of processes and touchpoints the user goes through to complete the service. Different users go through similar user journeys but may have completely different experiences.
For example, a user who doesn’t have a stable internet connection may have a bad experience trying to complete the service. Another user may go through a similar journey with a good connection and have a good user experience.
-
Owning the whole user experience means you try to create a good experience for all users and all journeys.
-
Service manager role
Every service needs a single service manager that owns the whole experience for the user.
Service managers are experienced leaders with a strong understanding of their service and its users. Service managers:
- represent their service at all agency levels
- work to make sure the service is delivered successfully and meets user needs
- have the decision-making authority to complete the service.
-
The service manager makes sure each product works together to give the user a consistent experience.
-
User needs, not government needs
To build services that are complete and reflect the whole user experience we need to start with needs – user needs, not government needs.
Owning the whole user experience means a service:
- is built on user needs and reflects how users think about the service and what they want to do
- has a beginning, middle and end that reflects how the needs of users change, for example finding out if you’re eligible to become a teacher is different to gathering documents so you can apply
- can be completed as needed by phone, online and on paper
- is accessible to everyone, for example people in a wheelchair, someone who is blind or deaf or someone who has an impaired memory.
-
Start the Discovery phase
Now you understand why owning the whole user experience is important, you can get ready for Discovery.
Before you start Discovery, you should:
- understand how a multidisciplinary team works and have the right roles
- understand why we need to own the whole user experience
- understand agile delivery
- know your stakeholders and subject matter experts
- have a user research plan ready
- have review and approval processes in place
- understand the legislation, regulations and policies that impact your service
- have a space for the team to collaborate either in person or virtually with the right equipment including internet access and IT.
Start the service design and delivery process by moving on to the Discovery stage.
-
Discovery stage: exploring the problem
Before you start designing and building, you need to understand the users and what they need a service to do.
The purpose of Discovery is to gain a deep understanding of the whole user experience.
The Discovery stage is where the Service Design and Delivery Process starts. This will help your team challenge their existing ideas and solutions. You won’t start prototyping and testing until the Alpha stage.
-
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.
-
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.
Connect with the digital community
Share, build or learn digital experience and skills with training and events, and collaborate with peers across government.