This playbook is a crash course on service design. It works alongside the 14 points set out in the Digital Service Standard to provide the basics needed to get started on a digital service.
Service design is a process that involves:
- conducting user research to better understand and build empathy for users
- building prototypes to act as the first models of a service
- testing a service regularly with the people who will use it
Understanding the people who will use a service helps to create solutions that work for them. Service design engages users throughout the design process so that decisions are made using observations and evidence, not assumptions.
A service is any activity that helps someone complete a task. With that in mind, all public servants – whether they work in digital, communications, policy or operations – are involved in service design.
Designing and delivering great service is at the core of public service. Using service design methods ensures that good ideas are implemented properly the first time.
Life's too short to design something that no one wants – Ash Maurya
The service design journey follows four phases, with each phase driven by user needs:
| User needs | |
|---|---|
 |
Conducting user research within the Ontario Digital Service and critical partners |
 |
Developing and testing prototypes with small user groups |
 |
Developing at larger scale, making test version available to the public |
 |
Continuing to improve based on user feedback |
User feedback quickly and continuously checks that a service works well for the people who will be using it.
By making small adjustments throughout a project instead of big changes later, costly changes are avoided.
Talking to users and investigating underlying issues before building a solution focuses efforts on designing a service that meets people's needs, as well as policy goals.
The team designing a service can't experience that service the same way that their user does. Service design replaces assumptions with observation and evidence.
You're almost always wrong about your users – Manik Rathee
Service design doesn't have to be expensive. User interviews, usability testing, prototyping and many other activities can be done for little-to-no cost. All that's needed is a piece of paper, a pencil and some elbow grease.
Service design processes were created for large, complex problems. The more complicated, unclear and unique a situation, the more valuable it is. Service design excels when the problem is unknown or the path forward is unclear.
Talking to users adds significant value for every hour spent. Feedback from users will validate or correct assumptions, leading to better decision-making during the project and avoiding expensive fixes after the service launches.
You're not a user experience designer if you don't talk to users – Whitney Hess
Discovery helps define a service's potential users and how their needs can be met.
In discovery:
- conduct user research
- decide who the primary user groups will be
- learn about the people who will use the service
- ask users what they want in a service
- check if there are existing or non-governmental services that meet user needs
- identify policies and other barriers that will make meeting user needs difficult
- document the findings
It can be tempting to skip discovery and design a solution based on similar services or brainstorm potential options immediately. These are solution-oriented design processes, but service design is a user-oriented design process.
All services are different, but most projects need 4-8 weeks to for discovery.
Give me six hours to chop down a tree and I will spend the first four sharpening the axe – Anonymous
The goal is to learn about users and the challenges they face, not to gather evidence to support a predefined solution.
Avoid making assumptions or thinking about solutions before the research is complete. Solutions and prototypes are built in the next phase, alpha.
Be flexible. User research is a fluid process, often leading to unexpected insights. Use research even if it doesn't align with expected findings, to show how far a problem might extend.
Existing research reports and discussions with stakeholders are useful, but they can't replace talking to real users. Go out and find people who will be using the service. Talk to them, observe them and learn how they feel about the service.
Research is the gathering of facts. In the absence of facts, you have assumptions. And assumptions are the enemy of design – Mike Monteiro
The first step in service design is to learn about the people that will be using the service. The only reliable way to do this is through first-hand research. When doing user research, be prepared to confidently explain the research methods being used. Respect the privacy and anonymity of participants.
These research methods can be used to understand the needs of users and their behaviour:
| What | How | Result |
|---|---|---|
| User interviews Use scripted questions to lead one-on-one discussions with users |
Interview and record users as they describe their needs and how they use a service | Understand who users are, see topics from their perspective and develop empathy for users |
| Ethnographic research Observe users and their habits in their natural environment |
Tag-along and observe users in their daily routine, without giving them specific tasks to complete | Learn how a service fits into the everyday lives of users and whether people use a service without prompting |
| Usability testing Give users a service or prototype to try out |
Observe users completing specific tasks in a prototype, asking them to speak aloud about what they are thinking and doing during each task | Identify challenges and pain-points when completing tasks and find out what users are thinking about while they use a service |
| Diary studies Ask users to document their thoughts and actions over a longer period |
Ask users to submit written notes, photo montages, video recordings or social media posts | Discover the daily habits of potential users and gather data on long or unpredictable processes |
Avoid relying on traditional research methods like surveys or focus groups. Traditional research methods won't give a deeper understanding of what causes certain user behaviours. Before using any research method, learn its strengths and limitations.
Involve everyone on the team in the user research process, at least as an observer. Reviewing transcripts and summary reports is helpful but there is no replacement for first-hand observations and interactions with real users. Ensure the whole team can participate.
Turn research findings into insights to inform the design of the service.
If I had asked people what they wanted, they would have said faster horses – Henry Ford
Consider documenting research in one or more of the following ways:
| What | How | Result |
|---|---|---|
| Personas Develop fictional characters to represent the key users of a service |
Research different sets of users and create mini-biographies that describe their typical behavioural patterns, beliefs, attitudes and challenges | Learn what kinds of users need to be considered when designing and making decisions about a service |
| Journey maps Draw a map of all the experiences users might have as they navigate through a service |
Sketch a complete user experience, told from the user's point of view and document how users handle different scenarios in a service | Identify opportunities for service improvement, break down assumptions about the user experience and build an empathy for users and their journey |
| Service blueprints Draw diagrams that show all the service delivery processes that support a service |
Outline the processes, support, systems and policies that are involved in each stage of a service | Build an understanding of the internal workings of the government and how they interact with a service |
| Affinity mapping Group information to uncover patterns and insights |
Place related pieces of information together and organize them into groups | Reveal unexpected relationships between different pieces of information |
| User stories Develop short sentences written from the user's perspective, describing a user need and the reason behind it |
Write user stories by following a simple template: As a <type of user>, I want <some need> so that <some reason> | Figure out different needs that a service must address, shifting the focus from creating detailed requirements to discussing user needs |
Discovery introduces a new way of working and new skill sets and abilities. A strong multidisciplinary team capable of a wide variety of tasks is needed.
During discovery, the team needs the skills to:
- learn about the users of the service by conducting direct interviews, observation and testing. How users behave, their challenges and what they need are essential details
- understand current policy, technology and business process environments
- document and draw insights from information collected
- manage the design process and use what is learned to draw connections to other work
Most teams will have one or more people dedicated to the following roles:
- Product manager
- Technology lead
- Service designer
- User researcher
- User experience designer
- Content writer
- Subject matter expert
The team needs to be flexible as it moves through the service design process. Since not all roles will be required in every phase of service design, team membership will have to adapt based on the needs of the service and the phase of work.
Make sure team members understand their roles and responsibilities for discovery. Everyone has their own expertise, but everyone still participates in the research process. User research is a team sport and everyone needs to play.
By the end of discovery, expect to have:
- a clear understanding of the problems that the service will address
- a documented set of user needs and stories
- a plan for what will be prototyped and tested in alpha
- a list of what resources will be required to support work in alpha
Not all projects should go beyond discovery. It's acceptable – and sometimes advisable – to end a project at this phase if that's what the evidence supports. It's better to refocus efforts than to design a service that will be unsuccessful.
Consider stopping the design of a service if research indicates:
- there is no user need for the service
- the user need is already being met by an existing service, either internally or by a third party
- policy, technology, financial or other constraints prevent the service from meeting user needs
- it's not cost effective to develop the service
You can use an eraser on the drafting table or a sledge hammer on the construction site – Frank Lloyd Wright
Stopping after the discovery phase should not be considered a failure. The purpose of discovery is to understand users and determine what they need. Sometimes that means changing plans or taking a new direction, and that's okay. The design process is iterative, not linear. Sometimes the outcome of discovery is a need for more research. The goal is to create better outcomes, not to implement a new service at all costs.
While discovery is about research, alpha is about testing hypotheses and experimentation. The purpose of alpha is to determine how to meet the user needs that were identified in discovery. It's an opportunity to quickly test many different approaches with users before building a service.
Alpha is fast-paced and may go in many unexpected directions before defining what the final solution could look like. Try new approaches to solving problems and test them quickly, so that potential issues can be found and fixed before investing too much time and money into one design.
Fail fast, iterate, explore. This isn't construction or rocket science – 37 Signals
In alpha:
- work directly with end users and stakeholders to co-create solutions
- build multiple prototypes of the service
- continuously test prototypes with users
- demonstrate that the service is technically and financially feasible
- estimate how much the service will cost
- identify existing processes or policies that will need to change to support the service
Alpha is a cyclical process of designing and testing potential solution options. Prototypes are built quickly, often together with users and stakeholders, and tested with real users. Feedback and testing results are used to improve the service. This process repeats itself until the prototype meets user needs and the first working version of the service is ready to be built. The first working version is called the minimum viable product. It will be built in the next phase, beta.
All services are different, but most teams will need 8-12 weeks to complete alpha.
To determine what solution will best meet the needs of users, it's important to build and test multiple concepts and hypotheses. The objective is to identify and learn from potential issues while there is still time to make corrections.
We want to give ourselves the permission to explore lots of different possibilities so that the right answer can reveal itself – Patrice Martin
Alpha involves the creation of mock-ups and prototypes, but it doesn't involve building the solution. The tools in alpha are needed to select a path forward, but are not meant to be phase one of a multi-phase build. The technical experts on the team should identify feasible solutions and help inform prototypes to test those ideas.
Prototyping is a useful tool to turn ideas and plans into real objects that users can understand and interact with. Prototypes are not presentation tools, and the primary audience of a prototype needs to be the user. Involve leaders and stakeholders in test sessions so they can understand the problem from the user's perspective.
Well-designed services extend far beyond what the user sees. Underlying processes, customer support and technology impact how well a service performs. Alpha is about designing the entire end-to-end service. Like a chain, a service is only as good as its weakest link.
Through research, the team should have an understanding of their users and their needs. These insights can then then be used to brainstorm ideas for solutions.
Remember that these brainstormed ideas can't be treated as fact or final solutions. They are assumptions that must be tested. The best way to do this is to turn the ideas into prototypes that can be tested with users.
Prototypes are physical, experimental versions of a service that are used to test ideas and concepts before building the service. It is easier to get useful insights when users can experience the service rather than imagining it. By making interactive prototypes for users, ideas spring into action and a common understanding of the service is formed.
Prototyping is the conversation you have with your ideas – Tom Wujec
Prototypes can be:
- simple paper sketches
- wireframes that use images to show the functional elements of each webpage and screen
- interactive digital mock-ups that mimic the functionality of a working website
Prototypes don't need to be expensive and they shouldn't take long to build. They need to be realistic enough to get meaningful feedback. Create something informed by research that users can react to.
Regardless of the form a prototype takes, the process is iterative. A good prototype leads to constructive feedback and further insights, not agreement.
It is extremely important that all members of the team are closely involved in prototyping during alpha, even if prototypes are simple. Not only does this lead to better design outcomes but it also helps to ensure that the team has a common understanding of the product and any design decisions that the team has made.
Co-creation is based on the belief that users are essential to the design process. In collaborative workshops, solutions to problems are found when designers, stakeholders and users work together.
Co-creation is incredibly efficient when users are allowed to take ideas in unexpected directions. Processes that normally take months can be condensed into a few days, as designers turn ideas into basic prototypes and get instant feedback from stakeholders and users. Potential solutions can be further refined into prototypes that can be tested with a wider range of users.
This approach sparks conversation between people that don't often interact. Beyond uncovering new insights, co-creation helps participants understand each other's motivations and creates empathy between service providers and users.
Alpha is about building and testing prototypes to make sure the right problem is being solved in the right way, before building a service.
Testing quickly determines if a design meets user needs and how easy it is to use.
| What | How | Why |
|---|---|---|
| Card sorting a method for understanding the mental models people use when interacting with a service |
users physically organize topics written on cards into groups and hierarchies that make sense to them | uncovers expectations users have when using a service and the categories they use to organize content |
| A/B testing a method of comparing two options to determine which one will result in a better outcome |
|
shows how a design decision changes user behaviour, and which design best helps users achieve their goals |
| Usability testing a method of testing an existing service or concept with real users |
|
identifies usability issues and measures the effectiveness of a service |
These testing methods are qualitative and not based on statistically significant sampling. However, when doing usability testing, a handful of users is often enough to uncover clear and helpful insights.
If the user can't use it, it doesn't work – Susan Dray
Each phase of the design process builds on work already completed and introduces new activities to advance the service further. Alpha moves the focus from research to experimentation, and with that comes a new set of skills and expertise.
During alpha, teams will need the skills to:
- interpret user research, transforming helpful insights into design decisions
- plan and facilitate co-creation sessions
- construct and test prototypes of the service
- understand what may be technically possible
By the end of alpha, expect to have:
- a clear vision for the service that will be built in beta
- thoroughly tested prototypes that demonstrate the design of the service
- a plan and prioritized list of features to be completed in beta
- a clear understanding of the technology that will be used to support the service
- a business proposal to justify funding for the next phase of work
The goal is to have defined a minimum viable product that can be built and more broadly tested in beta. The minimum viable product is the first working implementation of a service. It is the quickest and simplest version of a service with just enough features to meet basic user needs and provide value.
After completing alpha, it may make the most sense to stop and not progress to beta. That's perfectly fine, as not all projects should progress beyond alpha.
Stopping at this point should not be considered a failure. It's better to stop building a service that won't work before more resources are spent.
I have not failed. I just found 10,000 ways that won't work" – Thomas Edison
Consider stopping the development of a service if alpha indicates:
- there is no user need for the service being developed
- policy, technology, financial or other constraints will prevent the service from adequately meeting user needs
- it's not cost effective to develop the service
- adapting or developing another service is a better option
If any of the above apply to your project, it might be good to go back to discovery or start alpha over. Though it can be natural to perceive this as a setback, the lessons already learned will improve the quality of the final service.
Beta is when the service finally comes to life. The goal of beta is to build a real service that works well for a larger group of people. The prototypes that were developed and tested during alpha are used to build a minimum viable product in a live, user-facing environment.
Build quickly and in small segments, taking the time to confirm that each segment of the service is on the right track. Launching a public service is the ultimate usability test, as it collects real data and user feedback. Feedback is used to refine the service, adding and adjusting features until the service is complete.
In beta:
- make a prioritized list of the user stories that have already been researched
- build a minimum viable product that can be used by the public in a live environment
- continuously test the service with users to collect feedback and discover helpful insights
- test the design for accessibility and use assistive devices like screen readers
- measure the service against key performance indicators
- release updates to patch and improve the service
- resolve any remaining technical or process-related challenges
All services are different. Most teams need at least 3-4 months to complete beta.
Beta is not about perfection, it's about progress.
It's easy to surrender to perfectionism and delay the launch of a service until every single issue has been worked out and it functions perfectly. No service will ever be perfect. Services can and should be modified after launch, which is what makes continuous testing and improvement critical.
As soon as the service can provide value, or provides more value than the existing service, it's ready to launch.
Perfect is the enemy of good - Voltaire
The research and prototyping from discovery and alpha help to form a prioritized list (backlog) of user stories. This backlog functions as a list of features and improvements to incorporate into the service.
The backlog is never complete. Throughout beta new feedback will emerge and the backlog will be updated with more features and improvements.
The goal of beta is to prioritize these requirements into small tasks and begin to build a working service.
The scrum methodology was developed to support rapid software development, but the concept has been adopted by many fields, including service design. Scrum adds formal structure to abstract, messy and fast-paced creative work.
Gain a basic understanding of agile scrum, as it's likely to be used at some point.
Scrum is the most widely used framework for agile development. The idea is to break down an entire service into small features that are completed in fixed-length intervals called sprints.
Before each sprint, the team selects features from the backlog, determines how to implement them and assigns the work to someone. Before work begins, the team must understand the objective of the sprint.
Every day the team meets for a 15-minute daily scrum or "standup". These are discussions to improve inter-team communication, promote quick decision-making and avoid the need for longer meetings.
Each member of the team briefly says:
- what they accomplished in the previous day
- what they will focus on today
- any barriers that are preventing them from accomplishing their tasks
Sprints are usually 2-4 weeks long. At the end of a sprint, the selected features are complete and ready to be added to the service. Each sprint has a consistent duration, with new sprints beginning as soon as the previous one is complete.
During sprints in beta, the team will work in parallel. While the developers build selected features, the rest of the team tests the features that are already built.
This cycle repeats itself until all the features in the backlog are complete. The scrum methodology ensures that the most important features are built first and a prioritized list of outstanding features is maintained for future development.
Once enough essential features have been developed to form a minimum viable product, the service is launched as a beta for live testing. While feedback and analytics are collected to help inform the backlog, sprints continue, with new features and improvements being added to the service after every sprint.
Remember to track and report on key performance indicators, even during beta. At a minimum, analyze service usage with Google Analytics. Analytics are essential for measuring how well the service is doing and identifying weak points that require further attention.
Design is not what it looks like and feels like. Design is how it works – Steve Jobs
During beta, the team is focused on developing and testing the first iterations of the service while building towards a live version. The team is frequently iterating on the service and conducting usability testing, all while working in an agile way.
The team roles in beta won't change substantially from alpha, but the team may need to grow. User experience designers, developers and content writers will be essential for beta.
By the end of beta, expect to have:
- a fully functional version of the service that adequately meets user needs
- a list of major bugs and usability issues that have been identified and fixed
- a backlog of features to complete in order to improve the service
Before advancing to live:
- launch a version of the service for public consumption
- conduct usability testing to test and improve the design of the service
- use analytics to track and measure key performance indicators
- update any required policies to support the service
- plan how to conduct user research and testing on an ongoing basis
- keep an up-to-date and prioritized backlog of remaining features
Live begins when the service has officially launched. While most people understand the purpose of live, it's not always given the attention and resources it deserves.
Without proper resources devoted to live, services become quickly outdated and fail to meet both the Digital Service Standard and user needs.
Continuous improvement is one of the core principles of service design and that's what live is all about. The goal is to continuously monitor, research, test and iterate for as long as the service is active.
In live:
- monitor and track the status of the service and key performance indicators
- conduct ongoing user research and usability testing every three to four months
- continue building features from the backlog and releasing improvements to the service
- communicate and celebrate the successes of the service
- ensure the service continues to meet the Digital Service Standard
Live is not about "keeping the lights on," it's about continuous improvement.
Once a service launches, it's important to continually monitor its status, maintaining uptime and availability. Work on an active service should never be considered finished.
User's needs and behaviours change over time, so services must adapt to keep pace. User research, testing and analytics should be used to make continuous improvements.
Live works in a similar manner to the previous three phases. In many ways, live involves repeating discovery, alpha and beta in smaller iterations.
The goal of live is to use analytics, research and testing to continuously find and address problems that users have. Once problems are uncovered, conduct research to understand the issue. Prototype, test and build new features to improve the service.
Monitoring the performance of a service prevents and uncovers potential problems. Use Google Analytics to alert the team of areas for improvement and to initiate further research and testing.
The key performance indicators for a service measure the overall health of the service and identify priority areas to focus on. If a page has an especially high drop-off rate (the user leaves before finishing or doesn't follow the expected path), investigate the root causes of this behaviour.
Good performance monitoring should extend beyond Google Analytics, which will not uncover the user behaviour behind the statistics. It's important to understand the limits of analytics and put processes in place to track all aspects of the service's performance.
The product manager is accountable for the ongoing success of the service. It's their job to ensure that the service continuously meets the Digital Service Standard and the evolving needs of the users.
Monitor social media, direct user feedback channels and conduct usability testing. Have at least one round of testing quarterly.
As new problems are uncovered, add new features to the backlog to fix them. Rank these features by priority, and then begin testing and implementing improvements to the service.
By iterating, we validate our ideas along the way because we're hearing from the people we're actually designing for – Gaby Brink
Don't forget to celebrate and communicate successes, even the small ones. Recognizing good work is valuable for team morale and builds a sense of community across government.
Blogging is a great way to share the positive work being done within government, in Ontario's communities and by the public at large.
The Ontario Digital Service has a public blog where work, ideas and thoughts on digital government are shared. Anyone that works on government services is welcome to contribute to the blog, and a diversity of voices and opinions are welcomed. Any team member can write a blog post, not just the product manager. The Ontario Digital Service is always looking for new stories highlighting excellence in digital government.
Most features will be built at this point, but it's not time to disband the team. Ongoing user research, testing and improvement are essential parts of live and will require a dedicated team.
To reflect the change in workload, reduce the size of the team to a few key roles. Keep a sustainable and multidisciplinary team that can:
- finish building any additional features from the backlog
- manage, maintain and monitor the success of the service
- conduct ongoing user research and testing to update and improve the service
A product manager must continue to be accountable for the service as long as it is live.
At some point, the service may no longer be needed. Government policy changes can make a service obsolete, or a new service may better meet the same user needs.
When this does happen, support users through the transition. For some users, it may be a significant change. Make sure they are aware of the changes and understand how this impacts their access to the service. If a new service is developed or exists elsewhere that meets the same user need, tell users about it.
Make sure users know:
- what is being changed or cancelled and the reasons why
- how this impacts them and their ability to have their needs met
- what will happen to their data or any outstanding service issues
Share the team's knowledge, findings and experiences with a new service's product manager and always make sure that contact centres, front-line staff and other support structures are aware of the changes and are able to support users.
It's easy to catch the design thinking fever. Luckily, there is a world of service design resources to explore.
These resources range from design thinking as an overarching field of practice to the specific tools and methods used in service design.
- This is Service Design Thinking
- Don't Make Me Think, Revisited: A Common Sense Approach to Web Usability
- The Design of Everyday Things
- Designing for the Digital Age: How to Create Human-Centered Products and Services
- Interviewing Users: How to Uncover Compelling Insights
- Just Enough Research
- Interviewing for Research: A Pocket Guide to Design Research
- The Moderator's Survival Guide: Handling Common, Tricky, and Sticky Situations in User Research
- Rocket Surgery Made Easy: The Do-It-Yourself Guide to Finding and Fixing Usability Problems
- Handbook of Usability Testing: How to Plan, Design, and Conduct Effective Tests
- Moderating Usability Tests: Principles and Practices for Interacting
- Paper Prototyping: The Fast and Easy Way to Design and Refine User Interfaces
- Prototyping: A Practitioner's Guide
- The Ultimate Guide to Prototyping
- Australia Digital Transformation Agency
- GOV.UK Service Manual
- New Zealand Government Web Toolkit
- 18F Method Cards
- Usability.gov
- Service Design in British Columbia
Notice any glaring omissions that should be included on this list? Send them to digital.standard@ontario.ca
Developing excellent digital services requires a variety of skills and abilities. The roles and number of people required will change depending on the needs of the project and the service design phase.
Responsible for the overall delivery and operation of the digital service.
Portfolio managers are experienced leaders with a strong understanding of the service and its users. They represent the service at all levels within their organization, working to make sure that it's delivered successfully and meets both user needs and organizational priorities.
Portfolio managers are senior business executives (often directors) with the capacity to remove obstacles, champion the service at the most senior levels and assist in making sure that internal processes are focused on helping the service be successful. They need to be available to the team but not necessarily present with them at all times.
Involvement : Across all phases but not present 100% of the time
Works with the team to create the vision for the service, and sets the day-to-day priorities to fulfil that vision and ensure the team delivers.
The product manager (or product owner) provides the vision for the service and sets the day-to-day priorities for the team. They need to have a good understanding of user needs, organizational goals and stakeholder priorities. Ultimately, the product manager has the decision-making authority to deliver on all aspects of the service. They are responsible for the development, operation and continual improvement of the service.
Involvement : Across all phases
Helps agile teams to deliver high-quality services, removes obstacles or blockers to progress and leads service meetings.
The scrum master (or delivery manager) helps to structure and facilitate the agile development process. Their role is to track progress and lead service meetings, including daily stand-ups, sprint planning sessions and retrospectives. The scrum master works with the team to make achievable commitments to the product manager and works with the product manager to remove obstacles to delivery.
Involvement : Across alpha and beta phases
Help develop a deep understanding and empathy for the users and their needs so that the team can design the right service in the right way.
User researchers are responsible for building an understanding of the service's users and their behaviour and providing insight to the broader team about how users interact with the service. They design, conduct and analyze the results of user research and usability testing to help give insights on how the service should be designed.
Involvement : Across all phases
Design user-focused services and contributes to the development and continual improvement of service iterations.
Service designers leverage design practices to bridge the gap between research and final solutions. They are responsible for working with users and internal stakeholders to identify, prototype and test the service. They explore the various ways that a service can be delivered, looking for the solution that will best meet the needs of users and the broader organization.
Service designers are responsible for mapping the proposed solution across multiple delivery channels, such as web, call centres and correspondence. They help to identify the key elements of the minimum viable product to be built during beta.
Involvement : Across all phases
Responsible for designing a user-focused, consistent and accessible service by making use of established design patterns.
Designers create the user interface for the service, ensuring that it is designed to work across devices and browsers, meets web standards, is accessible and is able to be used by people regardless of their digital literacy.
They make use of existing design patterns and contribute to the design community to improve and add to future design patterns. They work closely with:
- the content writers to improve the usability of the service
- the service designers to conduct usability testing and design experiments
- the technical team members to develop and iterate prototypes with a view to continuously improving the service
Involvement : Across alpha, beta and live phases
Ensure that content is simple, clear and written in plain language so that users receive the information that they need and understand what the government requires of them.
Content writers create content that will help users understand what they need to know and do. They review content to make sure it's accurate, relevant and follows style guide standards.
Content writers work closely with subject matter experts, user experience designers and service designers to continuously improve written copy. Content writers also work with the government's overall content community to develop a common style and lexicon that is clear, approachable and consistent across multiple platforms.
Involvement : Across alpha and beta phases
Works with the team to decide on technical requirements and improvements for software development and help solve any technical problems that may arise.
The technology lead is the most senior technical person on the team. Their role is to:
- select the technology products best suited to support the service
- direct the technical build and all supporting technical staff
- provide coaching and feedback to other technical team members
- identify technical options and inform architectural approaches
- make sure that any new or updated platforms, services, transactions and architecture are robust, scalable, open and secure
Involvement : Across all phases
Build quality, well-tested software and services according to standards and best practices.
Developers write, adapt, maintain and support well-tested code to help build services that meet the needs of users.
Some developers will specialize in front end or back end development, but most will have solid skills in both. A good team has a mix of both front end and back end skills. As they work, they're expected to keep security, accessibility and open standards in mind. Developers help solve technical problems when needed.
Involvement : Across alpha, beta and live phases
Design, implement and run the production systems, help the team deploy features quickly and reliably and ensure the service runs smoothly.
DevOps engineers are responsible for keeping services online and establishing effective deployment and testing pipelines.
They work closely with developers to make sure that all technology is built with consideration to how it will be operated, and puts the foundations in place for the service to be hosted and deployed.
DevOps engineers have expertise in technical infrastructure, configuration management, monitoring, deployment and operating systems. Developers and DevOps engineers are expected to share responsibility when supporting the service outside of normal hours.
Involvement : Across alpha, beta and live phases but not present 100% of the time
Helps the team understand user behaviour and measure success by providing quantitative and qualitative evidence from web analytics and user feedback.
The digital performance analyst defines, collects and presents key performance data from the service. They support portfolio and product managers by generating new and useful information and translating it into recommendations that will improve the service for users. The performance analyst makes sure that the service meets all key performance indicators.
Involvement : Across beta and live phases but not present 100% of the time
Provide high-level knowledge and in-depth expertise about a particular subject matter area.
Subject matter experts vary widely depending on the type and scope of the project. They are collectively responsible for providing expert business knowledge of how the service or organization currently functions. Examples of subject matter experts include policy advisors, lawyers, privacy experts, front-line staff and call centre workers.
Involvement : Across all phases but not present 100% of the time