Speculative Design for UX Designers: Prototypes That Provoke Instead of Validate

Speculative design gives UX and product designers a way to prototype interfaces for products that do not exist yet, set a decade or more ahead, and to use those prototypes as provocations rather than validations. Instead of asking whether people can complete a task, a speculative prototype asks how they react to the future it implies — what they would want, refuse or fear — and traces the second-order effects back to decisions about the product you ship now.

UX designers are unusually well placed for this work, and unusually exposed to its main risk. A few hours in Figma and a 2037 banking app is running on a phone in someone's hand. That fidelity is what makes speculative work persuasive. It is also what makes people comment on the corner radius instead of the idea. Most of this guide is about using the first without falling into the second. The pillar essay covers what speculative design is in general terms.

What you already have: the shortest route from idea to artefact

The UX toolkit covers more of the speculative workflow than most designers realise. You can take a concept from a sentence to a clickable prototype in a day. You maintain a design system, so you already think about interfaces as rules rather than pictures. You probably have standing access to participants, which most futures practitioners would envy. And years of empty states and error messages have made you practised at asking what happens when things do not go to plan.

Speculative work turns all of that to a different purpose. The prototype stops being a proposal and becomes a provocation: an artefact from a possible future, built so that people react to the future rather than to the product.

The horizon problem: the interface is the most perishable layer

The UX horizon is the sprint and the release. Planning runs in two-to-six-week cycles, the design system has a version number, and "the future" in most design reviews means the next redesign. That is reasonable: the interface is the fastest-changing layer of any product, which is exactly why it is hard to see past.

Over ten years, though, the interaction model itself moves. Apple announced the iPhone on 9 January 2007, built around a large multi-touch display. A UX roadmap written in 2006 for 2016 would have been planning for keyboards, styluses and menus. This is Amara's Law at the scale of an interface: we overestimate the effect of change in the short run and underestimate it in the long run — the next release against the next decade.

Usability practice compounds the problem. Tests measure how today's users perform against today's conventions, so anything unfamiliar scores poorly by design. That is right for deciding what to ship, and the wrong instrument for exploring a different future.

Where it fits in a UX process

You do not need a parallel process. Each of your working documents can be pointed at a future instead of a release.

The methodology essay sets out the complete sequence. In a UX team, most of it can run inside the research cadence you already have.

A worked example: when no two members see the same app

Take a hypothetical app team at a regional building society — call it Kestrel. Kestrel and both its concepts are made up for this guide; the three events that start it are not.

The brief. What happens to everyday banking when every member's app is generated for them, each time they open it? Horizon: 2037.

The signals. In December 2017 Netflix described on its technology blog how it chooses different artwork for the same title for different members, based on what they watch — an early, mild case of two people seeing different interfaces to the same thing. On 31 July 2025 the Financial Conduct Authority published a review of digital design in consumer credit journeys, finding that some lacked "positive friction", the moments that make a customer pause before committing. And on 18 November 2025 Google launched generative UI experiments in which Gemini designs and codes a custom interactive response for each prompt, noting that results could take a minute or more to generate.

The future wheel. In the middle of the wheel goes the assumption that interfaces are generated per person, per session, everywhere; the focus is Kestrel's app. The inner ring is unsurprising: no fixed screens, a team that ships rules rather than layouts, a design system that becomes instructions to a generator. Further out, it gets uncomfortable. Support staff can no longer say "tap Payments at the bottom". A daughter helping her mother over the phone cannot describe a screen she has never seen. Screenshots stop being evidence in a complaint. Five usability participants tell you about five different interfaces. And the generator learns which arrangement is most likely to get each member to accept a credit offer. Furthest out, "what did the customer see?" becomes a regulatory question, members start asking for a standard view, and shared know-how about the app disappears from families and forums.

The concept.

• •Name: Kestrel Fitted.
• •Tagline: An app that rearranges itself around your month.
• •Description: The app has no fixed screens. Each session is composed from the member's accounts, where they are relative to payday, recent spending and the society's rules. Two days before payday it leads with a balance forecast and folds the savings transfer away; the week after, the savings pot comes first.
• •Sketch: Three phone screens for one member on the 1st, 14th and 27th of the month, and beside them her son's screen on the same day, unrecognisably different.

The provocation prototype. Build those four frames in an afternoon, outside the live design system. Use real, specific copy and numbers, because the content carries the argument. Use grey boxes and default type for the chrome, because polished components invite component feedback. Present it as an artefact from 2037, not a proposal for next year.

Then run a reaction session, not a usability test. Book five members from the research panel. Do not ask them to find the savings transfer. Show each person "their" screens, then reveal another member's version of the same day, and ask: what would you want to be able to prove? Who would you call if this went wrong? Would you trust an app you could not describe to someone else? What comes back is reaction, not a green light.

