Rolepocalypse: why service design is the high ground
Over the past few months, while trying my best to surf the new AI era, I’ve had some interesting feedback. “You should be a Power Apps developer.” “You should be a solution architect.” “You should be a BA.”
It’s sort of flattering. But I see it more as a symptom of something bigger: technical and design roles becoming less meaningful now AI is in the mix.
I’ve been building internal Power Apps inside a government department, which throws people sometimes, in a good way. I think the surprise comes from a slightly dated expectation that we’re all still working in neat, specialised roles. With AI and a lot of experience in the sector, I’ve been able to bridge the gap between designer, business analyst, solution architect, service designer, UI, UX and user researcher. There are lots of words for what that makes me. But I think it speaks to what may be coming: a mass flattening of roles down to a few hyper generalists.
It feels like only yesterday that generalists like me were being pushed aside in recruitment for not having fizzy Figma portfolios. Now the ground is shifting under everyone, and the market is in turmoil. So where is the high ground?
My answer is service design, coupled with a technical grounding.
Design and research have always had three jobs: do the right thing, do the thing right, and get people to use it. For the past 15 years or more, the middle job has shaped everything. Development was slow and expensive, so design and research largely existed to de-risk the build. Practices standardised, role definitions matured, and teams settled into researchers, analysts and designers producing artefacts for a separate team to develop.
AI has collapsed the cost and time of building. Of those three jobs, only the middle one is really changing. The other two are where the hard work, and the value, now sit.
The scale of this is hard to ignore. The Alan Turing Institute estimates that around 41% of public sector working time goes on activities generative AI could support, rising to 49% in education. Once a service that took eight people a year can be built by two people in a month, the economics of delivery change. Clients will stop paying for time and start paying for outcomes.
Directing AI isn’t the whole picture
I can see a role for some kind of product manager directing AI. But that alone isn’t enough, especially in public services.
Not every system has an API or a clean data point to plug into. And stakeholders can’t all be aligned through AI. Some of that work still has to happen in the room.
Who is going to understand a doctor’s perspective, or a patient’s? How a user experiences signing up for a service from beginning to end? What it’s really like for someone going through the court system, or how the probation system connects to everything around it? None of that is sitting in a dataset waiting to be summarised. You find it by being there, asking good questions and listening to people on the ground.
Speed also lowers the cost of being wrong on the screen, not the cost of being wrong for the people using the service. A fast, cheap, wrong public service still creates data debt, risk, support costs and harm to citizens, and those are hard to unwind. When anything can be built, the hard question becomes what the right problem is to solve.
Research matters more than ever
AI’s biggest weakness is trust. You can’t trust what it produces until you’ve validated it with users or experts.
That makes user research more important, not less. Someone has to be the human in the loop, testing whether the thing AI helped build actually works for the people it’s meant for. As more research gets augmented by AI, that validation role becomes the part you can’t skip.
AI already speeds up the mechanics of research: synthesis, drafting discussion guides, transcription. The skills that grow in value are knowing which questions to ask, and judging when an AI generated insight is plausible but wrong. Research starts to bookend the process, at the front and again at the end, checking that what got built is sound.
It also takes the confidence to say what isn’t known. Rooms full of confident stakeholders harden AI claims into fact very quickly, and the models are poor at signalling what they don’t know. Part of the job is slowing that down, asking for the evidence, and being honest about what the tools can and can’t yet do.
Research doesn’t just validate, either. Done well, the research itself can change the system.
I saw this working with Manchester NHS Sexual Health Services, which wanted to improve care for trans and gender diverse people. Over two weeks, we co-facilitated workshops that brought practitioners, service leads and trans and gender diverse people into the same room, building a journey map of the service from the user’s perspective together.
The map was useful, but the real change happened while we were making it. Practitioners heard first hand what the service felt like from the other side. People who don’t usually share a room started to see the same journey, and aligned around it. Together we narrowed everything we’d heard down to five areas of opportunity, with problem statements the service could take forward knowing they genuinely reflected the people it serves.
AI can summarise what people have said. It can’t create that moment in the room where a practitioner sees their service differently.
One or two people, end to end
Put this together and it’s quite conceivable that one or two people could run the workshops, shape the service vision, do the research and gather the insights, build the prototype, and in the not too distant future, produce the production code for the digital parts of the service.
The building isn’t the hard part any more. The fiddly part is aligning it all and spotting the gaps: between what the policy intends and what the frontline does, between one system and the next, between what people say and what they actually need.
And taking stakeholders on that journey doesn’t go away.
Working software isn’t an adopted service either. At DfE I’ve seen adoption running ahead of governance. Even when it’s the right problem, solved well, you still have to bring users on board, communicate the service, and make it operational, with ownership, governance and support in place. A built thing only becomes a service when an organisation owns it and runs it.
When there’s no journey
A leading agency director recently told me a story that stuck with me. They were responding to a tender for a public service. The brief asked bidders for a proposal and possibly a prototype.
Using AI, the agency produced a working, production ready application in about a week. The client couldn’t accept that it wasn’t a prototype.
The client hadn’t been brought along. There was no discovery, no shared understanding, no sense of how the thing came to be. There was no journey, so there was nothing to believe in.
That’s the gap service designers are made for. When development time drops from 12 to 18 months to a few weeks, someone has to create the journey that used to happen naturally along the way.
Reimagining the process around AI
So we need to rethink what a client and stakeholder design process looks like when building is fast.
Some of it stays the same. Getting the right people in the room, understanding how a service really works, building consensus and a shared language.
Some of it changes. Prototypes can be real much earlier. Feedback loops shrink from months to days. Stakeholders may be looking at something that works before they’ve had time to agree what the problem is. Pacing that, and making sure people understand and own what’s being built, becomes part of the job.
Why service design is the high ground
When anyone can produce a working app, the value moves to everything around it: understanding the people, aligning the system, validating what’s true, and bringing others along.
That’s service design. Add enough technical grounding to steer AI and build what you’ve designed, and you have the generalist this era seems to be asking for.
That generalist still needs some technical depth. Building end to end means building infrastructure, and clients won’t take an AI’s word that it’s sound, secure and responsible. Someone in a small team needs enough solution architecture and business analysis to interrogate what the AI proposes, and to reassure clients it’s built in a recognisable, defensible way. Which may be why people keep telling me I should be a solution architect.
It’s becoming hard to keep up, for sure. My strategy is to lean into being a generalist, with AI as my sidekick. I just hope it stays a sidekick.
Funny world, funny times. I’m curious to hear what other people are experiencing.