The Space Between Design and Engineering

In 2023, I joined AXA Mansard through its Executive Trainee programme. That was the beginning of my software engineering journey.

I started with frontend and mobile development, working on applications that people actually depended on to get things done.

It was quite different from freelancing.

For one, I was working within existing systems and codebases, alongside other engineers and teams. There were business requirements, dependencies, deadlines, and decisions that had been made long before I joined.

I also started seeing how much work goes into making even seemingly simple features behave properly.

Take a form, for example. From a design perspective, you might be thinking about the layout, field grouping, labels, and how easy it is to complete.

When you’re implementing that same form, you also have to think about validation, API responses, loading states, errors, permissions, and what happens when someone does something you didn’t expect.

And those things affect the design too.

An error message needs somewhere to appear. A loading state needs to communicate what’s happening. Validation rules can change how a form should be structured in the first place.

I started paying more attention to these details, even when I was doing design work.

One thing I’ve noticed is that it’s relatively easy to design for when everything goes right.

The data loads, the content fits, the user follows the expected flow, and every interaction behaves exactly as intended.

Real applications are rarely that straightforward.

Sometimes a request takes longer than expected. Sometimes the data is incomplete. Sometimes someone clicks something twice, or tries to do something they don’t have permission to do.

These are all things that need to be accounted for, and they can have a pretty big impact on the experience.

Even when everything works, there are smaller details to consider.

Does an interaction respond quickly enough? Is the feedback clear? Does an animation help someone understand what’s happening, or does it just look nice?

I’ve come to see these as design and engineering decisions happening at the same time.

You can design a really nice transition, but how it’s implemented affects how smooth it feels. You can build a technically correct feature, but if the feedback is confusing, people will still struggle with it.

The two constantly affect each other.

Here’s a simple example. Try submitting the form under different conditions and see how the experience changes.

Around 2025, I started taking on more backend and full-stack work, and this became even more apparent.

There wasn’t one particular project that changed how I thought about things. It was more of a gradual realization from working on different projects and running into different kinds of problems.

I’d be implementing something and notice that a small technical decision had implications for the user experience. Other times, I’d be designing something and realize that understanding the underlying system would help me make a better decision.

I’ve seen this play out in some of my personal projects too.

With the Ace Trail Tutors website, for example, I spent time working on the motion and interactions. Getting the animations to look right was one part of it. Making sure they performed well, using transforms where appropriate, and accounting for people who prefer reduced motion were just as important.

Here’s what the hero looks like with and without the full animation.

I don’t think every designer needs to become an engineer, or that every engineer needs to learn how to design.

There’s a lot of value in specialization, and I’ve worked with people who are exceptionally good at what they do because they’ve spent years focusing on it.

But I do think understanding a bit more of what happens on the other side makes a difference.

As a designer, knowing how things are built helps you make more informed decisions. You start thinking about performance, accessibility, and technical constraints earlier.

As an engineer, understanding design helps you look beyond whether a feature works. You pay more attention to how people experience it, whether the interaction makes sense, and whether there’s a better way to approach the problem.

Sometimes that means simplifying a design. Sometimes it means putting in extra engineering effort because a particular interaction is worth getting right.

And sometimes it means questioning the original approach entirely.

I think there’s a real craft in being able to move between those perspectives, understand the trade-offs, and make decisions that account for both.

These days, I work across product design, frontend development, backend systems, and whatever interesting thing I decide to experiment with next.

I still enjoy design for many of the same reasons I did when I started. I like good typography, thoughtful layouts, interesting interactions, and the little details that make a product enjoyable to use.

I also enjoy figuring out how things work, solving engineering problems, and building the systems behind those experiences.

There’s still a lot I don’t know, and that’s part of what keeps it interesting.

I don’t really see design and engineering as separate interests anymore. They’re both part of how I approach building things.

And I want to keep getting better at both.