# My Methodology — James Jing-Yi Mitchell Source: https://www.jingyi.co.uk/methodology > What I aspire to in every project. # My Methodology. What I aspire to in every project. Clarity over complexity. ## Clarity over complexity. Lots of competing factors pull against each other for every design decision. This isn't as simple as just removing complexity. Since complexity isn't inherently user-hostile. Rather, it's ı ntent ı onal, log ı cal d ı str ı but ı on. Easy to reach when needed, quiet when not. Poorly planned products can be identified by features feeling tacked-on. It's not that products can't evolve. It's not that products can't evolve. They just require careful, intentional planning. To ensure experiences remain cohesive and *intuitive*. Active discovery over instruction. ## Active expand_more over instruction. 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 these as concessions, not goals. Instead I aim for interfaces that users can figure out themselves. Revealing themselves as they are used, and building on patterns from other apps. Interfaces should trust users, rewarding their curiosity. Durability over trend. ## Durability over trend. Is this good now? Will this still be good in five years? Isn't the only question worth asking. Undiscovered featuresUnprecedented device typesShifted user needsChanging world eventsAdjusted business priorities Exact predictions are hard, but designing durable, flexible interfaces is key. Durable design focuses our effort on the decisions that actually matter. It might take longer to build our foundations, but these ensure our system outlasts the specific moment it was made in. Curiosity as a practice. ## Curiosity as a practice. The questions I can answer well are the ones I've pre-prepared without knowing it. Designing is only half the experience, you have to live it too. I deliberately use multiple platforms and form factors, trying to integrate them into my workflow. That means that when a design problem arrives, I already have a library of comparable paradigms to draw from. I read about emerging tech not because I'll design for it tomorrow... But because the paradigms they challenge may define the next decade. And that's what I'll be designing . ### 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 them at work in /process](https://www.jingyi.co.uk/process)