UX Design in One Lesson

And other mental models in my design toolbox

Dylan Cooper
9 min readMay 9, 2024

The following is my running list of mental models I use as a UX Designer. I’ll keep updating it.

UX Design in One Lesson

Becoming a designer starts with understanding what design is, the rendering of intent. Designers separate themselves from non-designers by putting intentionality at the forefront of every decision. In UX this intention is to design products that generate desired outcomes for both users and the business. The better I can design intuitive patterns to enable those outcomes the better a UX designer I’ll be.

I design these patterns with a carefully curated toolbox of techniques and mental models. The better my toolbox the more effectively I can work, so I need to design my toolbox like I would any other product.

The following is my toolbox, I’ll keep updating it.

Phases of Design

Design follows three phases: research, strategy, and execution, in that order. At any point in my process, I’m either gathering information (research), making decisions with that information (strategy), or following through on those decisions (execution).

This order exists regardless of my intentions. I can’t execute a strategy until I have one, and I can’t create one without information. If I’m not intentional about this process my mind will fill in the blanks unsupervised and the design will be driven by decisions I’m not aware I’ve made.


Research is where I gather mental raw materials to make my design decisions. I start by referencing my experience working on similar problems. Anything that doesn’t cover becomes an open question for me to investigate. So research is the process of identifying and answering my unanswered questions.

This includes research into my users and my business. I must understand both to design an effective product that connects solving both their needs. I also need to understand my context as a whole such as what my developer capacity is and the current state of our product.

The Infinite Building

I research these questions by exploring what I call the infinite building. The building is infinite because it represents potential questions for my design. I navigate the building by asking questions, the answers I find may uncover new questions which help me reach new areas.

What’s critical here is that UX design isn’t just about finding the right answers to questions, it’s often about finding the right questions to ask in the first place. In any complex design project I won’t come close to knowing all the questions I need to ask from the start. I need to discover them through asking other questions, and those answers will help me discover new questions to ask. A concrete example being industry regulations, I can’t know how to meet an industry regulation if I don’t even know what that regulation is.

Why Experience Matters

Pattern recognition. Each industry has common patterns such as features, user needs, and components. The more patterns I know the faster I can move throughout the infinite building. I can fast-track my experience by focusing my professional development on the patterns common to my industry.


Strategy is my hypothesis for how to best achieve my goal. Like any hypothesis, it should be tested and continuously refined as I learn new information.

Put simply, strategy is where I make decisions. Everything before the decision is research, and everything after is execution. There’s no avoiding strategy. All decisions are either to create my strategy or how to follow it.

Creating my strategy requires 3 decisions:

  1. The Problem
    A problem is the gap between where I am now and where I want to go. Defining it is often the hardest part of strategy with the largest delta between success and failure. If I’ve misdiagnosed my problem, my solution rarely matters. Great designers separate themselves from the mediocre by zooming out to identify the root cause of an issue to avoid solving symptoms of a deeper problem.
  2. The Rules
    I need rules to define my criteria for good design in my current context. This is what most people think when they think of ‘strategy’. It’s also the most vague and easy to gloss over. I know I’ve fallen for this trap when my rules aren’t useful when selecting my actions.
  3. The Actions
    Now I use my rules to decide which actions best solve my problem. This is the nuts and bolts of UX design: What’s my layout? Do I use a button or text link?

Part of the beauty of this process is that properly performing the previous step often makes the succeeding steps incredibly simple. To make this concrete, let’s apply this process to my portfolio. The problem my portfolio is intended to solve is how to demonstrate my value as a UX Designer to recruiters and hiring managers. My rules therefore are to understand the value they want, but also the value they don’t to eliminate any noise. Finally, my actions are to design my portfolio to present them with that value in the order that passes their mental filters when evaluating whether or not my value meets their needs.

The A=A Rule

Every decision requires logic to support it. The foundation of logic is the law identity: everything is equal to itself, also known as A=A. So if I want to design an experience, I need my design decisions to equal that experience.

Following A=A requires me to be consciously aware of both the experience I want to design as well as why my design decisions will equal that experience. If I don’t have a strong rationale to equate the two then I know I’m not designing logically.

The Designers Problem

The designer’s problem is when designers focus on their needs over their user’s needs. Designers want to design stuff they like, while we should design stuff our users like. Using the A=A rule, once I’ve defined my user's experience, the rationale supporting those decisions can’t be ‘because I like it’, that doesn’t equal a rationale for why it will deliver our intended experience. By using A=A I can check myself against falling for the designer's problem and ensure I‘m keeping my designs user-centric.

This is helpful when working with stakeholders as well. Anyone shaping the product is a designer whether they know it or not, so we all need to follow design principles. By keeping the conversation focused on explicitly defining our intended experience and the rationales behind our decisions I can help everyone think like a designer.


Designing logically requires consistency. In its simplest form, product design is about creating the patterns that enable people to use my application. Patterns can’t exist without consistency. Whatever I decide ‘A’ equals in a given context becomes the pattern I’ve set for my application.

It’s like creating a new language. Learning a new language is hard enough without inconsistent rules. Consistency makes it easier for users to learn and keeps my designs easier to develop and improve.

Generic Design

I achieve consistency through generic design. This means that before creating a solution to a problem, I need to zoom out to define the general problem for my product as a whole, and then create a general solution before applying it to my specific use case.


