The Speculative Design Methodology: A Practitioner's Workflow

The speculative design methodology is a working sequence for turning early evidence of change into concrete future products and services, and then turning those back into decisions an organisation can make now. In practice it runs: a brief, signals, trends and megatrends, a future wheel, scenarios, future personas, brainstorming, speculative designs, prototypes built to a chosen fidelity, implications, backcasting, and current strategy. The first half of that is foresight — a discipline most large organisations already own, and have owned for sixty years. The second half is design, and it is the part that makes a future specific enough to be argued with.

What follows is the workflow we teach and use. It is a methodology rather than a recipe: the value is in knowing what each stage is for. If you want the definitions first, start with what speculative design is and our comparison of speculative design, critical design, design fiction and futures studies.

A familiar process, deliberately

The shape of the process is a modified double diamond, with a third diamond added for implementation. Diverge on evidence of change, converge on a small number of futures worth taking seriously. Diverge on concepts within those futures, converge on the few worth building. Then diverge on what those concepts imply, and converge on what the organisation should do about it on Monday.

We use the familiar shape on purpose. Speculative design has a reputation problem inside organisations — it sounds like an art project, and art projects get funded once. When the process diagram looks like the process diagram the innovation team already uses, the work gets treated as work. This is the same reason we advise practitioners to de-jargon: in most rooms you will get further describing what you are doing than naming it.

The third diamond is the one most futures work is missing. A double diamond ends at a delivered concept — which, in this practice, means a beautiful object in an empty room. The third diamond exists because the deliverable is not the future — the deliverable is a changed decision in the present.

The decision that governs everything: time horizon

Before any of the methods matter, someone has to choose how far out the work looks. This choice determines what the project can find, and it is routinely made by accident.

Most organisations plan on a two-year horizon. Software teams often plan on a two-to-six-week one. Both of those are too near for this work. Inside two years the future is the roadmap, and speculation collapses into defending decisions that have already been made. Everything that shows up as a "future concept" turns out to be next year's feature with a nicer render.

The sweet spot is beyond ten years. Ten years is far enough that current commitments have expired, current job titles are negotiable, and the people in the room stop arguing about implementation. It is also close enough that the same organisation, the same regulator, and largely the same customers still exist.

Past twenty-five years, something else goes wrong. People stop being able to picture it, and stop feeling responsible for it. Work set in 2100 gets admired and filed. If you need a longer horizon for scientific reasons — climate, infrastructure, nuclear waste — plan for the fact that you will have to build much more of the world before anyone can hold it in their head.

Two things make the choice harder than it used to be. Roy Amara's observation still holds: we overestimate what a technology does in two years and badly underestimate what it does in ten, so linear intuition fails at exactly the horizon that matters. And the range of futures reachable within any given horizon keeps widening — what we call possibility dilation. More can now happen quickly, so a ten-year scan has to cover more ground than it did in 2005.

The front half is foresight

The first diamond is not speculative design. It is foresight, and it long predates us. Corporate scenario planning has been running since the 1960s; many of the organisations that hire us already have a foresight function, a trends deck, and a horizon-scanning subscription. Speculative design augments that capability. It does not replace it, and telling a foresight team otherwise is a good way to lose them.

The brief. A speculative brief has to pair a specific source of change with a specific domain of concern, and fix the horizon. Briefs that name only the technology produce generic futures; briefs that name only the domain produce roadmaps. The brief also has to carry the audience and the reason anyone is asking — the same signal explored for a regulator, an insurer and a retailer produces three different projects.

Signals. A signal is a specific event that suggests a new possibility has become real: who, when, and what specific outcome. In August 2022 a piece of AI-generated art won the digital category at the Colorado State Fair. That is a signal. "AI is getting better at images" is not a signal — it is an opinion with no date attached, and it cannot be checked. The discipline of insisting on named, dated, verifiable events is what stops the front of the process becoming a mood board, and it is what makes the work defensible when a sceptical executive asks where any of this came from.

