UX&Stuff | Posts

What is Design Thinking? A Practical Guide for Beginners

Tue, 07 Jul 2026 00:00:00 GMT

If you've spent any time around user experience (UX) design, you've seen the diagram: five coloured shapes labelled Empathise, Define, Ideate, Prototype, Test, usually accompanied by a wall of sticky notes and someone insisting there are no bad ideas. That's the public face of design thinking, and it's done the concept no favours. The workshops and the Post-its are the props. The actual idea underneath is more useful, and much older, than the branding suggests.

Design thinking is a human-centred, iterative approach to problem solving. Instead of jumping straight to solutions, it pushes you to understand the people involved, question whether the problem you've been handed is the real problem, and explore ideas through prototyping and testing rather than debate.

Designers have worked this way for decades. What's changed is where it gets applied: business strategy, public services, healthcare, even global development work. You don't need "designer" in your job title to use it, because it was never really about designing things. It's a way of thinking that happens to produce things.

This article covers what design thinking is, the principles underneath it, the five-stage model you'll meet most often, and the other frameworks you'll bump into, plus what they all have in common.

The Principles Behind Design Thinking

Strip away the diagrams and design thinking rests on a handful of commitments.

Human-centred. Start with people: their needs, behaviours, and the context they're operating in. Not the org chart, not the quarterly target, not the technology you happen to have lying around.

Solve the right problem. Problems usually arrive described by their symptoms. Design thinking treats the first description with suspicion and digs for causes, because a symptom you patch will come back. More on this below, it's arguably the whole point.

Think in systems. Problems don't exist in isolation. Speeding up your checkout is pointless if the payment step feels untrustworthy or deliveries keep failing; you've optimised one part of an experience that breaks somewhere else. Zoom out, look at the whole, and before you ship a fix, ask: "if we fix this, what else changes?"

Iterate. Don't build the final answer in one go. Make small interventions, test them, learn, improve.

Work non-linearly. The stages of any design thinking model can run in parallel, repeat, or loop back on each other. They're modes of work, not a checklist.

Collaborate. Designers don't have all the answers. Good ideas come from mixed-discipline teams, and frequently from the people you're designing for.

If some of this sounds like plain good sense, that's because it is. The value is in actually doing it when a deadline is looming and a stakeholder already "knows" the solution.

Solving the Right Problem

Here's where design thinking genuinely differs from how most of us are trained to work. Economists, engineers, and business analysts are excellent problem solvers, but they tend to solve the problem as presented. Design thinking asks an annoying question first: is this actually the problem?

The classic illustration comes from 1854, when cholera tore through the Soho district of London. The prevailing response was to treat the sick, which addressed the symptom and did nothing to stop new cases. A physician named John Snow mapped the outbreak instead and traced the cases to a single contaminated water pump on Broad Street. Remove the pump handle, and the outbreak collapses. The root cause was the water supply, and no amount of treating patients would have fixed it.

Product work repeats this pattern constantly. Support tickets spike, so the team writes better help articles, when the real cause is a confusing flow upstream. Sign-ups drop, so marketing spends more on ads, when the form itself is quietly rejecting valid email addresses. A useful rule of thumb: don't just treat the headache, ask what's causing it.

The Five Stages of Design Thinking

The most widely taught model comes from the Hasso Plattner Institute of Design at Stanford, better known as the d.school, which was co-founded in 2004 by David Kelley, who also founded the design consultancy IDEO. It breaks the work into five stages.

1. Empathise: Research Your Users' Needs

Empathise is about building a deep, human-centred understanding of the people you're designing for. Instead of relying on assumptions, you step into their world. Talk to them. Watch what they do, which is frequently different from what they say they do. Where you can, experience their environment yourself, an approach researchers call contextual inquiry or ethnographic research.

Collecting data is a means here, not the point. You're after motivations, frustrations, and needs, including the ones people can't articulate. Consulting domain experts helps too, but nothing replaces direct contact with users. Empathy matters here because it lets you suspend your own assumptions long enough to see the problem through someone else's eyes, and everything in the later stages is built on that foundation.

2. Define: State Your Users' Needs and Problems

Define is where you make sense of what the research told you. You sift the raw observations for pain points and recurring themes, then distil them into a problem statement that frames the challenge around the user's needs rather than the company's goals.

The framing matters more than it looks. Compare these two:

"We need to cut call-centre costs by 15% this year."
"Customers need to sort out simple account problems without waiting on hold."