Implications, and the shipwreck. Paul Virilio argued that every technology invents its own accident: invent the ship and you have invented the shipwreck. Fitted's is not hard to find. A generator optimising for engagement will find the arrangement of each member's screen most likely to lead them into their overdraft, and nobody else will ever see that screen. The generated interface invents the generated dark pattern, one per customer and invisible by construction. The human implication is quieter and worse: an app you cannot describe to your own family isolates the members who most need help.

The implications produced a second, more useful concept: Kestrel Same Screen — "See exactly what they see." A member can share a live, read-only view of their app with a named person — a son, a carer, a branch colleague — and replay any screen they were shown at the moment they made a decision.

Backcasting. Reason back from 2037 (how backcasting works). A regulatory rung: firms must be able to reproduce what each customer saw at the point of decision, a plausible next step for a regulator already reviewing journey design. A design system rung: components that carry invariants — elements no generator may hide, demote or move, such as the balance, the cancel button and the complaints route. A research rung: methods for testing a population of interfaces rather than one. A threshold rung: generation that took a minute or more in 2025 has to become faster than a member notices before anyone puts it in a payments flow.

What changes this quarter. Kestrel's team does not build Fitted. It writes invariants into its current design system documentation — the elements that must never move, whoever builds the screen — which is useful today, when several squads build screens. It starts archiving what members were shown at key decision points, because A/B tests already mean not every member sees the same app. And it takes Same Screen into the next discovery cycle for the power-of-attorney and carers journey, where it answers a need members have now.

Where it goes wrong for UX designers

The pixel critique. You show a 2037 interface and the first comment is about the navigation pattern. This is the fidelity trap, and it is usually self-inflicted: the prototype looked like a proposal, so it was reviewed like one. Polish the content, rough out the chrome, frame the artefact as found rather than proposed. The organisational version, the aesthetic doing the wrong rhetorical job, is one of the seven failure modes of speculative design inside organisations.

Testing usability by habit. Task success, time on task, a satisfaction score: the instruments come out because they are the ones you have, and none of them measures what a provocation is for. "They liked it" is not validation either; a provocation everyone likes has usually failed to provoke. If research colleagues run the sessions, our guide for researchers covers how to do it without leading the witness.

The backlog swallow. A good provocation looks like a good feature, and someone will put it on the roadmap. The 2037 concept ships next quarter in cut-down form — Fitted as "a personalised home screen" — without the implications that came with it, so the shipwreck ships too. Hand a concept over with its implications and backcast attached, or not at all. The guide for product managers covers the roadmap side.

Happy-path futures. The future gets designed along the flow: the member opens the app, the app is helpful, the member is pleased. That is ring one with a nicer render. Design the screen for when it goes wrong before the one for when it goes right.

A first exercise for your next research slot

Your existing design tool, and a research session you have already booked.

1. 1.Choose one live flow you own.
2. 2.Pick a real event from the last two years that would change that flow if it spread — a product launch, a regulator's report, a court ruling. Record who did it and when.
3. 3.Jump to 2036 or later and treat the event as fully realised.
4. 4.Duplicate the flow file. Redesign three screens as they would be then, and give the product a name and a tagline.
5. 5.Make the copy and numbers specific; replace components with grey boxes and default type.
6. 6.Add a fourth screen showing the moment it goes wrong.
7. 7.Show it to five participants in the booked slot. Ask what they would want, refuse, fear or need to prove — not whether they can complete the task.
8. 8.Write down one decision about the live flow that the session changed.

If nothing changes at step 8, the year in step 3 was probably too close.

Where to learn it

Our self-paced course, Speculative Design Basics, is taught by J. Paul Neeley across 42 lessons, with lifetime access and no prior experience assumed. For UX and product designers the most useful parts are the Tools & Methods chapters on future prototyping, signals and future wheels; the Creating Value section, which connects the work to user research and to product and service development; and the Process section on how it sits alongside the design process you already run. The Case Studies include practitioners such as Near Future Laboratory and Tellart. For how other roles take up the same practice, see speculative design for every role.

Key takeaways

• •Interface fidelity is the UX designer's advantage and trap: it makes a future convincing fast, and invites critique of the UI.
• •The UX horizon is the sprint and the release, but over ten years the interaction model itself changes.
• •Build prototypes as provocations, not validations. Make the content specific and the chrome rough.
• •Run reaction sessions, not usability tests: ask what people would want, refuse, fear or need to prove.
• •Look for the shipwreck. Every new interface invents its own failure, usually a ring or two out on the future wheel.
• •The output lands in today's product as a decision: a design system invariant, an archive of what users saw, a concept taken into discovery.