Ideas

I design by building, and I've done it in every role I've had. At Google X I was shipping code before ChatGPT could help with any of it. I kept git commands in a notebook, and looked up conditional formatting just to add a bit of delight to the product (thanks Sergei Nozdrenkov for trusting me and teaching me to do it!). It was slow, but I loved adding the delight myself (even though the PM (who was also me in that early-stage team lol) wouldn't necessarily wanna prioritise it).

In March I joined Miro, the visual collaboration platform, to design its AI features. We had three months until our biggest launch of the year, and a vision of AI agents working on the canvas alongside people. Design leadership had just asked every designer to ship at least one change to production code, and a few of them led by example. In my second week I had my first change merged. It was a tiny visual cleanup, but the perfect way to dip my toes in before diving.

It was an intense and exciting time, and I wanted to share what I learned about what changes when building becomes cheap, and the habits that helped our team turn that into a better product.

When anyone can vibe-code a prototype in an afternoon, ideas stop being scarce. Decisions become scarce. We had more concepts than we could ever ship, and product and engineering didn't need another one. They needed someone to pick, and a spec detailed enough to build from.

It was also the moment when the tools were changing under our feet. It felt like Anthropic was releasing something every week that would require a complete workflow redesign. At the same time, most of the team still wanted to follow the old ways of working. There was no playbook, there was a hard deadline, confusion, and quite a bit of anxiety.

The real question for a design team wasn't "should designers code?" It was "what turns a cheap prototype into something a team trusts enough to ship?" For me it came down to four habits.

The most precise spec is the thing that runs. But earning the right to ship it was the actual work.

My first production pull request for a new feature was huge and hard to review. Engineers didn't expect designers in their review queue, I didn't know their conventions, and many pushed back because they preferred the old ways (yes, static screens in Figma). Arguing for a new way of working would only have made everyone more stressed. So I learned theirs: how to keep changes small, their review etiquette, how they work with coding agents. I made our engineering manager an early ally, and continued shipping, each time a bit smarter and better.

Over time the format settled. I'd open a draft pull request with a short video walkthrough, and an engineer would either finish and merge it, or hand it to their own coding agent as a spec. Small improvements that would have drained away in the backlog got shipped, either by being directly reviewed as PRs or by convincing product, because a working change creates an urgency a ticket never does. Since March, 64 of my changes have been merged into Miro's production app. This might seem very small when there are people talking about merging 1,000 PRs in a month, but many more went through our in-house coding agent, which doesn't attribute the human owner.

I have shared this approach with many of my colleagues, and they have successfully adopted it too. By August, almost every designer across our 65-person design organisation had shipped a PR!

A prototype gets shown in a review. It's impressive. It looks like the actual product, it works, it feels almost done. Somehow your managers and cross-functional colleagues don't buy it. They seem a bit confused. Looks great, but have you given it enough thought? That micro-interaction you spent time on - did they even catch that 1 second? All the thinking and craft, the principles, the options you rejected and the edge cases, are not explained. Trust is not built.

I was just pitching the idea of making agents equal collaborators to humans on the canvas. Much of the design was motion and behavior: how an agent arrives, moves around, shows progress, and leaves. Static screens can't show it, and demoing it doesn't isolate the actual design principles visually in a way that the human brain can understand quickly. You need a spec.

So alongside the prototype I built a living documentation page. It works like a small product website. It starts with the pitch and the use cases, then the design principles, then every state captured as a short loop with its spec. It's interactive and it isolates all the states, so it's easy to comprehend. It quickly became the shared reference for design reviews, for working with our brand team, for pitching to leadership, and for handing over to engineering (or their Claudes).

The prototype shows you what it feels like, but a visual, interactive spec page allows you to have substantial conversations about the design, and enables collaboration again in a world where each of us produces more and more in a single-player setting with our own agent.

Quickly, these pages also became a medium for concept galleries: low-fidelity HTML pages to explore options side by side, fast, before spending time on bringing them into the actual product's digital twin. You evaluate many options and can then move to the prototype with a few candidates to really check how they feel in context.

In software development, teams have relied on feature flags for years to experiment in the product. I adapted the same for our design prototype: a hidden menu with a list of toggles, so you can mix and match and really see "which of these feels better?". It caught on fast. The registry now holds around 141 flags from 13 people, and Principal Designer and close colleague Robert Kortenoeven has added more than I have (it is so long now that it kinda bites us in the ass sometimes to find the right combination of flags!).

The last habit was the one that always took ages and was an afterthought rather than a foundation for many product organisations: design based on real usage data from the start.

Our top community request was a cleanup of the context menu on sticky notes, Miro's most-used object, which had grown to around a hundred options. Doing it properly means listing every action across every menu, grouping them, and checking usage to see what must stay one click away. None of it is hard, but it's very time-consuming. So I connected Claude to our data warehouse and dashboards and had it do the lot. The result was a page with a clear, data-backed approach. It classified the actions into meaningful categories and created variants for how we could approach the redesign. It also fed into a company-wide overview of all 59 context toolbars and their 251 actions. The final redesign was built on top of this analysis. It took me half a day to have this concrete, data-grounded proposal. Without AI, it would have taken me a week at least.

None of this was mandated. It spread because it was useful. Our CEO called out the changes I'd shipped at a company-wide session in my first months, and word travelled fast (the power of whisper marketing!). People started finding the documentation pages on their own and asking who to talk to. That's when they stopped being my working files and became something the org navigates by. Other designers started shipping code too, and I helped set up and onboard many of them.

Things that would typically take a designer a few days could be done in half the time. We had in-depth discussions much earlier, and decided and shipped much faster than ever before. And I believe it shows in the product itself: the amount of improvements and their quality is like never before. As the AI Stream, we broadly agree that we have finally reached a product state we can say we are proud of. Of course it's not perfect (welcome to the product world!), but we left it much better than we found it.

And what I'm happiest about is that designers now wear many more hats: engineering, analytics, product. For me, those are the strongest collaborators and product builders.

Coding was never the hard part. The hard part is making the work stick, so a fast prototype becomes something a team can ground decisions in, break down, prioritise and ship. That's what I'd build first in any design org learning to work with AI.