The first is a business target dressed up as a problem; it points you at staffing cuts and call-deflection tactics. The second is a human problem, and it opens up a much wider field of possible solutions. A good problem statement is human-centred, actionable, and focused enough to give direction while staying broad enough to leave room for creative answers.

Teams often then reframe the statement as "How might we...?" questions to set up ideation: "How might we help customers resolve simple problems themselves, in the moment?" That phrasing has a longer history than you'd guess. Min Basadur introduced it at Procter & Gamble in the 1970s, precisely because "how might we" invites possibilities where "how can we" invites objections.

3. Ideate: Challenge Assumptions and Create Ideas

With research insights and a clear problem statement behind you, ideation is where you generate as many solutions as you can. The mindset shift is deliberate: you stop interrogating the problem and start imagining answers, and early on, no idea is too wild. Quantity first, judgement later.

Structured techniques help, because "everyone shout ideas" reliably produces the loudest person's ideas:

Brainstorming – fast, free-flowing ideas in a group.
Brainwriting – the quiet version: everyone writes ideas down individually, then shares. Kinder to people who think before they speak.
Worst possible idea – deliberately invent terrible solutions to loosen everyone up. Bad ideas are easy to produce and surprisingly good at revealing what a good idea would need.
SCAMPER – a checklist of prompts (Substitute, Combine, Adapt, Modify, Put to another use, Eliminate, Reverse) devised by education writer Bob Eberle in 1971, building on brainstorming pioneer Alex Osborn's earlier question lists.

Once you've cast the net wide, you converge: refine, combine, and select the ideas that most directly address the problem statement or offer something worth building on. The point of all this divergence is to stop the team locking onto the first plausible solution, which is what groups do by default.

4. Prototype: Start Creating Solutions

Prototyping turns the chosen ideas into cheap, scaled-down versions of the product or feature, so they can be explored and tested rather than argued about. Paper sketches, clickable wireframes, cardboard mock-ups: whatever makes the idea tangible fastest.

Prototypes are questions, not answers. You build one to find out what works, what doesn't, and why. Testing several in parallel lets you compare approaches and learn faster than polishing a single favourite. Each prototype meets one of three fates: accept it and move forward, improve it based on feedback, or reject it and take the lesson.

This stage is where flawed ideas get exposed while they're still cheap. A usability problem found in a paper prototype costs you an afternoon. The same problem found after development costs a release cycle and some credibility.

5. Test: Try Your Solutions Out

Testing is where your ideas meet the real world: the best prototypes, usually at higher fidelity by now, in front of real users in realistic scenarios.

Testing exists to teach you things, and a session that only confirms what you already believed has taught you very little. Watch for more than task completion: emotions, expectations, workarounds, the moments where someone hesitates or uses a feature in a way nobody anticipated. Results tend to sort into three buckets. The solution works as expected (confirm). It mostly works and needs adjusting (refine). Or it reveals a deeper problem, and you loop back to an earlier stage (redirect).

That third outcome feels like failure and isn't. Discovering that you defined the wrong problem before you've built anything expensive is the process working exactly as intended.

A Loop, Not a Line

The five stages get drawn as a sequence, and that's the single most misleading thing about them. In practice the stages are modes of work that overlap, repeat, and feed back into each other. Teams prototype while research is still running. A test session sparks new ideas, or reveals that the problem statement was off, sending you back to Define. You cycle through as many times as the problem demands.

None of this is the process going wrong. The flexibility is the point: it's what lets a team respond to what they learn instead of marching through a plan that the evidence has already contradicted. As David Kelley put it: "Fail faster. Succeed sooner."

Other Frameworks Worth Knowing

The d.school model is the one you'll meet most often, but it has company. Each alternative slices the same underlying process differently.

The Double Diamond

Developed at the British Design Council in 2004, the Double Diamond builds on systems theorist Béla H. Bánáthy's divergence-convergence model from the 1990s. Its insight is rhythmic: design alternates between divergent thinking (opening up, exploring widely) and convergent thinking (narrowing down, deciding), and it does so twice. Once around the problem, once around the solution.

The four phases: Discover (gather insights, research user needs), Define (frame the problem in line with user needs and business goals), Develop (generate, test, and refine possible solutions), and Deliver (finalise and launch). If you've ever watched a team brainstorm solutions before anyone agreed what the problem was, the Double Diamond is the diagram to draw on the whiteboard.

