I’ve spent most of my career working on products where the hard problem was never really the screen.

There’s usually a business trying to achieve something, engineering figuring out what’s possible, customers with their own ways of working, GTM trying to explain why any of it matters, and a product somewhere in the middle absorbing all of it.

I really like working there.

I’m happiest when there’s a lot to untangle. Pulling things apart, understanding what’s actually going on, and figuring out how they fit together again is oddly my zen mode.

Not because I think designers should own every function around them. But because I don’t know how you can design the experience well without understanding what creates it, what impacts it and what breaks or fragments it apart.

The problem you see on the interface isn’t always the problem you need to solve.

Sometimes, a usability problem can actually be a positioning problem. People can understand the value perfectly well and still not want to change how they work to get it. Sales can be selling a version of the product that the product itself isn’t particularly good at. Sometimes the company has simply grown faster than the experience has.

You can redesign the UI in every one of those situations and still not solve much.

I think a big part of getting good at this work is learning to understand which problem you’re actually dealing with.

Technically complicated products taught me something else: complexity doesn’t really disappear. Someone has to deal with it.

Sometimes the user needs that complexity because it helps them make a better decision. Sometimes the product should absorb it for them. And sometimes a painful workflow exists because the business itself hasn’t made a decision yet, so the interface is being asked to somehow make an unresolved problem feel resolved.

Making everything look simple isn’t necessarily good UX.

I’m much more interested in asking: what does this person actually need to understand, decide or do here? What complexity is useful to them? And what can we take off their plate entirely?

That question comes up constantly in the kind of enterprise and AI products I work on.

Hiding model uncertainty behind a friendly chat interface, for example, can look simpler while quietly giving the user more work to do. They now have to figure out what to trust, what to verify and when the system might be wrong.

That isn’t really simplicity.

An insight should change something.

I get impatient when research ends at an accurate description of what people said or did.

Useful, yes. But there’s still work left.

The interesting part is what that understanding changes.

Maybe we were solving the wrong problem. Maybe the workflow changes. Maybe the positioning does. Maybe something moves up the roadmap. Or maybe everyone realises that the thing we were preparing to spend three months building shouldn’t be built at all.

Those are the insights I find useful.

And the really good ones tend to outlive the project that uncovered them. You keep running into them again across features, customers and business cycles because you found something more fundamental about how people behave or how the system works.

In my head the stack is strict: data is what happened, inference is what you conclude, insight is what rewires the problem. If nothing flips when you say it, you’re still in inference.

And the useful bit is what you do differently because of it.

I think about systems in much the same way. A system should remove work, not become more work.

I build design systems for large, mature product suites and also spend a lot of time on very early-stage products.

The needs are completely different.

A design system earns its place when it makes the next thing easier to build. If maintaining it creates more work than the problems it removes, I’m not sure what we’re optimising for.

Build what keeps repeating. Standardise what has become stable. Document when people actually need the documentation.

The product should never become secondary to an immaculate representation of itself.

Sometimes the right design system for an early-stage product is one page.

Please make the product work first.

I care a lot about what happens after something ships.

Good product designers think backwards and forwards at the same time.

I’m suspicious of design that looks excellent when it launches and makes everyone’s life miserable for the next four sprints.

Products move too much for that.

Teams change. Features accumulate. Engineering constraints change. The company learns things it didn’t know six months ago. Sales needs something nobody anticipated.

The best product designers I’ve worked with, and learnt most of my product design fundamentals from, are constantly moving backwards and forwards through all of this.

They’re thinking about what shipped yesterday, what users still don’t get, what needs to happen today to support something three or four sprints from now, how to make engineering’s life easier, where to remove a bottleneck, and what the business needs next.

They still ship by the launch dates. They still make tradeoffs. They don’t let caring deeply about the experience turn into perfectionism. But they also don’t stop thinking about something because its launch date has passed.

And somewhere in all of that movement, they’re still asking: does this actually make sense to the person using it?

I think that constant movement between the user, the product, the business and the people building it is one of the most underrated parts of being really good at this work.

And it’s also why, over time, the boundaries between the different kinds of design work I do have become less interesting to me.

And eventually, all of this has to hold together.

From the customer’s side, brand, website, product and system were never really separate experiences.

From their perspective, the boundaries between brand, website, sales and product aren’t nearly as clean as the teams working on them make them.

The website tells someone what the product does.

Sales gives them a reason to care.

The product has to make that promise true.

And the systems underneath it determine whether the company can keep doing that as it grows.

When those things disagree, people notice. They might not have the language for exactly what feels off, but you see it elsewhere: in trust, adoption, retention, support, sales.

Which is probably why I’ve ended up working across product, brand, websites and systems rather than treating them as completely separate kinds of work.

I have a thing for complicated product and business problems.

The kind where there’s a lot to untangle, where design has to do considerably more than make the interface good, and where getting the experience right can actually change what happens to the business.