As-is for service design

Something I’ve been reconsidering recently is the idea of ‘as-is’ work in service design, especially how this is part of discovery work.

Teams have to decide how much time to spend on understanding what happens now, and how much detail they then usefully capture in discovery artefacts. I’ve seen teams in government, often with an imbalance of Business Analysts compared to Service Designers and User Researchers, going to extreme levels of operational and process mapping in discovery. These teams can then struggle with getting unstuck from how they’ve prioritised working within the detailed constraints of existing business processes.

It’s easy to lose sight that discovery is about learning in order that you can design something. So a starting assertion here about a good as-is process:

A good as-is process isn’t just process mapping. It’s a set of activities. These activities should be focused on getting as much insight as is useful about how things work now, and why. This insight can then usefully inform and be the starting point for a design process.

As-you-were

The problem is when as-is becomes closer to ‘as-you-were’ work— it’s inexplicit goal being the creation of specifications for how things work already, limiting the perspective of how we then prioritise and manage changes to how services work.

As-you-were is the type of thinking that limits change to incremental improvements. Most service design problems require more radical thinking than this. Discovery and as-is work should be a place from which you can explore new service models for how services and organisations work.

As-it-was

As-it-was is more helpful. You can learn about user needs, and how front line staff really do their jobs working within existing operational and technology constraints. It’s these types of insights that offer up opportunities to think about how things could work differently, rather than getting stuck in improving how they work now.

User Research is the starting point here. This is where we’re looking for a broader set of insights to provide us with new perspectives and opportunities.

The work here can result in a collection of artefacts. More broadly, ‘service mapping’ should be different to process mapping, and be useful for visualising context, user needs, pain points, and touch points in a way that teams will have the basis and insight to move into a design process.

As you’re drawn into making maps, just think carefully about the types of maps you need to make. A more services-led approach should focus on mapping experiences rather than starting with business processes. You will then most likely need some sort of stakeholder maps, system views of how organisations and people work together, as well as an idea of how existing supply chains shape what happens.

The as-it-was mindset here is that the research is showing us what has already happened. That’s okay, and it’s useful. But the type of artefacts we choose to create and continue working from should reflect the understanding that everything in the problem space now continues to move with us.

Any map we build becomes something we can navigate with, rather than a historical record we should rely too much upon. The question is always: where are the artefacts you’re making capable of taking you? And, what kind of ambition do they represent — reinvention and exploration of complex systemic problems, or incremental improvements for old business processes?

Becoming increasingly unstuck

An important part of any discovery is making assumptions explicit. It’s this framing and understanding from as-is work that will support how teams can move into a ‘designing’ headspace, rather than moving straight into delivery mode. I suspect that this is the real tension when I’ve seen teams getting drawn into too much detail around how things work now, and the certainty they think they need in order to deliver something of value.

As-is work should be about helping teams to become gradually more unstuck as they frame the problem, opportunity, or understanding they need to move into a more defined design process.

The directions you take

I truly get the tension here when teams can’t agree on approaches to as-is work. The arguments about the value of process mapping versus a broader research approach that provides deeper qualitative insight into user experience (from the perspective of staff and citizens). The answer sometimes is to do both.

To be fair, as-is as part of a delivery process predates the most recent understandings of how service design can help organisations. There’s a difference here between something that supports how teams make and maintain software solutions, versus how other teams take a user-led approach to solving whole problems for people using services.

We can look to what has already happened, but the goal in service design should always be to carefully frame better ways and starting points to design what could happen next.

This post was first published on my personal blog. Read part 2: Mezzanine levels for service design.