Trends and megatrends. These are levels of abstraction above the signal, not synonyms for it. Many signals abstract into a trend; trends scale, or several abstract together, into a megatrend. A battery cost milestone, a national ban date for combustion engines and a fleet operator's procurement announcement are signals; electrification is the trend; the decarbonisation of energy is the megatrend. You need all three levels for different reasons. Signals give you specificity and credibility. Trends give you direction. Megatrends give you the underlying pressure that makes a future plausible rather than arbitrary.

The future wheel. Take one signal, place it with the domain you care about, and assume it has been fully realised in the world — not adopted, not trialled, but simply true. Then work outward: the direct consequences first, then the consequences of those consequences, and again. What the future wheel does is break the habit of stopping at first-order thinking. Almost nothing interesting sits in the first ring; the first ring is what the industry press already wrote. Two and three rings out is where you find the second-order effects that nobody has priced in — the ones that eventually decide whether a technology is welcomed or regulated. It is the cheapest high-yield method in the workflow.

Scenarios. Consequences are not yet a world. A scenario is world-building: the point at which the material becomes a coherent context with its own logic, economics and texture, rather than a list of effects. The test is whether someone who was not in the room can picture it. In teaching we push scenarios into forms that force this — describing a future the way a film trailer describes a film, for instance — because the compression exposes immediately whether you actually have a world or just a theme.

Future personas. A world without anyone living in it stays abstract, and abstraction is the failure mode this whole front half is fighting. A future persona puts a specific person in the scenario: what they think, say and do, what they want, what is hard for them, in a context that no longer works like ours. It is deliberately the same tool the organisation already uses for present-day users, relocated in time, which makes it one of the easiest parts of the process to hand to a team that has never done futures work.

The middle: making the future specific

The second diamond is where design begins, and it is what speculative design adds to foresight. Foresight produces scenarios. Scenarios are read, agreed with, and forgotten. What changes people's minds is a thing — something specific enough that they can want it, refuse it, or argue about who should be allowed to own it.

Brainstorming. Concepts get generated inside the scenario, by people who have spent time in it. The one principle we would defend anywhere is to start silent and solo: the first voice in an ideation session anchors everything after it, and in a futures context that anchoring usually pulls the group back towards the present.

Speculative designs. A concept is not finished until it is specific. The discipline we teach is a small one that does a lot of work: every concept needs a name, a tagline, a description and a sketch. The name in particular has to be branded and particular — "Dean's Drone Delivery", not "drone delivery" — because the act of naming forces the choices that abstraction lets you avoid. Who runs this? Who is it for? Is it a public service or a business? What does it cost, and to whom? A concept with a generic name can be nodded at. A concept with a specific name can be disagreed with, and disagreement is the raw material of the third diamond.

Staying abstract is the single biggest mistake in this practice, and it does not feel like a mistake while you are making it. It feels like keeping your options open.

Fidelity. The next decision is how much of the future to actually build: a written story, a film fragment, a photographed object, a working interface, a staged service. There is no correct answer, only a correct enough — the minimum fidelity at which the idea becomes arguable to the audience you have. Under-build and people debate the rendering instead of the idea. Over-build and you get admiration, which closes conversations rather than opening them. Fidelity is a budget decision disguised as a craft decision, and it is worth making explicitly rather than discovering in week six.

The back half: implications, backcasting, strategy

The third diamond is what makes this a practice rather than an exhibition.

Implications. Having made something specific, you work through what its existence would mean. We start at human experience — what changes about an ordinary day for an ordinary person — because an implication that never reaches a human life is not yet an implication. From there the questioning moves outward across the social, cultural, technological, ethical, economic, environmental and political dimensions in turn. We call this the Implications Pie, and its whole purpose is to make the exploration systematic rather than intuitive: teams left to themselves will always find the technological and economic implications and reliably miss the cultural and political ones, which is where the reputational damage actually lives.

