Designing in the Dark: Why Our Tools Can't See What We're Building
“We have the most sophisticated design tools in history. And yet the most important design decisions still happen in meetings, in people's heads, and in the margins of documents no one can find.”
There is something quietly absurd about the state of product design tooling. A designer can prototype a micro-interaction in Figma with sub-pixel precision. They can run an A/B test on button copy, instrument a funnel down to individual keystrokes, and ship a component to a live design system with a single merge. The craft layer of design has never been better supported.
And yet ask that same designer to answer a deceptively simple question — _why does this screen exist?_ — and you will likely watch them open four different tools, scan three Notion pages, and ultimately say something like "I think it was a decision from Q2, you'd have to ask Priya."
This is the central failure of current design tooling. It is extraordinarily good at capturing _what_ we designed. It is almost completely blind to _why_.
The four tools that built a blind spot
The modern product design stack converged around four dominant tool categories, each solving a real problem — and each, in solving it, quietly abandoned a different one.
| Tool | Description | Gap |
|---|---|---|
Figma Visual design prototyping | Masters the artefact - screens, components, flows, handoff. The single source of truth for what things look like. | Frames have no memory of the decision that created them. A component carries no record of the intent it was designed to serve. |
Mural/Miro Whiteboarding mapping | Captures the thinking session - journey maps, service blueprints, brainstorms, relationship sketches. | A snapshot of a conversation, not a living model. Relationships drawn in Miro decay the moment the workshop ends. |
Jira/Linear Backlog delivery | Tracks work units through a delivery pipeline. Excellent at answering: is this shipped? Is this blocked? | Tickets are divorced from the product theory that motivated them. "Why does this ticket exist?" is unanswerable from within the tool. |
Confluence/Notion Documentation specs | Houses the PRDs, the research readouts, the design rationale - when anyone writes them down at all. | Prose is not a model. Documents don't know what they relate to. A spec written today has no structural link to the decision it justifies. |
Taken together, these tools create a stack that is excellent at execution and poor at memory. They record artefacts, not reasoning. They track delivery, not meaning. And when a new designer joins a team, or a PM needs to justify a decision to a stakeholder, or the team hits a fork in the road and needs to know which path they've already walked — the stack offers nothing but a search box and the hope that someone wrote something down.
The design representation problem
The deeper issue isn't tooling — it's representation. Current tools represent products as collections of screens, tasks, and documents. But a product isn't any of those things. A product is a network of decisions, each made in a context, each serving an intent, each in relationship with others.
"A Figma frame is not a design decision. It is the residue of one. The decision itself — its intent, its context, its trade-offs — lives nowhere in the file."
This distinction matters enormously when a product scales. In the early days, the founder carries the product theory in their head, and the gap between decision and artefact is small. As the team grows, that gap widens into a chasm. Designers start building on assumptions they can't verify. PMs inherit a roadmap they can't fully explain. Engineers implement specs whose rationale has been lost.
Design with Memory is a direct response to this representation failure. It proposes that the fundamental unit of design is not the screen or the component or the ticket — it is the _decision entity_: a structured record of an intent, the context it was made in, and the outcome it was expected to produce.
What changes when design has memory
The practical difference between designing with memory and designing with the current stack becomes visible at moments of change — which is to say, constantly.
| Without any memory | With contextual memory |
|---|---|
| A new designer inherits screens with no rationale attached | Every screen/output traces to a decision with stated intent and context |
| Changing one flow requires tribal knowledge of upstream dependencies | Dependency relationships are explicit — change propagates visibly |
| Design decisions get re-litigated in every planning cycle | Decisions carry confidence (importance and priority) weights |
| Conflicts between features surface only after they ship | Conflicting intents are highlighted, noted, acted upon, prioritized, and resolved before they ship |
| "Why did we build it this way?" requires an archaeology exercise | Rationale is structural to the development process, not documentary — it lives in the process model, not a doc |
The shift is from design as artefact production to design as _model stewardship_. The designer's job doesn't change — they still create screens, flows, and systems. But now those artefacts are anchored to a living structure that makes the product's reasoning visible, navigable, and arguable.
Intent-consciousness as a design practice
The concept of intent-consciousness — designing not just for what a user does but for what they are trying to become — only becomes a practical discipline when your tools can hold intent as a first-class object. In current tools, intent is a comment in a Figma frame, if it exists at all. It has no weight, no relationship, no lifecycle.
In this approach, intent is a node. It has typed relationships to the contexts that qualify it, the decisions it motivates, and the outcomes that either validate or contradict it. A designer working in this model can ask questions that are currently unanswerable: which parts of this product are serving an intent that no longer exists? Which user intents have we modelled a context for but never designed a response to?
"Intent-consciousness isn't a philosophy you adopt. It's a structure you build. Without the structure, the philosophy stays in the slide deck."
This is what makes contextual memory a design tool in the deepest sense — not a tool for making design artefacts, but a tool for making design thinking durable.
Five principles for intent-conscious design
These are the working principles the memory framework surfaces for designers navigating product decisions:
| Principle | Description |
|---|---|
| 01. Name the intent before the screen | Every design decision starts with a written intent statement. Not a user story — a precise claim about what shift in user understanding, capability, or confidence this decision is meant to produce. |
| 02. Treat context as a constraint, not a footnote | The context a decision is valid in must be explicit and bounded. A design that works for an expert user in a desktop context is not the same decision as one for a first-time mobile user — even if the screens look identical. |
| 03. Carry the relationship, not just the artefact | When a screen is handed to engineering, the decision node that produced it travels with it. Rationale is not documentation added after the fact — it is part of the design output. |
| 04. Mark confidence explicitly | Every decision node carries a confidence weight — high, medium, or assumed. Low-confidence decisions are visible in the canvas as open questions, not hidden assumptions waiting to cause problems. |
| 05. Design for the model, not the milestone | The canvas is never finished. A design decision made today must be made in a way that the model can absorb, reference, and eventually contradict. Shipping is not the end of a decision — it's a data point that feeds back into intent. |
The tool we actually need
Nothing in this framework requires exotic technology. We need a different mental model for what design work is. The tooling follows from the model, not the other way around.
But the model does imply a tool that doesn't quite exist yet: one that can hold screens and decisions in the same workspace, that can traverse the relationships between them, and that can surface — without being asked — the parts of a product where intent and artefact have drifted apart.
That gap between the tool we have and the tool the model needs is, itself, a product opportunity. And it is exactly the kind of opportunity that only becomes visible when you stop looking at design as artefact production and start looking at it as something closer to what it actually is: a continuous act of making reasoning legible.
Discussion (0)
Loading...