My Principles.

A product isn't its feature list. It's the accumulation of careful, intentional decisions; what needs to be front-and-centre, what can sit in the layers below, and how it all culminates in a feeling.

The best interfaces disappear. Attention flows to the task, not the tool.

I always want to consider the whole arc of the relationship between a user and a product. Not just when they're using it, but how they feel when they aren't. Do they look forward to it, or dread it? Do changes feel like actual improvements, or just new processes to learn? That relationship matters as much as the interface itself.

Quality is the feeling users have when they use something; the sense that the details you didn't need to get right, you did. Edge cases handled gracefully. Defaults that just happen to be the right ones.

That's hard to measure, but you know it when you feel it.

Getting there isn't easy, and I'm suspicious when a design comes too easily. The overthinking of seemingly small decisions, whether that's walking to work or falling asleep, is what ensures a product feels 'correct'. Users might not consciously notice those details, but they're what makes something feel considered rather than assembled.

I don't produce personas. I believe they generalise away the insights that actually matter, producing specialist products that can feel incorrect if the user group shifts. They push teams towards a fictional character, where there's room for interpretation about what each member thinks a target user needs.

Instead, align on guiding principles.

Personas are artefacts that get lost beyond the original design process and require constant reinterpretation. Principles translate directly to requirements, which are easier to understand, evolve more naturally, and raise the floor for everyone by designing with specific user groups in mind rather than for a fictional one.

Designing with accessibility at the forefront creates products that work better for all. Captions aren't just for hearing impairments; they're for anyone without headphones in a loud room, or translating into another language. Higher contrast helps in bright environments, not just for vision impairments.

Accessibility-first isn't a compliance tax; it's a design lens that surfaces assumptions I might otherwise miss.

When fallbacks are implemented with the same care as the primary path, the whole product becomes more robust. If something isn't accessible, I want to know what design decisions are causing that, and what's been overlooked.

Collecting only what's needed is important, and that often means anonymising data since it's not relevant. There's a firm line between data used to improve something and data being sold.

Trust is hard to gain and easy to lose; communicate plainly about what's collected, and don't hide things in the fine print.

I know first-hand how data can enhance experiences, but it often feels like you have to hand over everything or nothing. I approach projects asking 'what's the least we can collect to gain insight?'. It takes more upfront work, but it lets us design without users feeling watched.

Information density, hierarchy, and findability pull against each other in almost every design decision. I don't see my job as minimising complexity; it's intentionally distributing it in the right places.

Easy to reach when needed, quiet when not.

When a product isn't well planned, features feel 'tacked-on' rather than living in logical places. It's not that products can't evolve and include new things, but thinking about whole roadmaps, how features will integrate, and how you're going to step up to that point requires intentional planning. It takes time, but leads to much more cohesive experiences.

Users remember rules they've worked out for themselves far better than rules they've been told. I know this from practice. Tooltips, coach marks, and tutorials have their place, but I think of them as concessions, not goals.

I want interfaces that users can figure out themselves, translate from their previous app experience, and that reveal themselves as they're used.

Interfaces that trust the user to be curious and reward that curiosity. If someone needs a manual to get started, I haven't done my job properly (though honestly, sometimes the complexity demands it).

'Is this good now?' isn't the only question worth asking. 'Will this still be good in five years, on devices we haven't built yet, for users whose needs have shifted?' is the harder one, and the one I think we should always be aiming for.

Durable design focuses effort on the decisions that actually matter, allows evolution, and saves rework in the long run.

It might take longer to get to the start point, but good foundations ensure a system that works for now and for the future, outlasting the specific moment it was made in.

The questions I can answer well are the ones I've spent time thinking about before I needed to. I deliberately keep multiple platforms and form factors on the go, so when a design problem arrives I already have a library of comparable paradigms to draw from.

Designing is only half the experience, you have to live it too.

I read about emerging tech not because I'll design for it tomorrow, but because the questions it raises will still matter in ten years. What you internalise once keeps paying out.