Whether we're building public services through user-centered design or trying to evaluate and learn from how a public service is being run, services rarely happen the way that we plan them. It doesn't matter what we put in our journey maps, project plans, or service blueprints—people adapt, work around gaps, and make sense of complexity in ways we can't anticipate. That’s why alongside designing how a service should work, we also need a way to understand how it does work.

Borrowing some terms from linguistics, we could think of most regular service design as prescriptive service design. It defines how things should be done — the intended journey, rules, and standards that guide delivery. Descriptive service design, on the other hand, is about how people actually behave in practice. Descriptive service design pays attention to what frontline teams actually do, what users actually experience, and how systems behave under real-world conditions. It complements prescriptive service design by grounding it in evidence from lived experience and helps us to understand real opportunities for redesign.

Why it matters

• Service designs are always prototypes until they hit live service. They might be informed by regulatory requirements, business constraints, and user research into what an ideal experience might look like, sure. But until operational staff pick that service up and start making it happen, it doesn't exist. Prescriptive service designs are nothing more than a wishlist. If staff can't get the thing done how you've designed it, they're going to find their own workarounds, shortcuts, and write their own guidance.
• Complex systems can't be predicted. When services start to get actually delivered, they immediately break down because no matter how well we plan, we can't predict every scenario. There's a person without a passport who needs to use your identity service, or a caseworker who everyone else goes to because "they just know everything". Even our best cycles of user-centered design should break down a little upon moving into operational delivery.
• ... and that's a good thing! The whole point of working in an iterative, test and learn environment is that we need to get our assumptions confirmed or disproved, we need to find the rough edges of things, and we need to do that as quickly as possible. Whilst user research can be a way of de-risking our services, the point of gathering insight is to be able to understand enough to make a change.

How do we do it?

Learning stewardship provides a lightweight way to gather descriptive insight, whilst building meaningful cross-organisation relationships. Frontline staff—from call centre advisers and case workers, to youth workers and housing officers—can act as “learning stewards,” noticing what’s happening in real time and sharing reflections in short, weekly or monthly facilitated sessions. They surface:

• what staff have been delivering,
• how they feel about what they've been delivering,
• what's working well and what isn't,
• whether they've noticed anything new or surprising,
• what end users are saying about the service.

Whilst learning stewardship activity can be run by anyone, we'd recommend service designers are at the forefront, ideally facilitating the sessions. User research being a team sport also means that user researchers shouldn't be the only people generating insight in a user-centered design team. Where user research tends to be based around the delivery of discrete projects with defined research questions, learning stewardship creates a space for bottom-up continuous insight.

This gives service designers fast and frequent sources of descriptive evidence of how a service is actually being delivered, enabling co-ordination with wider digital teams around potential changes. It strengthens prescriptive designs and highlights where services need redesign.