Before the prompt

AI has made it much easier to get an interface on screen. I can ask for a component, a prototype or a handful of directions, and have something tangible to react to before I would have finished setting up a file a few years ago.

I like that. It removes plenty of tedious work, and it gives us more chances to explore an idea before committing to it.

It also makes me pay more attention to the judgement around the work. I still need to understand the problem, decide whether an idea fits the product and investigate the bit that feels wrong. The agent can help me explore those things, but I need enough context to judge the answers it gives me.

That’s a large part of what interests me in design engineering: understanding the product and the people using it, then knowing enough about the design and code to work through the details. I want to be able to recognise the part that needs another look and do something about it.

Speed can hide the missing work

The first version from an AI tool often looks surprisingly complete. There are cards, shadows, rounded corners and an animation when something changes. It can feel like a shortcut through the normal process of exploring, designing and building.

That can be useful, although it’s also quite easy to get attached to the first idea once it looks like somebody has spent a lot of time on it.

If we have not understood the task, all that speed just gives us more polished wrong turns. We can spend a lot of tokens refining a detail that should have been removed, adding another state to a flow that was already too complicated, or trying to make the interface feel delightful before we have made it clear.

Once there’s a convincing interface in front of us, the conversation can drift towards refining it. I want to leave enough room to ask whether we still need the thing we’re spending all this time improving.

Giving the details somewhere to belong

I keep seeing the same version of design engineering presented online: a beautifully isolated component, a bouncy spring, a playful hover state and a clip that loops for ten seconds.

I enjoy making those things too. They’re easy to share, and much easier to show in a short clip than the reasoning that led to them.

But if I start there, I can spend a lot of time trying effects without deciding what the interaction actually needs. It’s very easy to keep adding one more bit of movement when the tools make it so quick to try.

That is rarely how a good product feels in use. The animation that asks for attention every time you open a menu gets tiring. A button can have a great spring and still be in the wrong place. A richly detailed prototype can still leave someone wondering what will happen when they press it.

There’s plenty of care in the less visible parts too: keeping an action available with a keyboard, handling a failed request, or making sure the page still loads comfortably on a slow connection. Those details affect how the product feels every time somebody uses it.

I want people to be able to get to what they came for, understand what’s happening and carry on. Sometimes a lovely transition helps with that, and sometimes it just gives them another thing to wait through.

Deciding what to ask for

Before asking for the next version, I want to look at the current experience and decide what I’m actually trying to improve. Understanding the constraints and the awkward bits gives me something more useful to say than asking the agent to make it feel better.

Then I can use it to explore alternatives, get a first pass working or help with the repetitive parts, and judge that work against what I was trying to do.

I’m happy to have faster tools. I just want to keep enough of my attention on the product to notice when the next useful change is smaller than the one I was about to ask for.