Service Design as the Engine of Internal Change

When I told people I was changing jobs, many asked, “So what are you actually going to do at Valimo?”

I’d laugh and say, well, I’ll be doing what I’ve always done - what else with this skillset of mine. And then, after the blank stare, I’d launch into a long and slightly winding explanation about service design, strategic design, process design, and standing up for humans in the middle of this rapid shift towards AI.

At some point I realized I was hard to follow. This clearly needed sharpening. What on earth does a designer with 20 years “in the field” actually do at an AI start-up? And I mean besides sales decks and occasional janitor duties.

The Human Is Still at the Core of My Work

Humans. That’s my job site.

The tech gets handled by people who understand it far better than I do. I focus on the human: their work, their world, their frustrations, their uncertainty, their goals — and how AI can genuinely support all of that. How we make things visible. How we build a positive vision of the future alongside all the dystopian noise.

The public conversation tends to circle around the big, dramatic themes: AI will disrupt “everything,” jobs will disappear, or AI will “create new growth.” What we talk about far less is how to first identify the real problems — and only then use AI to solve them. And how to keep people — employees, customers, users — actively part of the change.

I crave more pragmatism. More concreteness. A more constructive future narrative.

As a long-time service designer and advocate of human-centered design, I believe the core principles of service design and change management are just as relevant in the age of AI. They just take on slightly new forms. (Yes, pun intended.)

From Customer Journeys to Employee Journeys

If we used to talk about customer journeys and touchpoints, now we need to talk at least as much about employee journeys. About processes. About the flow of everyday work. And honestly — about how the nature of work itself is changing. (This is a theme that deserves a blog post of its own, but let’s come back to that later.)

In the AI transformation, there is a very real need — and demand — for human-centered service and process design. As we move toward agentic automation, where digital services are no longer just enablers of work but actors doing work independently, the human role shifts. More and more often, the human oversees, intervenes in exceptions, exercises judgment, and develops the process further. That’s a big change.

For many of us, our professional identity has been built around doing: “I’m the one who handles, decides, solves, runs the process.” What happens when I’m no longer the engine, but more of a guide, observer, and developer? How is the meaning of work redefined?

This is where service design becomes essential. We need to pause and ask:
– What does this new role actually feel like?
– Where does the human truly add value?
– How are exceptions handled so that no one is left alone with a machine’s decisions?

This is about redesigning work itself — and through that, rebuilding professional identity. And if we don’t do it consciously, it will still happen. Just in a more uncontrolled way.

That’s why the employee journey is now at least as important as the customer journey.

Why Do AI Projects Stall Halfway?

In many organizations, AI is introduced like a project. A platform is selected, a pilot is launched, guidelines are published, and everyone hopes for the best.

That project logic makes sense — it’s how we’re used to approaching something new. But often what happens next is familiar: adoption stalls. People work around the system. Or they quietly return to old habits.

More often than not, the issue isn’t technology. It’s the experience.

How does this feel in my daily work?
Do I know how to use it?
Does it genuinely make my life easier — or does it just add another layer on top of everything else?

Service design brings a very down-to-earth but essential question into the conversation: what kind of service are we building for our own employees?

Because yes — an AI-powered solution is a service. A service used in a rush, under pressure, sometimes with a bit of suspicion.

If it doesn’t fit into the workflow, it won’t be used.
If the workflow doesn’t fit into real life, it won’t be followed.
If responsibilities are unclear, people start double-checking everything (and things get messy fast).
And if the boundaries are blurry, the whole thing becomes something to fear.

That’s why change is not just about technical implementation. It’s about designing roles, responsibilities, and workflows.

Where does AI suggest — and where does the human decide?
What can be automated, and what requires approval?
Who ultimately owns the outcome?

As a service designer, I’m not just designing the solution. I’m designing the change itself.

Building Trust Together

I had a strong moment of validation for this thinking when I was involved in designing a service for healthcare and social care professionals.

They had identified clear pain points in their work: things that frustrated them, consumed time, things that simply should be done differently.

I pulled out my designer toolkit. Together with the project team, we translated these pain points into statements — or more elegantly put, hypotheses about problems and opportunities. We validated these with a larger group of professionals.

The discussion was rich. We refined the statements. Eventually we aligned on which issues would create the most value if solved.

There were several priorities on the list, because at that stage we didn’t yet know how easy or difficult each would be to tackle.

Next, together with AI and system experts, we narrowed things down:
What data do we have?
Which data is actually up to date (not always an easy question)?
Which systems can we realistically integrate with — and which can’t we?

From that, we shaped the backbone of one solution that made the most sense to build first. We developed it iteratively, with professionals continuously testing and giving feedback.

One insight stood out above all others: they needed to know the source of the data.

They rarely felt the need to verify the information itself — as long as they could see where it came from. That transparency was enough to maintain trust.

The whole process took six weeks. The feedback from professionals was excellent. Yes, we invested time upfront in defining and narrowing the problem and the solution. But it paid off — because the professionals stood behind the decisions made.

After all, the service was built for their own daily work.

A real-life example proves that change happens when people feel ownership.

Service design makes visible what actually needs to change in the work itself. What becomes easier. What disappears. What can be done differently.

And when people are invited into the design process, they’re not the targets of change.

They’re the ones making it happen.