The Manual Of Design Fiction

Getting Started With Design Fiction As A Practical Tool

Design fiction isn't about making pretty speculative concepts for a portfolio. It's about building fictional artifacts to expose the hidden assumptions in current systems before you commit engineering resources to them. I learned this the hard way after a client paid me three weeks to produce a set of product mockups that looked incredible and absolutely proved nothing about whether the underlying technology could actually function in their target environment. The core methodology is straightforward. You create objects, scenarios, or narratives that appear to exist in a near-future context. These fictions aren't predictions. They're argumentative tools disguised as design work. When someone encounters a fictional user manual for a product that doesn't exist yet, they react emotionally and intellectually, and those reactions reveal where real tensions lie in the domain you're studying.

The Manual Of Design Fiction

I've seen several documents circulate under names like The Manual Of Design Fiction across different institutions and consultancies. Most of them cover similar ground because the discipline has a fairly small number of foundational principles. The most useful version I've encountered is the one originating from Dunne and Raby's framework, which treats design fiction as a form of critical design practice. If you're looking for a specific PDF to download, search for the RCA publications on speculative design and design fiction. They're open access and far more rigorous than the typical startup guide that gets shared around. The basic process I use runs like this: define a provocation, build an artifact that embodies it, place the artifact in a realistic future context, and then observe how different stakeholders respond. The response data is what matters. The artifact itself is secondary and should be discarded or archived after the research window closes.

Building Artifacts That Actually Work

Beginners tend to spend too much time making things look convincing. A photorealistic rendering of a smart watch interface won't help you if the underlying question about privacy trade-offs hasn't been clearly defined first. I usually start with text-based specifications and rough paper prototypes before touching any design software. This forces clarity about what the fictional object actually does before aesthetics become a distraction. The artifact needs to include mundane details that real products have. A warranty page, a terms of service link, a customer support phone number that routes to a fictional call center. These boring elements are where the fiction becomes legible. People trust objects that include friction and bureaucracy because that's how real products work. A sleek concept without a return policy feels like marketing. A concept with a two-year limited warranty and a FAQ section feels like something you could order tomorrow, and that's when people start asking the questions you actually want them to ask. I once spent four days building a fully rendered fictional social media platform called a memory archive tool. The engagement from stakeholders was polite but shallow. Nobody said anything unexpected. I threw it out and rebuilt it as a single printed page that looked like an eBay listing for a discontinued device. The response was completely different. People argued about whether the product seemed legitimate, pointed out inconsistencies in the specifications, and revealed their own attitudes toward digital permanence. The simpler artifact generated more useful data in two hours than the polished version did in two weeks.

Common Pitfalls And Where The Method Breaks Down

Design fiction fails when the fiction is too distant from the audience's frame of reference. A scenario set fifteen years out about neural interface advertising will confuse more people than it clarifies. Keep the timeline tight. Two to five years is the sweet spot for most commercial applications. Beyond that, you're not doing research anymore. You're writing science fiction and calling it a workshop activity. Another failure mode is when the facilitator falls in love with their own fiction. If you believe your hypothetical product is genuinely viable, you'll unintentionally steer discussion toward adoption strategies instead of critical examination. The moment you find yourself defending the concept rather than observing reactions, stop. Switch to a red team exercise or bring in someone who has no investment in the outcome. The method also doesn't work well for highly technical domains where the audience lacks baseline literacy. I tried running a design fiction session with a group of structural engineers about autonomous construction drones and spent the entire first hour translating vocabulary. Design fiction assumes participants can suspend disbelief about the artifact itself so they can focus on the implications. If they're still figuring out what the thing is, the exercise collapses. In those cases, a traditional requirements workshop or a technical feasibility study will give you better ROI.

A Practical Walkthrough

Here's how I ran a recent session that actually produced actionable results. The client was a mid-size healthcare company considering a patient data portability feature. Instead of building user personas and wireframes, which is what they expected, I created a fictional regulatory document called the Cross-Facility Health Record Transfer Act of 2029. It was formatted like an actual government pamphlet with sections on compliance requirements, penalties for non-adherence, and a flowchart showing how data would move between providers. I printed it on slightly yellowed paper and left it on tables in a conference room with six stakeholders from engineering, compliance, and product. No facilitator notes. No prompts. Just the document and a notepad. Within forty minutes, the compliance lead started cross-referencing the fictional penalties against their current risk framework. The engineer noticed a gap in their existing API architecture that the fictional transfer flow exposed. The product person realized their assumption about patient consent workflows was wrong. We spent the next two hours discussing those discoveries rather than debating whether the feature was a good idea in the abstract. The whole exercise took roughly three hours of preparation including writing the document, formatting it, and printing. The insight generation lasted about ninety minutes. A traditional discovery process for the same scope would have taken two to three weeks of interviews and synthesis.

When To Use This And When Not To

Design fiction is useful when you need to surface unarticulated assumptions, test stakeholder reactions to a direction before committing to it, or create shared understanding across teams that normally don't communicate. It's not useful when you need quantitative data, when timelines are measured in weeks rather than months, or when the audience consists of people who respond poorly to ambiguity and prefer direct technical specifications. Combine it with other methods rather than relying on it alone. A design fiction artifact followed by a structured debrief interview produces stronger results than either approach in isolation. Pair it with journey mapping to understand how the fictional product would fit into existing workflows. Use it alongside technical spikes when you need to validate whether the underlying assumptions are even plausible. The Manual Of Design Fiction as a practice is less about a specific document and more about understanding that fiction can be a rigorous research instrument when constructed deliberately. The quality of your output depends entirely on how clearly you define the question you're asking before you start building the artifact. Most people skip that step and wonder why the results feel vague.