Mezzanine levels for service design

Ben Holliday
4 min readFeb 21, 2021

--

When designing services, one of the biggest challenge teams face is finding the right perspective to work from.

As I shared recently, something I’m talking about a lot right now is the idea of working from ‘mezzanine levels’. This is the idea that sometimes the most useful perspective for teams is somewhere in-between ‘as-is’ and future ‘to-be’ states.

As a more in depth introduction, and as context for this post, I’ve just finished writing about as-is for service design . I’ve asserted here that user research and learning time is better invested in going deeper into understanding user needs, context, and real scenarios. Rather than process mapping all the business processes and existing service blueprints, which can then lead quickly to requirements and incremental improvement based thinking.

To conclude the previous post I also said that “the goal in service design should always be to carefully frame better ways and starting points to design what could happen next.”

Introducing mezzanine levels

A mezzanine is an intermediate floor or level in a building. It’s an in-between space. I’ve been using this definition for service design:

Mezzanine levels in service design are the in-between of how things work now, and designing a future state for how we intend things to work.

You can break down this analogy as follows.

A ground floor perspective is focusing on how things work now, or starting in close proximity to assumptions that things have to work in a certain way.

Mezzanine levels take a more elevated view of what is happening right now and why? This perspective is more about recognising what needs to happen. The in-between spaces also give you access to what sits above and across them. These are our upper floors. Where goals, vision, and parts of services and organisations join together to hopefully solve whole problems for people and places.

These upper floors (if they’re within your reach) are further towards blue sky thinking, and the type of goal setting or ‘visioning’ work that teams focus on with good intentions. But these can also become quickly detached from any real understanding or considerations of real business needs and operating constraints.

Constraints are important, even when the goal is to radially rethink how things work now. It’s rare to find greenfield projects, and there are always as-is constraints like technology, policy, organisation models and complex supply chains involved in how services work.

Mezzanine levels are all about finding ways to explore and make thinking around new service models possible, while also recognising and working with different types of constraints. How you work with constraints depends on the type of questions you’re willing to ask, which will then determine the levels you find to work from.

The spaces in-between

The reality here is that managing and making change real means that we have to keep moving between the design of future states and what is actually possible in order to make progress. The challenge is finding the right anchor points that let us step both ways.

I’m not going to pretend that this is always straightforwards, and finding the right levels and perspective to work from will be directly related to the size, scale and ambition attached to a service area, or what your team and organisation is working on.

The following feedback I received has been helpful in providing insight into how designers are working in these spaces at the moment:

Paul Smith commented that “…the level of detail you go to when trying to understand the ‘as-is’ is key. Going back to rough first principles is probably enough to start thinking about that things could/should be”.

Jude Webb commented that this is more an approach to working with a “realistic future state” while also having to be less concerned with whether you’re working with a current or future state design.

Joel Bailey’s comment also provided clarity here on what mezzanine levels might start to look like. He explained that this means “…setting horizon points out to a target state, and stepping back in to now. Allowing people to move up and down this track, at each phase, [creating] order and clarity”.

And finally, Imogen Levy’s framing of this as work focused on “as-is with an eye on the what’s possible.

Finding your mezzanine levels

The question of ‘what needs to happen’ (mezzanine level) can provide a broader perspective and reframing of ‘what happens’ (as observed on the ground floor). You can then very quickly start to ask how things might best join up and connect as part of a more complex system supporting different types of needs, user journeys, business processes, ways of working and capabilities.

Any design process being supported here ultimately depends on what really happens.

This means less focus on implementing a to-be or future state solution, and more emphasis on learning by doing. This is the importance of making ideas real, testing out and iterating future models (side note: this is why I talk about service modelling versus service models).

The difference between what needs to happen, and what really happens is also the gap between policy intent and the reality of understanding what people do and why. The answer to this is treating what needs to happen as assumptions to be tested. The more you learn, the more you might choose to adjust your perspective.

New learnings, new levels.

Finding a way to move between now and then is going to be increasingly important to the more radical service design that most organisations need. As Sarah Drummond commented and articulated perfectly “[this is the] tricky balance of what’s possible and radical challenge for new realities.”

This post was first published on my personal blog.

I’ve quoted a number of people in the post who replied to the original Twitter thread and conversations on this topic. Thanks also to Caroline Jarrett, Joseph Emmi, Kathryn Grace, Mia Peters, James Green, and Sophie Dennis (and any other people I’ve missed here) for constructive feedback that has shaped this write-up.

--

--

Ben Holliday
Ben Holliday

Written by Ben Holliday

Designer and leader. Working with organisations and teams to deliver great products and services / also find me at benholliday.com