A service should be redesigned around the people who use it, not the people who deliver it

What the problem is

Almost every public and university service is designed around the administrative process that gave rise to it, and not around the person who uses it.

That is understandable, because the service was born to process something and was organised the way a procedure is organised. The problem appears when the organisation grows and every unit optimises its own part. The service then works from the inside — each silo does its job — but it starts failing on the outside: the person using it has to go to four different desks to sort out a single thing, and nobody is responsible for the whole journey.

The usual reaction is to reorganise the org chart or buy a digital tool. Neither touches the problem, because the problem is not one of structure or of software: it is that nobody has looked at the service from the other side of the counter.

The starting point

You do not redesign a service from outside. You redesign it with the people who deliver it, and you test it against the people who receive it.

An imposed redesign holds for as long as senior management is paying attention, and then it goes back to where it was. One built by the people who carry it, on the other hand, stays, because they own it. That is why the method is participatory by design and not out of courtesy: collective intelligence is not decoration for the session, it is the mechanism that makes the redesign survive.

The second condition is about form: the redesign has to be non-invasive. A public organisation cannot stop. The method is built in short cycles compatible with day-to-day operations, and that is a starting requirement, not a concession.

The four capabilities

The programme does not only leave a redesigned service behind: it installs four capabilities so the organisation can do it again without outside help.

1. CORE 1A user-centred focus Knowing how to design the service from scratch, involving the people who use it and the stakeholders around it.
   • Active listening for the diagnosis: reading someone else's perspective to identify needs and opportunities, not to confirm your own.
   • Reading social trends: anticipating the changes in the environment that are going to affect the service.
   • Understanding the user experience: real behaviour, motivations and expectations.
2. CORE 2Using collective intelligence Being able to build processes that take in every perspective and sensibility, including the uncomfortable ones.
   • Community facilitation: running collaborative processes and aligning a core team.
   • Identifying capabilities: spotting the strengths that already exist inside and allocating resources accordingly.
   • Communication and influence: putting ideas clearly enough that they get decided on.
3. CORE 3A light, agile method Learning to rethink the role of the service in a way that is non-invasive and compatible with day-to-day operations.
   • Iterative design: short cycles with feedback, to test, refine and scale.
   • Cross-cutting collaboration: working across academic, administrative and technical teams with shared responsibility.
   • Lean integration: building innovation into daily operations without adding complexity.
4. CORE 4A community around the service Leaving the people who have to carry the redesigned service connected to each other once the programme ends.
   • Mapping the actors: identifying and connecting everyone involved in the service, inside and outside the organisation.
   • Sustainability and continuity: the minimum governance that keeps the improvement alive without depending on one person.

How the work runs

Eight weeks, five sessions and analytical work in between. The sequence moves up and down on purpose: it starts and ends with the leadership team, and along the way it works with the people who deliver the service and with the people who receive it.

1. Kick-off with the leadership teamThree things are agreed before anything is touched: what the service exists for, who its main beneficiary is, and what success will mean six months from now. Without those three, everything that comes afterwards is argued in a vacuum.
2. Service maturity radarA diagnosis across eight dimensions, answered individually and handled anonymously and in aggregate. It is what allows the areas for improvement everyone already knows about to reach a table at last, at no personal cost to whoever points them out.
3. Listening to the people who use the serviceFieldwork on the real experience: where it gets stuck, what gets abandoned halfway, what gets solved through an informal channel. The full journey and its pain points are mapped, and that is the material no internal meeting ever produces.
4. Challenge and ideationA working session where the problem is stated precisely and concept directions are generated and selected. What comes out is a short list of prioritised concepts, not a wall of ideas.
5. Future scenarios and user-centred designTwo sessions, one with the external players in the ecosystem and one with the internal teams, to build scenarios and design the service and its programmes from the needs of the people who use it.
6. Service prototypeThe concept becomes something you can show: the journey, the channels, who does what, and what happens behind each point of contact. Unlike a description that gets approved and forgotten, a prototype gets criticised.
7. Validation and roadmapWith the leadership team we check that the redesign answers what the service needs, that it is viable and that it creates alignment, and the six-month roadmap is closed with governance and indicators.

Who carries the redesign

Ask the people who run public services and the ability to move from diagnosis to implementation is the one they score lowest of everything they assess in themselves. That is why the team is put together before the work starts and not once it is over. The service involved has to cover the following roles:

