Writing

Why I started design engineering

I wanted a faster way to get an interaction out of my head and onto a screen.

3 min read

A flipbook bound at its spine. Each page carries a still drawing of a ball at a different height. As the pages flick past, the stills become one ball bouncing and squashing on the floor.
No single page shows the bounce. You only see it when the pages run.

The part that took the longest was explaining how something should work.

I could show a screen in Figma. Explaining the behaviour took more effort. What happens after a click? What stays visible? How should it respond if someone changes their mind halfway through?

Then there was the next round. Once I could use the implementation, I would notice something I wanted to change. That meant explaining it again, waiting for an update, and trying it again.

None of those conversations seemed especially long on their own. Together, they made iteration feel slow.

The loop that felt slow

  1. Explain
  2. Wait
  3. Try it
  4. Then back to Explain, for every change.

What building with AI made easier

  1. Describe
  2. Try it
  3. Then back to Describe, while it's fresh.
A sketch of how the workflow changed, not a measurement of time.

I wanted to try the idea sooner

Building with AI gave me a shorter route. I could describe the behaviour, try what it produced, and ask for a change while the problem was still fresh in my head.

I still had to explain what I meant. But I could follow that explanation with something working, and use it to figure out what I had missed.

That mattered because I don't always know the right answer before I try an interaction. Sometimes using it is what makes the problem clear. Having to describe the next version before I could test it added another step to that process.

Figma felt like a box

Speed was only half of it. When I worked on interactions in Figma, I felt like I was designing inside a box. I could link frames and pick an easing curve from a menu. The parts that make an interaction feel right stayed out of reach.

In Figma I could try

  • Linking one frame to the next
  • An easing curve from a menu

In code I can also try

  • A haptic tap when a toggle snaps
  • A spring tuned until it settles right
  • Five fast clicks in a row
  • Every state in between

In code, those stop being guesses. I can change a spring, run it, and feel the difference in seconds. The number of ideas worth trying went up, not only the speed of trying them.

A working version changes the conversation

Consider a panel that opens after a click. A static screen can show its position and contents. It tells you less about whether opening it interrupts the task, whether focus moves somewhere useful, or how easily someone can return to what they were doing.

A static screen shows

  • Where the panel sits
  • What's inside it

A working version also shows

  • Whether it interrupts the task
  • Where focus goes
  • How to get back

These are easier questions to discuss when there is something to use. I can point to the behaviour, change it, and compare the result.

That is the part of design engineering that drew me in: being able to work through more of those decisions directly.

Faster iteration still needs judgment

AI makes it easier to produce a version that looks convincing. I still need to decide whether it behaves well. A polished first attempt can leave awkward states untouched.

The time saved is useful when I spend it trying the interaction again, including the cases that were easy to overlook in the first pass. If I stop as soon as it looks good, I've only made the first draft faster.

I started because the explanation-and-iteration loop was taking too much time. I wanted to get to a working version sooner, stay with the problem, and make the next change while I could still feel what needed fixing.

That's still the most useful part for me.