Speculative Design for Service Designers: Blueprinting Services That Don't Exist Yet

Speculative design gives service designers a way to blueprint services that do not exist yet: services set ten or more years out, where the backstage — the institutions, regulation and infrastructure a blueprint normally treats as fixed — has been allowed to change. Working from real, dated signals, it produces a future service specific enough to stage and argue with, then backcasts from it to the policy, contract and partnership decisions a service team can influence this year.

Services are where futures actually land. A new technology or a change in the law does not reach people as a headline. It reaches them as a changed appointment, a letter, a premium, a form that asks a new question. Service designers already work at that point of arrival. What the discipline usually lacks is permission to move the parts of the system it treats as given. (For the general definition, see what speculative design is.)

The combination has an academic lineage. At ServDes 2020, Troy McGee and colleagues at Monash University proposed a speculative service design framework for imagining, prototyping and reflecting on future service experiences, and applied it to a hospital emergency department waiting room. What follows is the practitioner's version.

The service design toolkit is already halfway there

Most designers who come to futures work have to learn to think in systems. Service designers do not. You already draw ecosystem maps full of actors who never meet the customer, and walk personas through journeys that last weeks or years. You already stage services before they exist — role play, walkthroughs, experience prototypes in a borrowed room — which is a form of prototyping a future.

Above all, you have the blueprint. Lynn Shostack introduced it in the early 1980s, most influentially in Harvard Business Review in 1984, splitting a service into what the customer sees and what they do not; later versions formalised that split as the line of visibility. The backstage is where most futures begin: a regulation, a data standard, a funding scheme, an infrastructure renewal. Speculative design asks you to keep blueprinting, and to stop holding the lower lanes still.

Long journeys, short horizons

Service designers have a particular horizon problem. A journey map's time axis can be very long — a mortgage, a pension, a tenancy, a long-term condition — while the horizon on the change work is short. The to-be blueprint usually describes the service at the end of the current transformation programme, and it treats the backstage as fixed because the project has no authority over it. Policy, contracts and legacy systems sit in the bottom lanes as constraints, drawn as they are today.

That is the wrong way round. The frontstage changes quickly and cheaply. The backstage changes slowly, on legislative and procurement cycles, and when it moves it redraws the whole service. A twenty-five-year mortgage taken out this year will still be running in 2051, long after everything in its backstage has been redrawn.

This is why we set the horizon beyond ten years: by then the programme has finished, the contracts have been re-let, and the backstage is negotiable.

Where it fits in a service design process

None of this needs a new process. Every map and blueprint you already produce has a futures twin.

Our practitioner's workflow runs from brief to strategy; the table shows where it plugs into yours. The distinctive artefact is the future blueprint, drawn from the bottom up.

A worked example: moving home in 2038

Imagine a service design team at a district council — call it Northmere — that owns the moving-in journey: council tax, electoral registration, bins, parking permits. Northmere is invented; every signal below happened.

The brief. How will people move home in 2038, when proof of who they are and where they live sits in a wallet on their phone rather than in each organisation's records? Horizon: 2038.

The signals. In May 2024 the EU's Digital Identity Regulation entered into force, requiring every Member State to provide at least one digital identity wallet, with wallets available from 2026. On 21 January 2025 the UK government announced GOV.UK Wallet to hold government-issued documents on people's phones; its first document, a digital Veteran Card, went live that October. And on 1 December 2025 most of Part 2 of the Data (Use and Access) Act 2025 came into force, putting digital verification services on a statutory footing with a register of certified providers. Each has a who, a when and a what, which makes them signals, and all three sit in the backstage.

The future wheel. The hub: every adult can hold verified identity and address credentials in a wallet, and every public and private organisation accepts them. Ring one of the future wheel is what anyone working in digital identity already expects: no utility bills as proof of address, sign-up in a minute, fewer checks at the counter. Ring two turns it into a service design problem. The authoritative record of who lives where moves out of the council's systems and into the resident's pocket, and the council subscribes to it rather than collecting it. Moving becomes one act that reaches every organisation the resident allows — Tell Us Once, the UK service for reporting a death to most government organisations in one go, applied to addresses. And for someone leaving an abusive partner, a system built to spread an address everywhere at once becomes a danger. Ring three: the counter empties and fills with the people the wallet does not serve — no smartphone, an insecure immigration status, a refuge address — so the visible service becomes an exceptions service, and electoral registration risks becoming one more toggle.

The concept.

• •Name: Northmere Arrivals.
• •Tagline: Move in once. We'll take it from here.
• •Description: When a new resident shares an address credential with the council, Arrivals opens the council tax account, offers electoral registration as a separate step, schedules the bin delivery, issues any parking permit and books a welcome call where one is needed. Each service has its own switch. Anyone without a wallet, or who needs their address withheld, reaches a named officer rather than a form.
• •Sketch: The moving-day notification: seven Northmere services, seven switches, and a line at the bottom — "Need your address kept private? Talk to Sam."

