The Decisions We Make. The Reasons We Lose.

How I built a design decision register that AI can read, without letting it decide.

The three-day problem

We agree on something in a meeting. The reasoning is clear in the room. A constraint nobody particularly likes. An alternative we considered and rejected. A technical limitation that changes what we can reasonably deliver.

Everyone agrees. Work starts.

Three days later, someone opens a ticket and asks why a particular element behaves that way.

The decision is there. The reasoning isn't.

Someone remembers part of the discussion. Someone else remembers a different version. Eventually, we either reconstruct the argument or make the decision again.

I've encountered this particularly often with small design decisions: an element's position, an interaction, a behaviour that seemed obvious when we discussed it.

We don't necessarily lose decisions. We lose the reasons behind them.

And when the reasoning disappears, it becomes difficult to challenge a decision intelligently. You can follow it, ignore it, or reopen the entire discussion.

I wanted another option.

Early 2023: I needed a way to keep up

In early 2023, I was working on metaverse projects while learning Unity and Blender alongside my UX responsibilities. We needed to develop enough of the experience to demonstrate its potential and secure the budget to grow the team, so much of the work happened in parallel. I was working more than sixty hours a week, including Saturdays.

The projects crossed several disciplines: 3D environments, native applications, smart glasses, WebXR, research and business considerations. A change in one area could affect decisions in several others.

My usual way of organising work wasn't keeping up. I had always worked relatively sequentially: focus on a subject, organise the information, finish it, close the folder, move to the next. That worked when subjects could be treated independently. It became increasingly inefficient when everything was connected.

The problem wasn't simply that I had too much information. It was that information I considered finished could suddenly become relevant again. I needed to move faster, but I was spending too much time reconstructing context.

So I invested time I barely had in changing the way I organised my work.

I started with Notion, building something closer to a project database than a traditional collection of documents. Decisions, constraints and subjects could have their own states instead of disappearing into closed folders. Later, I migrated towards Obsidian for its flexibility, extensibility and potential for automation.

Over time, the system evolved into what I now call my design decision register. It wasn't built to produce more documentation. It was built to stop losing the reasoning that made the documentation useful.

We eventually recruited a 3D designer, which relieved part of the workload. But I kept developing the system because the underlying problem hadn't disappeared.

From isolated decisions to connected reasoning

A user flow describes a path someone is expected to take. That's useful when the sequence of interactions is the problem. I still design user flows when they are needed.

But a flow doesn't describe everything surrounding that path. It doesn't necessarily explain the technical constraint that shaped an interaction, the business requirement that eliminated an alternative, or the unexpected behaviour that users developed to work around a limitation.

What interests me is the system the flow operates within: the decisions, constraints, assumptions and relationships that make the experience possible.

I also have a particular way of working. My background combines design and entrepreneurship. I tend to move quickly: test, observe, change, try again. That approach can be effective, but it can also be difficult to communicate in more hierarchical organisations. A successful result doesn't explain how you arrived at it.

When the reasoning isn't visible, a decision can look like intuition. Even repeated successes can be interpreted as luck rather than the outcome of a deliberate process. I've encountered that problem.

The register became a way to expose the reasoning without forcing everyone to think or work the way I do. Here is what I knew. Here are constraints A, B and D. Here is why I changed C. Here are the alternatives I considered, and why I rejected them.

This doesn't prove the decision was correct. It makes the decision understandable, and therefore challengeable. That distinction matters to me: a design register shouldn't exist to defend every past decision; it should make those decisions easier to revisit when the context changes.

It also creates continuity. I've shared the approach with designers I've worked with, and I use it with collaborators in my studio. When another designer joins a project, I want them to inherit more than a collection of screens, components and unexplained conventions. I want them to understand the reasoning behind those choices , and feel able to question it.

Giving the register an AI

Over time, the register became more structured, and I started connecting AI agents to it.

Today, it holds a few hundred notes across my working environment , the register itself, plus the research, watch notes and project records that feed it. The information lives in separate private vaults, and I've automated parts of the organisation and synchronisation that previously required manual work.

I use a hybrid setup: locally hosted open-weight models for some tasks, and external models accessed through APIs for others. GPT, Claude and Qwen are among the model families I work with, depending on the task and deployment.

Most calls still go through an API, which is a trade-off I accept and a risk I have to manage.

The agents don't all have the same permissions. Some are restricted to particular resources or local environments; external services are available only where they are needed and authorised.

This matters because UX decisions can contain sensitive information about products, strategy, users and internal discussions.

Keeping files locally doesn't automatically make a system secure, especially when external models are involved. Access to information and the ability to transmit it have to be controlled separately.

But the interesting part isn't the infrastructure itself. It's what happens when the agents begin connecting information.

When I start working on a subject, the agent begins with the context available to it. After a few exchanges, it can identify relationships with previous discussions, constraints and decisions. I can also direct it towards specific information or ask it to examine particular dependencies.

