Hi, I'm James

A product isn't its feature list, rather the accumulation and evolution of careful and intentional decisions. It's the result of multiple layers of reasoning and balancing, identifying what needs to be front-and-centre, and what can be hidden in the layers below; culminating in an overall experience which emulates a feeling. Does it feel intentional, tailored, and thoughtful? That's not something users will necessarily say, since the best interfaces disappear; attention flows to the task, not the tool.

No matter the project, I always want to consider the whole arc of the relationship between a user and the product. It's not just when they're using it, but also how they feel when they aren't using it. Do they look forward to using it, or are they apprehensive about its use? Do they recommend it to others? Do any changes we make feel like actual improvements rather than just "new processes to learn"? Does the transition feel like they're benefiting from the new version, or is it a loss?

My evaluation of the "quality" of my work is a constant battle. When you're just competing with yourself, you end up just raising the stakes higher and higher each time. But how do you actually measure this? With infinite time it'd be much easier, but in reality, deadlines and budgets pose actual limits. How do I ensure I've actually delivered a meaningful improvement?

It's hard, but I believe there's a way. It's the feeling users have, the gut feeling, the sense they have when they use it. That comes from noticing the details you didn't need to get right but did, through the edge cases handled gracefully, through the defaults that just happen to be the right ones.

Getting there isn't easy; it's constitutive of hard work, not incidental to it. I often feel uneasy if a design came too easily. It makes me suspicious. It's not that the simplest solution is never correct, it's more the worry that I've overlooked something. I need to be sure I've covered and catered for as much as possible within the limits of the project. The overthinking of seemingly small details, whether that's as I walk to work, or as I fall asleep, are the ones that ensure that the resulting product feels "correct". They might not be ones that users will consciously notice, but they're what makes the product feel right; 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 the team toward designing for a fictional character, where there's room for interpretation about what each team member thinks a target user needs. Instead, I believe aligning on guiding principles is much more important. Personas are artefacts that get lost in time beyond the original design process, and require constant reinterpretation. Guiding principles translate directly to requirements, which are easier to understand, and can evolve easier without reinterpreting a persona.

Don't just build a product for one user group. Raise the floor for everyone by designing with specific user groups in mind.

Designing with accessibility at the forefront creates products that work better for all. It forces you to reframe your product in different situations, whether that's temporary, situational, or permanent.

Captions and transcriptions on a video might sound tailored just for those with hearing impairments, but they also enable its information to be viewed by those without headphones in a loud environment, or more direct translations for those that don't speak the language. Higher contrast might help those with vision impairments, but it also ensures that in bright environments, other users can still read important information.

Designing accessibility-first isn't a compliance tax; rather, 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.

Collecting only what's needed is very important; that often means anonymising data since it's not relevant. There's a firm, uncrossable line between data that's being used to improve something, and that which is being sold. Trust is hard to gain and easy to lose. Communicate plainly about what's being collected, don't hide bits in the fine print, and definitely don't cross lines.

It's a personal struggle I have. I know first-hand how data can be used to enhance my experience, and how it can feed into better-designed interfaces, but often this can feel like I have to either hand over loads, or nothing at all. I approach my projects with the mantra of "what's the least amount of data we can collect to gain insight?". It takes a lot more upfront work and careful consideration compared to just "collect more", and can lead to having to go out again to collect more later, 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, rather it's intentionally distributing complexity in the right places. Easy to reach when needed, quiet when not.

It's easy to see when a product isn't well planned. Features feel "tacked-on" rather than living in actually 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 a lot more thought and intentional planning. It takes time, but leads to much more cohesive and intuitive experiences.

This is well documented, but I know it from practice. Users remember rules they've worked out for themselves far better than rules they've been told. Tooltips, coach marks, and tutorials have their place, but I think of them as concessions, not goals. I want interfaces that users can work out for 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.

"Is this good now?" isn't the only question to ask. "Will this still be good in five years, on devices we haven't built yet, for users whose needs have shifted?" is also a valid question. It's hard to answer, but it's something we should always be aiming for.

Durable design is timeless. It focuses effort on the decisions that actually matter, it allows evolution, and ultimately saves rework in the long run. It might take longer to get to the start point, but working on good foundations ensures a system that'll work 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 keep a Mac, a Windows PC, an iPhone, and an Android device on the go deliberately, so that when a design problem arrives, I already have a stocked library of comparable paradigms in my head. I try unusual form factors: a Pixel 9 Pro Fold because I wanted to understand how interfaces transition between folded and unfolded states; an iPad Pro without the Magic Keyboard because I believe touch-first devices should be good touch-first. I read about emerging tech not because I'll design for it tomorrow, but because the questions it raises will still be alive in ten years.

Some of this is just enthusiasm. Some of it's a justification to myself to spend some money on a new shiny object. But there's also my core belief that designing is only half the experience you need; you need to live it. That's how you build your internal library of things to try and experiment with when you're posed with a new problem.

I did some VR development at university in 2018, and the questions we wrestled with then (motion sickness, translating physical space into virtual space, the effect of latency on comfort) are still the ones I think about when I try any AR or VR experience. What you internalise once keeps paying out.