The LUMA System

The LUMA Institute distils design thinking into three core skills, each backed by a library of specific methods:

Looking – observing people and contexts
Understanding – making sense of what you've seen, spotting patterns and themes
Making – bringing ideas to life through prototyping and testing

Its appeal is flexibility. Rather than prescribing a sequence, LUMA treats the methods as a toolkit you combine to suit the size and messiness of the challenge in front of you.

Head, Heart and Hand

A simpler framing that maps the work onto three human capacities: the head solves (analytical thinking and problem solving), the heart empathises (understanding human needs and emotions), and the hand creates (making tangible solutions through prototyping).

Its useful reminder is about balance. Design that's all head produces clever things nobody wants; all heart, sympathetic things that don't work; all hand, beautifully built answers to the wrong question.

What Every Framework Shares

Names and stage counts differ, but all of these frameworks share the same DNA. They start with empathy, grounding the work in real user needs. They reframe the problem to get past symptoms and find causes. They diverge before they converge, exploring widely before narrowing down. They make ideas tangible early and test them with real people. And they draw on collaboration across disciplines rather than a lone genius at a whiteboard.

Get those habits right and the choice of framework matters far less than the diagrams imply. Done well, any of them points you toward the same target: solutions that are desirable to users, technically feasible, and viable for the business.

If you take one thing from all of this, take the reflex. When a problem lands on your desk with a solution already attached, pause and ask whether it's the real problem or just the loudest symptom. Don't just treat the headache. Ask what's causing it.

What is UX Design? A Complete Guide for Beginners

Sat, 07 Feb 2026 00:00:00 GMT

The term "UX" gets thrown around constantly - in job titles, on LinkedIn, in design tools, and in conversations about almost any product or service. But if you're new to the field, it can be difficult to pin down what it actually means.

This article will fix that. By the end, you'll understand what UX design is, what it covers, and why it matters. You'll also see where it fits in the broader landscape of product development and business.

Defining UX Design

The Official Definition

The International Organization for Standardization (ISO) defines user experience in ISO 9241-210 as:

"A person's perceptions and responses that result from the use or anticipated use of a product, system, or service."

Thrilling stuff. If that definition makes your eyes glaze over, you're not alone. It's technically correct, but reads like it was written by a committee of people who've never had to explain their job at a party.

Still, it's worth unpacking because it does capture something important. Nick de Voil breaks it down into five key parts in his book, User Experience Foundations:

A person – the user
A system – whether that's a product, service, app, or broader organisation
Use or interaction – the person engaging with the system
Perceptions – what the person notices, feels, or thinks during that interaction
Responses – how the person reacts, both emotionally and behaviourally

So user experience is what happens when someone uses something. It includes everything they perceive and how they respond, whether that's satisfaction, frustration, confusion, or delight.

A More Digestible Definition

Here's a version that's easier to hold onto:

User experience design is about making products useful, usable, and meaningful to use.

That means designing products that solve real problems (useful), that people can actually operate without wanting to throw their device across the room (usable), and that feel worth returning to (meaningful).

It's not just about what something looks like. It's about how it works, how it feels to use over time, and whether it genuinely helps people achieve what they're trying to do. A beautifully designed app that doesn't solve a real problem is just a pretty waste of time. Equally, a powerful tool that's impossible to navigate is functionally useless.

Good UX design considers the whole picture: the problem being solved, the people using it, the context they're in, and the journey they go through from first encounter to regular use.

UX vs UX Design: An Important Distinction

There's a critical difference between user experience and user experience design:

User experience (UX) is the experience itself: the perceptions and responses someone has when using a product.
User experience design (UX design) is the process of shaping the conditions that lead to that experience.

As noted HCI and UX expert Jeff Johnson puts it: "One cannot design a user experience, only design for a user experience. In particular, one cannot design a sensual experience, but only create the design features that can evoke it."

This distinction matters because it highlights a fundamental truth about the work. A designer cannot directly control how someone feels when they use a product. Emotions, perceptions, and reactions are personal and shaped by context, prior experience, expectations, and countless other factors outside the designer's control.

What a designer can do is create the conditions that make certain experiences more likely. They can design interfaces that are clear rather than confusing. They can structure flows that feel logical rather than arbitrary. They can reduce friction, provide feedback, anticipate needs, and guide people toward their goals.

The experience itself still belongs to the user. The designer's role is to shape the environment in which that experience unfolds.