I think of it as a web of connections. Not necessarily a technical knowledge graph, but a way of working where subjects aren't isolated simply because they belong to different folders or moments in a project.

For example, while working on the vertical orientation of a tablet interface for a client, an agent brought back information from a meeting five weeks earlier. Another designer had mentioned a change during a short discussion , it lasted perhaps two minutes. I systematically record meetings and take notes, so the information had been captured. But it hadn't made its way into the documentation I was consulting for that particular task.

I had forgotten it. The agent brought it back into context.

The same principle helps with decisions that haven't been made yet. Sometimes an upcoming discussion could affect a constraint I'm about to act on. The system can surface that dependency, giving me a reason to postpone an arbitration rather than create unnecessary rework.

This is the kind of assistance I find valuable. Not an AI telling me what to design. An AI helping me remember what I need to consider before designing it.

A register is only useful if you can question it

The system has made mistakes.

Agents have surfaced incorrect connections, outdated information and conclusions that didn't hold up when I examined them. That pushed me to change the workflow.

Instead of relying on a single interpretation, I began using specialised agents with different review responsibilities: some examine the quality of research, others question factual claims, legal references or editorial coherence.

Their findings are shared with an editorial agent, which integrates corrections into a new version. Previous versions, review reports and decision records are preserved so changes can be reconstructed.

This article went through that process.

During one review, a research agent challenged a sentence I'd written claiming that opening exact files allowed me to identify which file produced each sentence.

It was wrong.

Knowing which files were available to a model doesn't establish the origin of every statement it generates. A reproducible context is not the same as verifiable attribution. The latter requires a separate discipline: attaching sources to claims and checking whether those sources actually support them.

That correction made the argument stronger.

Another agent challenged the number of notes in the register. It counted 574; I checked the directory myself, found 4,090 Markdown files, and rejected the correction.

When I looked again, the agent turned out to be right about the underlying problem. Most of those files were dependency READMEs buried in node_modules , the register itself holds a few hundred real notes.

I had verified the count instead of verifying what was being counted.

One correction accepted, one correction wrongly rejected, and the mistake found later by the same system that made it possible to check.

The agents don't vote on what is true. They expose questions that need to be examined. Even when several agents agree, they can share the same misunderstanding.

That's why the review process doesn't remove my responsibility for what gets published.

For each substantial deliverable, I keep a record of its state, sources, reviews and design decisions, along with previous versions where relevant.

Concretely, a folder looks like this:

status.md       the state, sources, and reservations about those sources
reviews/        separate factual, research and editorial reviews, plus integration
decisions.md    what was decided, which options were discarded, and why
article-v1.txt  the previous version, so the difference is reconstructible

The aim isn't perfect traceability. It's to make the reasoning and its limitations visible.

There is also a practical cost.

Not every decision deserves the same level of attention. For a quick win, I may implement the change first and document the reasoning afterwards.

For larger problems , an epic, an interaction involving several parts of a product , the reasoning develops alongside the work: constraints, alternatives and unresolved questions are documented as they emerge.

Those two kinds of records aren't equivalent.

A decision documented afterwards is a reconstruction. A decision documented while the problem is being explored preserves more of the reasoning as it developed.

I want the register to make that distinction visible, rather than giving every entry an artificial appearance of certainty.

More documentation, less mental overhead

I started building this system because I needed to work faster.

Today, the most important benefit isn't simply the time saved.

It's the attention I get back.

During meetings, I can spend less energy trying to capture, organise and remember every detail. I can listen more closely. Ask another question. Follow an unexpected answer rather than worrying about losing the previous one.

The exchanges become more natural.

I still record meetings and take notes. But I no longer have to rely on my memory alone to preserve every connection between subjects.

The system takes care of some of the repetitive work of organising, retrieving and confronting information.

That doesn't make me a better designer automatically. It creates more space to do the parts of design that require human attention.

The next challenge is making this work for other people.

I currently use the approach personally and with collaborators, but I want to experiment with it over longer periods alongside other designers , understand where it helps, where it creates friction, and what would make it easier to adopt without requiring someone to build an entire technical environment.

Eventually, I'd like to turn it into a ready-to-use Design Registry. Something a designer or a team could install and adapt to their own way of working.

That is still a direction, not a finished product.

For now, I want to be clear about what this article represents.

The dates in this text are mine, not archive records: 2023 is memory, not a file. What you're reading is what I can defend in October 2026 , not a recording of what I thought in the room.

The register isn't a guarantee that every decision was right. It doesn't replace discussion, disagreement or judgement.

It gives those discussions somewhere to begin.

When someone asks why we designed something a particular way, we can examine the reasoning, question the constraints and decide whether the choice still makes sense.

And when I'm sitting across from another designer, a colleague or a user, I don't have to spend the conversation trying to remember everything.

The register preserves the context. So I can give my attention to the people in front of me.