Time to execute my strategy. The challenge here comes from coordinating with my team members. I’m a big believer in the idea that design doesn’t just belong to someone with “Designer” in their title. Everyone has a unique perspective and value they can add to the team. Designs aren’t ‘mine’ they’re ‘ours’. I make them ours by sharing designs early and often to get everyone's feedback and input to shape the final product.

Designing Design

At any point in the design process, I’m simultaneously within multiple phases of design. For example, when I interview a user I’m in the research phase to figure out what I need to know, the strategy phase to decide what questions to ask, the execution phase to ask the question, and back to the strategy phase to decide if the answer is sufficient or if I need to ask more questions.

The implication is that I’m not just determining the intent of my product, but that my process needs to be designed as well.

The Order of Operations

In any complex design challenge, there are an effectively infinite number of problems to solve. Infinity is quite a large number, so I design with the following order of operations to solve problems in the right order.

  1. Valuable
    What makes my product valuable? If my product has no value, no one will use it, so I define my product's value first (my generic use case). Every decision needs to be traced back to this point. If something doesn’t create value, it doesn’t go in my design.
  2. Usable
    Our brains are prediction machines. We never experience the present, rather we experience what our brains predict the present to be fractions of a second from now. When product design matches our predictions they feel intuitive, when they don’t we become frustrated. These predictions are based on our past experiences with similar products. So to design intuitive products I need to consistently use patterns that match my user's past experiences to ensure that their predictions are always right.
  3. Practical
    Businesses don’t hire designers to make things look nice in Figma, they hire us to shape the intent for developers to translate to code. I need to understand what solutions are realistic given my constraints and select the right solution given those constraints. This means re-using existing components where possible, creating components that scale to fit my generic use case, and even a bit of developer experience such as making my designs easy to develop.
  4. Emotional
    Great products not only serve users’ functional needs but their emotional needs as well. Aesthetics come last because people typically don’t pay to see shiny buttons and cool color gradients, but products need to look professional or people won’t take them seriously. However, beautiful design is often just good usability. Simple designs are easy to use. Complementary color pallets create good content hierarchies. As a result, this phase is often about cleaning up loose ends and shouldn’t go beyond adjusting alignments and finalizing color pallets.

In summary, I define 1. The value my design provides 2. The experience to deliver that value 3. The components to deliver that experience 4. The final presentation of those components.

Full disclosure, this is an idea shamelessly ‘borrowed’ from my older manager Andy Garica who originally wrote about the Order of Operations here. I’ve adapted his ideas to fit how I think but the two should be compatible.

The Kano Model

Unfortunately, any way of ordering infinity still leaves me with an infinite number of problems to solve. The Kano Model separates problems within each operation into 1. Basic Expectations 2. Performance Attributes 3. Delighters.

  1. Basic Expectations
    These are my user's “must haves”. Users can’t, or won’t, use my product without them. At this level, I’m essentially raising negatives to neutral. These requirements follow a pass/fail system and I don’t gain any points for having them but lose everything without them. This includes everything from a login screen to enabling functionality to meet industry regulatory requirements.
  2. Performance Attributes
    The things people use to compare and contrast my product with the competition. They follow a linear satisfaction curve, so the more I increase them, the better. This is the bread and butter of UX design. Many products have the same functionality but if people can use my product more efficiently than the competition they’ll prefer mine.
  3. Delighters
    Delightful is among the most misused words in all of UX design. Products aren’t delightful because they have cool animations, they’re delightful when they exceed expectations. So to create delight I need to understand what my users want but don’t expect to get. These expectations change over time so today's delighters become tomorrow's basic expectations.

The Kano Model isn’t a linear process but rather a tool to pick and choose which operation and level of the model makes the most sense to focus my research on.

Design is Non-Linear

Design isn’t a straight line, in theory or reality. Mistakes happen, but I also need to build non-linear design into my process. In practice, this means incorporating evaluative research to validate my solutions. This can include usability testing of course, but I also like to share early drafts of my designs with the team to get immediate feedback. This helps me communicate ideas more clearly and receive higher-quality feedback.

Creative Destruction

My favorite ideation technique. I ideate by identifying a weakness in my current idea and then finding a new idea that addresses that weakness. It works great solo and in a group, and helps me know exactly when to keep pushing and when to stop.

Don’t Reinvent The Wheel

Many design problems have been solved already. To begin any product, I should identify similar products to emulate and use them as a reference when designing my own solutions. This way I can leverage solutions that are already proven to succeed to jumpstart my process.

The Mom Test

People stink at predicting the future, particularly their behaviors. However, people are much better at describing the past. I get around this by asking ‘Mom Test’ questions, inspired by a book with the same name. The idea is to ask questions that even my mom can’t lie to me about. So her answer to ‘Is this a good business idea’ means little, but her answer to ‘What have you done to try to solve the problem my product fixes?’ means a lot.

Put another way, the quality of my user research boils down to the quality of my questions. I need to craft each to avoid giving myself false positives. My goal as a researcher isn’t to confirm my hypothesis, it’s to disprove them. Only then can I know for sure that I’m right and the sooner I do so the better off my design will be.

That’s all for now. Feel free to critique anything or send me any feedback here or at hello@dylancooper.design