# My Principles — James Jing-Yi Mitchell Source: https://www.jjy.me/principles > The beliefs that shape how I design. # My Principles. The beliefs that shape how I design. 01 Design is felt before it's noticed. 01 ## Design is felt before it's noticed. A product isn't its feature list It's the accumulation of careful, expand_more decisions. and how it all culminates in a feeling The best interfaces disappear. Attention flows to thetask, not the tool. I always want to consider the whole arc of the relationship between a user and a product. …but how they feel when they aren't. Do they look forward to it, or dread it? That relationship matters as much as the interface itself. Do changes feel like actual improvements, or just new processes to learn? 02 Quality is earned, not declared. 02 ## Quality is , not declared . Quality is that feeling The details tailored to the subject matter Edge cases you handled gracefully … Defaults that just happen to be right . That's hard to measure , but you know it when you f eel it. Getting there isn't easy. I'm suspicious when a design comes too easily. The overthinking of seemingly small decisions… …when I'm walking to work… …or when I'm falling asleep… …that ensures a product feels ‘correct’. 03 Design from principles, not personas. 03 ## Design from principles not personas . 1. I don't produce personas. 2. I believe they generalise away the insights that actually matter. 3. Producing specialist products that can feel incorrect if the user group shifts. 4. They push teams towards a fictional character… 5. …where there's room for interpretation about what each member thinks a target user needs. 6. Instead, I think it's better to align on guiding principles. 7. That translate directly to requirements, and raise the floor for everyone. 04 Accessibility benefits everyone. 04 ## Accessibility benefits everyone. Designing with accessibility at the forefront creates better products Captions aren't just for hearing impairments they're for digesting content without headphones in a loud room or translating into another language Higher contrast isn't just for vision impairments It also ensures legibility in bright environments Accessibility-first isn't a compliance tax. It's a design lens that surfaces assumptions I might otherwise miss. Designing * accessibility first * leads to more usable experiences Inaccessible interactions identify * opportunities to refine * Making the product more *robust*. With the goal of * levelling * the playing field for all. 05 Privacy is a default, not a feature. 05 ## Privacy is a *default*, not a feature. There's a firm line between data used to improve something and data being sold Data can be key for enhancing experiences But we don't want users to feel watched Often it feels like you have to hand over everything or nothing So the question is… What's the least we can collect to still gain insight? I always aim to collect the minimum, anonymising as much as possible It's more upfront work, but re-contextualising the problem is often a design audit in itself Users should be told what's being collected in clear and simple language, not hidden in fine print or legal jargon. Trust is hard to gain and easy to lose I believe that design decisions should be made on verified data, and a lot of characteristic data from providers is inferred. I wouldn't want to make key decisions on data that might be incorrect. Instead I use verified data to identify potential user research opportunities, and test insights with real, verifiable users. ### What I believe - #### Design is felt before it's noticed 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. Questions I return to - What does this product actually mean to the person using it? - How does it currently make them feel? - Does this align with what we want them to feel? - What are the peaks and troughs of their experience? - What do we envisage the product as? A tool? An aid? A piece of art? A companion? How do they currently view it? - #### Quality is earned, not declared 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. A question I return to - Would a first-time user feel like they knew how the application worked without consulting a manual? - Would a long-time user feel like iterations were made by someone who knew the application inside and out? - Does the interface feel like it was assembled with care? - #### Design with a person in mind, not for a type of person 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. A question I return to - What are the needs of the target groups of users? - How should this influence the design of the application? - How can we ensure that specific needs are met without causing detriment to the experience for others? - #### Accessibility benefits everyone 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. A question I return to - If something isn't accessible, what design principles are causing this? - What's been overlooked? - How can I create a better experience by designing accessibility-first? - #### Privacy is a default, not a feature 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. A question I return to - If I were a user, what would I feel comfortable sharing? - Is it clear what's being collected? - Can I opt out easily? - Do I feel like I'm being policed, or like I'm casually sharing my thoughts? ### What I aspire to - #### Clarity over complexity 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. - #### Active discovery over instruction 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). - #### Durability over trend '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. - #### Curiosity as practice 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. Principles, applied. ## The argument *is* the design. [See my methodology](https://www.jjy.me/methodology)