• The service ownerThe person accountable for the service, who gives the process its legitimacy and keeps it aligned with the constraints of the house.
• A front-line professionalThe person who delivers it day after day and knows exactly where the procedure breaks, which is almost never where the manual says.
• Someone who represents the people who use itBrings the lived experience and the pain points, and tests the prototypes. Not a consultation layer, but a design criterion.
• Authority to implementSomeone who can change a procedure, assign a resource or escalate a decision. A team that understands its users but cannot decide produces recommendations, not real change.
• A data or communication profileBuilds the baseline and the indicators, or makes the change understandable. It varies with the service, but somebody has to be given the job.

One figure worth keeping in mind when putting the team together: asked what matters most, the people who run services rate daily contact with users higher than formal authority. Both are needed, but the order surprises almost everyone.

The instruments

There are no filler exercises: every session has a tool behind it, tested and with a tangible result.

• Maturity radarEight dimensions (leadership and governance, innovation culture, capabilities, resources, partnerships, processes, digital capacity and impact measurement) scored from 0 to 5 by every participant and poured into a collective map. It produces a visual diagnosis in a single session.
• Journey map and pain pointsThe full path of the person who uses the service, step by step, with the moments where they give up, repeat a procedure or find a shortcut. This is where what no satisfaction survey captures shows up.
• Scenario foresightFrom the external uncertainties to tested scenarios, and from there to the strategic implications and the moves that are worth making whatever happens.
• Impact and feasibility matrixFor prioritising without arguing: every weakness and every opportunity is placed on two axes, and only what can be tackled in three to six months survives.
• Actor map and service blueprintWho is involved, at what moment, and what happens behind each point of contact. This is where the silos become visible.
• Design of the six-month roadmapExploration, design and validation month by month, with one activity, one result and one checkpoint per month, and the resources and risks written down alongside.

The six-month roadmap

It is the deliverable you leave with, and it is worth saying what it contains, because "roadmap" is used for very different things. Six months split into three stages, with a milestone and a decision point every month.

• Months 1 and 2 · ExplorationConfirming the scope of the pilot, the main beneficiary and the institutional sponsorship. Mapping needs, gaps and comparable practice. Decision at the close: calendar and people involved.
• Months 3 and 4 · DesignCo-designing the model with the people in the service, preparing materials, communication channels and coordination mechanisms. Decision at the close: the content and method of the pilot, and a review of risks.
• Months 5 and 6 · Validation and pre-launchRunning the first sessions of the pilot, gathering early feedback, assessing results and defining the scaling model. Decision at the close: scale it, iterate it, or drop it with the reasons written down.

And alongside each stage, written down and not assumed: what people are needed, what capabilities, what materials, what protected time and what budget, what risks have to be watched, and by what indicators you will know whether it has worked.

What makes it different

Who it works for

• Public administrationWhen a service has to give more value to the people who use it and silo logic makes it impossible to see it whole.
• UniversitiesWhen services were designed around the procedure and have to be handed back to students, researchers and staff.
• Alliances and institutional networksWhen several organisations want one common method and not a different consultancy in each of them.
• The non-profit sectorA variant aimed at social innovation, with the same structure and a different measure of impact.

Where it has been deployed

• Universidad Pública de NavarraFrom the insideService redesign as part of the management team, between 2016 and 2025. This is where the method was built.
• UNITA · Universitas MontiumA shared modelBuilding a shared service redesign model for the universities in the alliance, in order to prototype a real redesign at each one.

How it is contracted

What your organisation brings

• One specific serviceOne that matters and that is genuinely causing trouble. "Services" in the abstract will not do.
• The leadership team, twiceAt the start to set the model and at the end to validate it. Without that, the redesign never gets deployed.
• The people who deliver itTwenty to twenty-five service leaders in the central session, and the teams in the design session.
• Access to the people who use itIndividual and organisational users, to test outside what is decided inside.
• Eight weeks in the calendarThe programme can be spread out, but stretching it beyond a quarter takes away the tension that makes it work.

How it is agreed

Scope and terms are settled in a preliminary conversation, based on the service chosen, the number of sessions, and whether external players in the ecosystem have to be brought in as well. Every programme is quoted on that basis.