The Pattern Is the Theory

I'd been thinking about a problem I couldn't put down.

Design decisions evaporate. Not the decisions themselves. Those end up in Confluence pages and Figma comments and tribal memory. The reasoning evaporates. The why. The alternatives that lost. The constraint that made this the right call instead of that one.

I'd tried to fix it. Docs. Spreadsheets. Notes buried in roadmaps. Nothing could hold it. What I needed was something built to my exact specifications, and you don't get a tech team allocated to a meta internal tool. Nobody's putting that in a sprint.

So it sat. Until my design organization started running AI literacy challenges.

This one: use an AI coding tool to create a web app that runs in a browser. No spec. No rubric for what the app should do. Just: make a thing.

I opened VS Code. Started riffing with an AI tool on what a decision log could actually be. Not a record. A narrative. Not a lengthy writeup. A moment captured while the decision is still fresh. The difference between those two things is the whole idea, and it arrived over a weekend of building without knowing where I was going.

I shared it back to the group. Won a $75 award. Then a colleague picked it up. Then another team. Then a program I wasn't part of. No mandate. People pulled it in because it solved something real.

A patent disclosure followed. Then a second one.

None of that was the plan. There was no plan. I went toward something I didn't understand and came back with something that didn't exist before. That's the only method I know that reliably works.

In 1977, Christopher Alexander published A Pattern Language. It documented 253 recurring problems in built environments, the solutions that held up, and the conditions under which they applied. Not artifacts. Reasoning.

The pattern isn't "use a window here." It's: people need natural light where they spend time, and the solution that has held up across centuries catches light on two sides. The window is the artifact. Everything else is the pattern.

Design systems tried to do the same thing. They documented components instead. Here is the button. Here are its states. Here is the token for its border radius. That's a style guide with good PR.

It tells you what to ship. It doesn't tell you why this interaction model beat the alternatives, what edge cases were rejected, or whether the conditions that made it right still apply to your problem. That's why designers work around design systems. Not obstinance. The system gave them an artifact without the thinking, and they're solving a problem the system was never designed to speak to.

The component is the artifact. The pattern is the theory. We've been shipping artifacts and calling them theories.

A senior designer makes a hundred judgment calls a year. Why this navigation model and not that one. Why this disclosure pattern and not a modal. Each call is informed by years of context: research, failed experiments, stakeholder constraints, hard-won lessons from things that shipped and broke.

Then that designer leaves. The next person inherits the Figma files and almost none of the logic behind them.

We've decided this is just how it works. The knowledge lives in people. People move. You accept the loss and rebuild.

Design leadership has been operating in field notes mode for decades. Smart people writing smart things, giving smart talks, publishing smart frameworks. Other smart people read them and find them useful and can't quite translate them into their own context because the reasoning is wrapped in someone else's specifics. There's no accumulation layer. No mechanism for a decision made on one team to become something the next team inherits. Every organization rediscovers the same problems and solves them alone.

That's not a discipline. That's an industry of field notes with no way to become theory.

What I built is a reasoning layer. Decisions documented as narratives, not records.

A record says: we removed inline validation from the approval flow. A narrative says: here's the problem, here's what we learned when we went to find out if it was real, here's who pushed back and what they said, here's what shipped and why. You can interrogate a narrative. Does the problem this solved still exist? Have the conditions changed? A record can't answer those questions.

That system is working. In use across multiple programs, different leaders, different parts of the organization. No mandate. People pulled it in. That's the only proof of incentive alignment that matters.

When enough decisions are documented across enough teams, patterns that keep showing up stop being opinions and start being data. That's stage two. Stage three is what Alexander spent his career building toward: a pattern language that emerges from the aggregate of what many teams have actually solved, continuously updated by new evidence, retired when the conditions no longer hold. Not authored by a committee. Discovered from the bottom.

The field notes are already everywhere. Smart people in your organization are solving hard problems and the reasoning is disappearing when they move on. What's missing is the structure that turns those notes into something transmissible. Something the next person can interrogate instead of starting over.

I built this and it scaled. You can too.