What do service designers do in the beta phase of a project? (part 2)
Service design is vital because of its continual focus on zooming out and looking at the overall context of what’s about to go live
In the first of this 2-part series on service design in beta, I talked about how service designers apply their thinking during beta and how discovery type work can continue throughout a project. In this post I consider the service in its entirety and how we define and measure success.
Thinking about how the whole service joins up
In a beta project, the actual thing (a new system, application or tool) is being built. Whatever it is, it’s important to continue thinking about the wider service that the thing in question is part of. This is one of the important roles a service designer brings to a beta project – the ability to unpick, understand and consider where the whole service is and how different aspects interconnect.
For example, thinking about how people onboard or offboard the application – do they land on our application via another service, or a web search? What happens once they’re done with our application and what does their onward journey look like? It’s also important to think about how offline channels or support services link into the application. This is not only important for the success of the service and users’ end-to-end experience, designing for the whole service is also one of the 14 service standard criteria to meet in a Beta Service Assessment.
For more complex and larger programs of work, there may be a big service design job to join up a network of individual products or applications and create one whole, consistent end-to-end service. When there are different applications or products involved in making up one service, it’s important the connections between these are understood, considered and well designed. This might involve coordinating large collaborative sessions with different product teams to think about how different streams of work align, and if products and services are being built in a way that meets users’ needs.
Defining success and implementing measurements
Defining success and deciding on key performance indicators (KPI’s) is an important task for beta services as they head towards going live. This responsibility might not lay entirely with the service designer, but it’s an opportunity for them to work closely with business and performance analysts. Deciding on, and defining, these things is important to make sure the service is doing what you’d intended and will help inform ways to improve it in future.
The visibility and understanding service designers have of the whole problem space and users’ needs for a project, can help frame and drive the direction of these discussions. I like to start with a workshop involving the whole delivery team, where we first recap on things like business goals, our MVP scope and the high level user needs. We move on to think about what success wouldn’t look like for us – if the service was a disaster, what would have happened? And finally, flip that on its head to frame success and what’s within our control.
In a second session, we then work through an approach to measuring those success metrics and how the different disciplines can feed into that.
What other team members feel a service designer brings to the table in beta projects
When I spoke to our Head of Design about the role of service designers in beta and how it’s sometimes hard to define, he described what he was hearing in a way that really resonated with me:
“You can’t always be the driver of the car. Sometimes you’ll be the passenger and being a passenger giving the directions is equally as important. It makes sure you get to the right place on time.”
Throughout the lifecycle of a project, different disciplines may lead activities or tasks but, as a multidisciplinary agile team, you will work together taking turns at driving and giving directions.
When I asked my colleagues about the experience of working with service designers in beta, a couple of themes that came through were around steering focus or priorities, and considering the entirety of the problem at hand:
“Having a service designer is really useful to look at the end to end of a service and how things join up.”
“They keep the team focused on whether the larger problem is being solved by what is being shipped.”
Why you should make sure there are service designers in your multidisciplinary beta team
As a product moves closer to live, it becomes increasingly important to zoom out of those finite product details and continue to drive the design of the service by looking at the service as a whole. Making sure the different strands of the service are joined up, the future maintenance and reporting of the service is considered, and the shift in behaviour by users is supported.
While other disciplines within the multidisciplinary team add enormous value by focusing on the more micro details – the words used on screens, the design of screens, the experience of users – service design is vital because of its continual zooming out and looking at the overall context of what’s about to go live, and how it affects the service’s users and stakeholders.