UX Design in One Lesson
And other mental models from my design toolbox
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 outcomes: changes in user behavior that drive business results. The better I can define these outcomes and design patterns to enable them 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.
Research
Research is where I gather mental raw materials to make decisions. I need to identify the decisions I need to make and the questions I need answered before making them. I start by referencing my experience working on similar problems. Any remaining questions I have become topics for me to investigate. So research is the process of identifying and answering my unanswered questions.
The Infinite Building
I research these questions by exploring what I call the infinite building which represents potential questions and solutions for my design. I navigate the building by asking questions.
The answers I find help me make decisions, but UX research 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 by investigating the infinite building, and discovering them as I explore.
To make this concrete, picture industry regulations; I can’t know how to meet an industry regulation if I don’t even know what that regulation is. So to navigate the infinite building I might ask a subject matter expert if there are any regulations I need to know about before discovering which regulations I now need to ask questions about.
Why Experience Matters
Pattern recognition. Each industry has common patterns such as features, user needs, and regulations. The more patterns I know the faster I can move through the infinite building. I can fast-track my experience by focusing my professional development on the patterns common to my industry. With more experience, I can also learn to anticipate and solve problems before they arise, both in my product and my company.
Strategy
Every pixel is a decision, and strategy is where I make my decisions. Each decision is a hypothesis for achieving my goal and like any hypothesis should be tested and refined over time.
There’s no avoiding strategy. All decisions either create my strategy or attempt to fulfill it. Once again, if I don’t make these decisions consciously my subconscious will so I need to be very intentional about why I'm making each decision and how that decision supports my strategy.
Creating my strategy requires 3 decisions:
- 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 a problem to avoid solving its symptoms. - The Rules
Rules define my criteria for good decisions… what most people think when they think of ‘strategy’. They consist of things like design principles and the tradeoffs I’m willing to make. Many of these rules are universal like designs must be consistent and feasible, but user needs differ from project to project so I may value speed in one design and accuracy in another. What’s most important about rules is that they help me make decisions quicker. If a rule is too vague so I never use it it’s not a good rule. - The Actions
Now I use my rules to decide which actions best solve my problem. This is the nuts and bolts of UX design: Do I edit in-line or on a separate page?
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 a strong rationale to equate my designs to my intentions. For every decision I make I need to define the outcome I want from that decision and a clear reason why my decision produces that outcome.
A=A helps overcome a common pitfall in design which I call The Designer’s Problem: when designers put their needs first. The rule requires a conscious rationale to connect each decision to my desired outcome and ‘because I like it’ isn’t likely to do that.
Execution
Time to execute my decisions. 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.
Generic Design
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.
I achieve consistency through generic design. Before creating a solution to a problem, I need to define the general problem for my product as a whole, and then design a general solution that applies to my specific use case.
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.
- 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. - 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. - 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. - Presentable
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. Much of what people typically call beautiful design is usually just good usability, so this stage is more about fine-tuning and quality assurance rather than substantial design changes. - Testable
Any solution is a hypothesis until it’s been validated through testing. Once tested and finalized, decisions need to be documented and communicated to ensure consistency throughout the product. 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.
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.
- Basic Expectations
These are my user's “must haves”. Users can’t, or won’t, use my product without them. This includes everything from a login screen to enabling functionality to meet industry regulatory requirements. - 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. - 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 with 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.
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 researching by asking questions, strategizing by deciding what questions to ask and executing by asking those questions. But once I’ve asked a question I jump back to strategy to decide if the answer is sufficient or if I need to ask more questions.
As a result, I need to think about the design of my process as well.
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 that I’m right. The sooner I do so the better 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
