I make complex things clear

The most obvious change is speed. I've always been a fast designer, but AI has removed a remarkable amount of mechanical work. Creating component variants, exploring layouts, building interactions or getting a realistic prototype in front of someone can now take a fraction of the time it used to.

The real benefit however isn't producing more screens. It's having more time and attention for the things that are harder to automate: understanding what the product should actually be, thinking through the experience, questioning assumptions and exploring alternatives.

AI is also useful when I'm stuck. I can use it as an always-available thinking partner — to challenge an assumption, walk through edge cases, find gaps or suggest directions I hadn't considered. Sometimes it gives me a genuinely better idea. But the useful part is not that it gives me an answer. It's that it gives me more things to think about.

Fast prototyping has probably been the biggest practical improvement to my design process. An interactive prototype can communicate something that a collection of static screens can't. Stakeholders don't have to imagine how a flow works — they can use it. And because I can get to that level of fidelity much faster, I can use prototypes much earlier as a way of thinking and communicating.

But there is a catch.

When making something takes very little time, it's easy to show it before you've really thought it through. And once a realistic-looking version is in front of people, the conversation can shift from "Is this the right direction?", to "How should we improve this version?". That's how a quick experiment can quietly become a commitment.

I've become much more deliberate about what I show and when. A prototype is a hypothesis, not a decision. Its speed is valuable precisely because it gives us permission to question it.

Working effectively with AI has taught me that context is part of the design work. I usually start with a clean environment and make the important constraints explicit. I think carefully about the initial instructions, trying to give the model enough information to understand the problem without prescribing the solution.

The goal isn't to construct the perfect prompt. It's to establish a small set of sound assumptions and give the exploration a good place to start.

I also separate exploration from implementation. First we plan, question and clarify. Then we build. The same applies to the interface itself. I establish the design system early rather than letting individual screens accumulate their own decisions. It can evolve, but the surfaces should come from a system.

This matters because AI is very good at turning small assumptions into a lot of output. If the starting point is wrong, it can simply help you get further in the wrong direction, faster.

AI has taken me much further into building than I could previously go on my own. I can build substantial frontends, work through product logic and collaborate on backend structure. I've also built a few small projects privately from scratch to a full live product.

But being able to make something work isn't the same as being qualified to own every consequence of how it works.

For small private experiments, I'm happy to push those boundaries. The risks are limited, and the learning is valuable. For a real product, I want competent people involved wherever the consequences exceed my expertise — particularly around backend architecture and other technical areas where a superficially working system can still introduce serious problems.

That's not a retreat from building. It's the same collaboration I've always had with developers, just from a different starting point. AI lets me get further before I need that collaboration. It doesn't make the collaboration less important.

Once the direction is sound, I can move unusually quickly from prototype to implementation. I document the system logic — rules, exceptions, blockers and edge cases — and use that as the basis for the build. I test with seeded data, test manually, and only then connect the system to real data.

After that, the product can start teaching us things that we couldn't have predicted upfront. This is one of the opportunities I find most interesting about AI: when the cost of iteration falls, we can spend less effort trying to perfectly predict user behaviour and more effort observing it and improving the product from evidence.

That doesn't mean shipping something half-finished because it's easy to change. It means building enough quality into the foundation that iteration becomes a deliberate way of learning rather than an excuse for skipping the thinking.

Fast iteration is useful. Low standards aren't.