What UX Design Actually Covers

It's Not Just UI

One of the most common misconceptions about UX design is that it's the same thing as UI design. It's not.

UI (user interface) design focuses on the visual layer: colours, typography, buttons, icons, spacing, and how elements are arranged on screen. It's about making things look good and feel consistent.

UX design is broader. It includes UI, but also covers research, information architecture, interaction design, usability testing, content strategy, accessibility, and more. A product can have a beautiful interface and still deliver a terrible experience if the underlying structure is confusing, the features don't solve real problems, or key user needs were never identified in the first place.

The Breadth of UX

UX design draws on multiple disciplines and involves work that happens long before any pixels hit a screen:

Research – understanding who the users are, what they need, and what problems they face
Information architecture – organising content and functionality so people can find what they need
Interaction design – defining how the system responds to user actions and how people move through tasks
Usability testing – observing real people using the product to identify pain points and opportunities
Content strategy – ensuring the right information appears at the right time in the right tone
Accessibility – making sure the product works for people with varying abilities
Emotion and desirability – shaping how the product feels to use, not just whether it works

This breadth reflects UX design's roots in psychology, human-computer interaction (HCI), and computer science. These fields emerged in the 1970s and 80s, when graphical user interfaces and personal computers were breaking through to consumers. Researchers were asking some fairly fundamental questions: how should a human interact with a computer? Turns out, we're still asking.

Generalists vs Specialists

How these areas get divided up depends largely on the size and maturity of the organisation.

In smaller companies or start-ups, a designer might wear multiple hats, switching between research, wireframing, testing, and visual design as needed. In larger organisations with mature UX teams, roles become more specialised. Someone might work exclusively as a UX researcher, an interaction designer, or an information architect, bringing deep expertise to one specific area.

Some designers flex across disciplines reasonably well. Others discover they excel in one area and decide to specialise there. Both paths are valid.

Beyond Digital

While UX design is most commonly applied to digital products—websites, apps, software—the principles apply to anything designed for human use. Chairs, buildings, ketchup bottles, petrol pumps. All of these have a user experience, whether intentionally designed or not.

A door handle that suggests pulling when you should push is a UX problem. A form that asks for information in an illogical order is a UX problem. A checkout process that makes you second-guess whether your payment went through is a UX problem.

The discipline happens to be centred on digital products because that's where the complexity, scale, and competitive pressure have driven the most focused attention. But the thinking applies anywhere people interact with designed systems.

UX is About Systems, Not Just Screens

It's tempting to think of UX design as the process of designing individual screens or pages. Open Figma, design a login form, job done. But that's not how people actually experience products.

People don't experience products as a collection of isolated moments. They move between pages, make decisions, encounter problems, leave and come back days later with different expectations. They bring context with them: past experiences with similar products, goals they're trying to achieve, the fact that they've already tried three other apps today and this one better not waste their time.

UX design looks at that broader journey. It considers how one part of the experience affects another, how information flows through the product, and how people build up a mental model of how things work over time.

The Reality of Working on Slices

In practice, a designer might be responsible for just one slice of an experience: a specific feature, a particular flow, or a defined area of a product. That's normal, especially in larger teams where work gets divided up.

But even when working on a slice, that work can't happen in isolation. What comes before and after still matters, because it shapes how that slice is experienced.

If someone arrives at a feature already confused or frustrated by something earlier in their journey, that affects how they engage with what comes next. If a flow dumps them somewhere unexpected afterwards, the feature itself might have worked perfectly but the overall experience still falls apart.

Understanding how your work fits into the larger system is part of the job. It means thinking beyond the immediate task and considering the broader context.

Keeping Track of the Bigger Picture

UX teams use various methods to keep their finger on the pulse of the entire journey. Journey maps, for instance, visualise the end-to-end experience, highlighting pain points, emotions, and opportunities across different stages. Service blueprints show how front-end interactions connect to back-end processes. User flows chart specific paths through the product.

These aren't just nice-to-have documentation. They're tools for maintaining a shared understanding of how the system works as a whole, especially when multiple people are working on different parts of it.

