What do service designers do in the beta phase of a project? (part 1)

My focus has been continuously championing the need to think about the whole process and service at a high level

This is the first of 2 posts looking at the role, and value, of service design in the beta phase of a project.

I’m Morrighan, a service design practitioner at dxw. In May 2022, I had my first experience working on a beta project building a regulated professions register for The Department for Business and Trade (which used to be known as the Department for Business, Energy and Industrial Strategy (BEIS)).

I was confident, comfortable and familiar with my role as a service designer in the discovery phase, but beta was something new to me. I’ve since worked on 2 beta projects, and I’ve settled into my role as a service designer in beta and grown in confidence in the value I bring in this phase. So I’d like to share some of the things I’ve been doing.

The agile delivery phases

In dxw, we work in an agile way with multidisciplinary teams and often follow the GDS agile delivery phases:

We have a team of service designers at dxw who work across all phases of government projects. The role of a service designer can be defined in a number of ways.  We often work alongside user researchers to understand, and speak to, a service’s users and stakeholders and then validate how we might meet their needs with a new or improved service. So we are often associated with the discovery and alpha phases of delivery. But what’s the role of the service designer in beta and live?

What can service design in beta look like?

Applying service design thinking to the building phase

When I started on my first beta project at dxw, I found myself struggling to find my feet and pin down how I could be most valuable. I think that was because I was producing less things. But I soon realised that was okay, and that as a service designer, the value we offer isn’t just about producing artefacts. We also add enormous value through the thought processes and mindsets we bring.

It’s been important to apply service design thinking to the work being done throughout the beta phase. While in discovery, some of the main outputs of work might be things like ecosystem maps, user personas, or blueprints. During beta, I’ve been using my understanding of the whole service to have conversations about designs, priorities, and project direction. Ultimately my focus has been continuously championing the need to think about the whole process and service at a high level, not just the user interface and interactions in the application we’re building right now.

For example, at the moment our team is looking at how projects are assigned or reassigned to users within our beta service, and how different permissions structures work for different groups of users. The interaction of those assignment screens is crucial to a good user experience and accessibility, but it’s also important to think about the processes that surround that interaction. For example, what the business and user needs are for assigning someone and how we can support or enhance those considerations through the build of the service.

To help these conversations, I’ve done some additional mapping work to understand in more detail what the as-is process for assignment looks like, both in the existing legacy technology’s digital process and also in the person-to-person conversations and non-digital processes. I’ve used this work to help frame users’ needs in the assignment process and identify how our application slots into that process to enhance it. Rather than the service process fitting around the build of the application. Taking the discussion’s focus away from the interaction through digital screens, and applying service design thinking to how we might solve this journey.

An overview of the as-is position for one of the problem areas we were focusing on improving with our MVP service
A map of the as-is position for a specific problem area we were focusing on improving with our MVP service
An overview of the 'to-be' vision for one of the problem areas we were focusing on improving with our MVP service
Map of the ‘to-be’ vision for a specific problem area we were focusing on improving with our MVP service

Continuing to learn about the problem space and service landscape

Although the GDS agile delivery phases are relatively well defined with clear objectives and outcomes for each phase, the boundaries aren’t always that clear or straightforward. Even in beta, the scope of the project might change. You might uncover new users, tools or processes you don’t know everything about yet. So you could find yourself doing some discovery-like thinking and research, or prototyping and testing new concepts, in the same way you might during alpha.

The MVP for the current beta project I’m on went into public beta 8 weeks ago, and we’re now expanding our user scope to include the needs of an additional 3rd party user group. This user group wasn’t part of the previously delivered discovery or alpha work, so they’re entirely new to us and the build. It would be easy to simply replicate these users’ current ways of working within our new service. But this is an opportunity to discover what their processes are, what’s actually happening at service level, and design something better.

So, while we’re continuing to manage the live MVP service and design iterative feature improvements, we’re also running a mini discovery phase of work. This is a 2 week sprint to:

In my second post, I’ll look at creating a joined-up service and defining success.