While production is cheap, judgment isn't.

Written by George Mackenzie, design engineer

In the world of design, we used to rely on distinct tools for distinct phases of the design process. Some tools were used in multiple phases, but overall, there was a recipe for how you would go about designing an outcome. Nowadays, the tools that we use to design features are the same ones that we use to brainstorm ideas, and make them tangible. The conversations on brainstorming and UX intention now happen when something that could reasonably be shipped exists. The big question I'm asking myself is “how can we ensure that judgment is encoded in our process, so we aren't left catching mistakes in production?”

I'm asking this because while many parts of the design process have been automated, judgment is imperative for building the right thing. This means knowing what "good" looks like when nothing tells you.

The shape of design

Since the early 2000's, the design process has remained relatively unchanged, with the “double diamond” being touted as the good word at top-tier design institutions. During my time in design school, the process of archiving and curating each stage of expansion and compression of the double diamond as you developed ideas was as important as the final output. For many brain-scrambled mid-twenty year olds, this guidance was paramount for teaching critical thinking skills when tackling ambiguous problems. In reality though, problems are never double-diamond shaped. The process is more of a tangled ball of messy abstract thoughts and panicked scribbling until finally, somehow, inspiration and instinct strikes. As a design researcher at University of Tokyo's DLX Design Lab, our team used speculative design to bring imagined futures to life as a way to stress test hypotheses for how tech might develop over time. This process relied on deep research and mulling over possibilities far more than following a strict design process. At Cogna, we have “design time” dedicated to working through unstructured ideas as a team, and give ourselves the freedom and time to think through messy problems. Jenny Wen, designer at Anthropic, describes how above all else, good process is “a clear, unwavering ideal of what good looks like.” How you get there is entirely dependent on the problem's shape and size. Judgment is the instinct for what good looks like when there's no clear shape to a problem. What I want to share is how judgment gets exercised now that the design toolkit has changed.

Designing the full stack in an afternoon

The beginning of 2026 was when I really dipped my toes into the world of rapid prototyping in my local environment. For all of this to make sense, I had to understand git and the basics of the development stack. Fast-forward to June of 2026, and as a designer, I'm able to vibe-code working features in our codebase in an afternoon. The Claude suite has made manually crafting high-fidelity prototypes a thing of the past. I now judge features based on the generated front end, and feed back on UI/UX that needs adjusting. In this world, code is a by-product of design, not something that happens downstream of it. I can effectively collapse the entire design process and the design to engineering handoff into working front end code. While this process is extremely gratifying and empowering, design instinct and engineering judgment are more important than ever.

So here's what happened recently. We needed a space in our platform to configure data and relate it to the systems that it came from. We wanted to show what data was missing in this space, so it was clear what data our platform still needed access to, before proceeding. After a few conversations with our solution architects (our main users) about what was needed, and with developers on what was possible, I chatted to Claude Cowork to develop a first pass at what the data understanding space could look like. I thought about the information architecture of the space, and brainstormed the UI to upload new data examples and associate it with specific systems. After creating some sketchy designs with Cowork, I used those HTMLs as the starting point for Claude Code to create the feature within the context of our platform, within our design system. The process of taking insights from conversations about the feature to an open PR that I was happy with took about 4 days. Before these tools existed, I'd estimate that this sort of task would have taken 10ish days.

I was satisfied with the final UX that I curated through the updated UI in the platform, and as far as I could tell, the code itself was a means to an end. From a design perspective, I was looking at what Jenny Wen would call “good”. As the user, I could do what I wanted to. I could add files in the way I wanted to, configure them, and choose what data type a field may have within a file. The UI itself was cohesive and blended into the existing platform nearly perfectly. But from the perspective of a developer, the code was bad, perhaps even nightmarish. For example, the code resulted in bespoke components when it would have been more efficient to use existing ones from our preferred library. When looking at the code, it was easy for the developer to mistake Claude's deviations from the brief for my own design choices. It took time for the developer to unpick these deviations from what was really needed. What looked like a disagreement about code quality was really a difference in what "good" meant; mine and the developer's definitions of good weren't the same, and no tool could reconcile that for us.

