Method
From First Principles to Design Principles
A set of prior conditions that must be shared and true before any design principle, pattern library, or research method can do its job.
The Prior Conditions
- One
Design decisions are always decisions about specific people doing specific things in specific contexts.
- Two
Every workflow contains visible and invisible participants. Designing for only the visible ones reveals an incomplete problem statement.
- Three
Understanding that exists only in one person's head or only verbally in a meeting is not shared understanding. It is assumed understanding. And assumed understanding cannot be challenged, refined, or built upon.
- Four
Shared, specific, visible understanding of who is in a workflow and what they need is the necessary precondition for forming a research question worth asking.
Without it you don't have a research question. You have a component looking for cover.
- Five
You cannot design an improvement to something you haven't fully and specifically described.
Without a described current state you have no basis for knowing whether the new experience is better, different, or merely unfamiliar.
- Six
The goal is not complete understanding before action. The goal is a durable, shared, and honest account of what is known, what is assumed, and what remains to be learned.
The Design Narrative
The design narrative is what these principles produce. Not a research report. Not a PRD. Not a persona template. A living account of the people in a workflow, what they need, and what remains understood or not.
“Explain your workflow to me in narrative form, complete with characters. Roles. They need not have deep backgrounds. Just their goals, challenges, and ways they want to feel is enough.”
The narrative does not have to be right. It has to be present. A coherent but incomplete story is infinitely more useful than no story at all, because you can push against a story that exists. Every correction is domain knowledge entering the room voluntarily, because the story created a surface for it to land on.
Two distinct research question types emerge from the narrative:
The Project Hypothesis
What we believe is true about this workflow and why.
Participant Questions and Tasks
Specific questions and tasks scoped for direct use with participants.
These are not the same question at different sizes. Conflating them is how research sessions become leading interrogations rather than genuine inquiry.
Three Artifacts. Three Jobs.
The narrative lives on a collaborative board: FigJam, Miro, or equivalent. Not in Figma. Not in Jira. Those files have jobs. The board is where the reasoning behind the work lives alongside the work itself.
Figma
Design source of truth.
Designers own it. Developers reference it. Keep it clean.
Jira / Confluence
Development and product source of truth.
Tickets, specs, acceptance criteria, release tracking.
The Board
The collaborative surface where reasoning lives.
Narrative, history, branching paths, knowns and unknowns, decision archaeology. Not owned by design or development or product. Owned by the work itself.
The board structure that works: screens laid out left to right in a flow. Hyperlinks where one flow branches to another. Design narrative components prefacing each workflow row. Masks over abandoned patterns with explanations preserved, so the team doesn't relitigate settled decisions.
Asynchronous updates matter. @ linked comments generate notifications and emails. A developer with a question at 9pm on Tuesday doesn't wait for Thursday's sync. The answer stays on the board. The next person with the same question finds it already there.
Permissions: Read access broadly. Comment access widely. Edit access deliberately.
The Board
The board is not a documentation tool. It is not a design artifact. It is not a project management system. It is the place where shared understanding is built, stored, challenged, refined, and made available to anyone with a stake in the outcome, asynchronously, persistently, and without requiring a meeting to access.
The design library is useful. It is the floor, not the ceiling. It answers what a component does. It was never meant to answer whether the component belongs here, for this person, in this context, with these stakes. That answer requires a described current state, named participants, stated goals, acknowledged gaps, and a hypothesis worth testing.
The board is where that work happens.