The future blueprint. Draw Arrivals in 2038, starting at the bottom. Support processes: the trust framework and register of certified verification providers, whoever issues the address credential, the council's address gazetteer, electoral registration rules, the safeguarding route for residents at risk. Backstage: a subscription service receiving changes from wallets, a data-quality team reconciling them against the gazetteer, council tax liability triggered by a credential rather than a form, and Sam's caseload. Frontstage: the moving-day notification, the welcome call, Sam. Customer actions: sharing the credential, choosing services, or phoning.

Two things happen here that never happen to a to-be. Work that sat below the line of visibility — checking identity, keying in an address — moves into the customer lane, done by the wallet. And the blueprint splits in two: an automated service most residents barely notice, and an exceptions service that holds nearly all the human contact. The second is where the design effort belongs.

Implications. Start with an ordinary day: moving in takes a minute and nobody queues at the council. Then the uncomfortable part. The speed that makes it easy also spreads mistakes: one wrong credential reaches seven services at once, and a stolen wallet could move someone's address before they notice. Front-line staff see only the hardest cases. And if electoral registration is a switch, someone decides whether it starts on or off. That decision is political, and a service team should not make it alone.

Backcasting. Work back from 2038 and look for the rungs. The institutional ones come first, because that is where service futures stall: council tax and electoral rules that accept a digital credential as evidence; a settled answer to who issues an address credential and who is liable when it is wrong; a safeguarding rule that stops an address propagating. Then infrastructure: council systems that accept a subscription instead of a form. Then a threshold: the point at which wallet users outnumber form users, after which staffing has to be planned around exceptions. Some rungs are already climbed — the trust framework and register exist in statute.

What changes this quarter. Northmere's team does not build Arrivals. It adds an exceptions lane to the current moving-in blueprint and counts who already falls into it. It checks whether today's safeguarding route would still work without paper forms. It lists the identity checks the council runs now and asks which a certified verification provider could already do. And it puts the wallet on the ecosystem map as an actor, so the next systems procurement asks the right question. Each is a decision someone can make within this year's budget.

Where it goes wrong for service designers

Frontstage futurism. The commonest failure is a future frontstage bolted onto today's backstage: the touchpoints acquire an assistant or a sensor, and the policy, contracts and infrastructure beneath them are drawn exactly as they are now. If the bottom two lanes of your future blueprint could be pasted from the current one, you have redesigned the shopfront and kept the warehouse.

The to-be in disguise. When the horizon is too near, the future blueprint becomes the programme's target state with better illustrations. The test: if every changed cell maps to an item already in the programme plan, you have drawn a to-be. Move the date out until something in the backstage is genuinely negotiable.

Stopping at the line of visibility. Co-design sessions explore what customers can see, so the institutional rungs get skipped — and those are the rungs with named owners and live budgets. Residents can react to a staged moving-day notification from 2038; they cannot tell you which regulator has to move first. That part is yours. Our guide for policymakers covers the other side of that conversation.

A first exercise: redraw your blueprint from the bottom

An afternoon, the blueprint you already have, and whatever tool you drew it in.

1. 1.Duplicate your team's most recent blueprint and write a year at least a decade away across the top.
2. 2.Find one real, dated signal from the last three years that touches the backstage: a regulation passed, a scheme opened or closed, an infrastructure contract awarded. Note who, when and what.
3. 3.Assume it is fully realised by your year. Redraw the support processes lane first, then the backstage.
4. 4.Add the actors who would exist then and do not now; cross out the ones who would have gone.
5. 5.Only then redraw the frontstage and customer actions. Give the most changed touchpoint a name and a tagline.
6. 6.Mark each changed backstage cell with the institution that would have to change for it to exist. That list is your first backcast.
7. 7.Take the list to whoever owns the relevant policy or contract today and ask when it next comes up for renewal.

The last step is the one that turns an exercise into work.

Where to learn it properly

Speculative Design Basics is our self-paced course: 42 lessons, no prior experience assumed, taught by J. Paul Neeley, who supports the Service Design programme at the Royal College of Art. For service designers the parts that matter most are the Process section, which places speculative work alongside existing design processes and covers time horizons; the Tools & Methods chapters on signals, future wheels, future prototyping and backcasting; and the Creating Value section on product and service development. If the first ten lessons have not improved your understanding and potential for impact, you get a full refund. For other jobs, see speculative design for every role; the guide for UX designers is the companion when your future service has a screen in it.

Key takeaways

• •Services are where futures land: as appointments, letters, premiums and forms, across people, policy and infrastructure.
• •The service designer's horizon problem is long journeys and short change horizons, with the backstage drawn as though it will not move.
• •The future blueprint is the distinctive artefact. Set it ten or more years out and redraw it from the support processes upwards.
• •Service signals are often institutional — an Act commenced, a register launched, a wallet announced — and they belong in the backstage.
• •Backcasting's institutional rungs are where service futures stall, and they are the rungs with named owners and budgets.
• •The output is a change to this year's blueprint, ecosystem map or partnership conversation, not the future service itself.