PRs that aren't PRs

In the "old days," I would have created a build-ready file in Figma and left comments where pieces felt ambiguous and which pieces were the intentional changes from the current state of things. Our developer would reply and we would sort things out in comments. Once we were both happy, I would leave implementation to the developers. Today, the source of confusion between myself and engineering was that a PR no longer represented what it used to. It was infinitely faster for me to make an experiment in a branch in the platform than pull relevant pages from Figma into the right places. But the derived code from my designs did not match our developer's standard of merge-ready code. To address this, I've started talking about my outputs as “design PRs.” These PRs are chunks of code that visualise the user experience and behaviours needed to solve a problem in our platform, with code that is merely a consequence or by-product of the front end.

Along with this new terminology, I needed a way to communicate the diff in a design from our current platform. I started using Claude Design to develop presentations from my PR's branch. Developers could scan the presentation's visuals and immediately see what was different. For example, the images below are from a presentation on rethinking our history view in the platform. The judgment call here was about what to make visible by sharing the intentional design decisions, so the developer wasn't left guessing.

Example slide from design PR presentation

Start with "so what?"

The design PR and subsequent before/after images are one example of how we are fostering communication without leaning on manually-created design files. Another change is that the work which used to happen by default now has to happen on purpose. Before I talk to Claude, I need a clear view of requirements to make sure I'm not misguided by generated UIs. There's a real temptation to chuck a half-formed thought at Claude, make a cup of tea, and see what comes back. Sometimes that's the right move. More often, it's me delaying the harder work of figuring out what I'm actually trying to solve. I've started forcing a "so what?" on every feature idea before I start prototyping, which goes hand in hand with knowing what “Good” looks like. For example, the goal of the before/after images I shared was to ensure that the user reading through a project's history doesn't need to be git-literate to understand what has changed, and when. I kept a clear north star view on how a prototype fulfilled this requirement, and avoided getting sucked in to Claude's follow up statements (“would you like me to provide 3 alternative views, each using a different design system?” No! I don't!). What I create on a branch is a conversation starter, and can only be a candidate for merge once the keepers of the code are happy that the vibed-implementation is manageable, and won't create unnecessary entropy in our codebase. My presentations loudly point out what has changed and what the intended design achieves, so there's no guess work for our developers. When I get pushback due to feasibility, the polished prototype often feels hard to walk away from. What matters is carrying forward the user's needs, the design intent, and the constraint I just learned. Deciding what's essential to the outcome is the judgment call I must make.

Closing thoughts

The work feels harder because the messiness of discussing and deliberating design choices hasn't disappeared, it's been displaced. Those discussions are pivotal to good development. They can now happen while we use the incredible new prototyping tools out there. By establishing design intent before prototyping, and clearly noting intended differences in a branch vs main, I can make my design choices clear, even when using tools that provide infinite possibilities. Anyone can ship a shiny feature in an afternoon. The work I care about is whether the outcome is capital G Good, not just whether the polish is.

P.S. At Cogna, we help customers go from unsolved problems to production-ready solutions in weeks. Our platform sifts through messy ambiguous problems, and generates interfaces as potential solutions for customers to get work done with. The design PR, the design change presentations, and the "so what" check are several ways that we can clearly and rapidly iterate on our platform. Our teams are exploring even more ways to communicate when designs are expressed in code. If these thoughts resonate with you, please reach out. We are looking for like-minded designers and developers to join us.

About the author

George Mackenzie is a design engineer at Cogna with a background in design research and a previous life in biomedical engineering. Her work focuses on how design can be used to make complex experiences clear, and how to use the latest tools to make these experiences a reality.

George cares about using design as the tool to speak across disciplines, to ensure cohesion and shared understanding across different types of product builders. She also cares a lot about riding bikes and making art.