The question that finishes the exercise is the uncomfortable one: how does it go wrong? Paul Virilio's point about invention holds here — build the ship and you have built the shipwreck. Every future product invents its own failure alongside itself, and the failure arrives later, which is precisely why nobody looks for it in the business case.

Backcasting. Then you reverse the telescope. Standing in the future you have built, you work back towards the present, identifying the critical moments where things had to change and the thresholds that had to be crossed for this world to exist. Backcasting converts a scenario into a chain of dependencies, and dependencies have owners and dates. It is the mechanism by which a project stops being about 2040 and starts being about the next budget cycle.

Current strategy. The loop closes on the organisation's existing strategic language — aspiration, where it chooses to play, how it intends to win, in the lineage of the strategy cascade later popularised in Playing to Win. Output that arrives in the organisation's own vocabulary gets used; output that arrives in ours gets thanked for. If you want the argument for why this stage justifies the budget, we have written separately about measuring the return on speculative design.

It is a methodology, not a sequence

Written out, the pipeline looks tidy. It is not, and we say so plainly when we teach it. In real projects threads run in parallel: the case-study material and the signal scan often happen at once, a concept arrives during the trend work and has to be parked rather than lost, and the implications of one design frequently send you back to change the scenario it lives in. Sometimes you start from a concept somebody could not stop thinking about and reconstruct the world that would have to exist for it to make sense. That is a legitimate route.

The discipline is not that these happen in order. It is that none of them silently gets skipped — because each one is the antidote to a specific, predictable failure, and the failure always shows up later than the shortcut.

What it does not do, and where it breaks

This methodology does not forecast. Nothing in it produces a probability, and anyone who tells you their scenario is likely has stopped practising foresight and started practising prediction. The claim is narrower and, we think, more useful: treat this future as real for a moment, and see which of today's decisions look different.

Three failure modes are common enough to name. The first is falling in love with a future — the team becomes an advocate for one scenario, which quietly turns speculation into a pitch. The second is cliché: flying cars, chrome, dystopia by default. The antidote is finding the twist, the detail that is specific to this signal and this domain and could not be copied into any other project. The third, and the most damaging, is staying abstract, which is the failure the concept discipline and the persona work exist to prevent.

The organisational failure modes are separate and mostly harder, and we have written about the seven ways speculative design fails inside organisations. The short version: a project can execute every stage above competently and still change nothing, if the organisation has no mechanism to absorb what comes back.

Finally, the method is not free of the person using it. The signals you notice, the consequences you find plausible, the lives you can imagine — all of that is bounded by who is in the room. Widening the room does more for the quality of a futures project than any tool in the workflow, including all of the above.

Where to start

If you are running this for the first time, the two decisions to get right before anything else are the horizon and the brief. Set the horizon beyond ten years, and make the brief name both a specific source of change and the specific domain you are asking about. Almost every weak project we see is traceable to one of those two.

Our Speculative Design Basics course takes you through the whole workflow at your own pace, with the methods, the case studies, and a project of your own to run through it.

Key takeaways

• •The workflow is a double diamond with a third diamond added for implementation — the third one exists because the deliverable is a changed decision, not a future.
• •Time horizon governs everything: organisations think in two years, software teams in weeks, and the sweet spot for this work is beyond ten years and short of twenty-five.
• •The front half is foresight — signals, trends, future wheel, scenarios, personas — a capability many organisations already have and that speculative design augments rather than replaces.
• •Specificity is the whole game: a named, described, sketched concept can be argued with; an abstract one gets nodded at and forgotten.
• •Implications are worked outward from human experience across the social, cultural, technological, ethical, economic, environmental and political, and finish with "how does it go wrong?"
• •It is a methodology, not a sequence — threads run in parallel and no stage should be silently skipped — and it does not predict; it changes what today's decisions look like.