The Five Elements of UX (Garrett's Framework)

UX design isn't just what we see on screen. It's built in layers, from abstract to concrete.

Jesse James Garrett's model breaks this down into five elements, often visualised as an iceberg. The visible part—the polished interface—sits above the surface. But like an iceberg, most of the work extends below, invisible to the end user: identifying needs, setting scope, creating structure, and shaping the skeleton that holds everything together.

To make this more concrete, think of it like film production. The finished film is what audiences see, but getting there involves scriptwriting, storyboarding, blocking scenes, and final post-production. Each stage builds on the one before it.

Strategy (Most Abstract)

What it defines: Why the product exists—user needs and business goals

Typical questions: Who are we designing for? What problem are we solving? Why does this matter to users and to the business?

Common activities: User research, stakeholder interviews, competitive analysis, problem definition

Common outputs: Research findings, personas, problem statements, business objectives

Film analogy: Deciding what kind of film to make, who it's for, and why it matters. Is it a thriller? A comedy? Who's the audience? What's the story trying to say?

Strategy is the foundation. It answers the "why" before anyone starts thinking about features or layouts. Get this wrong, and everything built on top of it is shaky.

Scope

What it defines: What the product will do—features and content requirements

Typical questions: What will we build? What's in and what's out? What does success look like?

Common activities: Prioritisation workshops, feature definition, content audits, requirements gathering

Common outputs: Feature lists, content requirements, product roadmaps

Film analogy: Writing the script and deciding which scenes to include. You know the story you want to tell, now you're figuring out exactly what needs to happen to tell it.

Scope is where strategy turns into something tangible. It's about drawing boundaries: what the product will and won't do, at least in this version.

Structure

What it defines: How the system is organised and how it works behind the scenes

Typical questions: How do users move through the product? How is information organised? What happens when someone clicks this button?

Common activities: Information architecture, user flow mapping, task analysis, defining interaction patterns

Common outputs: Sitemaps, user flows, journey maps

Film analogy: Storyboarding the sequence of scenes and planning transitions. You've got the script, now you're mapping out how one scene flows into the next and how the narrative unfolds.

Structure is about logic and flow. It ensures people can move through the product in a way that makes sense, and that information is organised in a way they can navigate.

Skeleton

What it defines: Layout of interface elements—where things go on the page

Typical questions: Where should buttons, forms, and content live? How do elements relate spatially? What should be prominent and what should recede?

Common activities: Wireframing, layout design, navigation design, defining information hierarchy

Common outputs: Wireframes, low-fidelity prototypes

Film analogy: Blocking the scene—deciding where actors stand, how the camera frames them, what's in focus. The script and storyboard are set, now you're working out the precise positioning.

Skeleton makes structure tangible. It bridges the gap between abstract organisation and the visual interface people will actually interact with.

Surface (Most Concrete)

What it defines: Visual design and presentation—what users see and interact with

Typical questions: What colours, typography, and imagery reinforce the brand? How does it feel? Is it accessible and legible?

Common activities: Visual design, UI design, design system creation, accessibility considerations

Common outputs: High-fidelity prototypes, UI designs, design systems, developer handoffs

Film analogy: Final cinematography, colour grading, lighting, costumes—the polished visual experience that audiences see on screen.

Surface is the most visible layer, but it only works well if everything underneath is solid. A beautiful interface sitting on top of a confused structure or unclear scope is still a poor experience.

How the Layers Work Together

Changes at one layer ripple through the others. Adding a new feature (scope) might prompt a rethink of how information is organised (structure), which affects layouts (skeleton) and visual design (surface). Discovering a user need during research (strategy) might surface gaps in what's being built (scope).

UX is never "finished." Products are tested, questioned, and refined continuously. Once live, new insights emerge, prompting revisits to one or more layers.

As mentioned earlier when discussing the breadth of UX, how these layers are handled depends on team size and maturity. In larger or more mature UX teams, specialists often focus on specific layers: researchers on strategy, information architects on structure, interaction designers on flows and skeleton, visual designers on surface. In smaller teams or startups, one person might move between all five. Both models work. The layers themselves remain constant, regardless of who's handling them.

Common UX Deliverables (and What They're Really For)

UX designers produce a variety of artefacts throughout the design process. If you've looked at UX job descriptions or poked around design portfolios, you've probably seen these terms thrown about. Here's what they actually are:

Personas – Representations of key user types, grounded in research. They give teams a concrete sense of who they're designing for: goals, behaviours, pain points, context. Done well, they stop conversations devolving into "I think users want..." and ground decisions in actual evidence.

Journey maps – Visualisations of a user's experience over time, often highlighting emotions, pain points, and opportunities at different stages. They help teams see the full arc of an experience, not just the bit they're personally working on.

Wireframes – Low-fidelity layouts showing structure without visual polish. They focus on placement, hierarchy, and function. Think boxes and labels, not gradients and perfectly kerned typography. They let teams test ideas quickly before anyone wastes time making things pixel-perfect.

Prototypes – Interactive models used for testing. They range from rough clickable wireframes (low-fidelity) to polished, near-final designs (high-fidelity). They let teams validate ideas with real users before developers write a single line of code.

Sitemaps – Diagrams showing how content and pages are organised within a product. They clarify structure and help teams understand how different areas relate to each other. Less exciting than prototypes, but deeply useful when you're trying to figure out where something should actually live.

Heuristic reviews – Evaluations of a product against established usability principles (heuristics). They identify potential issues without needing full user testing, useful for spotting obvious problems quickly. Think of it as a health check before committing to more expensive research.

The Real Value Isn't the File

Here's the thing: while these artefacts matter, the real value often lies in the shared understanding developed during their creation and review.

A journey map isn't just a diagram to stick in a slide deck and forget about. It's a tool for getting stakeholders, developers, and designers aligned on what users actually go through. A wireframe isn't just a layout. It's a starting point for conversation about priorities, flows, and what matters most on a page.

UX is collaborative by nature. These deliverables are tools for alignment, discussion, and iteration. They're not just final outputs to hand off like completed homework.

Design Thinking and UX Methods

UX design can feel messy. You're dealing with human behaviour, which is unpredictable. You're balancing competing priorities. You're making decisions with incomplete information. It's rarely as tidy as following a recipe.

That said, there are frameworks that help structure the work. They don't eliminate the messiness, people will still surprise you, stakeholders will still change their minds, but they do provide a shape for navigating it all.

Classic Design Thinking

One of the most well-known is the five-stage Design Thinking model:

Empathise – Understand the people you're designing for through research and observation
Define – Synthesise findings into a clear problem statement
Ideate – Generate a range of possible solutions
Prototype – Build quick, low-fidelity versions of ideas to test
Test – Gather feedback from real users and refine

The process isn't strictly linear. Teams loop back as they learn more, revisiting earlier stages when new insights emerge.

The Double Diamond

Another common framework is the Double Diamond, which structures design work into four phases:

Discover – Explore the problem space broadly (divergent thinking)
Define – Narrow down to a focused problem statement (convergent thinking)
Develop – Generate and explore potential solutions (divergent thinking)
Deliver – Refine and finalise the solution (convergent thinking)

The "diamonds" represent periods of opening up (exploring possibilities) and closing down (making decisions). It's a useful reminder that good design involves both expansion and focus.

Frameworks, Not Rules

These are tools, not rigid prescriptions. Different teams adapt them to fit their context, constraints, and ways of working. Some skip stages. Some rename them. Some bolt on extra steps.

The goal is always the same: understand the problem, explore solutions, test and refine. The framework just helps keep that process intentional rather than haphazard.

The Seven Factors of UX (Morville's Honeycomb)

UX is often confused with usability. They're not the same thing.

Usability describes how easy something is to use, which matters, but it's only part of the picture. A product can be perfectly usable and still fail if it doesn't solve a real problem, if people don't trust it, or if using it feels about as enjoyable as filling out a tax return.

To help define what makes an experience genuinely good, Peter Morville created a framework known as the UX Honeycomb. It outlines seven key factors that contribute to a quality user experience.

The Seven Factors

Useful – The product must solve a problem or meet a need. Usefulness can be practical (an email app that lets you communicate) or experiential (a game that provides enjoyment). Without usefulness, nothing else matters. People won't adopt a product that serves no purpose, no matter how beautiful it looks.

Usable – The product should be effective, efficient, and relatively easy to learn. Can users complete their goals? How quickly? Can they recover from mistakes without wanting to throw their laptop out the window? Usability is what most people think of when they hear "UX," but it's just one factor among several.

Findable – Features and content must be easy to locate. If users can't find something, it might as well not exist. This is especially critical for products with lots of content or complex structures. Good navigation, clear labels, and functional search all contribute to findability.

Credible – Users need to trust the product. If they doubt its reliability, security, or honesty, they'll go elsewhere. Credibility is built through transparency, accurate information, consistent behaviour, and trust signals like security badges or clear privacy policies. One dodgy interaction can undo months of trust-building.

Desirable – Emotions matter. All else being equal, people gravitate towards products that look and feel good. Desirability is shaped by visuals, brand identity, tone, and interaction design. It's what makes one product feel more appealing than another, even when they do basically the same thing.

Accessible – The product must work for everyone, including people with disabilities. Accessibility isn't just morally right; in many cases it's legally required. And here's the thing: designing for accessibility often improves the experience for all users, not just those with specific needs.

Valuable – Value sits at the centre of the honeycomb. It's the sum of all the other factors. A product is valuable when it meets user needs while also being viable for the business. Some users might get value primarily from accessibility. Others might prioritise desirability or credibility. Value is contextual.

The Reality: Designing for Viability Too

Here's something a lot of beginner UX material glosses over: you also need to design for viability.

User-centred design is foundational to UX. Putting users first is the right approach. But without a profitable, sustainable business, there are no users to design for. The product doesn't get built, or it gets built and then shut down six months later when the funding dries up.

UX designers operate at the intersection of three concerns:

Desirability (human) – Do people want it?
Feasibility (technical) – Can it be built?
Viability (business) – Can it be sustained and profitable?

The goal is to find the overlap. A product that users love but costs too much to maintain isn't viable. A product that's technically brilliant but solves no real problem isn't desirable. A product that users desperately want and the business can afford to run, but can't actually be built with available technology, isn't feasible.

UX designers must balance user needs with business goals and technical constraints. That's not selling out or failing at user-centeredness. It's just the reality of working in the field.

Why UX Matters

The term "user experience design" is relatively new, but designers have always considered how people interact with the things they create. So why has UX become such a big deal over the past couple of decades?

Technology and Expectations Have Shifted

The rise of smartphones, particularly the iPhone, fundamentally changed what people expect from technology. Before touchscreens became ubiquitous, clunky interfaces were just part of the deal. Confusing menus? Buried settings? Cryptic error messages? That was just how computers worked, and people put up with it because there wasn't much choice.

The iPhone demonstrated that technology could be intuitive, responsive, and even enjoyable to use. It raised the bar overnight. Suddenly, people expected that level of polish and thoughtfulness from everything they interacted with. Going back to a confusing interface after that felt jarring.

At the same time, the internet gave people a megaphone. Poor design became visible. A frustrating checkout process or a confusing app didn't just annoy one person quietly—it got posted about, reviewed, and discussed publicly. Companies could no longer hide behind a lack of alternatives or hope bad experiences would go unnoticed.

Markets Are Crowded and Switching Is Easy

In most industries today, competition is fierce. There are dozens of project management tools, hundreds of note-taking apps, thousands of e-commerce sites selling the same thing. If one product frustrates users, they can switch to a competitor in about three clicks.

Switching costs are low. No long-term contracts, no expensive setup fees, no need to wait weeks for delivery. Try it, hate it, uninstall, move on. Done.

This puts enormous pressure on companies to get the experience right, because if they don't, users will simply leave. And they won't feel bad about it.

Great UX has become a differentiator. When features and pricing are roughly comparable, experience is what tips the decision. People choose the product that feels easier, more reliable, or just less annoying to use.

Emotion Plays a Bigger Role Than It Used To

Early technology design focused mainly on functionality. Does it work? Can it complete the task? Box ticked, job done.

Today, that's not enough. People expect to feel good using products, not just accomplish tasks. They want confidence, clarity, and a sense that the product respects their time and intelligence. Nobody wants to feel stupid trying to find the settings menu.

Emotional responses affect loyalty. Happy users stay, recommend the product to others, and forgive the occasional bug. Frustrated users leave, and they tell people exactly why on Twitter, Reddit, or app store reviews.

This shift toward emotional design isn't superficial. It's an acknowledgment that people aren't robots processing inputs and outputs. They're humans with feelings, and those feelings shape behaviour.

The Business Case Is Clear

Good UX drives tangible business outcomes:

Higher conversion rates – Clearer flows mean more people actually complete purchases, sign-ups, or other key actions
Better retention – Products that work well and feel good to use keep people coming back
Lower support costs – Intuitive design means fewer confused emails to customer support
Stronger loyalty – Satisfied users become advocates, recommending the product without being asked
Fewer costly redesigns – Getting it right early costs a lot less than fixing a mess later

In competitive markets, UX isn't a nice-to-have. As Alan Dix noted, UX has shifted from a minor consideration to a major driver of success. In highly competitive markets, only the fittest survive, and fitness now includes delivering a good user experience.

If your product frustrates people while your competitor's doesn't, guess which one they're using next month?

UX in Context: Related Disciplines

UX doesn't exist in a vacuum. It sits alongside other disciplines within product development and the broader business landscape. Understanding where UX fits—and how it differs from related fields—helps clarify what the role actually involves and stops you nodding along in meetings when someone mentions CX or IXD without having a clue what they mean.

UX vs UI

This is the most common source of confusion, so it's worth repeating:

UI (User Interface) design focuses on the visual surface and interactive layer of a product. It deals with typography, colour, icons, imagery, spacing, visual hierarchy, and how elements behave when you click or tap them. The question UI answers is: does it look good and feel consistent?

UX (User Experience) design focuses on the entire journey. It considers user needs, flows, research, usability, emotions, and value. The question UX answers is: does it actually work well for people?

UI is a subset of UX. You can have good UX with average UI—it might not win design awards, but it gets the job done. Great UI, on the other hand, can't rescue a fundamentally broken experience. A beautiful login screen doesn't help if users can't figure out what to do next.

UX vs Interaction Design (IXD)

Interaction design focuses on how users and systems communicate with each other: actions, responses, feedback, transitions. It's the conversation between person and product. What happens when you click this button? How does the system let you know something worked or failed?

Historically, back in the 1980s and 90s, UX was seen as a small part of interaction design. That's flipped. Today, interaction design is considered a core discipline within UX, sitting alongside research, information architecture, and visual design.

UX vs Marketing

Marketing is about finding customers for products. It uses surveys, focus groups, and clever segmentation to understand preferences and drive sales. The goal is to get people to buy.

UX is about designing products for people. The underlying mindset is completely different. Marketing asks: how do we get people to buy this? UX asks: what do people actually need, and how do we build something that serves them well?

There's overlap in techniques—both involve research and understanding people—but the goals point in different directions. UX projects are sometimes sponsored by marketing departments, which can get awkward if the marketing team expects UX to function as a sales tool rather than a design discipline focused on making things genuinely useful.

UX vs Customer Experience (CX)

Customer experience focuses on the customer relationship over time, analysing touchpoints and channels to optimise satisfaction and loyalty. It emerged from marketing and still carries some of that DNA: how do we keep customers happy so they keep spending money with us?

UX is broader. A customer is someone who makes a purchase decision, but UX covers everyone who uses the system: employees using internal tools, administrators managing backend systems, people who encounter the product without ever buying anything.

CX and UX overlap significantly, especially in consumer-facing products. The main difference is perspective: CX centres on the customer relationship, while UX centres on anyone interacting with the system.

UX vs Business Analysis

Business analysts focus on solving business problems. They gather requirements, define solutions, and ensure projects align with business goals. Their primary concern is business requirements: what does the organisation need to achieve?

UX designers focus on user needs. Their primary concern is making sure the product works well for the people using it.

Both roles need to understand the other's perspective. Business analysts benefit from grasping user needs. UX designers need to understand business constraints. But the priority differs, and that shapes how each role approaches the work. Sometimes those priorities align nicely. Sometimes they don't, and that's when things get interesting.

Bringing It Together

So, what is UX design?

At its core, it's about making products useful, usable, and meaningful to use. It's about understanding people's needs and designing the conditions that lead to good experiences—even though you can't directly control how someone feels.

UX is built in layers, from abstract strategy to concrete visual design. It considers systems, not just screens, because people experience products over time, moving between features, encountering problems, and building expectations as they go.

It's a broad discipline. In smaller teams, one person might handle research, wireframing, testing, and visual design. In larger teams, specialists focus on specific areas. Both models work.

And here's the part that often gets glossed over in beginner material: UX isn't just about users. Designers must balance user needs with business goals and technical constraints. That's not selling out—it's the reality of building products that people actually want to use and that can be sustained long enough to matter.

The field has grown in importance because technology is woven into everyday life, markets are crowded, and expectations have risen. Good UX is now a competitive advantage. Products that frustrate users don't last long when better alternatives are three clicks away.

This article has covered the foundations: what UX is, how it's structured, what designers produce, and why it matters. Future articles will dig into specific areas—research methods, accessibility, information architecture, usability testing, and more.

For now, the key takeaway is this: UX design is about designing for experiences, not controlling them. It's about creating the conditions that make useful, usable, and meaningful interactions more likely.

As Frank Chimero put it: "People ignore design that ignores people."