Service Design Playbook Bc

[Jackie Bullinger]

The goal of the service design playbook is to help designers that are new to service design in government understand how to apply service design thinking at each stage of product delivery and how to work with others in a multi-disciplinary team. It's the collective knowledge and experience of many of the service designers at the Ministry of Justice brought together to support other designers across the organisation.

One of my favourite descriptions of service design is working with users and delivering services, and there are many frameworks and processes that exist in helping us achieve this. The double-diamond method and the Stanford school design thinking process are just a couple of the ones out there.

Our service users are diverse, yet a thread ties them. They are affected by, care for, or are responsible for people who, in turn, are experiencing a vulnerable and distressing period in their lives.

I designed the playbook with all of this in mind. How do we approach the design of complex services that range from web pages to monolith legacy systems? How do we navigate the creation of services that impact people and staff across various prisons?

I collaborated with designers across the Ministry of Justice through a series of workshops and gathered our collective experiences to form the guidance shared in the playbook. The playbook prompts designers at each stage of the delivery process, from exploration to beta, to think about how they can collaborate with teams and stakeholders to deliver a service.

Whether it's looking at problem space and service users, exploring the policy space, to thinking about accessibility - there are tried and tested ideas and methods available to use at each step of every design phase. They include directions of when to use them and why.

I joined the Ministry of Justice from a mainly non-government background. It took a little time to navigate my role and understand the cross-overs of my responsibilities with others in a multidisciplinary team.

Whilst the Digital, Data and Technology capability framework is a helpful introduction to all the professions and disciplines, I recognised the gap in guidance of how these disciplines worked best together to design the service end-to-end. There are seven roles within the user-centred design family and most designers often wear many (multi-disciplined) hats. So, where did the role of a service designer fit amongst all of our wonderful disciplines? Furthermore, how do we describe our part to our team members?

We would welcome feedback on the playbook, which you can share via email, or through comments on the playbook via Miro. We have lots of ideas on developing this further, and if you'd like to be part of that journey - we'd love to hear from you.

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.

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.

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.

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.

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 and respect the privacy and anonymity of participants.

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.

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.

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.

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.

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.

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.

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

It can be difficult to know how to transition from discovery to alpha. Taking research insights and turning them into prototypes can often feel overwhelming. Design sprints provide a structured way to bridge the gap between research and design.

Detailed prototypes are not required to perform usability testing. At earlier stages of a project, simple paper based prototypes can be used to understand user expectations and gauge their initial reactions to the design.

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.

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.

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.

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

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.

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.

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.

c80f0f1006