# UX Academy (myuxacademy.com) -- full guide content for LLMs

> UX Academy (myuxacademy.com) is a UK-based live online UX design school (legal entity: Nomadic User Ltd), distinct from Designlab's product also called "UX Academy". This file contains the full text of every UX Academy guide for AI and LLM ingestion. The curated index, course details, and key facts are at https://myuxacademy.com/llms.txt.

---

# What Is User Interface Design? Definition, Examples and Skills

URL: https://myuxacademy.com/blog/what-is-user-interface-design/
User interface design explained in plain English: what UI designers actually do day to day, how UI differs from UX, the principles and tools behind good screens, and how to start learning it in 2026.

User interface (UI) design is the practice of designing the visual and interactive elements of a digital product -- the buttons, typography, colour, icons, layout, and responsive behaviour a person sees and touches on a screen. It covers everything you interact with directly: what a button looks like, how a menu is laid out, what happens when you tap something, and how a screen adapts between a phone and a laptop.

UI design gets confused with UX design constantly, and the two terms get used interchangeably online in a way that muddies both. This guide gives a clear definition of UI design, separates it properly from UX, and walks through what UI designers actually do day to day, the principles that guide good UI work, the tools of the trade, and how to start learning it.

> **Want to learn UI skills alongside the rest of the UX process?** UX Academy (myuxacademy.com)'s [Beginner UX (AI) Design course](/courses/beginner-ux-design/) covers visual hierarchy, layout, and design systems as part of a full, live curriculum. The next cohort starts <CohortDate /> -- [reserve your place with a £99 deposit](/courses/beginner-ux-design/). Or [try the free masterclass first](/masterclass/free-ux-ui-masterclass/).

## UI design vs UX design: what is the actual difference?

Think of UX as the whole building and UI as the finishes -- the paint, the door handles, the signage. UX design covers research, structure, and the overall path a person takes through a product: what screens exist, in what order, and why. UI design is the visual and interactive layer applied to that structure: what those screens actually look like and how they respond to touch, click, or tap.

A product can have solid UX and weak UI -- a checkout flow that is logically structured but visually cluttered and inconsistent. It can also have polished UI sitting on broken UX -- a beautifully designed screen that solves the wrong problem or buries the button a user actually needs. Good products need both working together. For a fuller breakdown of the two disciplines, see our guides to [what UX design is](/blog/what-is-ux-design/) and [UX vs UI design](/blog/ux-vs-ui-design/).

## What does a UI designer actually do?

Day to day, UI design work usually includes:

- **Building layouts** -- arranging content and controls on a screen so the important things stand out and the rest supports them.
- **Choosing typography, colour, and iconography** -- and applying them consistently across every screen, not just the ones a stakeholder happens to look at.
- **Designing components** -- buttons, form fields, cards, navigation bars -- as reusable pieces rather than one-off elements, usually organised into a design system.
- **Designing for multiple screen sizes** -- making sure a layout that works on a laptop still works on a phone.
- **Working closely with developers** -- specifying spacing, states (hover, active, disabled, error), and behaviour precisely enough that what gets built matches what was designed.

This work sits downstream of the structural decisions UX design makes -- which is why, on a real product team, UI design rarely happens in isolation from UX.

## Core principles of good UI design

A handful of principles show up in almost every well-designed interface:

- **Visual hierarchy.** The most important thing on a screen should be the most visually obvious thing on it. Size, weight, colour, and position all signal what to look at first.
- **Consistency.** The same type of button should look and behave the same way everywhere it appears. Inconsistency forces users to re-learn the interface on every screen.
- **Feedback.** Every action should produce a visible response -- a button changes state when pressed, a form shows an error clearly, a loading state tells the user something is happening.
- **Contrast and accessibility.** Text needs enough contrast against its background to be readable, including for users with low vision or colour blindness. This is not a finishing touch -- it is a requirement, and one that is often checked against the WCAG accessibility guidelines.
- **Whitespace.** The empty space around and between elements is part of the design, not a gap to be filled in. Generous whitespace makes an interface easier to scan and less overwhelming.

These principles are learnable and testable -- they are not a matter of taste, which is one reason UI design is teachable as a structured skill rather than something you either have or do not.

## The tools of UI design

[Figma](/blog/what-is-figma/) is the standard tool for UI design work today -- most teams design, build component libraries, and hand off to developers inside it. It runs in a browser, supports real-time collaboration, and has a free tier that is enough to learn on. Other tools exist (Adobe XD, Sketch), but Figma is where the overwhelming majority of current UI design work happens, which is why it is the tool worth learning first.

## From wireframe to polished UI: where UI design fits in the process

UI design does not start from a blank canvas. It follows on from earlier UX work:

A project typically starts with research and structure, then moves into [wireframes](/blog/wireframe-ux-design/) -- rough, low-fidelity layouts that establish what goes where without any visual design applied yet. UI design takes over from there, applying typography, colour, and visual polish to that structure. The result is then built into a [prototype](/blog/what-is-prototyping/) so it can be tested with real users before anything is handed to developers. Structural decisions -- like how a product's content and navigation are organised -- are the domain of [information architecture](/blog/information-architecture-ux-design/), which normally happens before UI design begins.

Skipping straight to polished UI without wireframing first is a common beginner mistake: you end up polishing a layout that has not been validated, and rework follows when the underlying structure turns out to be wrong.

## Responsive design: designing for every screen

Almost no product is designed for a single screen size anymore. Responsive design means a layout adapts sensibly across phone, tablet, and desktop -- not by shrinking everything proportionally, but by rethinking what should show, hide, or rearrange at each size. A three-column layout on desktop might become a single stacked column on a phone. UI designers typically design a handful of key breakpoints and let a design system's components adapt in between, rather than designing every possible screen width by hand.

## How to become a UI designer

There is no single licence or qualification that makes someone a UI designer. In practice, most people get there by building real UI skills -- visual hierarchy, layout, design systems, accessibility -- and demonstrating them through a portfolio of real or realistic project work, usually alongside the broader UX skills (research, structure, testing) that most product teams expect a designer to have to some degree.

UX Academy does not run a standalone UI-only course, because UI design is rarely practised on its own in a real job -- most roles expect both UI and UX fundamentals together. The [Beginner UX (AI) Design course](/courses/beginner-ux-design/) builds UI skills -- visual hierarchy, layout, and design systems -- as part of a full process from research through to [usability testing](/blog/usability-testing-guide/). If you are further along and want to go deeper into how AI tools are changing UI and product design workflows, the [Product Design & AI course](/courses/product-design/) covers that ground.

## Learning UI design properly

UI design is a specific, learnable skill set -- visual hierarchy, consistency, accessibility, responsive layout -- but it is rarely learned or practised in isolation from the rest of UX. UX Academy's live, online courses teach both together on real project work, in cohorts of maximum 15 students, starting <CohortDate />. [Join the free UX/UI masterclass](/masterclass/free-ux-ui-masterclass/) to see how the two disciplines fit together, or [reserve your place on the Beginner UX (AI) Design course](/courses/beginner-ux-design/) with a £99 refundable deposit.


---

# What Is Prototyping? A Practical Guide for UX Designers

URL: https://myuxacademy.com/blog/what-is-prototyping/
What is prototyping in UX design, why designers do it, the types of prototype, and how to build one. A practical guide for career-changers and new designers.

Prototyping is the process of building a simplified, testable model of a product before it is fully developed. A prototype can be anything from a rough paper sketch to a clickable digital mockup that simulates how the real interface would behave. The point is not to build the finished thing -- it is to put an idea in front of real people, learn whether it works, and fix the problems while they are still cheap to fix.

It is one of the most valuable stages in the [UX design process](/blog/ux-design-process/), and one of the most misunderstood. New designers often confuse prototypes with wireframes or finished visual designs, or skip straight to building without testing anything first. This guide explains what prototyping actually is, the different kinds of prototype, how designers build them, and where the stage fits into real UX work.

> **Want to build and test prototypes on a real client project?** UX Academy (myuxacademy.com)'s [Beginner UX (AI) Design course](/courses/beginner-ux-design/) teaches prototyping hands-on, live, with working professionals. The next cohort starts <CohortDate /> -- [reserve your place with a £99 deposit](/courses/beginner-ux-design/). Or [try the free masterclass first](/masterclass/free-ux-ui-masterclass/).

## Why designers prototype

The alternative to prototyping is guessing. Without a prototype, a team either argues about an idea in the abstract or -- worse -- builds it in full and finds out it does not work after the expensive part is done. Both are slow and both are risky.

A prototype turns an opinion into something you can actually try. Instead of debating whether a checkout flow makes sense, you build a clickable version and watch five people attempt to use it. The problems show up in minutes. Because the prototype is deliberately unfinished, changing it is quick: you are moving boxes and links around, not rewriting production code. That is the whole value of the stage -- it moves the moment of learning to the cheapest possible point in the project.

## The types of prototype: low, mid, and high fidelity

"Fidelity" just means how close the prototype is to the finished product. There is a spectrum, and good designers deliberately choose where on it to work.

- **Low fidelity.** Paper sketches or simple grey-box layouts. Fast, disposable, and ideal for testing a flow or a rough concept. Nobody mistakes a paper prototype for a final design, which is exactly why it gets honest feedback.
- **Mid fidelity.** Digital, greyscale, with real structure and basic interactions. Enough to test navigation and layout without the distraction of colour and branding.
- **High fidelity.** Looks and behaves close to the real product -- real content, visual design, and realistic interactions. Best for testing detailed usability, presenting to stakeholders, or handing off to developers.

The mistake beginners make is starting at high fidelity. Polishing the visuals before the structure is validated means you throw away expensive work when testing reveals the layout was wrong. Start rough, and increase fidelity only as the design earns confidence.

## Prototype vs wireframe vs mockup

These three get mixed up constantly, so it is worth being precise:

- A [wireframe](/blog/wireframe-ux-design/) is a static layout of one screen. It answers *what goes where*.
- A mockup is a static screen with visual design applied. It answers *how it looks*.
- A prototype is interactive. It links screens together so a user can complete a task. It answers *how it works*.

The usual order is wireframe, then mockup, then prototype -- though in practice designers often connect wireframes directly into a lo-fi prototype to test a flow before touching visual design.

## How to build a prototype

For anything digital, the standard tool is [Figma](/blog/what-is-figma/). It has prototyping built in: you link frames together, define what happens on a tap or click, add transitions, and share the result as a link that anyone can open in a browser. No code is involved. Figma's free tier is enough to build and share a working prototype, which makes it the natural starting point for anyone learning.

Other tools exist -- Framer for more advanced interaction and animation, and older options like Adobe XD (now largely discontinued as a standalone product) -- but for a career-changer, learning to prototype in Figma covers the overwhelming majority of real-world work. And the most underrated prototyping tool of all is still paper: for early flow testing, hand-drawn screens are faster than anything on a screen.

## Where prototyping fits in the UX process

Prototyping is not a one-off step at the end. It sits in the middle of the workflow and often repeats:

Research and [information architecture](/blog/information-architecture-ux-design/) come first, so you know what you are building and how it is structured. Then wireframes establish the layout. The prototype connects those layouts into something a person can use, which you then test, learn from, and revise -- frequently looping back to change the wireframes before moving on to polished visual design and developer handoff. In a [design sprint](/blog/what-is-a-design-sprint/), the prototype is the whole point of the week: a testable artefact built fast specifically so it can be validated on the final day.

## Testing your prototype with real users

A prototype that never gets tested is just a nicely animated opinion. The reason to build one is to put it in front of people who match your real users and watch them attempt a genuine task. You are looking for where they hesitate, misread a label, tap the wrong thing, or give up. See our [guide to usability testing](/blog/usability-testing-guide/) for how to run this properly, but the core discipline is simple: watch what people do, not what they say they would do.

Because the prototype is cheap to change, each round of testing feeds directly back into the design. Test, learn, revise, test again. That loop -- not any single polished deliverable -- is where prototyping earns its place in the process.

## Common prototyping mistakes to avoid

- **Over-polishing too early.** Time spent perfecting visuals on an unvalidated layout is time you will spend again when the structure changes.
- **Prototyping everything.** You do not need a full working product. Prototype the specific flow you need to learn about and leave the rest.
- **Confusing "it looks done" with "it works".** A beautiful prototype that no one has tested tells you nothing about usability.
- **Skipping the test.** The prototype is a means to an end. If you build one and never put it in front of a user, you have skipped the only part that mattered.

## Learning to prototype properly

Prototyping is a core, everyday UX skill -- not an optional specialism -- and the fastest way to learn it is by doing it on real problems with feedback from people who do it for a living. UX Academy (myuxacademy.com)'s [Beginner UX (AI) Design course](/courses/beginner-ux-design/) takes you from research through wireframing, prototyping, and testing on a real client project, and the [Product Design & AI course](/courses/product-design/) goes deeper into rapid prototyping for designers already working in the field. Both run as live UK cohorts of maximum 15 students, starting <CohortDate />, with a £99 refundable deposit to secure a place.


---

# What Is a GUI (Graphical User Interface)?

URL: https://myuxacademy.com/blog/what-is-gui/
What is a GUI, how it differs from a command line, and why designers build them. A plain-English guide to graphical user interfaces for career-changers.

A GUI (Graphical User Interface) is the visual, interactive layer of a piece of software that lets people use it by looking at and manipulating on-screen elements -- buttons, menus, icons, windows, and forms -- rather than typing text commands. It is what you actually see and touch when you use an app, a website, or your phone's home screen, and it is the thing UX and UI designers spend most of their working lives designing.

You have used hundreds of GUIs today without thinking about the term. Every app icon you tap, every dropdown menu you open, every "Add to basket" button is part of a GUI. This guide explains what a GUI actually is, how it differs from the command line, what it is made of, and why understanding it properly is central to a career in UX/UI design.

> **Want to try designing real interfaces before you commit to a career change?** UX Academy (myuxacademy.com)'s [Beginner UX (AI) Design course](/courses/beginner-ux-design/) teaches you to design usable GUIs from first principles, live, with working professionals. The next cohort starts <CohortDate /> -- [reserve your place with a £99 deposit](/courses/beginner-ux-design/). Or [try the free masterclass first](/masterclass/free-ux-ui-masterclass/).

## GUI vs CLI: the two ways to use software

Before GUIs became standard, most software was controlled through a CLI -- a Command Line Interface. You typed a precise text instruction, pressed enter, and the computer did exactly that and nothing more. No visuals, no menus, no clicking. It worked, but it demanded that the user already knew the exact command and its syntax.

A GUI removed that barrier. Instead of remembering a command, you look at a screen, recognise a button labelled "Delete", and click it. The computer is doing the same underlying work either way -- the GUI just wraps it in a visual layer that is far easier for an ordinary person to understand and operate. That shift, from typed commands to visual, clickable interfaces, is one of the reasons computers went from specialist tools to something almost anyone can use.

CLIs have not disappeared -- developers and system administrators still use them daily because they can be faster and more precise for technical tasks. But for the vast majority of people using the vast majority of software, the GUI is the entire experience.

## What a GUI is actually made of

A GUI is built from a small set of recurring building blocks, assembled in different combinations for different products:

- **Buttons** -- the primary way users trigger an action ("Sign up", "Pay now", "Delete").
- **Menus and navigation** -- dropdowns, tab bars, and side navigation that let people move between sections.
- **Icons** -- small visual symbols that represent an action or object (a bin for delete, a magnifying glass for search).
- **Windows and panels** -- containers that group related content, from a browser window to a modal pop-up.
- **Forms and inputs** -- text fields, checkboxes, toggles, and dropdowns that collect information from the user.
- **Feedback elements** -- loading spinners, progress bars, and confirmation messages that tell the user what just happened.

Every app you use is a particular arrangement of these same basic components. What makes one GUI good and another frustrating is not the components themselves, but the decisions about which ones to use, where to put them, and how clearly they communicate what will happen next.

## Real-world examples of GUIs

GUIs are everywhere, which is exactly why the term is worth understanding properly rather than skimming past:

- Your phone's home screen, where app icons and folders form a graphical interface over the operating system.
- A banking app's transfer screen -- input fields, a confirm button, and a success message.
- An e-commerce checkout -- product images, quantity selectors, a payment form, and an order confirmation.
- Software you use every day at work, like email clients, spreadsheets, and video calling apps, all of which present their underlying functions through graphical, clickable interfaces.

Anywhere you are looking at a screen and clicking or tapping something rather than typing a raw command, you are using a GUI.

## Why GUI design matters to UX and UI designers

The GUI is the point of contact between a person and a product -- it is where usability either succeeds or fails. A well-researched product idea can still fail commercially if its GUI is confusing, inconsistent, or hard to navigate. This is why GUI design is not decoration bolted on at the end; it is where the underlying structure of a product actually gets used by real people.

A few things designers hold themselves to when designing a GUI:

- **Usability.** Can someone complete their task without confusion or hesitation? Every button, label, and layout choice either supports this or works against it.
- **Consistency.** The same action should look and behave the same way everywhere in the product. Inconsistent buttons or navigation force users to relearn the interface on every screen.
- **Accessibility.** A GUI has to work for people with visual, motor, or cognitive differences -- sufficient colour contrast, large enough touch targets, and labels that work with screen readers are not optional extras.
- **Feedback.** Every action a user takes should produce a visible response, so they always know whether something worked, is loading, or has failed.

Get these wrong and even a technically excellent product feels broken to the people using it.

## Who actually designs a GUI: UX vs UI

"GUI design" sits mostly inside what people call UI design, but it depends on close collaboration with UX design -- see our full breakdown in [UX vs UI design](/blog/ux-vs-ui-design/). In short: UX design figures out the structure and flow -- what screens exist, what order they come in, what a user needs at each step. UI design is what turns that structure into the actual graphical interface -- the buttons, colours, typography, icons, and spacing the user sees. A GUI is, in effect, UX decisions made visible and clickable.

In practice, most designers do both. On a small team, or as a career-changer building your first portfolio, you are usually researching the problem, structuring the flow, and designing the visual interface as one continuous piece of work.

## How GUI design connects to information architecture and prototyping

A GUI does not start with buttons and colours -- it starts with structure. [Information architecture](/blog/information-architecture-ux-design/) is the earlier stage where a designer decides what content and features exist and how they are organised, before any visual interface is drawn. Get the structure wrong, and no amount of polished GUI design will fix a product that is organised in a way users cannot follow.

Once the structure is in place, designers build [wireframes](/blog/wireframe-ux-design/) to lay out where GUI elements will sit on each screen, then move into [prototyping](/blog/what-is-prototyping/) to link those screens together and test how the GUI actually behaves when someone tries to use it. Tools like [Figma](/blog/what-is-figma/) are where most of this GUI design work happens today -- designers assemble buttons, menus, and forms into screens, link them into a clickable prototype, and test it with real users before any developer writes code.

## GUI design is a learnable, practical skill

A GUI is not a technical mystery reserved for programmers -- it is a design discipline with clear principles, and it is exactly what UX/UI designers are hired to produce. If you are curious what UX design covers more broadly before narrowing in on interfaces specifically, start with [What Is UX Design?](/blog/what-is-ux-design/)

UX Academy (myuxacademy.com)'s [Beginner UX (AI) Design course](/courses/beginner-ux-design/) takes you from research and structure through to designing and testing a real graphical interface, on a real client project, live with working professionals. If you are already working in the field and want to go deeper on interface and interaction work, the [Product Design & AI course](/courses/product-design/) builds on these same foundations. Both run as live UK cohorts of maximum 15 students, starting <CohortDate />, with a £99 refundable deposit to secure a place.


---

# Voice and Conversational UX Design: A Practical Guide

URL: https://myuxacademy.com/blog/voice-and-conversational-ux-design/
What voice and conversational UX design is, how VUI differs from GUI, and the principles for designing voice assistants, chatbots and AI chat interfaces.

Ask someone to picture a user interface and they will describe a screen: buttons, menus, a layout. But a growing share of the interfaces people use every day have no screen at all, or use the screen only as a backdrop to a conversation. You speak to a voice assistant. You type to a chatbot. You hold an open-ended exchange with an AI chat tool. Designing those experiences is its own discipline, and it is one that has moved from niche to mainstream faster than almost any other area of UX.

This post explains what voice and conversational UX design is, how it differs from designing for the screen, the principles that make a conversation work, and how the skill fits into a modern UX career.

> **Want to design for AI-driven and conversational products?** UX Academy (myuxacademy.com)'s [Beginner UX (AI) Design course](/courses/beginner-ux-design/) covers designing for chat, voice, and AI-powered interfaces on top of solid UX fundamentals. Cohort 1 starts 21 Sep 2026 -- [reserve your place with a &pound;99 deposit](/courses/beginner-ux-design/). Or [try the free masterclass first](/masterclass/free-ux-ui-masterclass/).

## What voice and conversational UX design is

Conversational UX design is the practice of designing interfaces where the primary interaction is natural language. It splits into a few overlapping areas:

- **Voice user interfaces (VUIs)** -- voice assistants such as Alexa, Google Assistant, and Siri, plus voice features inside apps and in-car systems.
- **Chatbots** -- text-based assistants on websites, in messaging apps, and inside products, from simple rule-based flows to more capable AI-driven ones.
- **AI chat interfaces** -- the open-ended, large-language-model-powered tools that have become part of daily life for millions of people.

What unites them is that the design is a dialogue rather than a layout. You are not arranging elements on a canvas. You are anticipating what a person will say, planning how the system responds, and shaping the back-and-forth toward a useful outcome. The interface reveals itself through the conversation, not before it.

## VUI vs GUI: why voice is a different problem

The clearest way to understand conversational design is to contrast it with the graphical interfaces most designers start with. For a refresher on how screen-based UX works end to end, our [UX design process guide](/blog/ux-design-process/) walks through the standard stages.

A **GUI is visual and spatial.** Everything available is on the screen at once. The user can see the options, skim them, ignore the ones that do not apply, and choose. Going back is a button. Discovering a feature is a matter of looking.

A **VUI is linear and invisible.** Nothing is on screen. The user cannot see what the system can do, cannot skim, and cannot glance back at the last step. Every option has to be spoken, held in memory, and acted on before it disappears.

That single difference drives most of the hard parts of voice design:

- **Discoverability.** In a GUI, capabilities are visible. In a VUI, the user has no menu to scan, so they often do not know what they can ask. The design has to teach capability through the conversation without lecturing.
- **Cognitive load.** A screen offloads memory: the options are right there. A voice interface asks the user to hold everything in their head. Long lists of spoken choices fail because nobody remembers option four of six.
- **Error and ambiguity.** People phrase the same request in dozens of ways, and speech recognition mishears. A GUI button is either pressed or not. A spoken request is a probability. Designing for the times the system gets it wrong is not an edge case in voice work; it is most of the work.

Chatbots and AI chat sit between the two. They have a screen, so they can show buttons, quick replies, and history, but the core interaction is still language, so they inherit the ambiguity and the need to design for failure.

## Principles for designing conversations

A few principles hold across voice assistants, chatbots, and AI chat.

### Design the dialogue, not the screen

The deliverable in conversational design is a flow: what the system says, the range of things the user might say back, and how each branch is handled. Most designers map this in a whiteboard tool or a flow tool before anything is built, because the conversation is the design. If the dialogue does not read well out loud, no visual polish will save it.

### Set expectations early

Because capabilities are invisible, the opening moments matter. A good conversational interface signals what it can help with quickly and concretely, rather than an open "How can I help?" that leaves the user guessing. Naming one or two real things the system does is more useful than a friendly but empty greeting.

### Keep turns short and give one thing at a time

Long spoken responses lose people. So do walls of chatbot text. Break information into short turns, confirm progress, and avoid asking the user to hold several things in memory at once. In voice especially, offering more than about three options in a single turn tends to fail.

### Confirm, but do not nag

For anything consequential (a booking, a payment, a deletion), confirm before acting. For low-stakes steps, constant "Did you mean X?" checks make the experience feel slow and untrusting. Matching the amount of confirmation to the cost of getting it wrong is a judgement call that good conversational designers develop.

### Design the failure states first

The user will be misheard. They will ask for something out of scope. They will go quiet. A conversational interface is judged largely on how gracefully it recovers: acknowledging the problem, offering a way forward, and never trapping the user in a loop. Weak chatbots fail here more than anywhere else.

### Write in the product's voice

In conversational design, the words are the interface. Tone, brevity, and clarity are design decisions, not a copywriting afterthought. This overlaps heavily with UX writing -- our [UX writing guide](/blog/ux-writing-guide/) covers the principles that apply directly to bot and assistant responses.

## A simple process for a conversational project

The underlying UX process does not change for conversation; the artefacts do.

1. **Research.** Learn how people talk about the task in their own words. Real language, collected from interviews or existing transcripts, is the raw material for the whole design.
2. **Map the happy path.** Sketch the ideal conversation from start to successful outcome. Keep it short and natural.
3. **Branch and handle failure.** Add the realistic detours: misheard input, out-of-scope requests, silence, corrections. This is where most of the design effort goes.
4. **Prototype cheaply.** Test the dialogue with a Wizard of Oz session -- a person playing the system -- before any build. It reveals the phrases users actually use.
5. **Test and read transcripts.** Once live, real transcripts are the richest feedback you will get. Read them regularly and feed the gaps back into the flows.

## Tools of the trade

Conversational designers tend to reach for a small set of tools. Flow and dialogue mapping usually starts in Miro or FigJam, or in a dedicated tool such as Voiceflow for building and prototyping voice and chat flows without engineering. A plain script or spreadsheet is often enough to draft and pressure-test the dialogue itself. For chatbots, builders like Voiceflow and Landbot let you prototype working flows quickly. For AI chat, prompt design and evaluating the model's responses become part of the toolkit -- a fast-moving area covered more broadly in our look at [AI in UX design](/blog/ai-in-ux-design/) and the [AI tools UX designers use](/blog/ai-tools-for-ux-designers/).

## How it fits a modern UX career

Conversational and voice design is best understood as a specialism layered on top of strong UX fundamentals, not a separate track you start from scratch. The research, prototyping, and testing skills are the same ones every UX designer needs; what changes is the medium.

That layering matters for anyone planning a route into the field. The market has shifted toward AI-literate designers who can work across screens, chat, and voice, and who understand how a conversation is structured rather than only how a screen is arranged. Building solid UX foundations first, then adding conversational skill, is both the realistic sequence and the one employers expect.

> On UX Academy's [Beginner UX (AI) Design course](/courses/beginner-ux-design/), you learn to design for chat, voice, and AI-powered products on top of a proper UX grounding -- research, flows, prototyping, and testing applied to conversational interfaces. The instructors work in the industry and teach the process live. No prior design experience required.


---

# UX Designers and Leaders to Follow (and Why)

URL: https://myuxacademy.com/blog/ux-leaders-to-follow/
An evergreen guide to respected UX voices, writers and researchers worth following, plus the newsletters and communities that keep you current in UX design.

Search for UX designers to follow and you will find a lot of numbered lists that were out of date the year after they were published. Rankings age badly. Job titles change, people move companies, and last year's "top ten" tells you little about who is writing well about the problems you face today.

This guide takes a different approach. It is a set of voices worth your attention and, more importantly, the reason each is worth following, plus the newsletters and communities that keep you current. Treat it as evergreen: the specific people will evolve, but the kinds of thinking they represent stay useful for years. If you are [working out how to become a UX designer](/blog/how-to-become-a-ux-designer/), a good reading list is one of the cheapest ways to accelerate.

> **Learning UX and want a structured path rather than a scattered feed?** UX Academy (myuxacademy.com)'s [Beginner UX (AI) Design course](/courses/beginner-ux-design/) takes you from fundamentals to a job-ready portfolio, live with working professionals, with the option to extend into the [UX Career Track](/courses/ux-career-track/) for a second client brief and job search support afterwards. Cohort 1 starts 21 Sep 2026 -- [reserve your place with a &pound;99 deposit](/courses/beginner-ux-design/). Or [try the free masterclass first](/masterclass/free-ux-ui-masterclass/).

## Foundational voices worth knowing

These are the people whose work the discipline is built on. You do not follow them for the latest hot take; you read them for principles that do not go out of fashion.

- **Don Norman.** He popularised the term "user experience" and wrote *The Design of Everyday Things*, still the clearest introduction to why things are usable or infuriating. Co-founder of the Nielsen Norman Group. Read him for the fundamentals of human-centred design.
- **Jakob Nielsen.** A founder of usability as a rigorous field and author of the ten usability heuristics that most evaluation work still leans on. His writing is the antidote to design by opinion. Our own [heuristic evaluation guide](/blog/heuristic-evaluation-ux-design/) builds directly on that lineage.
- **Steve Krug.** *Don't Make Me Think* remains the most approachable book on web usability ever written. Read him for the discipline of removing friction and for testing on a shoestring.

## Practitioners and writers to follow now

These voices are worth following for how the work is actually done, and how it is changing.

- **Kim Goodwin.** Author of *Designing for the Digital Age* and a clear authority on personas, scenarios, and design at scale. Read her when you want rigour behind methods that are often used badly.
- **Erika Hall.** Author of *Just Enough Research* and a sharp, sceptical voice on doing research pragmatically rather than ceremonially. Essential if you find research intimidating or overblown. Pair her with our [UX research methods guide](/blog/ux-research-methods/).
- **Teresa Torres.** Through *Continuous Discovery Habits* and her Product Talk writing, she has shaped how modern product teams do ongoing research rather than treating it as a phase. Read her for the product-team reality of UX.
- **Julie Zhuo.** Former VP of Design at a major product company and author of *The Making of a Manager*. Read her for design leadership, career growth, and the move from doing the work to leading it.
- **Jon Yablonski.** Creator of Laws of UX, a well-made distillation of psychological principles into practical design guidance. A good bridge between theory and everyday decisions.

The point of the list is not to follow all of them. Pick two or three whose thinking is clear to you and read them properly.

## Voices for research and product thinking

Research is the part of UX that beginners most often underrate, so it is worth following people who do it well and talk about it plainly.

- **Steve Portigal.** Author of *Interviewing Users*, the practical reference for talking to people without leading them. Read him before your first research session and again after your tenth.
- **Indi Young.** Known for problem-space research and mental models, and a strong corrective to jumping to solutions too early. Read her when you want to understand people rather than validate an idea.
- **Kate Moran and the Nielsen Norman Group researchers.** The NNG team publishes some of the most consistently rigorous, method-focused writing in the field. Follow the organisation and you inherit a whole research library.

Reading research-minded voices alongside the design-led ones keeps you honest about the difference between what you think users want and what they actually do.

## Staying current without drowning

UX is a fast-moving field, and the arrival of AI-driven tools has accelerated it. The temptation is to follow everyone and read everything, which reliably produces anxiety and very little learning. A better approach is deliberately narrow: two or three individual voices, one or two publications, one community, and a habit of reading them rather than a feed you scroll.

Be sceptical of anyone selling certainty, especially about the future of the field or about a single "right" way to work. The voices worth keeping are the ones who show their reasoning, admit trade-offs, and change their minds when the evidence does. A ranking cannot tell you that; only reading someone over time can.

## Newsletters and publications to read

Following individuals is one input; a couple of reliable publications keep a steady flow of good material coming.

- **Nielsen Norman Group.** Research-backed articles on usability and UX method. When you want evidence rather than opinion, start here.
- **Smashing Magazine.** Founded by Vitaly Friedman, strong on practical design and front-end craft. Good for the how, not just the why.
- **UX Collective.** A large practitioner publication with a wide range of working-designer perspectives. Uneven by nature, but consistently surfaces useful pieces.
- **Growth.Design.** Case studies that break down real product experiences with a psychology lens. A readable way to train your eye.
- **Baymard Institute.** Deep, evidence-based research on ecommerce usability. Indispensable if you work on online stores.

A newsletter or two delivered to your inbox turns "keeping up" from a chore into a habit. That habit matters more than any single source.

## Communities worth joining

Reading is passive. The faster learning comes from having people to ask.

- **Interaction Design Foundation.** Courses and an active global community, useful for structured learning alongside the discussion.
- **Ladies that UX.** A global community supporting women in UX, with local chapters and events.
- **Local UX meetups.** Most cities run them, and they are the most direct route to people who do the work near you. For anyone [changing careers into UX](/blog/switching-careers-to-ux-design/), the connections and honesty you get in a room of practitioners are hard to replicate online.

Join one community you will actually participate in rather than lurking in ten. Asking a real question and getting a real answer is worth more than a month of scrolling.

## How to use a following list well

A reading list is an input to getting good, not a substitute for it. The designers and sources here will sharpen your judgement, fill gaps, and keep you current with how the field is moving. What they will not do is get you hired. That comes from putting the learning into practice: real projects, tested work, and a portfolio that shows your thinking.

So use this the right way round. Read a couple of the voices above, subscribe to one newsletter, join one community, and then spend most of your time doing the work. When you reach the point of [applying for UX roles](/blog/ux-design-jobs-uk/), it is your portfolio and your ability to talk about your process that will matter -- and everything you have absorbed from good sources will show up there, indirectly but unmistakably.

> On UX Academy's [Beginner UX (AI) Design](/courses/beginner-ux-design/) course, you learn the fundamentals and build a job-ready portfolio live with working professionals, instead of piecing it together from scattered articles. The instructors have done the work at companies including Adobe, Google, and Canva, and give feedback at every stage. No prior design experience required.


---

# Ecommerce UX Design: Best Practices That Drive Conversion

URL: https://myuxacademy.com/blog/ecommerce-ux-design/
Why ecommerce UX drives revenue, the online-store mistakes that lose sales, and a checklist for navigation, product pages and checkout.

An online store is unusual among digital products in how directly its design maps to money. A confusing navigation, a product page that leaves a question unanswered, a checkout that demands an account -- each is not just an annoyance but a lost sale, and at scale those lost sales are the difference between a store that grows and one that quietly bleeds revenue. Ecommerce is where UX and the bottom line meet most plainly.

This post covers why ecommerce UX matters commercially, the mistakes that lose the most sales, the best practices that recover them, and how UX skills apply to online retail.

> **Want to design experiences that move business metrics?** UX Academy (myuxacademy.com)'s [Advanced UX Design course](/courses/advanced-ux-design/) takes you deeper into research, testing, and the design decisions that drive conversion. Cohort 1 starts 21 Sep 2026 -- [reserve your place with a &pound;99 deposit](/courses/advanced-ux-design/). Or [try the free masterclass first](/masterclass/free-ux-ui-masterclass/).

## Why ecommerce UX drives revenue

On a physical shop floor, a good assistant answers questions, reassures the hesitant, and guides people to the till. Online, the interface has to do all of that alone. There is nobody to explain the sizing, no one to confirm the return policy, no human to steady a wavering buyer. Every doubt the design does not resolve is a doubt that ends the visit.

That is why UX has such a direct effect on ecommerce revenue. The path from arrival to purchase runs through several distinct stages -- finding a product, understanding it, trusting the seller, and paying -- and each stage leaks. Reducing the leak at any one of them lifts the whole funnel, and because online stores usually run at meaningful traffic volumes, even a small percentage improvement compounds into real money. This is one of the few areas of design where the value of the work can be stated in revenue with a straight face.

It is also why ecommerce leans so heavily on evidence. Assumptions about why people abandon are frequently wrong, which makes [usability testing](/blog/usability-testing-guide/) and behavioural data central rather than optional.

## The common online-store mistakes

Most stores lose sales in the same predictable places.

- **Overloaded navigation.** Too many categories, unclear labels, and no obvious hierarchy leave users unable to find what they came for. If people cannot navigate to a product, nothing else on the page matters.
- **Product pages that dodge the buyer's questions.** Sizing, materials, dimensions, delivery times, and return terms are the things people need to know before they buy. Pages that bury or omit them create hesitation the design never resolves.
- **A hostile checkout.** Forcing account creation before purchase, revealing delivery costs only at the final step, and asking for more information than necessary are among the most damaging patterns in ecommerce -- all the more so because they strike after the user has decided to buy.
- **Weak trust signals.** No reviews, hard-to-find policies, hidden contact details, and unfamiliar payment options make a store feel risky, especially for a brand the user does not already know.
- **A mobile experience built for desktop.** A large and often majority share of ecommerce traffic is on phones. Cramped tap targets, tiny text, and a checkout that assumes a mouse turn that traffic away.

## Best practices that recover sales

The fixes are not exotic. They come from applying UX fundamentals to the specific job of selling.

### Navigation and findability

Structure categories around how customers think, not around internal org charts. Keep top-level navigation short and legible. Make search prominent and forgiving of typos and synonyms, because search users are high-intent buyers. Getting the underlying information architecture right is what makes everything downstream findable.

### Product pages that answer everything

Treat the product page as the moment of decision. Answer the obvious questions before the user has to hunt: clear photography from several angles, honest descriptions, sizing and specification detail, delivery expectations, and return terms visible without leaving the page. Genuine customer reviews do heavy lifting here, both as information and as reassurance.

### Checkout: remove every avoidable step

Offer guest checkout. Show the full price, delivery included, early rather than as a late surprise. Cut form fields to the minimum and use sensible defaults. Show progress so the user knows how much is left. Reassure about security and returns at the point of payment. Every field removed and every surprise avoided is a recovered sale from someone who had already chosen to buy.

### Mobile first, genuinely

Design and test the store on a phone as the primary case, not as an afterthought once the desktop version is signed off. Large tap targets, readable text, and a checkout that works one-handed are the baseline. Understanding the full path a shopper takes across devices is where a [customer journey map](/blog/customer-journey-map-template/) earns its place -- people often browse on mobile and buy later, and the design has to hold that together.

### Build the trust stack

No single element makes a store trustworthy; the effect is cumulative. Real reviews, findable delivery and returns policies, visible contact details, recognisable and varied payment options, and security cues at checkout together tell the user it is safe to hand over money. For an unfamiliar brand, that stack can matter as much as the product.

## A short ecommerce UX checklist

A quick pass to run against any online store:

- Can a first-time visitor find a specific product in a few clicks?
- Does the product page answer sizing, materials, delivery, and returns without hunting?
- Is guest checkout available?
- Is the full price, including delivery, shown before the final step?
- Are there genuine reviews on product pages?
- Are returns and delivery policies easy to find?
- Does the checkout work comfortably one-handed on a phone?
- Are there clear trust and security cues at the point of payment?
- Do you have data or testing showing where users actually abandon?

Every "no" on that list is a plausible place revenue is leaking.

## How UX skills apply to ecommerce

Ecommerce is one of the most direct applications of core UX skills. User research uncovers the real reasons people hesitate. Information architecture shapes navigation and categories. Usability testing exposes exactly where the checkout breaks. Analysis of behavioural data locates the drop-off points that intuition misses. The difference from other UX work is that the stakes are explicit: improvements can be measured in conversion and revenue, not just satisfaction.

That measurability makes ecommerce a strong area to specialise in or to build portfolio work around. A case study that shows a redesigned checkout or a restructured product page, backed by testing and a clear before-and-after, speaks directly to the outcomes employers care about.

### Measure what the design changed

The habit that separates strong ecommerce designers from the rest is closing the loop. A redesign is a hypothesis; the numbers tell you whether it was right. Watch the metrics that map to the stages above -- product-page bounce, add-to-cart rate, checkout completion, and the drop-off between each step -- before and after a change. Where traffic allows, an A/B test isolates the effect of a single decision rather than leaving you to guess. Reading real session data and support tickets alongside the numbers is what turns a plausible idea into a defensible one, and it is exactly the evidence a hiring manager wants to see behind a case study.

> On UX Academy's [Advanced UX Design course](/courses/advanced-ux-design/), you work through research, testing, and conversion-focused design decisions on a real brief -- the exact skills ecommerce work demands. The instructors work in the industry and teach the process live, with feedback on your work at every stage.


---

# Animation in UX Design: A Practical Guide

URL: https://myuxacademy.com/blog/animation-in-ux-design/
How to use animation in UX design: microinteractions, transitions, easing, timing and accessibility, plus when motion helps and when it hurts.

Animation is one of the most misunderstood parts of UX design. Done well, it is close to invisible - a button that confirms your tap, a screen that explains where it went, a loading state that makes three seconds feel like one. Done badly, it is the thing users complain about without knowing why: an interface that feels sluggish, disorienting, or just "off."

**Animation in UX design is the use of motion to communicate state changes, provide feedback, and guide attention - and it should always serve a functional purpose, not a decorative one.** The best UX animation is barely noticed consciously; users just experience the product as clear and responsive.

> **Want to design interfaces that actually feel right to use, not just look right?** UX Academy (myuxacademy.com)'s [Beginner UX (AI) Design course](/courses/beginner-ux-design/) covers interaction design and prototyping - including when and how to use motion - as part of a full, live UX curriculum. Cohort 1 starts 21 Sep 2026 -- [reserve your place with a GBP 99 deposit](/courses/beginner-ux-design/).
> Or [try the free masterclass first](/masterclass/free-ux-ui-masterclass/).

## Why animation matters in UX design

Every interface change is, technically, information. When an element appears, disappears, moves, or changes state, that change either happens instantly, or it happens with some kind of transition. Animation is the design decision about how that transition is communicated to the user.

Experienced designers treat motion as a layer of the interface on the same level as typography or colour - not an afterthought bolted on after the "real" design work is done. It sits alongside the fundamentals covered in our guide to [what UX design is](/blog/what-is-ux-design/) and connects directly to interaction design, one of the core disciplines inside the broader [UX design process](/blog/ux-design-process/).

Animation earns its place in an interface when it does one of these jobs:

- **Communicates cause and effect.** A button presses down slightly when tapped, so the user knows the tap registered before any result appears.
- **Explains spatial relationships.** A new screen slides in from the right, implying it is "further along" in a flow; a modal scales up from the element that triggered it, implying it came from that element.
- **Reduces perceived wait time.** A skeleton screen or progress animation makes a load feel shorter and less uncertain than a blank screen.
- **Directs attention.** A subtle highlight or pulse draws the eye to something the user needs to notice, such as a new notification.
- **Confirms completion.** A checkmark animation after a form submits tells the user, unambiguously, that the action succeeded.

None of these are decorative. Each one removes ambiguity or effort from the user's experience. That is the test every animation decision should be run through.

## The main types of UX animation

Most animation in digital products falls into a small number of categories. Knowing these gives you a vocabulary for deciding what a given moment in a flow actually needs.

### Microinteractions

Small, single-purpose animations tied to one user action - liking a post, toggling a setting, adding an item to a basket. They are usually brief (well under half a second) and exist purely to confirm that an action registered. The heart icon that fills and briefly bounces when you like something on Instagram is a classic example. Microinteractions are the highest-frequency use of animation in most products, because users trigger them constantly.

### Transitions

Transitions govern how the interface moves from one state or screen to another - a page changing, a modal opening, a tab switching. Good transitions preserve spatial continuity: if a card expands into a full detail view, the card visually growing into that view (rather than a hard cut) helps the user retain a mental model of where they are and how to get back.

### Loading and progress states

Spinners, skeleton screens, and progress bars manage uncertainty - telling the user something is happening, roughly how long it might take, and that the product has not frozen. Skeleton screens (grey placeholder shapes that mimic the eventual layout) are now generally preferred over generic spinners because they hint at what is coming, not just that something is loading.

### Feedback and system status

Animations that communicate success, error, or a change in system state - a form field shaking gently on a validation error, a save icon briefly turning into a checkmark, a toast notification sliding in and back out. These are often the difference between a user confidently continuing and one hesitating, unsure whether their action worked.

### Orientation and spatial animation

These help users understand where they are in a product's structure - a slide-in navigation drawer, a transition that implies "forward" or "back," a zoom-in that implies "this came from that element." This matters most in flows with several steps or nested layers, where users can otherwise lose track of their location.

### Storytelling and onboarding animation

Larger, more expressive animations used in onboarding flows, empty states, or marketing moments inside a product. These have more creative latitude but should still be used sparingly - their job is to build a moment of delight or explain a concept quickly, not to slow down a user who already knows the product.

## Principles of good UX animation

**1. Purpose before polish.** Before animating anything, ask what problem the motion solves. If you cannot articulate one - feedback, orientation, perceived speed, attention - it is decoration, and decoration is the first thing that should be cut when a design needs to ship faster or feel less cluttered.

**2. Keep it fast.** As a rule of thumb, most interface animations should sit between 200 and 500 milliseconds. Small, local movements - button presses, toggles, icon state changes - should be on the shorter end, around 150 to 250ms. Larger movements, like a screen transition, can extend toward 300 to 500ms. Below roughly 100ms, a movement reads as a glitch. Above 500ms, it starts to feel like the interface is making the user wait, particularly for actions people repeat often.

**3. Use easing, not linear motion.** Real-world movement accelerates and decelerates; it rarely moves at a constant speed. An element that eases in and out (starting slow, speeding up, then slowing again before it settles) feels natural. Linear animation, where speed stays constant throughout, reads as mechanical, even if most users could not say why. Standard "ease-out" curves work well for elements entering the screen; "ease-in" suits elements leaving it.

**4. Practise restraint.** Not every element needs to move. A screen where everything animates at once is harder to parse, not easier - the eye has nowhere clear to land. The best UX animation is often the animation a user does not consciously notice; it just makes the interface feel responsive.

**5. Design for accessibility from the start.** Motion is not universally comfortable. Some users experience real physical symptoms - dizziness, nausea, headaches - from certain kinds of animation, particularly large-scale movement, parallax, and zooming effects. This is a documented accessibility requirement, covered in more detail below.

**6. Match the animation to the brand.** Timing and easing carry personality. A finance app calling for restraint and trust typically uses quick, understated motion. A youth-focused consumer product has more room for bouncier, expressive animation. The right choice depends on the product and its users, in the same way colour and typography decisions do.

## How to actually add animation to a design

**Decide the "why" first.** Before opening any prototyping tool, write down, in one sentence, what the animation needs to communicate - "this confirms the item was added to the basket," or "this shows the settings panel is a layer above the main screen, not a new page." If you cannot write that sentence, do not build the animation yet.

**Prototype it before building it.** Figma's Smart Animate feature is the fastest way to test a transition idea. It interpolates between two frames automatically, matching layers by name, so you can preview a state change without writing any code - enough for most prototyping and stakeholder walkthroughs. For more detailed micro-interaction work, Principle is a dedicated tool built specifically for that kind of interaction design.

**Hand it off clearly.** When a design goes to development, specify the animation the same way you would specify colour or spacing: what property changes (position, opacity, scale), the duration, and the easing curve. "Make it feel smooth" forces a developer to guess. "Fade and scale from 95% to 100% over 200ms, ease-out" does not.

**Build it efficiently.** For production interfaces, animations are almost always implemented with CSS transitions and transforms, or, in React-based products, a library like Framer Motion. Sticking to properties like `transform` and `opacity` (rather than layout-triggering properties like `width` or `top`) keeps animations smooth and inexpensive to run. For more complex vector animations - onboarding illustrations, detailed loading states - Lottie is the standard way to export work built in After Effects as a lightweight file that plays natively in apps and on the web.

This kind of practical, tool-specific decision-making is exactly the sort of thing covered in our broader look at [UX design tools](/blog/ux-design-tools/), and it is where the line between UX and UI design gets genuinely blurry - see our guide on [UX vs UI design](/blog/ux-vs-ui-design/) if that distinction is still unclear.

## Common animation mistakes

**Animating everything.** If every element on a screen moves on load, nothing feels special and the interface feels busier, not more polished.

**Animations that block interaction.** If a user has to wait for a decorative animation to finish before they can tap the next button, the animation is costing them time. Feedback animations should never gate the user's next action unless there is a genuine reason, such as payment processing.

**Inconsistent timing and easing across a product.** If one screen transitions in 200ms with a sharp ease and another takes 600ms with a bouncy overshoot, the product feels stitched together rather than designed as one system. Motion should be defined once, as a small set of reusable values, the same way a design system defines colour tokens or spacing scale.

**Copying trends without checking they fit.** Parallax scrolling, elaborate scroll-triggered reveals, and heavy 3D transforms look impressive in portfolio pieces, but frequently hurt usability, performance, and accessibility on real products. Test any trend-driven choice against the purpose test before shipping it.

**Ignoring performance.** Animations that cause visible jank - stuttering, dropped frames - do more damage to perceived quality than having no animation at all. A snappy interface with zero animation beats a laggy one with beautiful transitions.

## Accessibility and animation

Motion accessibility is not a niche concern. A meaningful share of users experience genuine discomfort from certain kinds of animation - particularly large parallax effects, rapid flashing, and aggressive zooming or spinning - ranging from mild distraction to vestibular symptoms like dizziness and nausea. Two things matter in practice.

**Respect `prefers-reduced-motion`.** This is an operating system-level setting users can turn on to ask every website and app they use to minimise animation. In CSS, this is detected with a simple media query, and it should be treated as a baseline requirement, not an enhancement:

```css
@media (prefers-reduced-motion: reduce) {
  * {
    animation-duration: 0.01ms !important;
    transition-duration: 0.01ms !important;
  }
}
```

When this setting is on, swap large or fast movement for simple fades, or remove the transition entirely and let state changes happen instantly. Functional animation (feedback, confirmation) can usually stay; large-scale decorative motion should go.

**Never use motion as the only signal.** If an error state is communicated purely by a shake animation, a user who has reduced motion enabled - or who simply looks away at the wrong moment - misses it entirely. Pair every meaningful animation with a static signal too: a colour change, an icon, or text.

WCAG's guidance on animation and motion sits under the broader umbrella of accessible design covered in our [UX design process](/blog/ux-design-process/) guide, and it is worth treating as seriously as colour contrast or keyboard navigation - not as a nice-to-have layered on at the end.

## Bringing it together

Animation is a functional design tool, not a finishing touch. Used well, it removes ambiguity, confirms actions, manages waiting, and helps users understand where they are in a product. Used badly, it slows people down, distracts from the actual task, and in some cases causes real physical discomfort.

The practical checklist is short: know why the animation exists, keep it fast, ease it naturally, use it sparingly, and always design an alternative for users who need reduced motion. Get those five things right and animation becomes one of the quieter, more effective tools in a UX designer's kit - one most users will never consciously notice, which is exactly the point.

If you want to build this kind of judgement - not just how to animate something in Figma, but when animation should exist at all - it is exactly what we teach on the [Beginner UX (AI) Design course](/courses/beginner-ux-design/) and the more advanced [Product Design course](/courses/product-design/) at UX Academy, through live, feedback-driven project work rather than tutorials alone.


---

# UX Design Courses UK 2026 - The Complete Guide

URL: https://myuxacademy.com/blog/ux-design-courses-uk-2026/
How to choose a UX design course in the UK: types of training, cost and ROI, live vs self-paced, and what to look for before you pay a deposit.

If you search "UX design course UK" right now, you will find dozens of options that all claim to make you job-ready. Self-paced platforms, in-person bootcamps, university postgraduate diplomas, and live online cohort courses -- all pitched at roughly the same audience, all priced differently, and all with wildly different completion rates.

This guide is not a ranked list. It is a framework for choosing, written for people who are about to spend real money and time on a career change and want to get the decision right the first time.

> **Already know you want live, small-cohort training?** UX Academy (myuxacademy.com) runs UX design courses UK-wide, fully online, taught live by working UX professionals -- including [Beginner UX (AI) Design](/courses/beginner-ux-design/) for career-changers with no design background. Cohort 1 starts 21 Sep 2026 -- [reserve your place with a £99 deposit](/courses/beginner-ux-design/). Prefer to see it in action first? [Join the free masterclass](/masterclass/free-ux-ui-masterclass/).

## The four types of UX design course

Before comparing individual providers, it helps to understand the four broad categories UK UX training falls into. Each has a genuinely different value proposition -- this is not just a difference in price.

### 1. Self-paced video courses

Pre-recorded video lessons, downloadable exercises, and (usually) an online community or forum for peer feedback. Providers in this category price themselves from a few hundred pounds up to around 1,500 pounds, often with monthly payment plans.

**Strength:** flexible, cheapest entry point, learn at your own pace around a full-time job.

**Weakness:** completion rates are low. Without a fixed schedule or a live instructor checking in, most people's momentum stalls somewhere around week 3 or 4. Feedback, when it exists, comes from peers or asynchronous reviewers rather than a working practitioner -- which matters, because the single biggest determinant of portfolio quality is expert feedback on your decisions, not just your screens.

### 2. Full-time, in-person or hybrid bootcamps

Intensive, often 10-16 weeks, sometimes with a residential or in-person component. Designed to take you from zero to job-ready as fast as possible, usually with career support built in.

**Strength:** immersive, fast, strong peer network, employer partnerships in some cases.

**Weakness:** expensive (often 5,000-10,000+ pounds), and most require you to pause or leave full-time work, which is not realistic for most career-changers with financial obligations.

### 3. University postgraduate courses (MSc/MA in UX or HCI)

Academic routes, typically one year full-time or two years part-time, run through university human-computer interaction or design departments.

**Strength:** deep theoretical grounding, a recognised academic credential, useful if you want to move into UX research or an academic/research-adjacent role.

**Weakness:** slow (a full year minimum), expensive when you include living costs and lost income, and academically weighted rather than portfolio-weighted -- which matters less to most UK employers than a strong, practitioner-reviewed case study portfolio.

### 4. Live, part-time cohort courses

A fixed group of students, a live instructor, a set weekly schedule (usually evenings), delivered over weeks rather than months. This is the newest category and it is growing fastest, because it solves the two biggest problems with self-paced courses (accountability and feedback quality) without requiring you to quit your job or spend a year in academia.

**Strength:** live feedback from a working professional, cohort accountability (you are less likely to drop off when 14 other people are showing up), structured pacing, and a realistic fit for people working full-time.

**Weakness:** fixed schedule means less flexibility than self-paced -- you need to be able to commit to specific evening sessions each week.

UX Academy sits in this fourth category: [live, evening cohorts](/courses/beginner-ux-design/) capped at a small class size, taught by a named working instructor rather than pre-recorded video.

## What to actually look for in a UX design course

Marketing pages tend to converge on the same claims -- "industry-recognised", "job guarantee", "hands-on projects". Here is what to check underneath the claims.

**Who is actually teaching it.** Is there a named instructor with a real, checkable background in UX practice, or is the course delivered entirely through pre-recorded video with anonymous "mentors" or "career coaches" providing support? At UX Academy, courses are led by a [named lead instructor](/instructors/), a working UX professional, alongside a named instructor team -- not an anonymous support pool.

**Cohort size.** A "live" course delivered to 200 people in a webinar is not meaningfully different from a self-paced course with a chat window. Ask what the actual class size is. Small cohorts (under 20) are the only structure where an instructor can give you specific, individual feedback on your work rather than generic notes.

**What the portfolio output actually is.** Ask to see example portfolios from recent graduates, not marketing screenshots. The strongest signal of a good course is graduates who land real roles -- for example, UX Academy graduate Vita moved from a marketing career into a UX Designer role at Airbnb, and other graduates have gone on to Spotify, Google, and Adobe. Named, checkable outcomes matter more than vague "94% job placement" statistics that most providers cannot substantiate.

**Whether feedback is live or asynchronous.** Written comments on a submitted file are useful. A live critique where an instructor asks you to defend your decisions in real time, and pushes back, is what actually prepares you for a UX interview -- because that is exactly what a portfolio review interview looks like.

**Refund and deposit terms.** Look for a course that lets you commit with a small deposit rather than the full fee up front, and check the cancellation terms before you pay anything.

**Real client or live-brief work, not just course exercises.** Portfolios built entirely from tutorial-style briefs read as generic to hiring managers who have seen the same brief a hundred times. Courses that include real client work -- like [Beginner UX (AI) Design](/courses/beginner-ux-design/) and its [UX Career Track](/courses/ux-career-track/) extension, which adds a second live client brief -- produce noticeably stronger portfolios.

## Cost and ROI: what you are actually paying for

UK UX design salaries for junior roles typically start between £24,000 and £38,000, rising to £40,000-£55,000 at mid-level and £60,000-£85,000 at senior level in London (see our [UX design jobs UK](/blog/ux-design-jobs-uk/) guide for the full breakdown by region and sector). Against that earning potential, the cost of training is worth evaluating as an investment, not just an expense.

| Course type | Typical cost | Typical duration | Time to portfolio |
|---|---|---|---|
| Self-paced video | £300-£1,500 | Self-paced, often 6-12+ months in practice | Variable, high drop-off |
| Live cohort course | £1,000-£2,000 | 6-12 weeks, part-time | Fixed, matches course length |
| Full-time bootcamp | £5,000-£10,000+ | 10-16 weeks intensive | Fixed, fast |
| University MSc/MA | £9,000-£17,000+ | 1-2 years | Slow |

The number that matters most is not the sticker price -- it is cost per completed, hireable portfolio. A £400 self-paced course that you never finish, or finish with a portfolio no employer takes seriously, is a worse investment than a £1,500 course you complete with real feedback and a credible case study.

UX Academy's [Beginner UX (AI) Design course](/courses/beginner-ux-design/) is priced at £1,500 with a £99 refundable deposit to hold your place -- roughly half the cost of a comparable full-time bootcamp, delivered live over evenings so you do not need to leave your current job while you train.

## Live vs self-paced: the honest trade-off

This is the single most consequential decision in choosing a UX course, so it is worth being direct about it.

Self-paced training works well if you are exceptionally self-disciplined, already have some design or research background, and mainly need structured content rather than accountability. For most career-changers, it does not work well -- not because the content is bad, but because life gets in the way of a course with no fixed schedule and no one checking in.

Live cohort training costs more but solves the completion problem structurally: a fixed weekly session, a named instructor, and classmates who are also showing up. You are not relying on willpower alone. This is the entire reason the live cohort model exists, and why it has grown fastest among the four course types over the past two years.

If you have tried a self-paced course before and stalled out -- including if you were part-way through a [CareerFoundry programme when it closed](/blog/careerfoundry-closed-what-happened/) -- a live, structured course with a hard weekly commitment is usually the better second attempt. See our [CareerFoundry alternative page](/careerfoundry-alternative/) for a direct transition offer.

## How to choose: a short checklist

1. Confirm the instructor is named and has a real, checkable UX background -- not an anonymous support team.
2. Ask for real graduate outcomes with names and companies, not unverifiable percentages.
3. Check whether feedback is live or asynchronous, and how often it happens.
4. Ask whether the portfolio work includes a real client or live brief, or only course exercises.
5. Compare cost against realistic UK junior UX salaries (£24,000-£38,000) to sanity-check the ROI.
6. Check the deposit and refund terms before paying the full fee.
7. If you are unsure, try before you commit -- a free introductory session should exist somewhere in the funnel.

For a curated shortlist across providers, see our [best online UX design courses UK](/best-online-ux-design-courses-uk/) roundup, which compares specific programmes side by side.

## Where UX Academy fits

UX Academy (myuxacademy.com) runs live, part-time UX design courses UK-wide, entirely online, in small cohorts taught by a named instructor team led by Natalia Veretenyk. Note: this is a different organisation to Designlab's "UX Academy" product in the US -- if you are researching us specifically, look for myuxacademy.com.

There are six courses across the career journey: [Beginner UX (AI) Design](/courses/beginner-ux-design/) for career-changers starting from scratch (the design process, and how AI is used at every step of it), [UX Career Track](/courses/ux-career-track/) as a 4-week extension adding a second live client brief and job search support, [Advanced UX Design](/courses/advanced-ux-design/) and [Product Design](/courses/product-design/) for practising designers, [UX Strategy](/courses/ux-strategy/) for leadership-track designers, and [Accessibility for UX](/courses/ux-accessibility/) for WCAG-compliant design.

Pricing is £1,500 with a £99 refundable deposit, roughly half the cost of a comparable full-time bootcamp. Cohort 1 starts <CohortDate />. If you want to see how the live format works before committing, the [free UX/UI masterclass](/masterclass/free-ux-ui-masterclass/) is the lowest-risk way to start -- no payment required, and it gives you a genuine sense of the teaching style before you decide anything else.

## FAQ

### What is the best type of UX design course in the UK?

It depends on your starting point and how you learn. For career-changers with no design background, a live, small-cohort course with a working instructor and real feedback produces the strongest portfolio in the shortest time. Self-paced video courses are cheaper but have far higher drop-off.

### How much does a UX design course cost in the UK?

UK UX design training ranges from free to over £3,000. Self-paced platforms typically charge £300-£1,500. Full-time bootcamps run £5,000-£10,000+. Live, part-time cohort courses sit in the middle, typically £1,000-£2,000.

### Is a UX design course worth it in 2026?

A UX design course is worth it if it produces a portfolio that demonstrates real UX process, alongside feedback from a working practitioner. Courses that combine live teaching, structured briefs, and mentor feedback have a much stronger track record of moving career-changers into paid UX roles than video-only courses.

### Do I need a certificate to become a UX designer in the UK?

No. UK employers hire on portfolio and interview performance, not certificates. Treat any certificate as a byproduct of doing the work, not the goal of the course.


---

# How to Get a UX Design Job in 2026 (UK)

URL: https://myuxacademy.com/blog/how-to-get-a-ux-design-job-uk-2026/
A step-by-step guide to landing a UX design job in the UK in 2026: portfolio, applications, interviews, networking and realistic timelines.

Getting a UX design job in the UK in 2026 is achievable, but it is not automatic, and it rewards a specific, deliberate process more than raw enthusiasm. This guide pulls together everything a career-changer needs to know -- market context, portfolio, applications, interviews, networking, and a realistic timeline -- into one practical sequence.

> **Want structured help getting from portfolio to job offer?** UX Academy (myuxacademy.com)'s [UX Career Track](/courses/ux-career-track/) is a 4-week extension for Beginner UX (AI) Design graduates: a second live client brief run as a design team, plus dedicated job search support -- portfolio critique, interview preparation, and LinkedIn optimisation. Start with [Beginner UX (AI) Design](/courses/beginner-ux-design/), Cohort 1 starts 21 Sep 2026 -- [reserve your place with a £99 deposit](/courses/beginner-ux-design/). Or [start with the free masterclass](/masterclass/free-ux-ui-masterclass/) to see whether UX is the right move before committing.

## Step 1: Understand the market you are entering

The UK UX job market has stabilised after the 2023-2024 layoff cycle but remains more selective at entry level than it was in 2021-2022. Senior and mid-level roles are hiring steadily across finance, retail, healthcare, and the public sector. Entry-level roles are tighter -- larger companies increasingly prefer mid-level hires for the same headcount -- but junior roles still exist, particularly at start-ups and agencies that need to scale delivery capacity.

Geographically, London accounts for roughly 60-70% of UK UX job listings, with active secondary markets in Manchester, Bristol, Edinburgh, and Leeds. Hybrid and remote working has become standard for a large share of roles, which meaningfully widens your options if you are not based in or near London. For the full breakdown by city, sector, and salary band, see our [UX design jobs UK](/blog/ux-design-jobs-uk/) guide.

Knowing this context matters because it shapes strategy: a scattergun approach targeting only large, brand-name product companies will be slower than a targeted approach that includes agencies, start-ups, and companies newer to UX where the bar is more accessible.

## Step 2: Build a portfolio that actually gets you interviews

The portfolio is the single biggest filter in UX hiring. Not the visual polish -- whether it demonstrates a real UX process: a problem, research, synthesis, decisions grounded in evidence, and iteration.

**What to include:** two to four case studies. Quality over quantity -- three strong, detailed studies beat six shallow ones. At least one should involve a real client, start-up, or live brief rather than a tutorial-style exercise; employers can tell the difference immediately, and it is one of the fastest ways to stand out from the flood of near-identical bootcamp portfolios.

**What each case study needs:** the problem you set out to solve, what research you did and what you learned, the decisions you made and why (including the ones you reversed), the trade-offs you navigated, and the measurable or observed outcome. Screens alone, without this narrative, do not pass the filter.

**Common mistakes to avoid:** portfolios built entirely from the same generic briefs everyone else on your course also completed; polished final screens with no visible thinking behind them; case studies that are all breadth and no depth, covering ten screens each in a paragraph rather than three projects covered properly.

For structured guidance, see our [how to build a UX portfolio from scratch](/blog/how-to-build-a-ux-portfolio-from-scratch/) guide and our [UX portfolio examples](/blog/ux-design-portfolio-examples/) post for what strong work actually looks like.

## Step 3: Get the practical skills employers check for

Beyond the portfolio, UK employers consistently look for:

**Figma fluency.** Non-negotiable in 2026. You need to be comfortable with components, auto-layout, and prototyping, not just able to drag boxes around.

**Research skills.** Evidence you can run user interviews or usability tests and translate findings into design decisions, not just file them away.

**Communication.** The ability to explain design rationale to product managers and engineers -- people who do not share your vocabulary -- is cited by employers as consistently as portfolio quality.

**Collaboration.** Understanding how to operate inside agile and sprint workflows alongside product and engineering counterparts.

Career-changers often underestimate how transferable their existing skills are here. Marketing, teaching, psychology, and project management all build exactly this kind of stakeholder communication and structured thinking -- it is a genuine advantage, not a gap to hide.

## Step 4: Apply strategically, not broadly

Twenty well-researched applications to companies that are genuinely a fit outperform a hundred generic submissions to everything with "UX" in the job title. For each application:

- Read the actual job description closely and mirror the language they use for the skills they are prioritising
- Write a short, specific cover note that references their product, not a generic template
- Prioritise companies where job descriptions mention research and process, not just "wireframes" -- it signals UX is taken seriously internally
- Include agencies and start-ups in your target list, not only large product companies -- they hire more at entry level

**Where to look:** LinkedIn is the primary channel for UX hiring in the UK -- set up job alerts for your target titles and locations. Indeed and Wellfound (formerly AngelList) are useful for start-up roles. Work in Startups is worth checking regularly.

## Step 5: Prepare properly for UX interviews

UX interviews do not follow a standard format, but most UK employers run a similar structure: a screening call, a portfolio review, a design challenge (live or take-home), and a final panel. The portfolio review is usually weighted most heavily.

The preparation that matters most: being able to talk through every decision in your portfolio out loud, unscripted, including the decisions that did not work out. Practise this specifically -- record yourself walking through a case study and watch it back. Interviewers are testing whether your polished-looking decisions were intentional and evidence-led, or just aesthetic instinct.

For a full breakdown of what to expect at each stage and how to prepare, see our dedicated guide to [UX design interview questions](/blog/ux-design-interview-questions/).

## Step 6: Network -- it moves faster than job boards

A significant share of junior UX hires in the UK originate from informal conversations rather than formal applications. Practical ways to build this:

**Go direct on LinkedIn.** Reach out to designers at companies you are interested in and ask to learn about their work -- not for a job. Most working designers will take a short call with someone who has done their homework and asks specific questions.

**Attend events.** UX London and UX Brighton are the largest annual conferences; local UX Crunch meetups and Design Ops events are lower-commitment ways to build relationships, even if you attend only once or twice a year.

**Ask for introductions.** If you know anyone in product, design, or tech, ask if they can introduce you to someone in UX at their company. Warm introductions convert to interviews far more often than cold applications.

## Step 7: Set realistic expectations on timeline

For career-changers who have completed structured training and built a portfolio, a realistic job search takes three to nine months. The range is wide because the variables genuinely matter: portfolio quality is the single biggest factor, followed by how actively and specifically you are applying, and your flexibility on location.

What tends to speed this up: a portfolio with real client or start-up work rather than only course exercises, active LinkedIn networking rather than passive applications, and targeted applications to companies where UX clearly has internal advocates.

If you are still deciding whether UX design is the right career change for you before investing time in a portfolio, our guide to [switching careers to UX design](/blog/switching-careers-to-ux-design/) is a good starting point, alongside [how long it takes to become a UX designer](/blog/how-long-to-become-a-ux-designer/).

## Where structured training changes this timeline

The market in 2026 rewards specificity, not enthusiasm. Employers are hiring on evidence of UX thinking, and that evidence comes from your portfolio -- which is why the quality of the training behind it matters so much.

UX Academy's [UX Career Track](/courses/ux-career-track/) is a 4-week extension for Beginner UX (AI) Design graduates, built specifically around this problem: it puts you through a second live client brief run as a design team, so you graduate with a second genuine case study in your portfolio, plus structured job search support -- portfolio critique, interview preparation, and LinkedIn optimisation. Cohorts are capped at a small size so feedback is specific, not generic.

Graduates have gone on to named outcomes including a move from marketing into a UX Designer role at Airbnb, and roles at Spotify, Google, and Adobe. Cohort 1 starts <CohortDate />. If you have no prior design background, [Beginner UX (AI) Design](/courses/beginner-ux-design/) is the starting point before the Career Track. To see the teaching style first with no commitment, [join the free masterclass](/masterclass/free-ux-ui-masterclass/).

## FAQ

### How do I get a UX design job with no experience in the UK?

Build a portfolio of two to four real, brief-driven case studies that show your research and decision-making process. Learn Figma to a fluent level. Get feedback from working UX practitioners. Network directly on LinkedIn. Target agencies and start-ups first, since they hire more at entry level than large product companies.

### How long does it take to get a UX design job after training in the UK?

A realistic timeline is three to nine months for career-changers who have completed structured training and built a portfolio. Portfolio quality and active, targeted networking are the biggest factors in moving faster.

### What should be in a UX design portfolio to get hired?

Two to four case studies showing the problem, your research, your decisions and why, the trade-offs, and the outcome. At least one case study involving a real client or start-up brief significantly strengthens a portfolio.

### Do I need a degree to get a UX design job in the UK?

No. Most UK employers hire on portfolio and interview performance, not degree subject. Many working UX designers switched from unrelated fields including marketing, teaching, psychology, and customer support.


---

# What Is a Wireframe? A Practical Guide for UX Designers

URL: https://myuxacademy.com/blog/wireframe-ux-design/
What is a wireframe in UX design, why it matters, how to create one, and where wireframes fit in the UX process. A practical guide, not a textbook definition.

A wireframe is a low-detail layout of a screen -- the structural skeleton of a design, showing what content goes where and how users navigate, without any visual design. It is one of the most useful things a UX designer produces, and also one of the most misunderstood, often confused with mockups, [prototypes](/blog/what-is-prototyping/), or finished designs.

This guide explains what wireframes actually are, where they fit in the [UX design process](/blog/ux-design-process/), and how to create one that does its job. If you are learning UX design or preparing for your first role, getting comfortable with wireframing early is one of the best things you can do.

> **Want to practise wireframing on a real client project?** UX Academy (myuxacademy.com)'s [Beginner UX (AI) Design course](/courses/beginner-ux-design/) teaches wireframing hands-on with working professionals. Cohort 1 starts 21 Sep 2026 -- [reserve your place with a £99 deposit](/courses/beginner-ux-design/).

## What a wireframe is

A wireframe is a low-detail layout of a screen or page. It shows:

- **What content exists** on the screen (headings, body text, images, buttons, form fields)
- **Where that content sits** relative to everything else
- **How a user navigates** through the interface (which buttons go where, what links to what)

What it does not show: colour, typography, imagery, brand style, or anything else that belongs to visual design. Wireframes are typically produced in greyscale with placeholder text and simple boxes in place of images.

The purpose is to make layout and structural decisions fast, before anyone has invested time in visual design. A wireframe that turns out to be wrong costs almost nothing to fix. A finished visual design that turns out to be structurally wrong is expensive.

## Lo-fi vs hi-fi wireframes

Not all wireframes are the same level of detail. The right level depends on what question you are trying to answer.

### Lo-fi wireframes

Lo-fi wireframes are rough. Boxes stand in for images. Headings are labelled "H1", "H2". Text areas say "body copy goes here". The visual roughness is deliberate — it signals clearly to everyone reviewing the work that this is a structural conversation, not a design review.

Lo-fi wireframes are right when:
- The overall layout and information hierarchy is still being worked out
- You want stakeholder input on structure before committing to design
- You are moving quickly through multiple layout options
- You want usability test participants to give honest feedback rather than commenting on visual style

### Hi-fi wireframes

Hi-fi wireframes are more detailed. They use real copy (or near-final copy), correct spacing, real component sizes, and occasionally simple greyscale styling. They look closer to a finished design but still carry no colour or brand treatment.

Hi-fi wireframes are right when:
- The structure is settled and you are testing specific interactions or content decisions
- You are handing off to a UI designer who needs accurate layout specs
- The team needs to communicate detailed interaction behaviour to engineering before visual design is finalised

Most UX designers start lo-fi and move to hi-fi as decisions get made. Jumping straight to hi-fi before the structure is clear wastes time.

## Where wireframes fit in the design process

Wireframing sits between synthesis and prototyping. By the time you are wireframing, you should have:

1. Done research to understand user needs (interviews, observations, surveys)
2. Defined the problem you are solving and who you are solving it for (often documented as [user personas](/resources/templates/user-persona/))
3. Done ideation to generate layout directions

What wireframing does is take the best ideas from ideation and give them enough structure to be evaluated and tested. Once wireframes are validated, they get connected into a prototype for [usability testing](/blog/usability-testing-guide/).

Skipping wireframing and going straight to visual design is one of the most common mistakes in UX. It produces work that gets redesigned after testing because the structure was never validated — only the appearance was.

## What to include in a wireframe

A wireframe should contain enough information to answer structural questions and no more. The practical checklist:

**Content and hierarchy**
- All content elements that will appear on the screen (do not leave things out "until later")
- A clear visual hierarchy showing which content is primary, secondary, and tertiary
- Real headings where the wording matters for the user's understanding; placeholders everywhere else

**Navigation and interaction**
- All buttons, links, and interactive elements — labelled with what they do
- Clear indication of what happens when a user takes an action (which screen follows)
- Any states that matter: empty states, error states, loaded vs loading

**Annotations**
- Notes explaining decisions that are not obvious from the layout alone
- Interaction descriptions for anything more complex than a simple link
- Questions or open decisions flagged for discussion

What you leave out:
- Colour, typography choices, iconography, imagery
- Brand styling of any kind
- Anything that could distract reviewers into debating aesthetics instead of structure

## How to create a wireframe

**Start with the user goal.** Before you touch a tool, be clear on what the user is trying to accomplish on this screen and what they need to achieve it. Everything in the wireframe exists to serve that goal.

**Sketch on paper first.** Even two minutes with a pen generates more layout options than opening Figma. Paper forces quick decisions. Figma invites fiddling. Get four or five rough layout ideas down before committing to one.

**Open in Figma and build grey boxes.** Set up an artboard at the right dimensions for your target device. Place rectangles for the major content areas. Do not touch the component library or styles yet — stay in grey boxes until the structure is right.

**Add real headings and placeholder text.** Write the actual heading copy where it matters. Use "Lorem ipsum" or a content label everywhere else. If you do not know what the heading says, you do not know what the section is for.

**Add interaction labels.** Every button and link should be labelled with its destination or action. If you find yourself labelling a button "Button", the design is not clear enough yet.

**Annotate anything non-obvious.** A sticky note in Figma is faster than a meeting. Write annotations as you go rather than trying to reconstruct your thinking later.

**Share and discuss before moving forward.** Wireframes exist to be challenged. A wireframe that no one has commented on has not done its job. Share it with a colleague, a stakeholder, or a potential user before treating it as settled.

## Wireframes vs mockups vs prototypes

These three terms are often used interchangeably. They are not the same thing.

| | What it is | What it answers |
|---|---|---|
| **Wireframe** | Static layout, no visual design | Is the structure right? |
| **Mockup** | Visual design applied to the structure | Does it look right? |
| **Prototype** | Interactive flow connecting multiple screens | Does it work? |

The three are additive — you typically produce them in this order. The common mistake is jumping to mockups or prototypes before the wireframe has been validated, which means the visual design or interaction work gets thrown away when the structure turns out to be wrong.

## Tools for wireframing

**Figma** is the industry standard. It handles lo-fi wireframes (grey boxes, basic shapes) through to hi-fi wireframes with the same tool, which means no file conversion when you move between levels of fidelity. Most UX teams use Figma from wireframe through to final handoff. If you are [learning UX design](/blog/how-to-become-a-ux-designer/), learning Figma is not optional. See our [beginner's guide to Figma](/blog/what-is-figma/) for where to start.

**Balsamiq** produces deliberately sketchy-looking wireframes. The rough visual style is a feature, not a limitation — it makes clear to everyone viewing the work that structure, not visual design, is what's being discussed. Useful when stakeholders have a habit of derailing wireframe reviews by commenting on aesthetics.

**Paper and pen** still produces the fastest first iteration of any layout. Many experienced UX designers sketch on paper every day, even after years of Figma use. Paper is right for generating options; Figma is right for refining them.

## Common wireframing mistakes

**Making it too detailed too soon.** If your first wireframe looks like a finished screen, you have skipped the exploratory stage where the best structural ideas tend to emerge. Start rougher.

**Using placeholder text where real copy matters.** "Lorem ipsum" in a call-to-action button or a key heading is useless for evaluating whether the design communicates the right thing. Use real copy anywhere the wording affects the user's decision.

**Wireframing without researching first.** A wireframe made without user research is a guess at what users need. It might be a good guess. Research is how you find out.

**Treating the wireframe as done before it has been challenged.** Wireframes are for discussion. If you are showing a wireframe to a stakeholder or colleague for the first time in a full review meeting, you have missed the earlier feedback loop that would have caught structural problems cheaply.

**Skipping annotations.** Every non-obvious decision in a wireframe should be annotated. Three weeks later, neither you nor anyone else will remember why the navigation was structured that way.

## Wireframing as a career skill

In a UX job interview or portfolio review, your wireframes are evidence of how you think. A hiring manager looking at your case study is not just checking that you can use Figma — they are looking at whether you made good structural decisions, whether you iterated based on feedback, and whether you can explain the reasoning behind your layout choices.

Wireframes produced for tutorial briefs where the "right answer" was provided are much less useful for this than wireframes produced for a real problem where you had to make real decisions under real constraints.

On the [Beginner UX (AI) Design](/courses/beginner-ux-design/) course at UX Academy, you wireframe as part of a real client brief — working through discovery, research, and synthesis first, so your wireframes are grounded in what users actually need rather than what seemed like a reasonable guess. If you want to see what live UX training feels like before committing, the [free UX masterclass at UX Academy (myuxacademy.com)](/masterclass/free-ux-ui-masterclass/) is the place to start. Our lead instructor and team run the process with you, drawing on professional experience at organisations including Adobe, Google, and Canva. If you are [switching careers into UX design](/blog/switching-careers-to-ux-design/), that supervised practice on a real project is what builds the confidence to wireframe well on your own.


---

# What Is a Storyboard in UX Design? A Practical Guide

URL: https://myuxacademy.com/blog/what-is-a-storyboard-ux-design/
What UX storyboards are, how to create one, and the mistakes that turn them into a workshop exercise rather than a working design tool.

A storyboard in UX design is a sequence of frames that shows how a real person experiences a product or service in context. Not just the screens they tap through — the whole situation: where they are, what prompted them to act, how they feel at each step, and what their life looks like afterwards.

It borrows the format from film production, where storyboards map scenes before shooting begins. In UX, the purpose is similar: to make a user scenario concrete enough to discuss, critique, and build from, before significant time or money has been spent. A storyboard is one of the cheapest ways to test whether your team actually understands the problem it is trying to solve.

> **Want to use storyboards on a real project?** UX Academy (myuxacademy.com)'s [Beginner UX (AI) Design course](/courses/beginner-ux-design/) teaches storyboarding and the full UX process with working professionals. Cohort 1 starts 21 Sep 2026 -- [reserve your place with a £99 deposit](/courses/beginner-ux-design/).

## What a UX storyboard is

A UX storyboard is a visual narrative. It shows a specific user — usually someone drawn from your [user personas](/resources/templates/user-persona/) — moving through a specific scenario in a sequence of panels.

Each panel captures a moment:
- **What is the user doing?** (their action or situation)
- **What is the context?** (where they are, what device they are using, who else is present)
- **What are they feeling?** (frustrated, relieved, uncertain, satisfied)

A storyboard typically has between four and eight panels. More than that and it starts to become unwieldy. Fewer than four and it rarely captures enough context to be useful.

The key distinction from other UX artefacts is the emotional layer. A user flow tells you what a user does. A storyboard tells you what that experience is actually like. That difference matters because design decisions that look sensible on a flow diagram often reveal problems when you imagine how a real person would feel moving through them.

## Why UX designers use storyboards

### To build and share empathy

Research interviews and observation sessions generate rich insight. The problem is that insight often stays inside the heads of the people who did the research. A storyboard externalises it — it gives the whole team, including stakeholders who were not in the room, a shared picture of who the user is and what their experience looks like.

Teams that skip storyboarding tend to design for an abstract, idealised user rather than the complicated, distracted, time-pressured person revealed by the research. The storyboard keeps that real person visible throughout the project.

### To spot problems early

When you draw out a scenario in sequence, you often notice things that were not obvious in the research notes. A user who is on a train with patchy signal. A moment where the product asks for information the user does not have to hand. A step that assumes the user has remembered something from three screens ago. These friction points surface naturally when you commit a scenario to paper — much more cheaply than they surface in a usability test six weeks later.

### To align teams before design begins

Storyboarding is particularly valuable at the point in the [UX design process](/blog/ux-design-process/) just before wireframing starts. A short collaborative storyboarding session gets product managers, designers, and developers looking at the same user scenario and resolving disagreements about what the product needs to do before anyone has built anything.

### To communicate to stakeholders

A three-panel storyboard showing a user's journey from frustration to resolution is faster to read and more persuasive than five paragraphs of research findings. If you need a client or senior stakeholder to understand why a design decision was made, a storyboard often does the job more effectively than a written rationale.

## What does a UX storyboard contain?

The elements are simple. Most storyboards include:

**Scenario** — a one-sentence description of the situation being depicted. "Maya is trying to book a GP appointment during her lunch break." This grounds every subsequent panel.

**Persona** — the named user type the storyboard is drawn from. Even if the panels show a generic figure, naming the persona ties the storyboard back to the research.

**Panels** — the sequence of frames. Each panel shows a single moment in time. The visual does not need to be sophisticated — stick figures and rough sketches are completely acceptable. The point is communication, not illustration.

**Captions** — a short note under each panel explaining what is happening and, crucially, what the user is thinking or feeling. "Maya realises she cannot find her NHS number. She considers calling the surgery instead."

**Emotional indicators** — some storyboards include a simple emotion marker for each panel (a face showing frustration, relief, confusion). This makes the emotional arc of the journey explicit rather than implicit.

What you do not include: screen-level detail, UI specifications, exact copy, or anything that belongs in a wireframe. A storyboard is not a low-fidelity prototype. It operates at the level of human experience, not interface design.

## How to create a UX storyboard

**Step 1: Start with your research.** A storyboard without research behind it is fiction. You need to know who the user is, what they are trying to do, and what their current experience looks like. If you have not done this yet, go back to your [user research methods](/blog/ux-research-methods/) before you pick up a pen.

**Step 2: Choose a specific scenario.** Pick one task, one situation, one user type. Storyboards that try to show multiple users or multiple scenarios simultaneously lose their clarity. "How a busy working parent discovers and books a place on a course" is a usable scenario. "How users find us" is not.

**Step 3: Map the key moments.** Before drawing anything, list the moments that matter in the scenario. Aim for six to eight moments. These become your panels. Include the trigger (what prompted the user to act), the key interactions with the product, any friction points, and the resolution.

**Step 4: Sketch each panel.** Use whatever drawing medium is fastest. Paper and pen for a first draft. Figma or Miro if you need to share it remotely or refine it for a presentation. Each panel should be visually distinct — one moment, not a sequence within a panel.

**Step 5: Write the captions.** Captions are where most of the thinking happens. Write them in the user's voice or close to it: what they are doing, what they are thinking, and how they feel. Read them back and ask whether someone who had not done the research would understand the experience being depicted.

**Step 6: Share and discuss.** A storyboard that has not been reviewed is not finished. Share it with your team before treating it as a foundation for design decisions. The goal is to surface disagreements about the user scenario early, when they are cheap to resolve.

## Storyboards vs user flows vs journey maps

These three artefacts are often confused. They are not interchangeable.

| | Focus | Level of detail | Best used for |
|---|---|---|---|
| **Storyboard** | Human experience in context | Scenario-level | Aligning on user needs; communicating empathy |
| **User flow** | Steps through an interface | Screen-level | Mapping navigation logic; handoff to engineering |
| **Journey map** | End-to-end experience over time | Service-level | Understanding the full customer lifecycle |

A storyboard is narrower than a journey map — it shows a single scenario in detail rather than the full arc of a customer relationship. It is broader than a user flow — it includes emotional context and real-world factors that a flow diagram does not capture.

In practice, you often use all three at different stages. Storyboarding comes early, when you are still establishing what the experience should be. Once the scenario is agreed, the next step is usually [wireframing](/blog/wireframe-ux-design/) — translating the storyboard's human scenario into interface structure. User flows come alongside or after wireframing, when you are specifying how the interface will work. Journey maps are most useful for complex, multi-touchpoint products where the full service experience needs to be understood before any single scenario is designed.

## When to use storyboards — and when to skip them

Storyboards earn their place when:
- The team has done research but has not yet aligned on the core user scenario
- You are starting a new product or a significant redesign
- Stakeholders are not close to the user research and need a bridge
- You want to communicate the rationale for a design decision in a way that will be understood by non-designers

They are less useful when:
- The user scenario is already well-established and agreed by the team
- You are making incremental changes to an existing product with known users
- You need to move quickly to [wireframes](/blog/wireframe-ux-design/) and the team does not need alignment on the scenario first

Like most UX methods, storyboards scale to the complexity and uncertainty of the problem. On a one-week sprint for a mature product, they may add no value. On a six-month project for an entirely new service in an unfamiliar context, they can prevent months of wasted design work.

## Tools for storyboarding

**Paper and pen** is the right tool for a first draft. The roughness is a feature — it keeps the focus on the scenario rather than the aesthetics, and it signals clearly that the work is exploratory. Most experienced UX designers sketch storyboards by hand even if they will later transfer them to a digital tool.

**Figma** works well for storyboards that need to be shared remotely, included in a presentation, or refined to a higher level of visual clarity. A simple frame-by-frame layout with annotation boxes is straightforward to produce. Figma's real advantage is that it lives in the same tool as your wireframes, so the transition from storyboard to design is frictionless.

**Miro and FigJam** are popular for collaborative storyboarding in workshop settings, where multiple team members are building the storyboard together in real time. The infinite canvas makes it easy to rearrange panels and add annotations without the structure of a formal Figma file getting in the way.

Dedicated storyboarding tools exist but are rarely used in UX practice. Boords, for instance, is designed primarily for film and animation storyboarding, not UX — it is rarely seen in product design teams. The method does not require specialist software — any tool that lets you place images and text in sequence will do the job.

## Storyboarding as a learning exercise

For designers early in their careers, storyboarding is one of the most valuable skills to develop for a reason that goes beyond the artefact itself: it forces you to think from the user's perspective rather than the product's perspective. Drawing someone's experience in sequence — their context, their frustrations, their relief when something works — builds the habit of user-centred thinking that underpins every good design decision.

If you are [switching careers into UX design](/blog/switching-careers-to-ux-design/), storyboarding is the kind of method that tends to resonate immediately because it connects design work to human experience in a visible way. It is also the kind of method that is easy to practise without a job — pick a scenario from your own life, research it (interview a friend, observe what happens), and draw it out. The thinking is what matters, not the drawing.

On the [UX Career Track](/courses/ux-career-track/) at UX Academy, storyboarding is taught as part of the discovery and synthesis phase of a real client project — alongside research methods, personas, and journey mapping — so you build a portfolio of connected artefacts that show a complete design process rather than isolated exercises. If you want to see what live UX training feels like before committing, the [free UX masterclass at UX Academy (myuxacademy.com)](/masterclass/free-ux-ui-masterclass/) is the place to start. Our lead instructor and team have used storyboarding professionally at organisations including Google, Adobe, and Canva. If you want to use these methods under supervision before you have to use them independently in a job, that is the fastest way to build the confidence to do it well. Take a look at our [UX design courses](/courses/) to see what fits your situation.


---

# What Is UX Writing? A Guide to Microcopy

URL: https://myuxacademy.com/blog/ux-writing-guide/
UX writing explained: what it is, what UX writers produce, how it differs from copywriting, and how to break into the role in the UK.

UX writing is the practice of crafting all the text that appears within a digital product -- buttons, error messages, onboarding flows, tooltips, empty states, form labels -- to guide users clearly and reduce friction. It is not about being clever with words. It is about removing every obstacle between a person and the thing they are trying to do.

That definition sounds simple. The execution is not. A single error message, written badly, can lose a customer. A well-written empty state can turn a moment of confusion into a moment of understanding. UX writing operates at the seams of a product, and those seams are often where the experience falls apart.

> **Build the full product design skill set.** UX Academy (myuxacademy.com)'s [Beginner UX (AI) Design course](/courses/beginner-ux-design/) covers UX writing alongside research, wireframing, and prototyping -- taught live by working UX professionals. Cohort 1 starts <CohortDate />. [Reserve your place with a £99 deposit](/courses/beginner-ux-design/). Or [try the free masterclass first](/masterclass/free-ux-ui-masterclass/).

## How is UX writing different from copywriting?

This is the first question most people ask, and it is worth answering directly.

Copywriting aims to persuade. It appears in advertising, landing pages, email campaigns, and social media. The goal is to change someone's mind or prompt an action -- click, sign up, buy. The craft involves emotional appeal, attention-grabbing hooks, and compelling benefit statements. Success is measured in click-through rates and conversions.

UX writing aims to help. It appears inside a product once someone has already decided to use it. The goal is to help them succeed at whatever they came to do. The craft involves clarity, precision, and consistency. Success is measured by task completion rates, error frequency, and how often people have to contact support because something was confusing.

The skills overlap -- both require a strong sense of language, an understanding of the reader's state of mind, and the ability to say something clearly in very few words. But the disciplines are distinct, and treating them as interchangeable is how you end up with product copy that reads like a promotional email when someone is in the middle of trying to delete their account.

## UX writing vs content design -- are they the same thing?

You will see both terms used, sometimes interchangeably. The distinction is real but not always consistently applied.

UX writing is the craft: writing the words. Content design is the broader discipline: shaping how information is structured, sequenced, and presented to meet a user need -- using words, yes, but also considering format, modality, and information architecture.

The term "content design" was popularised by Sarah Richards and the UK Government Digital Service, and it has been widely adopted in the UK public sector and in larger tech organisations. Many roles titled "content designer" in the UK are doing work that is identical to what a "UX writer" does in a US company.

For practical purposes: if a job listing says UX writer or content designer and the work involves in-product copy, the role is substantively the same. The broader content design framing is useful for understanding that the discipline is about problem-solving with language, not just producing words.

## What does a UX writer actually produce?

Understanding UX writing is easier when you look at the specific deliverables.

**Microcopy** is the catch-all term for short functional copy inside a product: button labels, form field labels, placeholder text, checkbox labels. "Submit" is bad microcopy. "Save your preferences" is better. "Continue to checkout" is clearest of all because it tells the user what will happen next.

**Error messages** are where UX writing is most consequential and most often neglected. A good error message tells the user what went wrong, why, and what to do about it. "An error occurred" is useless. "Your card was declined -- check the details or try a different card" is useful.

**Onboarding copy** guides a new user through their first experience of a product. It has to do a lot of work: explain what the product does, show the user what is possible, and get them to a moment of value before they lose patience and close the tab. Onboarding copy is often the highest-stakes writing in the product because the user's initial experience determines whether they come back.

**Empty states** appear when there is no content to show yet -- an inbox with no messages, a dashboard with no data, a contacts list that has not been populated. Most products treat empty states as an afterthought. Good UX writing uses them as an opportunity: explain why it is empty, tell the user what to do to change that, and if appropriate, show them what it will look like once it is full.

**Confirmation and success messages** close the loop after a user completes an action. They reassure users that something worked, set expectations about what happens next, and occasionally create a moment of warmth that makes the product feel less mechanical.

**Tooltips and in-context help** surface information exactly when the user needs it, without requiring them to leave the page or open a help article. Written well, they are invisible -- the user just knows what to do. Written badly, they are either ignored or create more confusion than they resolve.

## The core principles of UX writing

Every credible style guide for UX writing comes back to roughly the same set of principles.

**Clarity over cleverness.** The product is not the place for wordplay. A user who has to re-read a button label to understand what it does is a user who is about to make a mistake or abandon the task. Every word should have a reason to be there.

**Brevity.** Users scan. They do not read. Microcopy that requires more than a few seconds to process will either be ignored or misread. The discipline of UX writing is partly the discipline of cutting: removing every word that is not doing work.

**Consistency.** If "Save" and "Keep changes" and "Confirm" all do the same thing in different parts of the product, users will not know what to expect. A voice and tone guide exists to prevent this. Consistent language also matters for accessibility -- screen reader users and users with cognitive differences rely on predictable language to navigate.

**Voice and tone.** Voice is the consistent character of a product's language -- whether it is warm or formal, playful or serious. Tone is how that voice adapts to context. The same product can have a lighter tone in an empty state and a more careful, direct tone in an error message. Getting this right is what separates copy that feels human from copy that feels generic.

## How do UX writers work with designers and researchers?

UX writing does not happen after the design is finished. That is the most common and most expensive mistake. Copy pasted into a finished design at the last minute is almost always too long for the space, wrong for the context, or misaligned with the interaction.

Good UX writers are involved from early in the process. They sit in on user interviews and research synthesis sessions, because understanding the language users actually use is core to writing copy that resonates. They work in Figma alongside product designers, writing directly into prototypes rather than in a separate document that has to be reconciled later.

The working relationship between a UX writer and a product designer is collaborative. The designer is thinking about layout, hierarchy, and interaction. The UX writer is thinking about what words appear at each point, what the user knows at that moment, and what they need to know to proceed. The two disciplines reinforce each other -- a well-written label can make an ambiguous interaction clear, and a well-structured interaction can make a complicated concept easy to explain.

The relationship with UX research is equally important. UX researchers surface what users find confusing, what language they use themselves, and where copy is contributing to errors or abandonment. That is the input that drives better writing. You can read more about the research methods behind this in [our guide to UX research methods](/blog/ux-research-methods/).

To understand how writing fits into the broader design workflow, it helps to see the [full UX design process](/blog/ux-design-process/).

## Tools UX writers use

Most UX writers spend a significant portion of their time in Figma, the dominant design tool for product teams. Being comfortable in Figma -- not as a designer, but enough to add and edit text layers, annotate copy in context, and follow along in a working file -- is a near-universal expectation for the role. If you are unfamiliar with it, [our guide to UX design tools](/resources/) covers Figma and the wider tool landscape.

Beyond Figma, UX writers typically maintain or contribute to a content style guide: a document that defines the product's voice and tone, preferred terminology, and patterns for common UI copy like error messages and empty states. Some teams keep this in Notion or Confluence; others use dedicated tools like Frontify or Zeroheight.

Content management and localisation become relevant in larger products where copy is pulled from strings files or translated into multiple languages. At that scale, UX writers often work with engineers on content infrastructure as much as with designers on individual screens.

## Is UX writing a separate role or part of UX design?

Honestly: it depends on the company.

At large technology companies -- Google, Spotify, Meta, Monzo, Deliveroo -- UX writing is a distinct discipline with dedicated headcount, career tracks, and senior leadership. These organisations have learned, often the hard way, that copy left to product managers or designers without a writing background produces inconsistent, confusing products at scale.

At medium-sized product companies and startups, UX writing is often absorbed into the product design role. Designers are expected to write their own copy, sometimes with a brief from a marketing team or with review from a content lead. The quality varies considerably.

At smaller companies and agencies, it is common for a single person to cover UX design, UI design, and writing -- particularly in the earlier stages of a product.

For people entering the field, this means that building some writing ability alongside design skills makes you meaningfully more capable, regardless of the job title you are targeting. The [product design vs UX design](/blog/product-design-vs-ux-design/) breakdown covers how these role boundaries vary in practice.

What does a UX designer do day-to-day, and where does writing fit? [Our explainer on the UX designer role](/blog/what-does-a-ux-designer-do/) covers that in detail.

## UX writer salaries in the UK

UX writing roles in the UK typically sit within the broader product design salary band. Based on job board data, a junior or associate UX writer role tends to start in the range of £30,000--£40,000. Mid-level UX writers at established product companies typically earn £45,000--£55,000. Senior and lead roles at larger organisations can reach £65,000 and above.

These are estimates based on general job board signals -- salary varies significantly by location (London premium is real), sector (fintech and large consumer tech pay more), and company stage. The role is in demand in the UK market, particularly as product organisations have recognised that copy quality directly affects conversion, retention, and support costs.

## How to move into UX writing

The most common routes into UX writing are from UX design, from editorial and journalism, and from marketing and content.

What unites all three paths is language ability combined with an understanding of how users behave. You do not need a specific degree. You do need to be able to demonstrate, with case studies, that you can identify a copy problem, understand its root cause, write a better solution, and explain your reasoning.

A UX writing portfolio typically consists of annotated case studies: take a real product (or a fictional one), identify where the copy is failing users, rewrite it, and document the thinking behind each decision. The best portfolios show the before, the after, and the reasoning -- not just attractive mockups.

Studying the fundamentals of UX -- research methods, information architecture, how design decisions are made -- is valuable regardless of the specific role you are targeting. Understanding what UX designers need from a writing collaborator makes you a better one.

## Summary

UX writing is a discipline that sits at the intersection of language, psychology, and product design. Done well, it is largely invisible -- users simply know what to do, things work as expected, and errors are rare and easy to recover from. Done badly, it is the friction that drives users away.

The role is growing in the UK as product organisations invest in the quality of their in-product experience. For designers, building writing skills is a way to become more effective in any role. For people coming from writing backgrounds, UX offers a way to apply language skills to problems that have measurable impact.

If you want to build a solid foundation in UX -- including how writing, research, design, and product thinking fit together -- that is what we teach in UX Academy's [Beginner UX (AI) Design course](/courses/beginner-ux-design/). It is a live, online programme starting <CohortDate />, designed for career-changers who want to enter the field properly. [The free masterclass](/masterclass/free-ux-ui-masterclass/) is a good first step if you are still working out whether UX is the right move.

-- Natalia Veretenyk, Lead Instructor


---

# UX vs UI Design: What's the Difference?

URL: https://myuxacademy.com/blog/ux-vs-ui-design/
UX vs UI design explained clearly: how the two disciplines differ in focus, deliverables, tools, salary and career path -- and which to learn first.

UX design and UI design are two of the most confused terms in digital product work. Job ads blur them together, beginners use them interchangeably, and even experienced designers sometimes struggle to say where one ends and the other begins. They are related, they overlap constantly, and the best digital products need both -- but they are not the same discipline.

**UX design (user experience design) is about how a product works: the structure, flows, and logic that let someone accomplish a goal. UI design (user interface design) is about how it looks and how you interact with its surface: the visual layer of colour, typography, buttons, and components.** Both matter, they constantly inform each other, and most professional roles expect some fluency in both. This guide explains the difference clearly, with a full comparison, so you can decide which direction fits you.

> **Wondering where to start with UX vs UI design?** UX Academy (myuxacademy.com)'s [Beginner UX (AI) Design course](/courses/beginner-ux-design/) covers both UX and UI within a single live programme taught by working professionals. Cohort 1 starts 21 Sep 2026 -- [reserve your place with a £99 deposit](/courses/beginner-ux-design/).
> Or [try the free masterclass first](/masterclass/free-ux-ui-masterclass/).

## What is UX design?

UX stands for user experience. UX design is the practice of making products useful, usable, and satisfying -- concerned with the whole journey a person takes to accomplish a goal, and whether that journey is logical, efficient, and frustration-free.

A UX designer asks: Who is this for? What are they trying to do? Where do they get stuck? Is this flow as simple as it can be? Their work happens largely before a single pixel is polished, and it includes:

- **User research:** interviews, surveys, and usability testing to understand real needs and behaviours
- **Information architecture:** how content and features are organised, labelled, and navigated
- **User flows and journeys:** mapping the steps a person takes to complete a task end to end
- **Wireframing:** low-fidelity layouts that communicate structure and logic, not visual styling
- **Prototyping and testing:** building rough versions to validate design decisions with real users

UX is fundamentally about problem-solving before visual execution. A UX designer might never choose a colour, but they decide what goes on the screen, in what order, and why. To understand how UX work is structured in practice, see our guide to the [UX design process](/blog/ux-design-process/).

## What is UI design?

UI stands for user interface. UI design is the craft of the visual and interactive surface -- everything a user sees and touches when they use a product. If UX decides what the checkout flow should be, UI decides exactly how each button, field, and confirmation message looks and behaves.

A UI designer is responsible for:

- **Visual design:** colour, typography, spacing, layout, and visual hierarchy
- **Interactive elements:** buttons, menus, toggles, form fields, and all their states (default, hover, active, error)
- **Design systems:** reusable components and documented styles that keep a product consistent at scale
- **Microinteractions:** the small animations and feedback cues that make an interface feel responsive and alive
- **Visual accessibility:** ensuring the interface is legible, on-brand, and usable by people with a range of visual needs

UI is where usability meets aesthetics. A beautiful interface that is hard to navigate is a UX failure. A logical flow that looks broken and unpolished is a UI failure. Good products get both right.

## A simple analogy

Think of a house. UX is the architecture and floor plan: where the rooms go, how you move between them, whether the kitchen is near the dining room, whether the layout makes sense for the people who live there. UI is the interior design: the finishes, the colour palette, the fixtures, the way a light switch feels under your thumb.

You can have a beautifully decorated house with a terrible layout, or a sensible floor plan with ugly, awkward finishes. Neither is a good home. The same is true of digital products.

## UX vs UI design: full comparison

| | UX Designer | UI Designer |
|---|---|---|
| **Focus** | How a product works and whether it solves real user needs | How a product looks and feels to interact with at the surface level |
| **Core deliverables** | Research synthesis, user flows, wireframes, usability test reports | High-fidelity mockups, design systems, component libraries, style guides |
| **Tools** | Figma (wireframing), Maze/Useberry (testing), Dovetail (research), Optimal Workshop (IA) | Figma (high-fidelity design + design systems), After Effects (motion) |
| **Key skills** | User research, information architecture, usability testing, structured thinking | Visual design, typography, colour theory, component systems, motion design |
| **Typical salary (UK, 2026)** | Median £55,000 (ITJobsWatch) | Median £50,000 (ITJobsWatch) |
| **Career path** | Junior UX Designer > UX Designer > Senior UX Designer > UX Lead > Head of UX | Junior UI Designer > UI Designer > Senior UI Designer > Design Lead > Head of Design |

In practice the line shifts depending on team size and project phase. In a small startup one person does all of the above. At a larger product company, these are distinct roles with separate reporting lines and career tracks.

## What does a UX designer do that a UI designer does not?

The upstream, strategic work sits firmly with UX. Before any visual decisions are made, a UX designer is responsible for:

- Running user research sessions to understand what people actually need -- not what the brief assumes they need
- Mapping information architecture: how features and content are organised, named, and linked
- Designing task flows end to end, before any visual layer is applied
- Creating wireframes that communicate structure and logic, stripped of styling
- Running usability tests on prototypes and synthesising findings into design decisions that inform the next iteration

A UI designer picks up after the structure is established. They apply the visual layer, build the component system, and ensure the product looks and feels as intended across screen sizes, states, and devices.

This division also explains why UX roles carry slightly more strategic weight in larger organisations -- the decisions made at the UX stage have downstream consequences for everything that follows.

## Which should you learn first: UX or UI?

For career-changers, this is one of the most common questions. The answer is practical rather than theoretical.

**Start with UX if you are coming from a non-visual background.** UX is rooted in thinking, not drawing. You are learning to understand problems, structure information, and make decisions on behalf of users -- skills that transfer directly from almost any previous career. Project management, teaching, research, customer service, finance: all of these build exactly the analytical habits UX design rewards. A solid UX foundation gives you a framework for everything UI-related that follows.

**Start with UI if you already have a visual or graphic design background.** You likely already think in terms of hierarchy, colour, and composition. Learning UX on top of that rounds out your profile and makes you competitive for product design roles. Our post on [UX design vs graphic design](/blog/ux-design-vs-graphic-design/) covers the crossover points in detail.

**Learn both together if you want the broadest opportunities.** Most entry-level roles in the UK advertise for UX/UI Designer or Product Designer, not one or the other in isolation. Courses that separate them can leave a gap at exactly the moment you are trying to get your first role.

The sequencing we recommend: UX foundations first (research, flows, wireframing), then UI fundamentals (visual principles, Figma, design systems), then combined practice on a real project with feedback. That mirrors how the [UX design process](/blog/ux-design-process/) actually works in product teams.

For a full guide to breaking into the field, see [how to become a UX designer](/blog/how-to-become-a-ux-designer/).

## Can one person do both UX and UI?

Yes -- and most designers working in the UK market do exactly that. The "unicorn" label that used to attach to UX/UI generalists was always an exaggeration. Full-stack design work is the norm outside large enterprise product organisations.

What matters is knowing when you are doing UX work versus UI work, so you can allocate the right time to each. A designer who conflates the two tends to rush research in favour of pixels, which produces visually polished products that users do not understand or cannot navigate.

T-shaped skills -- deep in one discipline, capable across the other -- are what most employers are hiring for. A UX designer who can produce professional-looking mockups is far more hireable than one who can only deliver wireframes. A UI designer who understands why a flow is structured the way it is produces far better work than one who simply executes a spec.

## UX vs UI salary in the UK

Salary is one of the most common follow-up questions once people grasp the UX/UI distinction -- and the difference is smaller than many expect.

According to ITJobsWatch 2026 data, the UK median salary for UX Designer roles sits at approximately **£55,000**, and for UI Designer roles at approximately **£50,000**. The gap opens more significantly at the senior end, where strategic UX work (leading research programmes, defining information architecture at product scale) commands a premium over visual execution.

Senior UX roles in the UK -- UX Lead, Principal Designer, Head of UX -- regularly reach £70,000 to £85,000 at larger product companies in fintech and SaaS. For a full breakdown by role level and sector, see our [UX designer salary guide](/blog/ux-designer-salary-uk/).

The clearest salary levers are not actually UX vs UI but:

- **Seniority:** The jump from mid to senior adds £10,000 to £20,000 more reliably than any lateral discipline switch
- **Sector:** Fintech, SaaS, and enterprise software pay meaningfully more than agency, retail, or public sector
- **Business impact:** Designers who connect their work to measurable outcomes -- conversion, retention, task completion -- are paid more at every level

## Tools: what UX and UI designers actually use

The two disciplines share some tools and diverge in emphasis.

**Figma** sits at the centre of both. UX designers use it for wireframing and low-fidelity prototyping. UI designers use it for high-fidelity mockups, interactive prototypes, design systems, and developer handoff. If you are learning design in 2026, Figma is the first tool to learn. Our [what is Figma](/blog/what-is-figma/) guide explains what it does and why it has become the industry standard.

**UX-specific tools** include: Maze or Useberry for unmoderated usability testing, Dovetail or Notion for research synthesis, Optimal Workshop for card sorting and tree testing (information architecture validation), and occasionally specialist survey platforms.

**UI-specific tools** include: After Effects or Principle for motion and microinteraction design, Zeroheight or Storybook for design system documentation, and the Figma Dev Mode for structured developer handoff.

Both disciplines require a foundation of empathy for the user and an eye for what is not working. For a full picture of the UX toolkit, see our guide to [UX design tools](/resources/).

## How UX and UI overlap in practice

In practice the line is rarely clean. Wireframes (a UX deliverable) flow naturally into high-fidelity mockups (a UI deliverable). Usability findings (a UX output) drive visual decisions (a UI output). The two disciplines constantly inform each other throughout a project, and most designers move between them within a single working day.

The typical handover point is a wireframe: UX produces the structure; UI applies the polish. In smaller teams, the same designer does both in sequence -- sometimes within the same afternoon. Understanding both is not just a nice-to-have; it is how the work actually gets done.

## Learn UX and UI together at UX Academy

UX vs UI is not a competition. It is a partnership -- and understanding both is what makes you effective as a designer and competitive in the UK jobs market.

At UX Academy (myuxacademy.com), our live, small-group training covers both UX and UI within a single structured programme, applied to a real project with weekly feedback from working professionals. Cohort 1 starts <CohortDate /> and places are limited.

Our lead instructor at UX Academy has worked with Adobe, Google, and Canva, and brings that industry perspective directly into the teaching. The programme is built around the full design process -- from research to high-fidelity -- because that is what the job actually looks like.

If you want to see what live UX training feels like before committing, the [free UX masterclass at UX Academy (myuxacademy.com)](/masterclass/free-ux-ui-masterclass/) is the place to start.


---

# UX Design Job Boards UK: Where to Find UX Jobs

URL: https://myuxacademy.com/blog/ux-design-job-boards-uk/
The best job boards for UX designers in the UK — general boards, specialist UX platforms, and community routes that often work better than job boards.

Finding UX design jobs in the UK is not simply a matter of picking the right job board and applying — but the boards you use do affect what you see and how early you see it. This guide covers which platforms are worth your time, which are quiet or overly generic, and how to structure your search so you are not missing the roles that do not always make it onto the big aggregators.

The underlying market context matters: the UK UX job market has stabilised after a difficult 2023-2024, but entry-level roles remain competitive and the best opportunities move quickly. For a broader picture of the market — sectors, salary ranges, and what employers want — see our post on [UX design jobs in the UK](/blog/ux-design-jobs-uk/).

> **Building the portfolio that gets you hired?** UX Academy's [Beginner UX (AI) Design course](/courses/beginner-ux-design/) teaches live with working professionals and ends with a real client project for your portfolio. Cohort 1 starts 21 Sep 2026 -- [reserve your place with a £99 deposit](/courses/beginner-ux-design/). Or [try the free masterclass first →](/masterclass/free-ux-ui-masterclass/)

## General UK Job Boards

These are the platforms with the highest volume of UX listings in the UK. They are not UX-specific, but the sheer number of employers posting to them means they are worth running parallel searches on.

**LinkedIn** is the primary channel for UX hiring in the UK. Most recruiters search LinkedIn profiles directly rather than waiting for applications — which means having a well-optimised profile (clear headline, portfolio link, up-to-date skills) generates inbound interest separately from your active applications. Use the Jobs tab with saved searches set to your target titles and locations. Volume is highest for mid-level and senior roles.

**Indeed** carries a broad range of UX listings, including from employers who do not post to specialist boards. Use it for coverage. Set up email alerts with multiple search terms (see the FAQ above) and expect some noise — not all listings labelled UX involve genuine UX work. Read job descriptions carefully before applying.

**Reed** is particularly strong for public sector, NHS, and agency UX roles. It is worth including in any UK job search, especially if you are interested in the public sector or are based outside London.

**Glassdoor** has solid UX listing volume and is useful for its reviews alongside job listings. It will not surface roles that other platforms miss, but company review data makes it a good research tool when you are evaluating whether to apply.

**Totaljobs** aggregates broadly and covers UK regions well. Useful for coverage, especially outside London.

## UX and Design-Specific Job Boards

These boards focus specifically on UX, product design, and creative roles. The signal-to-noise ratio is better, and some list roles that do not appear on general boards.

**UX Gigs** ([uxgigs.co](https://uxgigs.co/)) is the most focused UK-specific option. It curates listings from company career pages and covers UX, UI, and product design roles. Bookmark this.

**Dribbble Jobs** ([dribbble.com/jobs](https://dribbble.com/jobs)) is one of the longest-running design job boards and is actively maintained in 2026. It leans toward visual and product design roles. UK listings are present but mixed with global and US-heavy roles, so filter by location.

**UI/UX Jobs Board** ([uiuxjobsboard.com](https://uiuxjobsboard.com/)) has been active since 2018. Global in scope but includes UK and remote roles. Worth checking weekly if you are also open to remote work.

**Behance Jobs** ([behance.net/joblist](https://www.behance.net/joblist)) still operates and surfaces creative and UX roles from Adobe's network of employers. Listings skew toward agencies and studios. Behance's job board has significantly reduced activity since 2023 — treat it as a secondary option rather than a primary source.

**User Interviews UX Research Job Board** ([userinterviews.com/ux-job-board](https://www.userinterviews.com/ux-job-board)) is specifically strong if you are targeting UX research roles rather than generalist UX design positions. Updated regularly and worth checking if research is your focus.

## UK Design Community Boards

These boards serve the broader UK creative and design industry. Volume is lower than the general boards, but the roles tend to be from employers who care about design quality — studios, agencies, and in-house teams at consumer brands.

**Design Week Jobs** ([jobs.designweek.co.uk](https://jobs.designweek.co.uk/)) is the job board of the UK's main design trade publication. Listings come from studios, agencies, and in-house teams across branding, digital, UX, and product. Employers posting here are design-literate and often recruiting for roles that would not appear on general boards.

**Creative Pool** ([creativepool.com/jobs](https://creativepool.com/jobs)) is a global creative network with strong UK representation. Jobs span graphic design, UX, branding, and advertising. It is also a portfolio platform, so completing your profile gives you some additional discoverability.

**The Dots** ([the-dots.com/jobs](https://the-dots.com/jobs)) is often described as LinkedIn for creatives. It includes UX and product design listings alongside broader creative roles. More networking-oriented than job-board-oriented — the connections you make there can be as useful as the listings themselves.

## The Comparison

| Platform | Best For | UX Specificity | UK Coverage |
|---|---|---|---|
| LinkedIn | High volume, all levels | Moderate | Excellent |
| Indeed | Broad coverage, public sector | Low | Excellent |
| Reed | Agencies, public sector, regional | Low | Very good |
| UX Gigs | UK UX and product design, clean listings | High | UK-focused |
| Dribbble Jobs | Visual and product design | High | Mixed (global) |
| UI/UX Jobs Board | UX and UI roles, remote friendly | High | Good |
| Design Week Jobs | Studios, agencies, in-house design teams | Moderate | UK-focused |
| Creative Pool | Agency and brand design | Moderate | UK and global |
| The Dots | Creative networking + jobs | Moderate | UK-focused |
| Glassdoor | Research + job listings combined | Low | Very good |

## Community and Network Routes

Job boards are not where most junior UX hires come from. This is worth saying plainly, because it changes how you should allocate your time.

Many entry-level and junior roles are filled through community networks before they are formally advertised. Designers refer people they know. A hire comes from a coffee chat that started on Twitter or at a meetup. A portfolio someone saw in a UX community leads to a conversation that leads to a contract.

The UK UX community is not enormous, and it is genuinely connected. Some things worth doing:

**Attend UX events.** UX London and UX Brighton are two of the most established annual UX events in the UK. Local UX meetups (Eventbrite usually surfaces these — search "UX" and your city) are lower stakes and often where junior designers build early relationships. Even attending a handful of events a year meaningfully increases your network.

**Engage on LinkedIn.** Share your process publicly — what you are working on, what you learned from a user research session, how you approached a design problem. Designers who share their thinking get noticed by recruiters and hiring managers who are not actively searching job boards.

**Reach out directly.** Most experienced UX designers will take a short call with someone who is genuinely interested in their company and has done their homework. The ask should not be for a job — it should be curiosity about their work. A meaningful proportion of junior hires originate from conversations like this.

## How to Set Up Effective Job Alerts

Running alerts with a single search term will cause you to miss roles. UX job titles are inconsistent in the UK — the same role might be advertised as "UX Designer", "Product Designer", "UI/UX Designer", or "Interaction Designer" depending on the company. Set up separate alerts for each:

- UX designer
- Product designer
- UX researcher (if research roles interest you)
- UI/UX designer
- Interaction designer

On LinkedIn, save each search and set alert frequency to daily for the first few months of your search. On Indeed, do the same. On UX Gigs, check the site directly two or three times a week since the listings are pulled fresh from company pages.

For agency and start-up roles specifically, following company pages on LinkedIn often surfaces roles before they appear on any board.

## What Your Application Needs

Being on the right job boards does not matter if your application is not competitive. One thing is non-negotiable across all employers and role levels: **a portfolio link that works**.

A surprising number of applications are dismissed because the portfolio link is broken, password-protected without instructions, or leads to a site with no UX case studies. Before you start applying in volume, check your portfolio link in an incognito browser window from a fresh device.

Beyond the link, employers are looking for case studies that show your process — not finished screens. Problem definition, research, synthesis, decisions, and iteration. Two or three strong case studies will outperform a portfolio of eight polished mockups with no context. See our posts on [how to build a UX portfolio from scratch](/blog/how-to-build-a-ux-portfolio-from-scratch/) and [UX design portfolio examples](/blog/ux-design-portfolio-examples/) for the specifics.

When you are preparing for interviews, [UX design interview questions](/blog/ux-design-interview-questions/) covers the questions that come up consistently across UK employers and how to frame your answers.

## Salary Context

If you are using job boards to benchmark salaries, exercise some caution. Posted salary ranges on job boards skew heavily toward London and do not always reflect what employers actually pay. For a more detailed breakdown, see [UX designer salaries in the UK](/blog/ux-designer-salary-uk/).

## Starting the Job Search

If you are at the beginning of a career change into UX, the job board question is secondary to the portfolio question. You will not get traction on any of these platforms without case studies that demonstrate UX thinking, and you will not have those case studies without structured training or self-directed project work. If you are not yet at the portfolio stage, the [free UX masterclass](/masterclass/free-ux-ui-masterclass/) is a useful first step — a live session that shows you what the course experience is like before you commit.

If you are specifically making the switch at 30 or later, [career change to UX design at 30](/blog/career-change-to-ux-design-at-30/) covers the realistic timeline, transferable skills by background, and what to expect from the job market. [Switching careers to UX design](/blog/switching-careers-to-ux-design/) covers how to frame a non-traditional background for employers and what the realistic transition timeline looks like.

If you are looking for training that produces the kind of portfolio employers actually want to see, the [Beginner UX (AI) Design course](/courses/beginner-ux-design/) at UX Academy (myuxacademy.com) is an 8-week live programme taught live by our instructor team of UK UX practitioners — it ends with a real client project you can put directly into your portfolio. The [UX Career Track](/courses/ux-career-track/) extends this with a further four weeks and structured job search support including portfolio critique, mock interviews, and LinkedIn optimisation. Both run with a maximum cohort size of 15 so that feedback is specific rather than generic.

Cohort 1 starts <CohortDate />. Places are reserved with a £99 deposit.


---

# What Is Ideation in Design Thinking? Techniques and Process

URL: https://myuxacademy.com/blog/ideation-in-design-thinking/
Ideation in design thinking is where most UX projects go wrong. Learn what it is, how to run a session, and which techniques actually work in practice.

Most teams think they know how to ideate. They book a meeting room, put sticky notes on a wall, and call whatever comes out of it a brainstorm. Then they pick the idea the most senior person in the room seemed keenest on and start designing. This is not ideation. It is consensus dressed up as creativity.

Ideation -- the structured creative phase of [design thinking](/blog/design-thinking-ux/) -- is where the gap between a mediocre solution and a genuinely good one usually opens up. Rush it or skip it and you will spend the rest of the project executing the wrong idea very efficiently.

> **Want to practise ideation on a real brief?** UX Academy (myuxacademy.com)'s [Beginner UX (AI) Design course](/courses/beginner-ux-design/) runs live ideation sessions with working UX professionals. Cohort 1 starts 21 Sep 2026 -- [reserve your place with a £99 deposit](/courses/beginner-ux-design/).

## What ideation actually is

Ideation is the third stage of design thinking, sitting between Define (agreeing what problem to solve) and Prototype (making your best ideas tangible). Its job is to generate a wide range of possible solutions before any of them are evaluated.

The operative word is "before." Ideation works on a simple principle: diverge first, converge later. You open up the solution space as wide as possible, then narrow it down. Teams that collapse these two steps -- generating and evaluating simultaneously -- consistently produce narrower, less creative output than teams that keep them separate. This is well-established in the research on creative problem-solving -- the evidence consistently favours diverging before converging, generating options before evaluating them.

What ideation is not: a single brainstorming session, a vote on existing ideas, or a space where the loudest person wins. Done well, ideation is disciplined creative work with a clear structure and a deliberate output.

## Where ideation fits in the UX process

If you are mapping this against the [UX design process](/blog/ux-design-process/), ideation follows research and synthesis. You have spent time understanding your users, found patterns in what they told you, and arrived at a well-defined problem statement. Ideation is what you do next.

The sequence matters. Ideation without research produces solutions to problems nobody has. Research without ideation produces insight reports that change nothing. The two phases are co-dependent.

In the design thinking model specifically, the Define stage should hand ideation a sharp problem statement -- often framed as one or more "How Might We" questions. A good problem statement opens creative space without prescribing a solution. "How might we help new users understand the product's value before they commit to signing up?" is generative. "We need to redesign the onboarding flow" is not -- it has already decided the solution.

[User personas](/resources/templates/user-persona/) built during research are an important input here. They stop ideation from becoming abstract. When a team is sketching ideas, asking "would Priya actually do this?" -- where Priya is a persona grounded in real interviews -- keeps solutions anchored to genuine human behaviour rather than designer assumptions.

## Why ideation is not just brainstorming

Brainstorming is one tool. Ideation is the whole workshop.

The reason this distinction matters is that brainstorming has real weaknesses. In a group setting, people anchor to the first idea that gets said. Social pressure suppresses unusual or half-formed ideas. Extroverts dominate. The result tends to be a handful of ideas that cluster around whatever the group already thought before the session started.

Good ideation uses structures that get around these tendencies: silent individual generation before sharing, time pressure that forces quantity over polish, provocative constraints that break familiar patterns. The specific techniques matter less than the underlying principle: protect the generation phase from evaluation until there is enough volume to make comparison meaningful.

The other thing brainstorming misses is the value of individual divergence. Some of the most useful ideas in an ideation session come from one person working quietly for eight minutes, not from group energy. The techniques below mix both.

## What are the best ideation techniques in design thinking?

### How Might We

"How Might We" (HMW) is a question format that turns a problem statement into a creative prompt. "How might we reduce friction in the checkout flow?" invites solutions. "The checkout flow has too many steps" describes a problem without opening space for creative response.

HMW questions are often generated in clusters during synthesis: the team reviews their research themes and turns each one into a generative question. You might end up with ten to fifteen HMW questions from a single research synthesis session. Not all of them will be equally useful, but having a range of angles prevents the ideation from being dominated by the most obvious interpretation of the problem.

### Crazy 8s

Crazy 8s is a time-boxed sketching exercise: eight rough sketches in eight minutes. The brief is to generate eight genuinely different ideas, not eight variations of the same idea.

The time pressure is deliberate. It removes the temptation to polish and forces volume. Most people produce ideas 6, 7, and 8 that they would never have reached without the constraint. It is also an equaliser -- in a room where some people are more comfortable speaking than sketching, Crazy 8s gives everyone the same format.

Sharing happens after the individual generation, with a short explanation of each sketch. The group discusses the ideas, not the quality of the drawings.

### SCAMPER

SCAMPER is a structured checklist for generating variations on an existing idea or product. The letters stand for: Substitute, Combine, Adapt, Modify/Magnify, Put to other uses, Eliminate, Reverse/Rearrange. (borrowed from broader creative problem-solving practice, originally developed by Bob Eberle)

It is most useful when a team has a reasonable starting point but needs to push further. Working through each SCAMPER lens systematically generates modifications that the team would not have thought of in free-form discussion. "What if we eliminated this step entirely?" often surfaces a simplification that was staring the team in the face.

### Worst Possible Idea

This technique inverts the brief: instead of generating good solutions, the team generates deliberately terrible ones. The value is in what those terrible ideas reveal about assumptions.

If the worst possible idea for improving a GP appointment booking system is "remove all confirmation messages," the inversion is obvious: confirmation is critical. But the group now has an explicit reason to explore what confirmation should look and feel like, rather than assuming the current approach is sufficient.

Worst Possible Idea also reduces the anxiety of early-stage idea generation. It is genuinely funny, which relaxes the room, and it shifts the group into a more generative mode before pivoting to serious solutions.

### Design Studio

Design Studio is a structured session format for larger teams or complex problems. It typically runs in three rounds: individual silent sketching, pair or small-group critique, and whole-group convergence.

The structured critique element is what distinguishes it from straightforward sharing. Participants describe what they designed and why, then the group identifies what works and what questions remain -- without evaluating the person. Design Studio is time-intensive but produces more thoroughly stress-tested directions than shorter formats.

## How to run an ideation session

**Before the session:** make sure the problem statement is agreed in advance. Sharing a HMW question or problem statement cold at the start of an ideation session wastes the first twenty minutes on discussion that should have happened during Define. Send it ahead. Brief participants on the format so they are not surprised by Crazy 8s.

**Open with diverge:** start with individual, silent generation -- either Crazy 8s or a quiet HMW response. This sets the norm that ideas are individual outputs first, not group productions. It prevents anchoring.

**Share without judgement:** go around the room and have each person present their sketches or ideas briefly. The facilitator's job is to record ideas visibly (on a shared whiteboard or Miro board) and prevent evaluation. "That won't work because..." is not allowed yet.

**Cluster and build:** once all ideas are visible, look for themes and combinations. Some of the best solutions in ideation sessions are hybrids of two ideas that seemed unrelated. Encourage building on ideas: "Yes, and..." rather than "but."

**Converge:** at the end, the group votes or discusses to identify two or three directions worth prototyping. The output should be a shortlist with enough shared understanding that someone can sketch a [wireframe](/blog/wireframe-ux-design/) from it without needing to reconstruct the decision.

A session that ends with one "chosen" idea has usually converged too early. Two or three directions going into prototyping is the right output -- prototyping quickly will tell you more than any amount of in-room debate.

## Common ideation mistakes

**Evaluating too early.** The most common problem. Someone says "that's interesting but we'd never get sign-off on it" and the idea dies. All evaluation, including feasibility filtering, should happen after generation is complete.

**Only doing it once.** Ideation is not a single event in a project lifecycle. It happens at multiple points: early to generate solution directions, again when prototypes reveal new constraints, again after [usability testing](/blog/usability-testing-guide/) surfaces problems the original solutions did not address. Teams that treat ideation as a one-off phase tend to over-invest in their first ideas and under-respond to what they learn later. Structured formats like [design sprints](/blog/what-is-a-design-sprint/) build in multiple ideation phases by design, which is part of why they tend to produce stronger solutions than unstructured project workflows.

**Ignoring the research.** Ideation that is not grounded in user research produces solutions to problems the team imagined rather than problems users actually have. The personas, themes, and problem statements from synthesis are not optional inputs -- they are the reason the solutions generated in ideation will be relevant to anyone outside the room.

**Using only one technique.** Different people generate ideas in different ways. Some need visual prompts. Some need time pressure. Some need the structure of SCAMPER. Relying on a single format advantages whoever is naturally suited to it and disadvantages everyone else.

**Skipping silent generation.** Group discussion from the start creates anchoring. The first idea said out loud shapes everything that follows. Silent individual generation before sharing is not a nice-to-have; it is the structural element that makes the rest of the session work.

## Ideation as a learnable skill

Ideation feels uncomfortable at first. Most people have spent years in educational and professional settings where half-formed ideas are implicitly penalised. The discipline of generating before evaluating runs counter to that instinct.

The good news is that it is genuinely learnable. Designers who run regular ideation sessions -- and who reflect on what worked and what did not -- get better at it. They learn which techniques unlock the room, how to facilitate without dominating, and how to protect the generation phase when someone tries to skip it.

That is one of the reasons live, supervised practice matters more than self-study in UX education. Reading about Crazy 8s gives you the concept. Actually running one in a structured session -- with feedback from an experienced facilitator who has run it in a professional setting -- gives you the skill.

If you are [switching careers to UX design](/blog/switching-careers-to-ux-design/) and wondering whether this kind of thinking will come naturally to you: it does not need to. It needs to be practised. That is what design education is for.

On UX Academy's [Beginner UX (AI) Design course](/courses/beginner-ux-design/), ideation sessions are part of the live curriculum -- not a section to read through, but a structured workshop you participate in, with a brief grounded in real user research and led by our instructor team, who have run these sessions professionally at Adobe, Google, and Canva. If you want to see what live UX training feels like before committing, the [free UX masterclass at UX Academy (myuxacademy.com)](/masterclass/free-ux-ui-masterclass/) is the place to start. If you are serious about doing this work professionally, learning to ideate well is one of the most transferable skills you can build. [See the course details and reserve your place here](/courses/beginner-ux-design/).


---

# How to Create a User Flow in UX Design: A Step-by-Step Guide

URL: https://myuxacademy.com/blog/how-to-create-a-user-flow/
What a user flow is, the standard symbols, step-by-step creation, and the mistakes that make most flows misleading rather than useful. A practical UX guide.

A user flow is a visual diagram showing the steps a user takes through a product to complete a specific goal — from entry point to successful completion. Most UX designers learn to draw them quickly. A few rectangles, some diamond decision points, arrows connecting them — it looks straightforward on a tutorial diagram. The trouble is that real user flows, the kind that are actually useful to a design team, are substantially harder to produce than a tidy flowchart of the happy path.

This guide is about what makes a user flow genuinely useful: the thinking required before you touch a diagramming tool, the distinctions that matter, and the mistakes that make most flows misleading rather than illuminating.

> **Want to create user flows on a real project?** UX Academy (myuxacademy.com)'s [Beginner UX (AI) Design course](/courses/beginner-ux-design/) teaches user flows and the full UX process live with working professionals. Cohort 1 starts 21 Sep 2026 -- [reserve your place with a £99 deposit](/courses/beginner-ux-design/).

## What a user flow actually is

A user flow is a visual representation of the path a user takes through a product to complete a specific goal. It shows every step, screen, and decision point between where the user starts and where they finish. The goal might be completing a purchase, signing up for an account, booking a call, or resetting a password. The flow maps what happens — and what can go wrong — at every stage.

User flows sit within the broader [UX design process](/blog/ux-design-process/) as a bridge between research and design. They come after you understand your users and their goals, and before you start sketching wireframes. Their purpose is to make alignment explicit: everyone on the team can see the intended experience before a single screen is designed.

What user flows are not is a record of how the system works internally. The logic that runs on a server, the database queries, the API calls — none of that belongs in a user flow. A user flow captures only what the user sees, decides, and does.

## User flows, task flows, and flowcharts — what is the difference?

These three terms are used inconsistently in the industry, which causes confusion. Here is a practical distinction:

| Term | What it shows | Typical use |
|---|---|---|
| Task flow | A single linear path through one task | Analysing a specific interaction |
| User flow | Multiple paths, entry points, decisions, and error states | Mapping the full experience before wireframing |
| Flowchart | Logic or process steps, often system-focused | Engineering, business process documentation |

A task flow assumes one type of user, one entry point, and one outcome. It answers: what are the steps in this task? A user flow is richer: it shows what happens when the user makes different decisions, what error states look like, and how different entry points lead to different paths. A user flow is the more complete and more useful artefact for design purposes.

## What symbols are used in a user flow diagram?

User flows use a small vocabulary of shapes. Different tools use slightly different conventions, but these are the most widely recognised:

- **Rounded rectangle / oval** — start and end points (sometimes shown in a different colour)
- **Rectangle** — a step, screen, or action the user takes
- **Diamond** — a decision point; the user makes a choice, leading to two or more paths
- **Arrow / connector** — shows direction of travel between steps
- **Parallelogram** — occasionally used for data inputs and outputs

The exact shapes matter less than consistency. Define your symbols at the start of a project, add a legend to the diagram, and use the same conventions throughout. A flow where diamonds sometimes mean decisions and sometimes mean screens is not a useful artefact — it is a source of confusion.

## How to create a user flow: step by step

### 1. Define the goal and the user

Before opening a diagramming tool, you need two things clearly in your head: whose flow are you mapping, and what are they trying to achieve?

If you have [user personas](/resources/templates/user-persona/), choose the one most relevant to this flow. A first-time visitor trying to understand your pricing behaves very differently from a returning customer trying to change their billing details. Mixing the two into a single flow produces something that describes nobody accurately.

The goal should be a specific outcome: "user successfully completes the checkout and receives a confirmation email," not "user buys something." The specificity forces you to think about what "complete" actually means.

### 2. List the entry points

Real users do not always arrive at the beginning. They land on product pages from organic search. They follow a link in an email that drops them three steps into a journey. They return to an app mid-task. Your flow needs to reflect this.

List every realistic entry point for this particular goal. Then decide whether to map them all in one diagram or produce separate flows per entry point. For complex products, separate flows per entry point are often cleaner.

### 3. Map the steps and decisions

Work through the journey step by step, adding a rectangle for each screen or action, and a diamond wherever the user faces a meaningful choice. "Meaningful" is doing a lot of work in that sentence — not every micro-interaction needs its own decision diamond. A user flow is a strategic document, not a pixel-by-pixel walkthrough.

The decisions to include are those that create genuinely different paths: logged in or not, payment method selected, error encountered or not, email verified or not. If a choice does not change what happens next, it probably does not need a diamond.

### 4. Add error states and edge cases

This is where most first-attempt flows fall short. The happy path — user does everything correctly, no errors, perfect outcome — is the easy part to draw. The flows that are actually useful show what happens when:

- The user enters invalid information into a form
- The session times out mid-checkout
- A required field is left empty
- The user wants to go back and change a previous step
- A payment fails

Edge cases are not edge cases in practice. Password resets, failed payments, and validation errors happen constantly. If your flow does not show them, the designers building from it will have to make decisions on the spot — and those decisions will be inconsistent.

### 5. Review and simplify

A finished user flow should be readable by a stakeholder who has not been in any of the design conversations. If it requires a five-minute verbal explanation before it makes sense, it is too complex or too poorly structured.

Common simplifications: collapse sub-flows into a labelled box and document them separately, remove steps that are identical across paths, and check whether any diamonds are actually redundant (both paths lead to the same next step anyway).

### 6. Test and iterate

A user flow is a hypothesis. It is your team's best current understanding of how users will move through the product. That understanding should be updated as you learn more.

Once you have wireframes built from the flow, run [usability testing](/blog/usability-testing-guide/) to see whether real users actually follow the paths you mapped. They often do not — and the divergences are the most useful information you will gather. Update the flow to reflect what you learn.

## Common user flow mistakes

**Mapping only the happy path.** The most common error. A flow that shows nothing going wrong is not a complete flow — it is an optimistic sketch. Error states and alternative paths are where design decisions have the most impact on user experience.

**Too many paths in one diagram.** The opposite problem: a flow so dense with branches that it cannot be read without a magnifying glass. If your flow has more than two or three levels of branching, consider splitting it into multiple focused diagrams.

**Confusing user actions with system actions.** A flow should show what the user does and sees, not what the backend does in response. "Database updates user record" is a system action; it does not belong in a user flow unless it produces something visible to the user.

**Starting too detailed too early.** It is tempting to jump into a diagramming tool and start adding every micro-interaction from the beginning. The more useful approach is to sketch the broad structure first — on paper if necessary — and add detail only once the overall shape is agreed.

**Skipping the flow entirely.** Perhaps most common of all: jumping straight from research to wireframes without ever mapping the journey. The result is screens that look reasonable in isolation but do not connect logically. [Wireframes](/blog/wireframe-ux-design/) built without a user flow often expose structural problems too late, when fixes are expensive.

## Tools for creating user flows

You do not need specialist software to create a useful user flow. The right tool is whichever one your team will actually use and share.

**Paper and pen** is genuinely underrated for early-stage flows. Speed matters when you are still figuring out the structure, and paper forces you to simplify.

**[Figma](/blog/what-is-figma/)** — specifically FigJam, Figma's whiteboarding tool — has built-in flow shapes and connectors that snap together automatically. If your team already uses Figma for design, keeping flows there means everything lives in one place.

**Miro** and **Whimsical** both have dedicated flowchart templates and are well-suited to collaborative sessions where multiple team members are building the flow at the same time.

**Lucidchart** and **draw.io** are more traditional diagramming tools that work well for complex flows with many branches.

The choice of tool has no bearing on the quality of the thinking. A mediocre flow in Figma is no better than a mediocre flow on a sticky note. The discipline of working through entry points, decision points, error states, and edge cases is what produces a useful artefact — not the tool.

## Where user flows sit in the design process

User flows connect naturally to several adjacent UX skills. They sit after [information architecture](/blog/information-architecture-ux-design/) work — once you have decided how to organise the content, you can map how users will move through it. They inform [wireframes](/blog/wireframe-ux-design/), which translate the flow into actual screen layouts. And they are testable: you can walk participants through a flow in a research session before any screens exist, to check whether the overall journey makes sense.

They are also an underused alignment tool. A well-constructed user flow, shared with engineering and product stakeholders early, surfaces disagreements about scope and logic before they become expensive design changes. The conversation "wait, what happens if the user is not logged in at this point?" is much cheaper to have over a diagram than over a half-built prototype.

User flows are not glamorous work. They are rarely shown in portfolios, and they do not photograph well for social media. But the ability to think clearly about how users move through a product — including when things go wrong — is one of the most practically useful skills a UX designer can develop.

If you are [switching into UX design](/blog/switching-careers-to-ux-design/) from another field, building this skill early will save you significant rework later. Understanding how to map a journey before designing screens is the kind of thinking that separates designers who build things that work from designers who build things that look good.

If you want to see what live UX training feels like before committing, the [free UX masterclass at UX Academy (myuxacademy.com)](/masterclass/free-ux-ui-masterclass/) is the place to start. For a structured introduction to user flows and the full UX process — with live feedback on real work — the [Beginner UX (AI) Design course](/courses/beginner-ux-design/) at UX Academy (myuxacademy.com) covers exactly this, taught live by our instructor team. Cohort 1 starts <CohortDate />.


---

# How to Give and Receive Design Critique in UX

URL: https://myuxacademy.com/blog/design-critique-ux/
What a design critique is, how to structure one, and how to give feedback that references user goals rather than personal preference. A practical guide.

Design critique is one of the highest-leverage skills in UX -- and one of the most poorly taught. Most designers learn to give feedback by osmosis, absorbing the habits of whoever ran the crits they sat in on. If those habits were good, they got lucky. Most were not.

This post explains what a design critique actually is, how to structure one, and how to give feedback that improves the work rather than just filling the room with opinions.

> **UX Academy (myuxacademy.com)'s [Advanced UX Design course](/courses/advanced-ux-design/)** includes live weekly critique sessions where you give and receive structured feedback on real design work. Or join a free [UX Design Masterclass](/masterclass/free-ux-ui-masterclass/) to see the approach in practice.

---

## What is a design critique -- and what it is not

A **design critique** is a structured conversation about how effectively a design solves a user problem.

That definition has two important parts. "Structured" means it follows a deliberate process -- it is not a free-for-all. "Solves a user problem" means the evaluation is anchored to user goals, not to aesthetic preference or internal opinion.

Critiques are often confused with two other things:

**A design review** checks whether the work is complete and meets agreed requirements. It is a quality gate -- essentially a pass/fail check against a spec. Reviews are useful, but they do not evaluate whether the design does the right thing; only whether it does what was specified.

**Informal feedback** is reactive and unstructured. "This looks busy" or "I'm not sure about that colour" are informal observations -- they may contain a useful signal, but they are not critique. Informal feedback tends to reflect the reviewer's taste rather than the user's experience, and it rarely generates anything actionable.

A critique sits between research and final delivery in the [UX design process](/blog/ux-design-process/). It is most useful after an initial round of design but before polish -- when there is still room to change direction.

---

## How to structure a design critique session

A well-run critique follows a simple sequence. The designer leads; the reviewers respond.

### 1. Present the context

Before anyone looks at the design, the designer should frame it: What problem does this solve? Who is the user? What constraints shaped the decisions? What specific questions do you want the critique to address?

Skipping context is the most common mistake in critique sessions. Without it, reviewers default to personal preference -- because they have nothing else to anchor their feedback to. Context gives reviewers a frame of reference: does this design serve that user in that situation?

### 2. Share the work

Walk through the design without pre-emptively justifying every decision. Present it as it would be encountered -- ideally with a prototype or flow, not a static screen with no context. Explain what you were trying to achieve at each stage, but resist the urge to defend choices before anyone has said anything.

### 3. Gather feedback

Give reviewers time to look and form observations before speaking. Ask open questions: "What is clear?" "What is confusing?" "Where do you think a user would get stuck?" Start with observations -- what people notice -- before moving to interpretations -- what those observations mean.

### 4. Discuss

This is where critique becomes genuinely generative. Once observations are on the table, explore the design decisions behind them. Why was that choice made? What alternatives were considered? What would change if the user goal shifted? Good critique is a conversation, not a verdict.

### 5. Close with clarity

The designer should leave with a clear sense of which feedback they will act on and why. Not every piece of feedback warrants a change -- but every piece should be heard. A brief summary at the end ("I'm going to revisit the navigation, hold the colour change, and test the CTA wording") signals that the session produced actionable output.

---

## How to give feedback that's actually useful

The most common failure mode in critique is feedback that expresses preference without evidence: "I don't like the layout," "It feels off," "Make it cleaner." This kind of feedback is not useful -- it tells the designer nothing about what to change or why.

Useful feedback has three parts:

**1. An observation** -- what you noticed in the design, described objectively.
**2. A user implication** -- why that observation might matter for the user experience.
**3. An alternative** -- not a prescribed fix, but an avenue to explore.

A practical structure: *"I noticed [observation]. This might cause [user problem]. What if [alternative]?"*

For example: "I noticed there are four calls to action on this screen. That might cause decision paralysis for a first-time user who is not sure what to do next. What if the primary action was more visually distinct?"

This is more useful than "there's too much going on" because it is specific, grounded in user experience, and opens a direction rather than demanding a particular solution.

---

## The IDEO method: I Like / I Wish / What If

One of the most widely used frameworks for giving structured critique is the **I Like / I Wish / What If** method, developed at IDEO and the d.school at Stanford.

- **I Like** identifies what is working and why -- specific, not generic praise.
- **I Wish** surfaces a problem or friction point -- again, specific and user-centred.
- **What If** opens an alternative possibility -- not a prescription, but an invitation to explore.

The value of this structure is that it starts from what works before moving to what does not, which keeps the conversation generative rather than purely critical. It also separates observation (I Like, I Wish) from possibility (What If), which prevents critique from collapsing into a list of demands.

When using this method, the same rule applies: ground each statement in user goals, not personal taste. "I like the contrast on the CTA because it will be easier for users to identify the next step" is useful. "I like the blue" is not.

---

## How to receive a critique

Receiving critique is a skill that takes practice -- and it is harder than giving it, because the work is yours.

A few principles:

**Listen without interrupting.** The instinct to explain or defend while someone is still speaking is natural but counterproductive. Let the observation land before you respond.

**Take notes, not offence.** Writing down feedback as it is given serves two purposes: it signals that you are taking the critique seriously, and it gives you something to review later when the immediate emotional reaction has settled.

**Ask clarifying questions, not rhetorical ones.** "Can you say more about what you noticed?" is useful. "But didn't you notice that I already addressed that with the tooltip?" is not.

**Remember you are not obliged to agree.** A critique is not a vote. You can hear feedback, understand it, and decide not to act on it -- as long as you can explain your reasoning. The critique improves your decision-making; it does not make the decisions for you.

---

## Common mistakes that undermine critique sessions

**Defensive designers.** When the person presenting spends most of the session explaining why their decisions were correct, the critique stops being a learning exercise and becomes a negotiation. If you find yourself defending before others have finished speaking, pause.

**Feedback without context.** Reviewers who have not understood the problem the design is solving cannot give useful feedback. If context was not presented, ask for it before commenting.

**"I like / I don't like" without rationale.** Taste-based feedback is the default when reviewers do not have a framework. If you find yourself in a session producing this kind of feedback, redirect: "Can we look at this from the user's perspective? What would they notice first?"

**No clear close.** Sessions that end without the designer naming what they will do with the feedback tend to produce work that does not change. Build the close into the structure.

**Treating critique as approval-seeking.** Some designers present work in critique hoping for validation rather than challenge. This misses the point. A critique that only confirms what you already believe is a waste of everyone's time.

---

## How critique develops in practice

Critique is a skill that improves with repetition -- but only if the repetition is structured. Reading about feedback frameworks helps; applying them in real sessions, with real work, under light pressure, is what builds the habit.

At UX Academy, students give and receive live design critique every week throughout the [Advanced UX Design course](/courses/advanced-ux-design/). The critique sessions are built into the curriculum deliberately -- not as a bonus activity, but as a core part of how the design skills develop. By the end of the course, structured feedback is no longer something students have to think about; it is how they look at design.

This matters because when you enter a professional environment, critique is already happening -- in design reviews, in Slack threads, in stakeholder presentations. Arriving with the habit already formed means you can contribute usefully from day one, rather than spending your first few months learning to take feedback without flinching.

---

## Critique in context: the broader design process

Design critique sits alongside [usability testing](/blog/usability-testing-guide/) as one of two primary ways to evaluate a design before it ships. Usability testing answers "can users complete this task?" -- it surfaces problems through observed behaviour. Critique answers "does this design reflect sound thinking?" -- it surfaces problems through structured reasoning.

Neither replaces the other. [Wireframes](/blog/wireframe-ux-design/) and early prototypes benefit from critique before they are polished enough to test usably. Later-stage designs benefit from both. And [ideation](/blog/ideation-in-design-thinking/) sessions that produce multiple directions can use critique to evaluate which direction is most worth developing.

The designers who progress fastest are usually the ones who are good in a room -- who can present their thinking clearly, hear feedback without getting defensive, and give feedback that moves the work forward. Critique is how that skill is built.

---

If you want to develop this skill in a live environment with weekly practice, our lead instructor Natalia Veretenyk leads the [Advanced UX Design course](/courses/advanced-ux-design/) at UX Academy -- join the next cohort or start with a free [UX Design Masterclass](/masterclass/free-ux-ui-masterclass/) to see the approach firsthand.


---

# Customer Journey Map Template: How to Create One That Works

URL: https://myuxacademy.com/blog/customer-journey-map-template/
The standard components of a customer journey map, a ready-to-use template structure, step-by-step process, and the mistakes that make most maps useless.

Customer journey maps are one of the most widely used artefacts in UX design. They are also one of the most widely misused. Walk into a product team and there is a reasonable chance you will find a journey map pinned to a wall or buried in a Confluence page -- a polished grid of stages, touchpoints, and emoji emotion curves that nobody has looked at since it was presented six months ago.

That kind of journey map is a decoration. This guide is about the other kind: a living, research-grounded tool that helps teams identify where the experience breaks down and where the real opportunities are.

> **Want to create journey maps on a real project?** UX Academy (myuxacademy.com)'s [Beginner UX (AI) Design course](/courses/beginner-ux-design/) teaches journey mapping and the full UX process live with working professionals. Cohort 1 starts 21 Sep 2026 -- [reserve your place with a £99 deposit](/courses/beginner-ux-design/).

## What a Customer Journey Map Actually Is

A customer journey map is a visualisation of the end-to-end experience a person has with a product or service -- not just the screens inside an app, but the whole arc from first awareness through to long-term use or abandonment.

The key word is *end-to-end*. This is what separates journey maps from user flows and screen-level documentation. A journey map is interested in the context surrounding product use: how someone first heard about you, what they were thinking when they decided to try you, what happened in the moments between digital touchpoints, and how they felt after the experience ended. It covers offline moments, emotional states, and the decisions that happen away from your interface.

That broader scope is what makes journey maps valuable for [understanding what UX design is really about](/blog/what-is-ux-design/) -- designing experiences, not just interfaces. It is also what makes them hard to do well. The breadth means you cannot create a credible journey map from assumption alone. It has to be grounded in [user research](/blog/ux-research-methods/).

## The Standard Components of a Journey Map

Every journey map has its own format, but the core components are consistent. Understanding what each layer is for helps you build one that is actually useful.

| Component | What it captures | Why it matters |
|---|---|---|
| **Persona** | Who the map is built for | Anchors the map to a specific user type; prevents generic, everyone-means-no-one maps |
| **Scenario** | The goal the user is trying to achieve and the context they are in | Defines scope; a single map = a single persona + a single goal |
| **Stages** | The major phases of the experience (e.g. Awareness, Consideration, Decision, Onboarding, Ongoing Use) | Provides structure; typically 4--7 stages depending on scope |
| **Actions** | What the user does at each stage | The behavioural layer; grounded in observation, not assumption |
| **Touchpoints** | Where they interact with the product, brand, or service | Reveals channel gaps and moments of friction |
| **Thoughts** | What the user is thinking or assuming | Exposes mental models, misconceptions, and unmet expectations |
| **Emotions** | How they feel at each stage (often shown as a curve) | Highlights emotional peaks and troughs; the low points are usually the biggest opportunities |
| **Pain points** | Where things break down or create unnecessary friction | The diagnosis layer; what is causing the low emotional moments |
| **Opportunities** | Where the team could improve the experience | The output layer; what to act on |

This is the template structure. The goal is not to fill in every cell with polished content -- it is to surface honest, research-backed answers to each layer so that the map reflects what actually happens, not what you hope happens.

Stage names are domain-dependent — "Purchase" might become "Referral", "Enrolment", or "Renewal" depending on your context.

## How to Create a Customer Journey Map (Step by Step)

### 1. Define the scope

Before doing anything else, agree on which persona and which scenario the map will cover. A map that tries to cover all users and all journeys covers nothing. One persona, one goal, one scenario. If you are mapping how a career-changer discovers and enrols in a UX design course, that is your scope. You are not also mapping how an existing professional takes a short course at the same time.

If you have not yet built your personas, read [user persona template](/resources/templates/user-persona/) first. Journey maps sit one level above personas -- they use the persona as a lens to interpret the journey. Without a grounded persona, the journey map will drift back to the generic.

### 2. Conduct the research

This is the step most teams skip, and it is why most journey maps fail.

The research phase typically combines:

- **User interviews** -- one-to-one conversations that surface goals, behaviours, mental models, and the moments where things go wrong. Aim for five to eight participants per persona segment. This is your primary source.
- **Contextual inquiry** -- observing users in the environment where the experience actually happens, rather than asking them to recall it in a meeting room. Especially valuable for journey stages that happen offline or across channels.
- **Diary studies** -- participants log their experience in real time over a period of days or weeks. Useful when the journey unfolds slowly (such as evaluating and choosing a course or service).
- **Analytics review** -- where users drop off, which touchpoints generate friction, which paths people actually take versus the ones you designed for.

The [UX research methods guide](/blog/ux-research-methods/) covers the full toolkit. The point here is simple: research feeds the map. If you build the map before the research, you are documenting assumptions, not experience.

### 3. Synthesise the findings

Once you have your research data, the [synthesis stage](/blog/ux-design-process/) is where patterns emerge. Group observations by journey stage. Look for repeated pain points, unexpected behaviours, moments of high frustration or delight, and gaps between what users expect and what they get.

Affinity mapping is a useful technique here -- clustering raw observations until themes become visible. The themes become the content of your journey map rows.

### 4. Build the map

With your synthesis in hand, populate the template. Work through each stage and ask: what is the user doing here? What touchpoints are they using? What are they thinking? How are they feeling? Where does it break down?

Plot the emotional curve as you go. The points where it dips sharply are usually the most important -- they are where the experience is losing people, and where the opportunities are largest.

At this stage, resist the urge to smooth the map into something that looks good. Honest maps are messy maps. A journey that shows consistent medium-positive emotions across every stage is almost certainly not telling the truth.

### 5. Validate and share

Take the draft map back to users -- through [usability testing](/blog/usability-testing-guide/), additional interviews, or a review session -- to check whether it reflects what they actually experience. Then share it with your team: engineering, product, customer success, whoever owns the touchpoints you have mapped. Journey maps are most valuable when the people who can act on them have seen and understood them.

### 6. Update it

A journey map is not a deliverable. It is a working document. When research reveals that a stage looks different from what you mapped, update the map. When a new product feature changes a touchpoint, update the map. A journey map that is six months old and has never been touched is a snapshot of past assumptions, not a useful design tool.

## Journey Maps vs User Flows vs Service Blueprints

These three artefacts are frequently confused. They are related but distinct.

**A [user flow](/blog/how-to-create-a-user-flow/)** documents the sequence of steps a user takes inside a digital product to complete a specific task. It is granular, linear, and interface-focused. It asks: what happens between screen A and screen B? It does not ask how the user felt, or what they were doing before they opened the app.

**A customer journey map** is broader. It covers the full arc of experience -- before, during, and after product use -- including emotional state, cross-channel context, and offline moments. It asks: what is the whole experience like for this person trying to achieve this goal?

**A service blueprint** is broader still. It maps the journey from the user's perspective and then adds the internal organisational layer underneath -- the backstage processes, systems, and staff actions that produce each front-stage touchpoint. It is most useful for service design work where the experience depends on organisational operations that users never see directly.

**A [storyboard](/blog/what-is-a-storyboard-ux-design/)** is a related but distinct tool: it narrates a scenario frame by frame, usually to communicate context and emotion to stakeholders rather than to document interaction logic. Journey maps and storyboards are complementary — the map gives you the emotional arc across the full journey; the storyboard brings a specific moment within it to life.

For most UX projects, start with the journey map. Add a service blueprint when internal processes are causing front-stage friction you need to redesign.

## Common Journey Map Mistakes

**Building it without research.** The most common and most damaging mistake. A journey map built in a workshop from team assumptions is a visualisation of your collective biases. It will be wrong in ways you cannot detect because you have no data to check it against.

**Making it too product-centric.** If every stage and touchpoint in your journey map lives inside your app, you have built a user flow and called it a journey map. Real journeys extend far beyond the product. The moments before someone opens the app and after they close it are often where the most important design opportunities sit.

**Ignoring the emotional layer.** A journey map that captures only actions and touchpoints misses the most actionable information. Emotions are where you find the moments that make people leave, or that make them recommend you to a colleague. Plot the emotional curve. Take the dips seriously.

**Treating it as a deliverable, not a tool.** A journey map that gets presented once and then filed away has added no value to the design process. The map earns its existence by being visible in sprint planning, referenced in design critiques, and updated when understanding changes.

**Mapping too broad a scope.** A journey map that covers all users from first awareness through to churn and re-acquisition is trying to do too much. It will be accurate about nothing. Narrow the scope: one persona, one scenario, one goal.

## Tools for Journey Mapping

**Miro** is the most widely used collaborative whiteboarding tool for journey mapping. Its real-time collaboration and template library make it straightforward for cross-functional teams to build and iterate on maps together.

**FigJam** is the natural choice for teams already working in Figma. Journey maps can sit alongside wireframes and prototypes in the same project, which makes them easier to keep updated as design work evolves.

**UXPressia** is purpose-built for journey mapping and includes features specifically designed for emotional arc visualisation and multi-persona comparisons. Useful when journey mapping is a regular practice rather than a one-off project activity.

**Spreadsheets** (Google Sheets or Excel) are underrated. The format matters less than the research. A well-structured spreadsheet with honest, research-grounded content is more useful than a beautiful Miro board built on assumptions.

**Figma** works for teams who want the map to live inside their design system, particularly if it needs to be presented to stakeholders in a polished format.

For practical experience building journey maps alongside the other core tools of UX -- from [user research](/blog/ux-research-methods/) through synthesis, ideation, and testing -- the [UX Strategy course](/courses/ux-strategy/) covers the strategic layer, while the [Beginner UX (AI) Design course](/courses/beginner-ux-design/) takes you through the full process hands-on, with live feedback from our lead instructor, Natalia Veretenyk, on the work you produce.

---

Journey maps are not complicated. What makes them hard is the discipline they require: the discipline to do the research before building the map, to keep the scope narrow enough to be honest, and to update the map when your understanding changes. Most teams skip one or all three of those things. The teams that do not end up with an artefact that genuinely shapes decisions -- which is the only reason to make one in the first place.

If you want to see what live UX training feels like before committing, the [free UX masterclass at UX Academy (myuxacademy.com)](/masterclass/free-ux-ui-masterclass/) is the place to start. If you are [switching careers to UX design](/blog/switching-careers-to-ux-design/), journey mapping is one of the first tools you will learn and one of the ones you will use most consistently throughout your career. Learning it properly -- with real research to back it and real feedback on your output -- is worth doing once and doing well.


---

# Career Change to UX Design at 30: What You Need to Know

URL: https://myuxacademy.com/blog/career-change-to-ux-design-at-30/
Career change to UX design at 30? This guide covers the real advantages of switching later, transferable skills by background, and a realistic timeline.

If you are in your thirties and wondering whether it is too late to switch into UX design, the honest answer is: no, it is not. But the more useful question is what switching actually involves at this stage of your life - what you bring, what you lack, and what the realistic path looks like. This guide gives you the unvarnished version.

> **Thinking about switching to UX?** UX Academy (myuxacademy.com)'s [free UX masterclass](/masterclass/free-ux-ui-masterclass/) is the lowest-risk way to see if it is right for you — a live session with no commitment. Or if you are ready: [reserve a place on the Beginner UX (AI) Design course](/courses/beginner-ux-design/) (£99 deposit, Cohort 1: 21 Sep 2026).

## The age question, answered directly

UX design is a young field. The majority of working UX designers did not study it at university - most retrained from something else, many of them in their thirties or later. When you walk into a UX team, you are likely to find former teachers, nurses, marketers, engineers, lawyers, and project managers. The idea that you needed to start at 21 to be taken seriously does not hold up against the reality of who is actually doing this work.

The anxiety around age is real, though. Thirty can feel like a deadline, especially if you have spent the last decade building credentials in a different direction. It is worth naming that directly: you are not imagining the pressure, but you are probably misreading what it means. The UX industry is not looking for youth - it is looking for people who can think clearly about users, communicate well, and produce work that demonstrates both. Those things do not have an age ceiling.

That said, this guide will not tell you it is simple or that your age is purely an advantage. There are genuine challenges to making this switch in your thirties. Acknowledging them is what makes preparation useful.

## Why life experience is a genuine advantage - not just reassurance

The instinct to frame this as a positive is correct, but it needs to be specific rather than vague. Saying 'life experience helps' means nothing unless you can point to what, exactly, transfers.

**Empathy that comes from real professional context.** A former nurse understands the cognitive load on a healthcare worker trying to use a badly designed electronic patient record system in a way that a recent graduate simply cannot. A customer service manager knows - in detail - the friction points users encounter and the gap between what a product claims to do and what users actually experience. This is not soft; it is directly useful in user research and in making design arguments to stakeholders.

**Stakeholder communication.** Junior UX designers often struggle to present their work persuasively to people who do not think in design terms. If you have spent years in a professional environment navigating competing priorities, presenting to management, or advocating for decisions under pressure, you already have a significant head start here.

**Domain expertise.** If you are switching into UX from finance, healthcare, education, or retail, you bring domain knowledge that is commercially valuable. A UX designer with genuine expertise in financial services or NHS systems can walk straight into specialist roles that younger candidates without that background cannot credibly target. This is a real competitive advantage, not a consolation prize.

**Maturity in process.** People in their thirties tend to be better at the parts of UX work that do not get glamorised: project management, documentation, running a user research session professionally, writing a clear brief. These things matter in practice, even when they do not appear in job adverts.

## What you are genuinely up against

It would be dishonest to stop at the advantages without the other side of the picture.

**You are starting from zero on portfolio.** This is the real challenge. Employers hire UX designers based on case studies - evidence of how you think, how you research, and how you design. When you are switching careers, you do not have any of that yet. Building a credible portfolio from scratch takes time, deliberate effort, and the right structure. It does not happen by watching tutorials.

**You may be competing with younger candidates for the same entry roles.** They may have more design-specific coursework or internship experience. Your transferable skills and domain knowledge offset this, but they do not erase it. You need to compensate with portfolio quality and interview preparation.

**The first role is the hardest.** This is true for almost all career changers regardless of age. Once you have 12 to 24 months of paid UX experience, everything becomes significantly easier - subsequent moves are based on that track record. Getting to that first role is where the real work is concentrated.

**Ageism exists in tech.** Ageism exists in parts of the tech sector and is not limited to workers over 40 — it is worth being aware of, but it is not a reason to rule out a career change at 30. UX is better than many tech disciplines in this respect - design teams tend to value experience - but it would be misleading to say it is not a factor anywhere. Being aware of it is more useful than either ignoring it or catastrophising.

## Transferable skills by previous career

Different backgrounds transfer differently. Here is what is most likely to be useful, and how to position it.

**Teaching or training.** You already run structured sessions, adapt to different learning styles, and translate complexity into clarity. These map directly onto facilitation skills (user research, workshops, stakeholder sessions) and the ability to communicate design rationale. Frame your experience around the moments you identified a gap in understanding and redesigned how something was taught.

**Healthcare.** Deep empathy, comfort with high-stakes user needs, and domain knowledge in a sector where UX is genuinely underdeveloped. NHS digital transformation is a growing area; private health technology companies actively look for designers with clinical backgrounds. Position your clinical experience as domain expertise, not just soft skill.

**Marketing.** You understand audience thinking, user journeys (even if you called them something else), and the relationship between copy, design, and conversion. Analytics, A/B testing, and customer research all appear in marketing careers in forms that are directly relevant. The bridge to UX is shorter than most marketing professionals realise.

**Finance.** The combination of analytical rigour and domain knowledge makes you a strong candidate for fintech and financial services UX roles. Organisations designing complex financial products need designers who understand the underlying concepts. Your background removes a learning curve that competitors face.

**Customer service or operations.** You have spent years listening to what users actually say and what they actually do - which is the core of user research. The translation work is less about new skills and more about learning to document and present those insights in a structured way.

**Software development or IT.** You already understand technical constraints and can communicate fluently with engineering teams, which is a persistent pain point in product teams with junior UX designers. Your ability to evaluate feasibility in real time is commercially valuable. The shift to UX is typically more about broadening from 'what can we build?' to 'what should we build, and for whom?'

## The realistic timeline

Many career changers who approach this seriously land their first UX role within **six to twelve months** of starting structured training, though the timeline varies significantly depending on how much time you can commit. That range is real, not a hedge.

Six months is achievable if you can dedicate significant time - either through a structured programme that compresses the learning curve, or through a full-time self-directed effort that produces portfolio-ready work quickly. It requires treating the job search as a second job from roughly month four onwards.

Twelve months is more common for people who are fitting training around existing employment. Part-time learning is slower, but it is also more financially sustainable. Many of our students at UX Academy train in evenings and weekends while staying in their current role until they have something credible to show.

Beyond twelve months, the constraint is usually portfolio quality or job search effort, not the training itself. If you have completed a structured programme and are not making progress at the twelve-month mark, the answer is almost always to revisit and strengthen the portfolio case studies rather than to do more courses.

For a deeper look at the overall career path, the guide to [how to become a UX designer](/blog/how-to-become-a-ux-designer/) covers the full journey from first principles.

## What the job market actually wants from you

The single most important thing to understand is that **employers are not hiring you based on your certificate or your course**. They are hiring based on what your portfolio demonstrates.

That means: case studies that show your process. Not just finished screens. The brief you started from, the research you did, what you found, how it changed your thinking, what you designed, and what you tested. Two or three thorough case studies built this way will outperform a portfolio of ten polished screens with no process behind them.

Career changers often have an advantage here that they underuse: you can build portfolio projects around domains you already understand. A former nurse who redesigns a patient-facing NHS booking system is bringing credibility to that project that a design graduate cannot match. Use your background. Do not try to hide it behind generic 'redesign a popular app' briefs.

The [UX design portfolio guide](/blog/ux-design-portfolio-guide/) covers what strong case studies look like in detail. The [UX design interview questions](/blog/ux-design-interview-questions/) guide covers how to present them once you get in the room.

## Part-time vs full-time training: who should do which

**Go part-time if:** you have financial commitments that require your current income, you can genuinely sustain the discipline of evening and weekend study over six to twelve months, and you have a job that is not so exhausting that you arrive at an evening session unable to absorb anything.

**Go full-time or intensive if:** you have savings or a partner's income to draw on for three to six months, you want to move quickly, or you have found that self-paced learning tends to stall for you without external accountability.

The honest practical difference: part-time training stretches the learning across a longer period but allows you to stay financially stable. Full-time training compresses it but requires a financial bridge. Neither is inherently superior - the right choice is the one you can actually sustain.

For a broader look at the training options available, the post on [are UX bootcamps worth it](/blog/are-ux-bootcamps-worth-it/) covers what to look for and what to avoid. And if you are questioning whether the career itself is the right destination, [is UX design a good career](/blog/is-ux-design-a-good-career/) addresses that directly.

## Salary expectations: what to plan for

Your first UX role in the UK will likely pay between £28,000 and £38,000. London roles skew higher; roles outside the capital are typically lower. This may be less than you are currently earning if you are mid-career in your previous field.

Plan for that honestly. It is a temporary position. The UX salary trajectory is steep once you have verifiable experience: mid-level roles typically pay £45,000 to £65,000, and senior roles exceed that. The full picture is in the [UX designer salary UK](/blog/ux-designer-salary-uk/) guide, which covers entry, mid, and senior levels with current data.

## Getting started

A career change at 30 is not a gamble - it is a calculated decision that tens of thousands of people make successfully every year. The field genuinely values what you bring. The process is learnable. The portfolio is buildable. The job market is real.

What it requires from you is honest preparation: understanding what the job involves, building case studies that demonstrate your thinking, and being patient enough to see the job search through.

The [career change to UX design hub](/career-change-to-ux-design/) has a full breakdown of everything involved in making this switch - from first steps through to job offer. Not ready to commit yet? The [free UX masterclass](/masterclass/free-ux-ui-masterclass/) is a one-session live taster with no deposit required. If you are ready to start building the skills themselves, the [Beginner UX (AI) Design course](/courses/beginner-ux-design/) is designed specifically for working adults making this transition: Wednesday evenings, live instruction, and a structured portfolio project that comes out the other end. If you want a second live client brief and structured job search support once you have graduated, the [UX Career Track](/courses/ux-career-track/) is a 4-week extension built for exactly that.

You can also read more about what other career changers have learned along the way in our post on [switching careers to UX design](/blog/switching-careers-to-ux-design/), or explore whether [you can become a UX designer without a degree](/blog/become-a-ux-designer-without-a-degree/) - a question that matters more than people often expect.

Thirty is not a cutoff. For most people, it is a genuinely good time to make this move.

Our lead instructor teaches these cohorts live — she made a similar career shift herself and understands the anxiety and practicalities involved.


---

# Card Sorting in UX Research: A Complete Guide

URL: https://myuxacademy.com/blog/card-sorting-ux-research/
Card sorting in UX research explained: open vs closed vs hybrid, when to use it, how to run sessions, analyse results, and avoid common mistakes.

Card sorting is a UX research method in which participants group a set of cards -- each representing a piece of content, a feature, or a category -- into arrangements that make intuitive sense to them. The output is a window into users' mental models: how they naturally organise information, what they expect to find grouped together, and what vocabulary they use for things designers often name differently. Information architects and UX designers use card sorting to build navigation structures and content hierarchies that reflect the way users think, rather than the way internal teams think about their own products.

The method has been a standard part of the UX research toolkit for decades. The Nielsen Norman Group has published extensive research on card sorting as an information architecture tool, and it remains one of the clearest examples of research that directly drives a structural design decision.

> **Want to practise card sorting on a real client brief?** UX Academy (myuxacademy.com)'s [Advanced UX Design course](/courses/advanced-ux-design/) includes a hands-on IA research module where you run live card sorts and present findings to stakeholders. Or [try the free masterclass first](/masterclass/free-ux-ui-masterclass/).

## What Problem Does Card Sorting Solve?

The core problem card sorting addresses is this: the people who design and build a product think about its content differently from the people who use it. Internal teams organise things by department, product line, or business function. Users organise things by task, goal, or how they understand the world.

When those two mental models diverge -- and they almost always do -- users cannot find what they are looking for. They either give up, contact support, or leave. Card sorting gives you evidence to close that gap before you build a navigation structure that makes sense only to the people who created it.

It sits within the broader category of [UX research methods](/blog/ux-research-methods/) that inform information architecture decisions. For a fuller picture of how IA fits into the design process, see [information architecture in UX design](/blog/information-architecture-ux-design/).

## Open, Closed, and Hybrid Card Sorting

### Open Card Sorting

In open card sorting, participants receive a set of unlabelled cards and create their own category groups. They name those groups themselves, using whatever label feels natural to them.

This is the variant to reach for when you are designing a new information architecture from scratch and do not yet have a proposed structure. Open card sorting tells you two things: how users group content together, and what they call those groups. Both are valuable. Users' own category labels often surface vocabulary that should feed directly into navigation labels and copy.

**Use it when:** You are starting a new project or undertaking a significant redesign and have no existing structure to validate.

### Closed Card Sorting

In closed card sorting, participants sort cards into categories you have already defined. The categories are fixed; participants cannot create new ones.

This is the variant to use when you have a proposed or existing navigation structure and want to test whether users can predict where things live within it. It answers a different question from open sorting -- not "how do users naturally group this?" but "does our proposed grouping match how users think?"

**Use it when:** You want to validate an existing or proposed IA before committing to it, or when you are testing whether a redesign has improved findability.

### Hybrid Card Sorting

Hybrid card sorting gives participants a set of predefined categories but allows them to create new ones if a card does not fit anywhere. It is a middle ground: you get data about your proposed structure while also learning what gaps exist in it.

**Use it when:** You have a proposed structure but suspect there may be content that does not fit cleanly anywhere within it.

## When Should You Use Card Sorting?

Card sorting belongs at the generative end of the research process -- early, before you have built a structure. The ideal sequence is:

1. Run an open card sort to understand users' mental models and vocabulary.
2. Draft a proposed information architecture based on the findings.
3. Run a tree test to validate that users can actually navigate the proposed structure.

(Tree testing is the evaluative counterpart to card sorting -- it tests whether people can find things in a structure you have already designed, without the visual design getting in the way. It is worth thinking of the two methods as a pair.)

Card sorting is particularly valuable for:

- **Website navigation redesigns** -- especially on sites with large content libraries where the current navigation grew organically rather than by design.
- **Product menus and settings** -- particularly in B2B tools where users need to find specific functionality quickly.
- **Content categorisation** -- blog taxonomies, help centre structures, e-commerce category hierarchies.

It is less useful for task-based or flow-based design problems, where [usability testing](/blog/usability-testing-guide/) or user interviews will give you more relevant insight.

## How to Run a Card Sorting Session

### Step 1: Define Your Content Set

Select the cards carefully. Aim for 30 to 100 cards -- enough to surface meaningful groupings, few enough that participants do not become fatigued. Each card should represent a single, clearly defined piece of content or feature. Avoid overlap between cards and avoid jargon that might confuse participants before they have even started sorting.

If you have more than 100 pieces of content to sort, consider running multiple studies with different subsets, or prioritising the content that is most frequently accessed.

### Step 2: Choose Your Delivery Method

**Remote, unmoderated:** Tools like Optimal Workshop's OptimalSort or Maze let participants complete the sort online, at their own pace. This approach scales well -- you can reach 20 to 30 participants quickly -- and removes the logistical overhead of scheduling sessions. The trade-off is that you cannot ask follow-up questions when a participant does something unexpected.

**Remote, moderated:** Screen-sharing tools combined with a digital card sort tool allow you to observe in real time and ask participants to think aloud as they sort. You lose some scale but gain much richer qualitative data -- you will hear why participants made the choices they did, which is often as valuable as the groupings themselves.

**In person:** Physical index cards on a table. Slower to set up and harder to analyse at scale, but some participants find physical cards more intuitive than screen-based tools, and the think-aloud data from in-person sessions is frequently excellent.

### Step 3: Recruit Participants

The Nielsen Norman Group recommends a minimum of 15 participants for open card sorting and 20 for closed card sorting. For most projects, 20 to 30 participants is a practical target. If your user base is divided into meaningfully different segments -- for example, administrators and end users in a B2B product -- recruit separately for each segment and analyse the results independently.

Recruit from your actual user base wherever possible. Card sorting results from the wrong population can be actively misleading.

### Step 4: Run the Sessions

For moderated sessions, ask participants to think aloud as they sort. Do not guide them -- your job is to observe, not to explain or validate. Note what they say as much as what they do. Participants who hesitate, move a card back and forth, or create an "I do not know where this goes" pile are giving you important signal.

For unmoderated sessions, include a brief open-ended text field where participants can comment on any cards they found confusing or categories they nearly created but did not.

## How to Analyse Card Sorting Results

### Similarity Matrix

A similarity matrix is the standard starting point for card sort analysis. It shows, for every pair of cards in your study, what percentage of participants grouped them together. A high agreement score (say, 80% or above) means users consistently see those items as belonging together. A low score means there is no consensus -- which might mean the relationship is unclear, or that different user segments think about it differently.

Most dedicated tools (Optimal Workshop, Maze) generate the similarity matrix automatically. You read it as a heat map: darker cells indicate stronger agreement.

### Dendrograms

A dendrogram is a tree diagram that visualises the hierarchical relationships between cards based on the similarity data. Items that cluster tightly were frequently grouped together by participants; items that sit far apart were rarely grouped together.

Dendrograms are useful for spotting natural cluster boundaries -- the points in the hierarchy where you might draw the line between one category and another. They are not a prescription: they show you what users did, and you still need to make design judgements about how to translate that into a navigation structure. But they make the patterns in the data visible in a way that a raw matrix does not.

### Qualitative Themes

Do not ignore the category labels participants create in open card sorts. Read through all of them. You will often find that several participants independently coined the same label -- or very similar ones -- for the same cluster of content. Those labels are your navigation copy, handed to you by your users.

## Common Mistakes in Card Sorting

**Too many cards.** Participants lose patience around the 100-card mark and start sorting arbitrarily. If you have more content than that to sort, split the study.

**Cards that are too similar.** If participants cannot tell the difference between two cards, they will group them together by default, not because they belong together conceptually. Make sure each card represents a genuinely distinct piece of content.

**Recruiting the wrong people.** Card sorting results from participants who do not represent your users are worse than no data at all, because they create false confidence in a structure that will not work.

**Treating the dendrogram as a finished architecture.** The dendrogram is evidence, not a design. You still need to apply judgment -- particularly around breadth vs depth trade-offs, top-level category count, and labelling -- to turn the research findings into a navigation structure that works.

**Skipping tree testing.** Card sorting tells you how users group things; it does not validate that they can find things in the structure you build from those groupings. Always follow up with a tree test before finalising the architecture.

## Fitting Card Sorting Into the Wider Research Process

Card sorting is a generative method. It sits alongside user interviews and contextual enquiry in the early, problem-definition phase of a project -- helping you understand users' mental models before you commit to a structure. Once you have a proposed architecture, tree testing validates it. Once you have a designed interface, usability testing checks whether people can navigate it in practice.

Understanding where card sorting fits in the sequence is part of becoming a well-rounded UX researcher. For a broader map of the methods and when to use them, [UX research methods](/blog/ux-research-methods/) is the right place to start. And if you are thinking about how to define and reach your users before running any research at all, [user persona templates](/resources/templates/user-persona/) covers the foundations of building a research-grounded understanding of your audience.

## Learn Card Sorting by Doing It

Reading about card sorting is useful. Running a real session -- watching a participant hesitate over a card, hearing them say "I would never call it that," seeing a cluster emerge that completely contradicts your assumptions -- is where the learning actually happens.

UX Academy's lead instructor, a designer with experience at Adobe, Google, and Canva, includes card sorting as a hands-on exercise in the [Advanced UX Design course](/courses/advanced-ux-design/). Students run live sessions with real participants, analyse their own similarity matrices, and present findings to a stakeholder audience -- the same workflow they will use in a professional UX role.

If you are not ready to commit yet, the [free UX masterclass](/masterclass/free-ux-ui-masterclass/) is a good place to start. You will get a grounded introduction to the discipline and a clear sense of whether UX research is the direction you want to take your career.


---

# Best UX Design Certifications UK 2026: An Honest Comparison

URL: https://myuxacademy.com/blog/best-ux-design-certifications-uk-2026/
The best UX design certifications in the UK in 2026 compared: Google, IxDF, Nielsen Norman, UXDI, and live courses. What each delivers and who it suits.

The UX certification market is crowded and, frankly, uneven. Some options are genuinely useful as a starting point; others are overpriced relative to what they deliver. This post gives you an honest comparison of the main options available to people in the UK in 2026 — what each one actually is, what it costs, who it suits, and what employers make of it.

> **Not sure which option is right for you?** UX Academy (myuxacademy.com)'s [free UX masterclass](/masterclass/free-ux-ui-masterclass/) lets you experience live instruction before committing to anything. Or if you are ready to enrol: [Beginner UX (AI) Design course](/courses/beginner-ux-design/) — £1,500, £99 deposit, Cohort 1: 21 Sep 2026.

## What employers actually look for

Before comparing certifications, it is worth being clear about what UK employers actually evaluate when they are hiring UX designers.

The answer is almost always: your portfolio first, your ability to discuss your design process second, and your cultural fit with the team third. The name of the certificate provider — Google, Nielsen Norman, IxDF — is rarely the deciding factor. Hiring managers at UK tech companies and agencies look at your case studies: can you articulate a real user problem, show how you researched it, demonstrate how you iterated, and explain what the outcome was?

This matters because some providers sell their certification as a job guarantee or a signal that employers specifically screen for. That is an overstatement. A strong portfolio with two or three well-documented projects, built during a structured programme with tutor feedback, will open more doors than a certificate from a prestigious name with nothing to show for it.

That said, certifications and structured programmes are useful — they give you the foundation, the language, and (if the programme is well designed) the project work. The question is which option gives you the most for your circumstances.

## The main options compared

| Programme | Format | Duration | Cost (approx.) | Best for |
|-----------|--------|----------|-----------------|----------|
| Google UX Certificate (Coursera) | Self-paced online | 3–6 months | ~£35–49/month (Coursera sub) | Absolute beginners wanting a broad foundation |
| IxDF Membership | Self-paced online | Ongoing | ~£80–100/year | Supplementary learning; professionals deepening knowledge |
| Nielsen Norman Group | Live/virtual workshops | Varies | $900–1,500 per course; $6,000–10,000 for full certification | Experienced practitioners seeking senior-level validation |
| UX Design Institute (UXDI) | Self-paced online with mentor | 6–9 months | Check current pricing on their site (was ~£1,995) | Career changers wanting a structured diploma |
| UX Academy (myuxacademy.com) | Live online, small group | Part-time over several months | £1,500 (£99 deposit) | Career changers wanting live instruction + UK context |

Prices correct as of June 2026 where confirmed; check provider sites for current rates.

## Google UX Design Certificate

The Google UX Design Professional Certificate is a seven-course programme on Coursera covering UX foundations, research methods, wireframing, prototyping in Figma, and responsive design. It is self-paced and designed to be completable in three to six months.

**Pros.** It is affordable — Coursera operates on a subscription model, so the total cost is modest if you move through it efficiently. The curriculum is solid for a beginner: you come out knowing what a design sprint is, how to conduct a usability test, and how to use Figma at a basic level. You produce three portfolio projects, which is more than most self-paced options offer. Google has expanded its employer partnerships, and many UK startups and mid-size tech companies now recognise it.

**Cons.** There is no live instruction. When you get stuck — and you will get stuck — you are relying on forums and community threads rather than a tutor who can look at your specific work and tell you what to do differently. The projects are template-driven, which means portfolio reviewers who have seen many Google cert graduates will notice the similarity. Recognition varies: smaller UK agencies and traditional businesses are less likely to know it.

**Who it suits.** Absolute beginners who want a low-cost, low-commitment introduction before deciding whether to invest more seriously. It is a solid first step, not a complete career-change programme on its own.

### Is the Google UX Design Certificate worth it in the UK?

For most people in the UK, the Google certificate is worth doing as a first step — not as a complete career-change solution. It gives you enough vocabulary and foundational knowledge to know whether UX is right for you, and the Coursera cost is low enough that it is not a significant financial risk. Where it falls short is in producing portfolio work that stands out, and in providing any live feedback on your progress. If you complete it and decide to pursue UX seriously, treat it as a foundation to build on rather than a finishing point.

## Interaction Design Foundation (IxDF)

IxDF offers a membership model: around £80–100 per year (with discounts for students) gives you access to a library of over 100 courses covering everything from user research to mobile UX to design leadership. Check IxDF's site for current UK pricing. The content is informed by practitioners including Don Norman and reviewed by industry experts. IxDF reports over 130,000 members globally.

**Pros.** The breadth is unmatched at this price point. If you already have some UX experience and want to go deeper on a specific area — accessibility, information architecture, design systems — IxDF has well-regarded material on all of it. It is also genuinely useful for working designers who want to stay current without paying for expensive short courses.

**Cons.** It is a knowledge library, not a structured career-change programme. There is no cohort, no live instruction, and no tutor feedback. The certificate of completion signals that you read the material; it does not demonstrate that you can apply it. For someone starting from scratch, the lack of structure and accountability makes completion harder.

**Who it suits.** Professionals already working in a related field (product management, research, marketing) who want to build UX knowledge systematically. Also useful as a supplement to a more structured programme. It is less suited to complete beginners as a standalone path.

## Nielsen Norman Group UX Certification

The NN/g certification is the most demanding and most expensive option on this list. It requires completing a series of specialisation courses — research, interaction design, UX management, and others. Online courses are typically priced around $300–500 each; in-person conference intensives run $2,000 or more. Full certification typically requires spending $6,000–10,000 or more over time. Check NN/g's site for current pricing as it changes frequently.

NN/g is not a beginner programme. It is designed for working UX professionals who want a senior-level credential recognised across the industry. The course content is rigorous and the brand carries real weight with employers, particularly at more established companies and consultancies.

**Pros.** Genuine credibility with experienced hiring managers. The content quality is high. The specialisations allow you to signal specific areas of depth (research, leadership, etc.) rather than generic UX knowledge.

**Cons.** The cost is significant. There is no portfolio component — you earn the certification through completing coursework and passing assessments, not by producing case studies. It is also primarily aimed at people who already have UX experience and want to validate or deepen it, not at career changers building from scratch.

**Who it suits.** Mid-career UX professionals looking to signal seniority or move into more specialised roles. Not the right starting point for someone new to the field.

## UX Design Institute (UXDI)

UXDI offers a Professional Diploma in UX Design — a self-paced online programme with optional mentor support. It is based in Ireland with a strong presence in the UK market. The programme covers the full UX process from research through to high-fidelity prototyping, and produces a diploma rather than a short certificate.

**Pros.** More depth than a short certificate programme. The diploma framing carries a bit more weight than a completion badge. There is a structured curriculum with assignments. UXDI has been operating for several years and has reasonable brand recognition in UK and Irish markets.

**Cons.** It is self-paced, so the accountability issue remains — completion rates for self-paced programmes are consistently low, regardless of the provider. Check current pricing on their site; it sits in a bracket that makes the value proposition worth scrutinising carefully relative to live alternatives. There is no live instruction, so feedback on your work depends on how actively you engage with the mentor option.

**Who it suits.** Career changers who need a flexible, self-directed option and are confident they can sustain motivation without a cohort or live sessions. If you have strong self-discipline and schedule constraints that rule out live programmes, it is a solid choice.

## Live courses vs self-paced certificates: the real distinction

The comparison above contains programmes that are quite different in structure, and that difference matters more than any other factor for most career changers.

Self-paced programmes — Google, IxDF, UXDI — let you work through material at your own pace. That flexibility is genuinely useful if you have unpredictable schedules or need to spread costs over time. The tradeoff is that you are learning alone: no live instructor to ask questions, no cohort to work alongside, no tutor to review your specific work and tell you what is missing.

Live courses — where sessions happen at a fixed time, with a real instructor and a small group of students — address those gaps directly. You get feedback on your actual work from someone who can see what you have done. You have accountability built in because the sessions happen whether or not you feel motivated on a given Tuesday. You are also learning alongside other career-changers, which provides peer perspective and a small professional network.

The tradeoff is schedule commitment: live sessions require you to be available at specific times, which does not suit everyone.

[UX Academy (myuxacademy.com)](/courses/) runs small-group courses with live online instruction from UK-based UX professionals, taught live by our lead instructor, Natalia Veretenyk, and a team of UK UX practitioners. It is not a self-paced certificate programme — it is closer in spirit to a structured bootcamp, with the class size and instructor access of a more intensive programme, built specifically for career-changers in the UK. For more on how live instruction compares to certificate programmes, see our [guide to UX bootcamps](/blog/are-ux-bootcamps-worth-it/).

## How to choose based on where you are

**If you are exploring the field and not ready to commit.** Start with IxDF or the Google certificate. Both are low-cost ways to confirm that UX is a field you want to pursue before spending more. Treat them as a foundation, not a complete solution.

**If you are ready to make a career change.** The question becomes: what will actually get you hired? The answer is a portfolio with real case studies. Choose a programme — live or self-paced — that produces real project work and gives you feedback on it. A certificate without a portfolio is not enough in 2026's UK job market.

**If you are already working in UX and want to go deeper.** IxDF is good value for ongoing professional development. NN/g certification is worth considering if you are targeting senior roles or want to signal credibility in research or UX leadership specifically.

**If you are switching careers from a professional background.** A live programme with a small cohort is usually more effective than self-study — both because of the accountability and because the feedback loop accelerates your learning significantly. See [how to become a UX designer](/blog/how-to-become-a-ux-designer/) and [switching careers to UX design](/blog/switching-careers-to-ux-design/) for more on the career-change path.

It is also worth noting that a degree is not a prerequisite. Many practising UX designers in the UK have neither a design degree nor a formal certification. The field remains portfolio-driven. See [becoming a UX designer without a degree](/blog/become-a-ux-designer-without-a-degree/) for more on this. For realistic salary context as you plan your move, the [UX designer salary UK guide](/blog/ux-designer-salary-uk/) is worth reading alongside this one.

## The honest bottom line

No single certification is the right answer for everyone, and no certification is a substitute for a portfolio. The programmes that tend to produce the best outcomes for career-changers are the ones that combine structured learning with real project work and some form of tutor or mentor feedback — whether that is a live course or a well-supported self-paced diploma.

If you want to compare the broader landscape of courses available in the UK, the [best online UX design courses UK](/best-online-ux-design-courses-uk/) roundup covers more options. And if you are building your portfolio in parallel with any programme, the [UX design portfolio guide](/blog/ux-design-portfolio-guide/) covers what actually makes a case study stand out to a hiring manager.

UX Academy's (myuxacademy.com) next cohort starts <CohortDate />. It is a live, small-group programme taught live by our lead instructor, Natalia Veretenyk, and a team of UK UX practitioners — a different option from the self-paced certificate market. If that sounds like what you need, [view the courses](/courses/) or [reserve your place with a £99 deposit](/courses/beginner-ux-design/).


---

# Affinity Mapping in UX: Turning Data Into Insights

URL: https://myuxacademy.com/blog/affinity-mapping-ux/
Affinity mapping explained: how to run a diagramming session, organise qualitative data into themes, and turn findings into design insights.

Affinity mapping (also called affinity diagramming) is a synthesis method for organising large amounts of qualitative research data into emergent themes. After user interviews, usability testing sessions, or observational research, you are typically left with dozens or hundreds of individual observations, quotes, and findings. Affinity mapping gives you a structured way to make sense of that material -- moving from raw data to patterns, and from patterns to insights that can actually drive design decisions.

The method was developed by Japanese anthropologist Jiro Kawakita in the 1960s and is often called the KJ Method after his initials. Kawakita originally used it in field anthropology to synthesise large bodies of qualitative field data. UX and product design teams adopted it because it solves the same problem: too much raw material, not enough structure, and a need to find signal in the noise.

If you are new to the research process that feeds into affinity mapping, [UX research methods](/blog/ux-research-methods/) covers the methods you will most commonly draw from.

> **Want to practise affinity mapping on a real brief?** UX Academy (myuxacademy.com)'s [Advanced UX Design course](/courses/advanced-ux-design/) covers synthesis and research methods with live tutor feedback -- you will run real sessions, not just read about them. Cohort 1 starts 21 Sep 2026. Or [try the free masterclass first](/masterclass/free-ux-ui-masterclass/).

## When Should You Use Affinity Mapping?

Affinity mapping belongs in the synthesis phase of the design process -- after research, before ideation. Concretely, that means after you have completed a round of user interviews, usability testing, or contextual enquiry, and before you start writing problem statements, creating [user personas](/resources/templates/user-persona/), or generating solutions.

It is most useful when you have data from multiple participants or sessions. If you have interviewed eight people, you will have somewhere between 80 and 200 individual observations to make sense of. Without a synthesis technique, you risk anchoring on the most memorable or most recent interview and ignoring quieter signals that cut across the full dataset.

You do not need affinity mapping for every research activity. A quick round of five-user usability testing on a specific flow might surface clear, actionable problems that do not require collaborative synthesis. Affinity mapping earns its place when you are dealing with exploratory, generative research -- discovery interviews, early-stage user research, or post-study synthesis where the findings are open-ended.

## What You Need Before You Start

Before running an affinity mapping session, you need your research data captured at the right level of granularity. That means:

**One observation per note.** Each sticky note should contain a single, discrete piece of data -- a direct quote, an observed behaviour, a stated frustration, a moment of confusion. Notes like "generally found the interface confusing" are too vague to cluster meaningfully. Notes like "couldn't find the save button -- assumed progress would auto-save" are specific enough to reveal a real pattern.

**Enough participants.** Affinity mapping on data from two interviews will surface coincidences, not patterns. You typically need at least six to eight participants before clustering becomes genuinely revealing.

**The right people in the room.** The value of affinity mapping is partly in the collaborative sense-making -- having designers, researchers, and product people looking at the data together. That does not mean everyone needs to have been present for the interviews, but bringing in people who were not involved at all can mean the session becomes a debate about the data rather than a synthesis of it.

## How to Run an Affinity Mapping Session

### Step 1: Prepare the raw data

Transfer every observation from your research into individual sticky notes -- physical or digital. Colour-code by participant if it helps you track where data came from, but do not impose categories yet. Resist the urge to pre-sort. The whole point is to let themes emerge from the data, not from your assumptions about what the themes should be.

### Step 2: Put everything on the wall

Post every note on a shared surface -- a whiteboard, a wall, a Miro board -- without any structure. The initial state should look like chaos. That is correct.

### Step 3: Sort in silence (initially)

Ask participants to start moving notes that feel related close to each other -- working in silence. The silence is deliberate. It prevents one person's framing from dominating early and forces everyone to work from the data rather than from each other's interpretations.

After ten or fifteen minutes, open the floor and let people discuss groupings, move notes between clusters, and flag disagreements. Disagreements are often where the most interesting insights live.

### Step 4: Name the clusters

Once groupings have stabilised, give each cluster a descriptive header. A good cluster header captures what the theme means, not just what it is. "Navigation" is a label. "Users cannot predict where settings will be, so they give up rather than explore" is a theme. The second version already points toward a design implication.

### Step 5: Identify second-order patterns

Look at your named clusters. Are there clusters that belong together at a higher level of abstraction? You may find that several clusters all relate to trust, or onboarding anxiety, or a specific mental model mismatch. These second-order groupings often become the pillars of your synthesis -- the three or four big things you learned from the research.

### Step 6: Move from clusters to insights

A cluster is not yet an insight. An insight is a statement about what the data means and why it matters for design. Take each cluster and ask: what does this tell us about users' goals, mental models, or frustrations? What design implication follows?

This is the step most teams skip or rush. The clusters feel like the output, but they are actually just organised data. The insight -- the statement that tells you what to do next -- requires interpretation.

## Physical Sticky Notes vs Digital Tools

The original affinity mapping method uses physical sticky notes and a wall. There is something genuinely useful about the tactile, spatial quality of moving paper around -- it slows the process down in a way that prevents premature closure on themes.

For distributed teams, digital tools are the practical alternative. **Miro** and **FigJam** are the most commonly used platforms. Both support virtual sticky notes, real-time collaboration, and colour coding. Miro has more sophisticated organisation and navigation features; FigJam integrates naturally into a Figma-based design workflow. Either works.

A few practical tips for digital sessions: use colour to distinguish participants or data sources, not to pre-categorise themes (that defeats the purpose). Keep video on so you can see when someone is about to move a note. Use a time-boxed silent sorting phase even in digital sessions -- it is easy to lose this discipline when everyone is looking at the same screen.

## Moving From Clusters to Insights

The synthesis step -- moving from organised clusters to usable design insights -- is where affinity mapping often stalls. Here is a framework that helps.

For each cluster, complete the sentence: "We learned that [type of user] [does/feels/needs X] because [underlying reason]." The "because" is the part that most teams omit. It forces you to explain the mechanism, not just describe the observation.

From that statement, ask: what does this mean for our design? Some clusters will point toward clear implications (a navigation pattern needs to change, a concept needs better onboarding). Others will surface questions that require further research. Both are legitimate outputs -- knowing what you do not yet understand is itself a research finding.

If you are using personas to communicate research findings, the insights from affinity mapping will become the raw material. [User personas](/resources/templates/user-persona/) work best when they are grounded in synthesis like this, not assembled from demographic assumptions.

## Affinity Mapping vs Thematic Analysis vs Journey Mapping

These three methods are often confused because they all involve organising qualitative research data. They serve different purposes.

**Affinity mapping** is a collaborative, bottom-up workshop technique. The team physically or digitally sorts data together in real time, letting themes emerge from the material. It is fast, participatory, and well-suited to design teams who need actionable insights within a day or a sprint.

**Thematic analysis** is a more formal qualitative research methodology involving systematic coding, reviewing, and defining of themes, typically done by one or two researchers working through interview transcripts methodically. It is more rigorous and auditable than affinity mapping -- appropriate for academic research or high-stakes contexts where the analysis needs to withstand external scrutiny. For most UX design teams, affinity mapping offers the right balance of structure and speed.

**Journey mapping** is a different activity altogether. Where affinity mapping organises findings by theme, a [customer journey map](/blog/customer-journey-map-template/) organises them by the user's sequence of actions and experiences over time. Journey mapping is an output of synthesis, not a synthesis technique itself -- you might use affinity mapping to identify themes first, then use those themes to inform the emotional arc of a journey map.

## Common Mistakes

**Starting with categories.** Defining your clusters before you sort the data turns affinity mapping into a filing exercise. You will find what you expect to find and miss what you did not know to look for.

**Mixing data and interpretation.** Sticky notes should contain data (what participants said or did), not your interpretation of what it means. Keep the interpretation for the cluster-naming and insight-generation steps.

**One person driving the sort.** If one person moves all the notes while others watch, you lose the collaborative sense-making that makes affinity mapping useful. Everyone should be moving notes.

**Stopping at the clusters.** Clusters are organised data. Insights are what you do with them. If your synthesis deliverable is a photograph of a clustered whiteboard, you have done half the work.

**Skipping the "because."** The most common failure mode in synthesis is describing what happened without explaining why. A finding that explains the underlying cause is ten times more useful to a design team than one that just names the problem.

## Affinity Mapping in the Broader Design Process

Affinity mapping sits between research and definition in the [UX design process](/blog/ux-design-process/). It is the bridge that connects what you observed to what you will design. Used well, it means your problem statements, personas, and design decisions are grounded in evidence rather than assumption.

For career-changers learning UX, affinity mapping is often one of the first synthesis techniques that makes the design process feel concrete. You go from a stack of interview notes that feel overwhelming to a clear picture of what users need and why. That transformation -- from raw data to structured insight -- is one of the core skills that separates designers who can do research from designers who can use research.

At UX Academy, our [Advanced UX Design course](/courses/advanced-ux-design/) covers affinity mapping alongside the full research and synthesis toolkit, with hands-on practice on real client briefs. Tutor-led sessions give you direct feedback on your synthesis -- not just on whether you ran the session correctly, but on whether your insights are strong enough to drive design decisions. Cohort 1 opens 21 Sep 2026. [Register your place with a £99 deposit](/courses/advanced-ux-design/), or [join the free masterclass](/masterclass/free-ux-ui-masterclass/) to get a feel for how we teach.


---

# UX Research Methods: A Practical Guide for Designers

URL: https://myuxacademy.com/blog/ux-research-methods/
UX research methods explained: user interviews, usability testing, card sorting and surveys. Learn when to use each and how they fit a UX design process.

UX research is not a nice-to-have. It is the mechanism by which you find out whether you are solving the right problem, for the right people, in a way that actually works. Skip it and you are designing in the dark -- making decisions based on assumption rather than evidence.

But research is also a toolbox, not a single method. Choosing the wrong tool for a question wastes time and produces misleading results. This guide covers the UX research methods you will use most often in real design work, when to reach for each one, and how to think about fitting research into the broader design process.

If you are new to the field and want a foundation first, [what is UX design](/blog/what-is-ux-design/) covers the discipline from the ground up.

> **Thinking of making research your specialism?** UX Academy (myuxacademy.com)'s [Advanced UX Design course](/courses/advanced-ux-design/) covers every method in this guide with live practice and tutor feedback. Cohort 1 starts 21 Sep 2026 -- [secure your place with a £99 deposit](/courses/advanced-ux-design/). Or [try the free masterclass first](/masterclass/free-ux-ui-masterclass/).

## Qualitative vs Quantitative Research

Before looking at individual methods, it is worth being clear on this distinction, because it determines how you interpret everything you collect.

**Qualitative research** involves observing or talking with a relatively small number of participants -- usually fewer than twenty -- to understand their motivations, mental models, goals, and frustrations. It tells you *why* something is happening. The output is themes, patterns, and insight, not percentages.

**Quantitative research** collects data at scale. Surveys, analytics, A/B tests, and clickstream data all fall here. They tell you *how many* users do something, how often, and with what frequency. You can be statistically confident in the results. What you cannot learn from quantitative data alone is why those numbers look the way they do.

The distinction matters because they answer different questions. If your analytics show that 60% of users abandon a checkout flow at step three, that is quantitative: you know there is a problem and where it is. A round of usability testing or user interviews tells you what is actually going wrong at that step. You need both.

## Generative vs Evaluative Research

A second distinction that shapes how you plan a research programme:

**Generative research** happens early. Its goal is to understand the problem space -- who your users are, what they are trying to do, what currently frustrates them. You are not evaluating anything yet; you are building the foundation that makes good design decisions possible. User interviews, contextual enquiry, and diary studies are generative methods.

**Evaluative research** tests something you have already made -- a prototype, a concept, a live product. You are asking: does this work? Does it solve the problem? Can users actually use it? Usability testing, tree testing, and A/B testing are evaluative methods.

Getting this wrong is expensive. Running usability tests before you understand the problem space will tell you whether a solution works, but not whether it is the right solution in the first place.

## The Key Methods

### User Interviews

User interviews are one-to-one conversations with people who represent your target users. They are the most flexible and widely used qualitative method because they can be adapted to almost any research question.

Used well, they surface the motivations, mental models, and contextual factors behind user behaviour -- things you cannot observe directly and that users will not mention if you ask them what they want from a product (because people are generally poor at predicting their own future behaviour).

**When to use them:** Discovery and problem definition. Use interviews when you are starting a new project, entering an unfamiliar domain, or trying to understand why a known pattern exists.

**How many participants:** Eight to twelve is typically enough to reach thematic saturation for a reasonably homogeneous user group. If your user population is diverse across significant variables (e.g., different levels of technical literacy, different job roles), you may need segments with five to eight participants each.

**What you get:** Themes, mental models, vocabulary users actually use, and the contextual factors that shape their behaviour. Not validation of specific solutions.

**A common mistake:** Asking leading questions or pivoting to solutions mid-interview. Your job is to listen and probe, not to pitch.

### Usability Testing

Usability testing means giving real users a set of realistic tasks to complete on a product, prototype, or even a sketch, and observing what happens. You are not asking them to evaluate the design; you are watching how they interact with it. Where do they hesitate? Where do they make errors? Where do they give up?

This is the most direct way to identify [usability](/blog/usability-in-ux-design/) problems before they become support tickets and lost customers.

**Moderated vs unmoderated:** Moderated testing means a researcher is present -- in person or by video call -- and can ask follow-up questions, prompt the participant to think aloud, and probe when something interesting happens. Unmoderated testing uses a tool (such as Maze or Useberry) to run sessions remotely without a facilitator. Moderated sessions produce richer insight; unmoderated sessions scale further and are faster to run.

**How many participants:** Jakob Nielsen's research at the Nielsen Norman Group (2000) established that five participants will surface roughly 85% of usability problems in an interface. This does not mean you always stop at five -- if you have distinct user segments, test each one separately. But five is a defensible number for most formative rounds, and it is far better than zero.

**When to use it:** Any time you have something to test -- wireframes, prototypes, or live products. Usability testing should happen throughout the design process, not just at the end.

### Surveys

Surveys let you collect structured data from a large number of people quickly and cheaply. When designed well, they are genuinely useful for measuring attitudes, satisfaction, and the frequency of specific behaviours across a user base.

The critical limitations: surveys tell you what people say they do, not what they actually do. They are poor at uncovering unexpected insights because you can only ask about things you already know to ask about. And badly written surveys -- with leading questions, ambiguous scales, or false assumptions baked into the questions -- produce data that feels reliable but is not.

**When to use them:** After you have done qualitative work and want to check whether a finding holds at scale. Also useful for ongoing satisfaction measurement (e.g., NPS, CSAT) with existing users.

**Best practice:** Test your survey on five people before you send it. You will almost always find questions that participants interpret differently from how you intended.

### Card Sorting

Card sorting is a method for understanding how users naturally categorise and group information. Participants are given a set of cards -- each representing a piece of content or a feature -- and asked to arrange them in a way that makes sense to them.

**Open card sorting:** Participants create their own category labels. Use this when you are designing a new information architecture from scratch and want to understand users' mental models.

**Closed card sorting:** Participants sort cards into categories you have already defined. Use this to validate an existing structure or test whether users can predict where things will live in a proposed navigation.

**When to use it:** Designing or redesigning navigation, menus, or information architecture. Card sorting is a generative method -- it helps you understand how users think about your content before you build a structure around it.

### Tree Testing

Tree testing is the evaluative counterpart to card sorting. You present users with a text-based version of your navigation hierarchy (the "tree") and ask them to find specific items. Because there is no visual design involved, you are testing the structure and labelling of the navigation, not the layout.

**When to use it:** After you have designed an information architecture (often informed by card sorting) and want to test whether users can actually find what they need within it. Tree testing is particularly useful because it isolates navigation problems from visual design problems -- so you can fix the structure before investing in full visual design.

Tools like Treejack make tree testing straightforward to set up and run remotely.

### Contextual Enquiry and Field Research

Contextual enquiry means observing users in their actual environment -- at their desk, in a warehouse, on the factory floor, at a kitchen table -- rather than in a lab or on a video call. You are watching how they work in context: what tools they use alongside your product, what interruptions they deal with, what workarounds they have developed for problems the product has not solved.

**When to use it:** When the context of use is an important variable. If you are designing software for hospital staff, watching how they use it at a nursing station -- surrounded by noise, interruptions, and competing demands -- will reveal constraints that a controlled interview will not surface.

**What you get:** Insight into the real environment, genuine workflows (not the idealised version people describe in interviews), and often a better understanding of what users actually need vs. what they say they need.

The trade-off is time and logistics. Contextual enquiry is slower and harder to schedule than remote interviews, but for complex or high-stakes products it is often the research method that produces the most useful findings.

### Diary Studies

A diary study asks participants to record their experiences, thoughts, or behaviours over an extended period -- days, weeks, or sometimes months. Entries might be written notes, photos, voice recordings, or responses to prompted questions sent via SMS or an app.

**When to use them:** When you need to understand behaviour over time rather than in a single session. How do people use a health tracking app across a week? How does someone's experience of onboarding a new SaaS product evolve over a month? These are longitudinal questions that a one-hour interview cannot answer.

**The catch:** Participant compliance drops over time. People start enthusiastically and trail off. You need to design the prompts carefully, keep the recording burden low, and expect some attrition. For that reason, diary studies work best when you have a clear longitudinal question that genuinely cannot be answered any other way.

### A/B Testing

A/B testing (also called split testing) shows different versions of a design to different groups of users and measures which version produces a better outcome -- more conversions, longer session time, fewer support requests. It is a quantitative method and requires sufficient traffic volume to produce statistically reliable results.

**When to use it:** Optimising a design decision at scale, where you have a specific metric you are trying to move and enough users to reach statistical significance. Common applications include landing page headlines, checkout flows, and email subject lines.

**What it cannot do:** A/B testing tells you which variant performs better on the metric you are measuring. It does not tell you why. And it cannot help you if you are building the wrong thing in the first place -- it optimises within a defined problem space, it does not define the problem space. That is what qualitative research is for.

A common mistake is running A/B tests before gathering enough qualitative insight. Testing two versions of a confusing page will tell you which version is less confusing. It will not tell you that the page should not exist at all.

### Heuristic Evaluation

Heuristic evaluation is an expert review of an interface against a set of established usability principles -- most commonly Jakob Nielsen's 10 usability heuristics. Unlike the other methods listed here, it does not require recruiting participants. An experienced evaluator (or a small group of evaluators) reviews the interface systematically and identifies where it violates known usability principles.

**When to use it:** When you need fast, low-cost feedback without access to participants, or to complement user testing by preparing a cleaner prototype before running sessions. It is particularly useful early in a project to identify obvious problems quickly.

**What it cannot replace:** Real users. Heuristic evaluation is efficient but it is not a substitute for observation. Experts miss things that naive users surface immediately, and experts will not find problems that are specific to your user population's domain knowledge or context. For a step-by-step guide to running one, see [heuristic evaluation in UX design](/blog/heuristic-evaluation-ux-design/).

## How to Choose the Right Method

The best method for any situation depends on two questions:

**What is the research question?** Are you trying to understand users' mental models and motivations (qualitative, generative)? Are you trying to test whether a design works (qualitative, evaluative)? Are you trying to measure something at scale (quantitative)? Being precise about the question stops you reaching for a familiar method out of habit.

**What stage of the process are you in?** Early stages call for generative methods -- interviews, contextual enquiry -- that help you understand the problem. Later stages call for evaluative methods -- usability testing, tree testing, A/B testing -- that test your solutions. The two phases overlap and cycle; this is not a linear process.

A practical heuristic: if you do not know what question to ask, start with user interviews. They are the most forgiving method and they will almost always surface something you did not know to look for.

## Research in Agile Teams

Running research inside agile development cycles is its own discipline. The pressure to ship is real, and research that cannot keep pace with the team's decision cycle gets deprioritised. The short answer is that research has to be continuous and scoped tightly to the team's current bets -- not front-loaded into a long discovery phase and not skipped entirely.

[UX research in agile development](/blog/ux-research-agile-development/) covers the practical approaches in detail, including continuous discovery, dual-track agile, and how to run lean research that is fast enough to be useful without being so thin that it misleads.

## Build the Skill by Doing It

Reading about research methods and being able to apply them are different things. The gap between the two closes through practice -- running real sessions, making mistakes, learning to spot when a participant is telling you what they think you want to hear, and knowing when you have enough data to act.

If you want to practise these methods on a real client brief, the [Advanced UX Design](/courses/advanced-ux-design/) and [UX Career Track](/courses/ux-career-track/) courses at UX Academy include hands-on research modules with real companies. You will run interviews, conduct usability tests, and present findings to stakeholders -- the same work you will be asked to do in a professional UX role.


---

# UX Design vs Graphic Design: What's the Difference?

URL: https://myuxacademy.com/blog/ux-design-vs-graphic-design/
UX design vs graphic design: how the two disciplines differ in skills, tools, day-to-day work, and UK salary. An honest breakdown for career-changers.

Both disciplines live under the word 'design'. Both attract people who care about how things look and feel. Both can produce work that ends up on a screen. And yet, UX design and graphic design are genuinely different jobs — different in what they ask you to do each day, different in the problems they solve, and different in how success is measured.

If you come from a graphic or visual design background and you are thinking about moving into UX, this article is written for you. Not to tell you that graphic design is less valuable — it is not — but to give you an honest account of what is different, what transfers, and what you would need to learn.

> **Making the move from graphic to UX design?** UX Academy (myuxacademy.com)'s [Beginner UX (AI) Design course](/courses/beginner-ux-design/) is built for people with a visual background who want to add research, prototyping, and product thinking. Cohort 1 starts 21 Sep 2026 -- [reserve your place with a £99 deposit](/courses/beginner-ux-design/). If you were previously studying at CareerFoundry, see our [CareerFoundry alternative page](/careerfoundry-alternative/) for a transition offer. Or [try the free masterclass first](/masterclass/free-ux-ui-masterclass/).

## What graphic design actually is

Graphic design is the practice of visual communication. A graphic designer shapes how information is presented and perceived — through typography, colour, layout, imagery, and hierarchy. The output is usually a finished visual artefact: a brand identity system, a poster, a packaging design, a magazine spread, an advertising campaign, a motion graphic.

The brief tends to be relatively well-defined. A client or creative director sets the objective, the graphic designer produces work that meets it, and the outcome is judged against aesthetic standards and whether it communicates the intended message. Revision rounds happen, but the process is broadly linear: brief to concept to execution to delivery.

Graphic design encompasses a wide range of specialisations — brand identity, editorial, advertising, motion, illustration, environmental. What they share is a focus on how things look and what they communicate through visual language.

## What UX design actually is

[UX design](/blog/what-is-ux-design/) — user experience design — is the practice of designing how people experience a product or service. In practice, this almost always means digital products: websites, apps, dashboards, onboarding flows, checkout processes.

The output of UX design is not a finished visual artefact. It is a solution to a user problem — one that has been tested with real people and iterated until it works. A UX designer might produce research findings, user journey maps, wireframes, interactive prototypes, and annotated handoff files for developers. What they are always trying to answer is: can people use this, and does it help them achieve what they came to do?

UX design sits inside product development cycles. It involves working closely with product managers, engineers, and data analysts. The work is explicitly collaborative and explicitly iterative.

## Where UX and graphic design overlap

The overlap is real, and if you come from graphic design it gives you a genuine head start.

**Visual hierarchy and layout.** UX design lives or dies on clear visual hierarchy. Users need to scan a screen and understand what matters, what is clickable, and what to do next. Graphic designers think about this instinctively. That skill transfers directly.

**Typography.** In UX, typography affects readability, accessibility, and cognitive load. A graphic designer who understands type — scale, spacing, contrast, line length — will produce wireframes and UI work that are immediately more usable than someone without that background.

**Colour theory.** Colour in UX is functional as well as aesthetic: it communicates status (errors, success states), guides attention, and must meet accessibility contrast standards. Graphic designers tend to have a more developed colour vocabulary than people coming into UX from other fields.

**Figma.** Figma has become the dominant tool across both disciplines. If you already work in Figma for graphic design, you have less tool-learning overhead than someone coming from a completely non-design background. UX work in Figma extends into prototyping and developer handoff modes, but the foundations are the same.

**Attention to detail and craft.** The care that good graphic designers bring to spacing, alignment, and consistency is exactly the mindset UX design needs. Sloppy layouts signal low trust to users. That standard of craft matters in product work.

## Where UX and graphic design diverge

This is where it gets honest.

### Focus: aesthetics versus behaviour

Graphic design's primary question is aesthetic and communicative: does this look right, does it convey the right message, does it reflect the brand? UX design's primary question is behavioural: can people use this, and do they? A UX designer who produces something beautiful that users cannot navigate has failed. A graphic designer who produces something technically imperfect but emotionally resonant may have succeeded entirely.

This is not a hierarchy. It is a different set of priorities, and they require different instincts.

### Research

This is the biggest structural difference between the two disciplines. UX designers conduct primary research as a core part of their job. That means user interviews, usability testing, contextual enquiry, surveys, and analysis of behavioural data. They use tools like Maze for unmoderated testing and Miro for synthesis. Research findings drive design decisions.

Graphic designers rarely conduct primary user research. They respond to briefs, work with client-supplied audience insights, and draw on cultural knowledge and aesthetic judgement. The information architecture of a UX designer's work week looks very different from a graphic designer's.

If you are making the switch from graphic to UX, research is the skill that will require the most active learning. It is also, for many people, the most interesting and satisfying part of the job.

### Iteration

UX design is explicitly and structurally iterative. You prototype, you test with users, you discover what does not work, you go back and redesign, you test again. This is not a sign that the first attempt failed — it is the method. The process expects imperfect first versions.

Graphic design tends toward a more linear workflow. Brief, concept exploration, refinement, client presentation, revisions, delivery. The revision rounds happen in response to client feedback, not in response to tested user behaviour. The mental model of the process is different.

### Measurement

UX design is measured against user behaviour. Did task completion rates improve? Did users reach the checkout? Did the onboarding flow reduce drop-off? These are quantifiable outcomes tied directly to business performance. A UX designer working in a product company will be expected to connect their design decisions to metrics.

Graphic design is more typically measured against aesthetic judgement and client satisfaction. These are real and valid standards, but they are different from the data-driven accountability UX designers operate under.

### Tools

Both disciplines use Figma. Beyond that, they diverge.

UX designers use prototyping and research tools — Maze for unmoderated usability testing, Miro or FigJam for research synthesis and journey mapping, Zeroheight or Storybook for design systems and developer handoff documentation, and analytics tools like PostHog, Hotjar, or Mixpanel to review behavioural data.

Graphic designers use Adobe Illustrator and InDesign extensively — tools built for print, illustration, and editorial production. These have limited relevance in day-to-day UX work, though Illustrator skills are useful for icon work and illustration assets.

### Collaboration

UX designers work inside product development teams. Their daily collaborators are product managers (who define what to build and why), engineers (who build it), and data analysts (who measure how it performs). This is a fundamentally different working environment from a studio or agency, where the closest collaborators are likely art directors, copywriters, and account managers.

If you are used to working with brand and marketing teams and presenting polished work to clients, working in product development will feel quite different — more continuous, less project-shaped, with fewer clear endpoints.

## Can a graphic designer transition to UX?

Yes. Genuinely. It is one of the most natural routes into UX.

Visual skills transfer strongly. Your layout thinking, your typography instincts, your colour sense, your standard of craft — these give you a foundation that someone coming from a non-design background has to build from scratch. Hiring managers can see that on a portfolio.

What you need to add:

- **Research skills.** How to plan and conduct user interviews. How to run a usability test. How to synthesise findings into insights that drive design decisions.
- **Information architecture.** How to structure content and navigation for digital products. How to think about user flows across multiple screens, not just individual layouts.
- **Prototyping.** How to build interactive prototypes in Figma that simulate real user journeys, not just static mockups.
- **Product literacy.** How product development cycles work, what an MVP is, how to work with agile or iterative delivery processes, how to talk to engineers about feasibility.

What you may need to unlearn:

The idea that your job is to produce a beautiful deliverable. In UX, the deliverable is almost never the point. The point is whether the thing you designed works for real people. This sounds like a small reframe, but in practice it changes how you approach nearly every decision.

**Portfolio advice for the transition.** You do not need to wait until you have a paid UX job to build a portfolio. Pick one or two personal or volunteer projects — a local charity's website, a mobile app concept, a redesign of something you use regularly — and use them to show UX process end to end: research, synthesis, wireframes, prototype, usability testing, and iteration. Hiring managers want to see how you think and how you work, not just what the final screens look like. Final screens are what a graphic design portfolio shows. A UX portfolio shows the reasoning behind the screens.

See also: [how to switch careers into UX design](/blog/switching-careers-to-ux-design/) and [how to become a UX designer](/blog/how-to-become-a-ux-designer/).

## Salary comparison: UX vs graphic design (UK, 2026)

If salary is part of your thinking, here is a straightforward comparison. The ranges below are drawn from UK-specific sources including ITJobsWatch, Reed.co.uk, and Glassdoor UK, and reflect typical 2026 figures rather than outliers.

**UX designers in the UK** typically earn:
- Junior (0-2 years): £28,000 to £38,000
- Mid-level (2-5 years): £35,000 to £55,000
- Senior (5+ years): £55,000 to £80,000+

**Graphic designers in the UK** typically earn:
- Junior (0-2 years): £22,000 to £28,000
- Mid-level (2-5 years): £25,000 to £40,000
- Senior (5+ years): Up to £50,000 in London, but senior roles at this level are less common than in UX

The pay differential reflects where each discipline sits in the commercial landscape. UX design is embedded in product and technology companies, where design work is directly tied to revenue metrics. The demand has grown substantially over the past decade and salaries have followed.

For a more detailed breakdown, see [UX designer salaries in the UK](/blog/ux-designer-salary-uk/).

It is worth noting that some graphic design roles — particularly at senior levels in large agencies or in-house at major brands — can pay competitively. But the UX salary floor tends to be higher, and the progression is faster at mid to senior level.

## A note on UI design

It is worth briefly clarifying where [UI design fits in relation to both](/blog/ux-vs-ui-design/). UI (user interface) design sits closer to graphic design in terms of visual output — it is about the visual layer of a digital product: buttons, icons, typography, colour systems, component libraries. Many graphic designers move into UI design first as a stepping stone, because the visual skill set transfers more directly.

UX design is broader and sits upstream of UI. UX defines what needs to be designed and why. UI defines how it looks. In practice, many roles combine both — especially at startups and smaller companies where one designer covers research through to final visual polish.

If the research and process side of UX interests you, a combined UX/UI role is a realistic and common entry point for graphic designers making the switch.

## Ready to make the switch?

If you are a graphic designer who is seriously considering UX, the [Beginner UX (AI) Design](/courses/beginner-ux-design/) course at UX Academy is built specifically for this kind of transition.

Over eight weeks of live online sessions, you will build the research skills that graphic design does not teach, learn UX process from the ground up, and develop a portfolio case study that shows the full arc of UX work — from user interviews through to a tested prototype. Cohorts are capped at 15 students. The small group size means you get real feedback on your work, not just access to recorded content.

Your visual background is an asset here. You will not be starting from zero. You will be adding to what you already know.

[View the Beginner UX (AI) Design course](/courses/beginner-ux-design/) to see the curriculum, cohort dates, and what past students have gone on to do.


---

# UX Design Tools: The Full Stack Explained (2026)

URL: https://myuxacademy.com/blog/ux-design-tools/
The essential UX design tools for 2026: Figma for design and prototyping, Maze for testing, Miro for workshops. What each one does and when to use it.

A question that comes up constantly from people moving into UX design: "What tools do I need to learn?"

It is a fair question. UX design involves a range of different activities — sketching ideas, building wireframes, creating prototypes, running research sessions, analysing data — and different tools support each stage. Unlike a developer who might live in one IDE, a UX designer moves between several tools depending on the task.

But the toolkit is smaller than people expect. And if you are just starting out, the answer to "where do I begin?" is straightforward: start with Figma.

> **Learn the tools in context, not in isolation.** UX Academy (myuxacademy.com)'s [Beginner UX (AI) Design course](/courses/beginner-ux-design/) teaches Figma and the full UX toolkit through live, hands-on projects. Cohort 1 starts 21 Sep 2026 -- [secure your place with a £99 deposit](/courses/beginner-ux-design/). Or [try the free masterclass first](/masterclass/free-ux-ui-masterclass/).

## Start here: the honest advice for beginners

Before going through the full toolkit, one thing is worth saying directly.

Many people researching UX tools get overwhelmed by the number of options and try to learn several at once. That is the wrong approach. The tools that matter most early on are:

1. **Figma** — non-negotiable; learn this first
2. **Miro or FigJam** — for collaborative exercises
3. **One research tool** (Maze or Lyssna) — when you get to that stage of your training

Everything else can wait until you are in a role and a specific job requires it. The tool is never the barrier to getting hired. Your ability to do the thinking behind the tool is what matters.

---

## Design and prototyping

This is where UX designers spend most of their screen time, and Figma dominates.

### Figma

Figma is the industry standard for UX and product design. It is used by the vast majority of product teams, from early-stage startups to large organisations. If you are going to learn one tool, this is it.

What makes Figma the right choice:

- **Web-based and collaborative.** You design in the browser. Your team can open the same file simultaneously and leave comments in real time — no emailing files back and forth.
- **Covers the full workflow.** You can go from rough wireframe to polished high-fidelity screen to clickable prototype without leaving Figma.
- **Free tier is genuinely useful.** The free plan lets you work on multiple files and share them publicly. For learning and building a portfolio, it is more than enough.
- **Industry adoption.** Most job listings for UX roles expect Figma. In London especially, it is close to universal in product teams.

If you want to go deeper on Figma specifically, see our guides on [what Figma is](/blog/what-is-figma/) and [how to get started with Figma as a beginner](/blog/figma-for-beginners/).

### Adobe XD

Adobe XD was Adobe's answer to Figma. It is still used in some agencies that have deep Adobe Creative Suite workflows, but it has lost significant ground. Adobe itself announced in 2023 that it was deprioritising XD development. You do not need to prioritise learning it — if you know Figma, XD is easy enough to pick up if a specific role requires it.

### Sketch

Sketch is a Mac-only design tool that was the industry standard before Figma. It is still present in some mature London design teams, particularly those that built their design systems before the shift to Figma. It is worth knowing it exists, but there is no good reason to prioritise it when you are starting out.

**Verdict: learn Figma. The others are easy to pick up if a specific job requires them.**

For a detailed side-by-side comparison of Figma and Sketch, see [Figma vs Sketch: which should you use?](/blog/figma-vs-sketch/).

---

## Wireframing and lo-fi sketching

Wireframing is the process of sketching out the structure of an interface before you commit to visual design. The tools here are intentionally rough — the point is to explore ideas quickly.

### Paper and pen

Do not underestimate this. Experienced designers frequently start with paper sketches before opening any software. It is faster for early ideation, has no learning curve, and keeps you from getting attached to visual details too early. A whiteboard works equally well for team sessions.

### Figma (wireframing kits)

Figma has built-in wireframing capabilities and a large library of free wireframe kits available in the Figma Community. Most designers do their wireframing directly in Figma so everything stays in one file. There is rarely a reason to use a separate tool.

### Balsamiq

Balsamiq is a deliberately lo-fi wireframing tool. Its sketchy, hand-drawn aesthetic is intentional — it signals to stakeholders that they are looking at a rough concept, not a finished design. Some designers like it for early stakeholder presentations for exactly this reason. It is not essential, but it has a straightforward interface and a free trial.

**Verdict: use Figma for most wireframing; paper for early ideation; Balsamiq if you want something that reads as explicitly rough.**

---

## Collaboration and workshop facilitation

UX design involves a lot of facilitation — workshops, design sprints, affinity mapping sessions, journey mapping exercises. These typically happen on a virtual whiteboard, especially in remote or hybrid teams.

### Miro

Miro is the dominant virtual whiteboard tool for design teams. It is particularly good for:

- Affinity mapping (organising research findings into themes)
- Journey mapping
- Design sprint facilitation
- Remote workshops with multiple participants

The free tier allows three boards, which is enough to get started and to use it in a course or bootcamp context. Miro is widely used enough that knowing how to run a session in it is a practical skill.

### FigJam

FigJam is Figma's built-in collaborative whiteboard. It is tightly integrated with the Figma ecosystem, so if you are already working in Figma, switching to FigJam for a quick workshop session is seamless. It is less fully featured than Miro for complex facilitation work, but more than capable for most purposes.

**Verdict: Miro for complex collaborative sessions and formal workshops; FigJam for quick exercises when you are already in the Figma ecosystem.**

---

## User research and testing

UX research has its own toolset, and you will encounter these once you move into the research and testing phases of a project. The good news is that most have free plans that are suitable for portfolio projects.

For a broader look at research methods and when to use them, see our [UX research methods guide](/blog/ux-research-methods/).

### Maze

Maze lets you run unmoderated usability tests on Figma prototypes. Participants complete tasks on their own device, and Maze records where they clicked, how long they took, and where they gave up. It is quick to set up and generates quantitative usability data — useful when you need to test with larger numbers of participants. Free plan available.

### Lyssna (formerly UsabilityHub)

Lyssna offers a range of research formats: preference tests, five-second tests, click tests, and unmoderated task-based tests. It is particularly useful for quick, lightweight tests early in the design process — for example, testing which of two homepage layouts feels clearer, or whether users understand an icon without a label. Free tier available.

### Dovetail

Dovetail is a research repository and analysis tool. If you are doing qualitative research — user interviews, diary studies, usability sessions — Dovetail helps you tag, organise, and synthesise your notes and transcripts. It is especially useful on teams where multiple researchers are working on the same project. Less relevant for early learners, but worth knowing about.

### Lookback

Lookback supports both moderated and unmoderated research sessions, with screen and camera recording. It is widely used for remote user interviews where you want to see the participant's face and screen simultaneously. Has a free trial.

### Google Forms and Typeform

Do not overlook surveys. For quantitative research — gathering data at scale, testing assumptions, running screener surveys before interviews — Google Forms is free and more capable than its plain interface suggests. Typeform has a more polished participant experience and a free tier. Many professional UX researchers use surveys regularly alongside qualitative methods.

---

## Analytics and behaviour tracking

These are not "design tools" in the traditional sense, but UX designers use them regularly to identify where users are struggling before any design work begins. Understanding analytics data is increasingly expected of UX designers, particularly in product roles.

### Hotjar

Hotjar provides heatmaps, session recordings, and on-site surveys. Heatmaps show where users click and scroll on a page. Session recordings let you watch real users navigate your product. It is one of the most widely used tools for this kind of diagnostic work, and the free tier is useful for smaller sites.

### Google Analytics / GA4

GA4 is the standard for web traffic and conversion data. Every UX designer working in digital products should be able to read a GA dashboard — understanding bounce rates, funnel drop-off, and traffic sources is part of diagnosing usability problems at a product level. It is free and, despite its reputation for complexity, the basics are learnable quickly.

### PostHog

PostHog is an open-source alternative to tools like Mixpanel and Amplitude, popular with early-stage startups and technical teams. It combines product analytics, session recording, and feature flagging. Worth knowing about if you are heading into startup or scale-up environments.

---

## Handoff and developer collaboration

Once a design is ready to build, it needs to be handed off to engineers in a way they can work from. This is an often-underestimated skill.

### Figma's developer mode

Figma has a built-in developer mode that generates specs, measurements, spacing values, and code snippets directly from your design files. This is now the standard handoff workflow in most teams. Engineers can inspect your Figma file themselves rather than waiting for you to document everything manually.

Good handoff is a skill in its own right. A well-organised Figma file with consistent naming, a clear layer structure, and properly defined components makes a significant difference to how smoothly a build goes.

### Zeplin

Zeplin was a dedicated design handoff tool that was widely used before Figma's developer mode matured. Some teams still use it, particularly where the design-to-development workflow is more formalised. It is not something to prioritise learning, but it is easy to pick up if you encounter it.

---

## AI tools for UX designers

AI is changing parts of the UX workflow, particularly in areas like writing UX copy, generating user personas, and synthesising research. This is a fast-moving area and worth a dedicated look. For a full breakdown, see our guide on [AI tools for UX designers](/blog/ai-tools-for-ux-designers/).

---

## Where to start

The toolkit described above covers the full range of what UX designers use day-to-day. If you are just starting out, do not try to learn all of it at once. The realistic starting point is:

- **Figma** — learn it properly, including prototyping and basic component organisation
- **Miro or FigJam** — use it in a workshop context
- **One research tool** — Maze or Lyssna, once you reach that stage

The rest becomes relevant once you are working on real projects with real teams.

On the [Beginner UX (AI) Design course](/courses/beginner-ux-design/) at UX Academy, you learn Figma hands-on from day one. By the end of the course you will have used it across a full design project — wireframes, high-fidelity screens, and a clickable prototype — with live feedback from an instructor who works in the industry. No prior design experience required.


---

# The UX Design Process: Steps, Methods and How It Works

URL: https://myuxacademy.com/blog/ux-design-process/
The UX design process explained: discovery, research, prototyping, testing and handoff. How real UX teams work in practice, not the textbook version.

If you search for "UX design process" you will find a lot of diagrams with five neat boxes and arrows between them. The reality is messier and more interesting than that.

The UX design process does have recognisable stages. Understanding them is essential if you are [considering a career in UX design](/blog/what-is-ux-design/) or trying to understand what UX designers actually do all day. But the stages do not run in a straight line, teams skip backwards constantly, and in an agile product team a full "cycle" might fit inside a two-week sprint.

This post explains what each stage involves, how they connect, and what working through them actually looks like on a real project.

> **Ready to learn the full process hands-on?** UX Academy (myuxacademy.com)'s [Beginner UX (AI) Design course](/courses/beginner-ux-design/) walks you through every stage live, with working professionals. Cohort 1 starts 21 Sep 2026 -- [reserve your place with a £99 deposit](/courses/beginner-ux-design/). Or [try the free masterclass first](/masterclass/free-ux-ui-masterclass/).

## Why process matters

Teams without a shared process produce inconsistent work. Two designers on the same team will approach a problem differently, make decisions for different reasons, and produce designs that conflict with each other and with what users actually need.

Process is not about following rules. It is about making sure that decisions are grounded in evidence, that the problem is understood before the solution is reached, and that the people who will use the product are involved before build begins rather than after.

The other reason process matters: it is what you are hired to bring to a team. Any reasonably competent person can learn a design tool. What takes longer to develop is the ability to run a research session, make sense of conflicting data, frame the right design problem, and know when a prototype is good enough to test.

## The core stages

### 1. Discovery and scoping

Every project starts with a brief of some kind. A product manager has a problem they want solved. A client has a business goal. An executive has noticed a metric they want to change.

Discovery is the stage where you interrogate the brief before accepting it. What is the actual problem here? Whose problem is it? What constraints exist — technical, commercial, regulatory, time? What has already been tried?

This usually involves conversations with stakeholders: the people who commissioned the work, the people who will build it, and sometimes legal or compliance teams if the product touches sensitive areas. The output is a shared understanding of scope and goals, documented well enough that the team can refer back to it when decisions get contested later.

Skipping discovery is one of the most common mistakes junior designers make. It feels like a shortcut to get to the designing faster. It usually means redesigning things twice.

### 2. Research

Research is how you find out what users actually need, rather than what stakeholders assume they need. The two are often different.

The main methods at this stage are user interviews, contextual enquiry (watching people do the thing in their real environment), surveys for quantitative signal, analysis of existing data (analytics, support tickets, previous research), and competitive analysis to understand what alternatives exist.

[UX research methods](/blog/ux-research-methods/) is a large topic. The short version is that good research at this stage is about asking open questions, observing real behaviour, and resisting the urge to confirm what you already think. Confirmation bias in research is not unusual. Guarding against it is a skill.

The output of research is raw data: interview notes, recordings, survey responses, analytics exports. That data is not yet useful until you have made sense of it.

### 3. Synthesis

Synthesis is the work of turning raw research data into insight. It is the stage that most newcomers to UX underestimate.

The main techniques are affinity mapping (grouping observations and quotes by theme to find patterns), journey mapping (charting the steps a user takes through an experience and where friction occurs), and personas (composite profiles that represent different user types based on research rather than assumption).

Synthesis usually involves collaborative sessions where the team works through the data together, often on a physical or digital whiteboard. Tools like Miro and FigJam are built for this. The reason you involve the team rather than doing it alone is that synthesis is interpretive, and having multiple people challenge each other's interpretations produces more reliable insight.

The output is a defined problem statement or set of "how might we" questions that the ideation stage will work from.

### 4. Ideation

Ideation is where solutions are generated. The key word is "generated" rather than "chosen" — the goal of ideation is quantity first, quality later.

Common formats are "how might we" question framing (turning a problem statement into a generative question), individual sketching followed by sharing, and design studios where the team sketches multiple solutions and discusses the ideas rather than the people who produced them.

Good ideation is deliberately uncritical. Evaluating ideas too early in the process kills the less obvious solutions before they have been considered. The evaluation comes after, when there are enough options to compare.

The output is a set of candidate directions, usually as rough sketches or concept notes, ready to be narrowed down and taken into prototyping.

### 5. Prototyping

A prototype is a representation of a design that can be tested without being built. The question at this stage is always: what is the minimum fidelity needed to test the thing we need to learn?

**Lo-fi prototypes** — paper sketches, rough wireframes, basic clickable flows in Figma — are fast to produce and fast to throw away. They are right for early-stage testing when the fundamental structure of the experience is still in question. They also communicate cheapness clearly, which encourages test participants to be honest rather than polite.

**Hi-fi prototypes** — detailed Figma files with real UI, realistic copy, interactive components — are right when the structure is settled and you need to test specific interactions, visual design decisions, or edge cases. They take longer to build and are harder to revise, so using them too early is expensive.

The most common prototyping mistake is jumping to hi-fi before the core flow has been validated. This is partly because hi-fi looks more impressive in stakeholder reviews, which creates the wrong incentive.

### 6. Usability testing

Usability testing means putting the prototype in front of real users and watching what happens. Not asking them if they like it. Watching what they do, where they get stuck, and what they say while they are doing the task.

The standard format is a moderated session: one facilitator, one participant, a set of tasks to complete, and a recording running. Five to eight sessions is usually enough to surface the main patterns. You are not looking for statistical significance — you are looking for friction, confusion, and failure points.

[Heuristic evaluation](/blog/heuristic-evaluation-ux-design/) is an alternative method when you cannot recruit participants quickly — a structured review of the design against established usability principles. It is faster and cheaper than testing but less reliable because it replaces real user behaviour with expert judgement.

The output of testing is a prioritised list of issues to address before the next iteration or before build begins.

### 7. Handoff

Handoff is the point where the design is transferred to engineering for build. A poor handoff is one of the most common sources of quality loss in product development.

A good handoff means the design files are organised and annotated in Figma: component states documented, spacing and sizing specified, interaction behaviour described, edge cases covered. It also means being available to answer questions during build rather than disappearing after the design is "done."

The [distinction between UX and UI design](/blog/ux-vs-ui-design/) becomes concrete at handoff. The UX layer — flows, information architecture, component logic — is what the engineering team builds from. The UI layer — visual polish, motion, brand details — is what makes it look right. Both need to be in the handoff package, but they are different things and they require different attention during build review.

Handoff is also where designers learn whether their decisions are actually buildable. Some things that look straightforward in Figma are expensive or technically complex to implement. Building a good relationship with engineering early in the process — not just at handoff — makes this less likely to become a problem.

### 8. Launch and iteration

Launch is not the end of the process. It is the beginning of the next research cycle.

After launch, analytics data shows what users are actually doing with the shipped product. Support tickets surface problems that testing did not catch. A/B tests (where they are appropriate) give signal on specific design decisions. This data feeds back into discovery for the next iteration.

In a product team, this loop runs continuously. There is no "finished" state — only the current version and the queue of improvements being worked on. Understanding this is important for anyone coming from a background where projects have a defined end.

## The Double Diamond

The Double Diamond is a model developed by the Design Council that is worth knowing because it explains the underlying logic of the process clearly.

The idea is that good design involves two rounds of diverge-then-converge thinking. The first diamond is about the problem: you start by opening up your understanding of the situation (research, discovery), then converge on the right problem to solve (synthesis, problem definition). The second diamond is about the solution: you open up again with possible approaches (ideation, prototyping), then converge on the right solution to build (testing, iteration).

In practice, most teams compress this. The two diamonds run simultaneously rather than sequentially, loops happen within each stage, and commercial pressure means the converging usually happens faster than it should. Knowing the model is useful because it helps you diagnose where a team is cutting corners and what the likely consequences are.

## Process in agile teams

Agile product development works in short cycles called sprints, typically two weeks. UX work has to fit inside those cycles, which means the full research-to-handoff arc gets compressed.

What this usually looks like in practice is "dual-track" agile: one track doing discovery and design work that stays one or two sprints ahead of engineering, and one track building from designs that have already been validated. Research happens continuously rather than in a dedicated phase. Synthesis and ideation are squeezed into shorter sessions. Prototyping is often just enough to test the critical interaction before build starts.

The thinking does not change. The timelines do. [Doing UX research in agile development](/blog/ux-research-agile-development/) requires knowing what you can compress without losing the signal and what you cannot cut without guessing.

## Tools at each stage

The tools UX designers use map fairly closely to the stages described above:

- **Discovery and research:** Google Docs or Notion for brief documentation, interview recording tools (Teams, Zoom, Lookback), survey platforms (Typeform, Google Forms)
- **Synthesis:** Miro or FigJam for affinity mapping and journey mapping, Dovetail or Notion for storing and tagging research notes
- **Ideation:** Paper and pen first, then Miro or FigJam for structured sessions
- **Prototyping:** Figma for both lo-fi and hi-fi work — it handles the full range from rough wireframes to interactive prototypes
- **Testing:** Maze or Lyssna for unmoderated testing, Lookback or Zoom for moderated sessions
- **Handoff:** Figma again, with organised layers, components, and annotations; Zeplin is still used in some teams

The tools matter less than the thinking. Designers who understand the process can use unfamiliar tools. Designers who know the tools but not the process are applying techniques without understanding why.

## Learning the process in practice

Reading about the UX design process gives you a map. Working through it on a real project gives you the experience of using one.

The difference matters more than people expect. Interview techniques that read straightforwardly are hard to execute when a participant gives one-word answers. Synthesis that looks logical as a framework is genuinely difficult when you are staring at 40 interview quotes that seem to point in different directions. Presenting design decisions to a sceptical stakeholder requires a different skill set from making those decisions in the first place.

That gap between knowing and doing is why portfolio projects made from tutorial briefs rarely communicate the right things to hiring managers. They show you can use Figma. They do not show you can run a process.

On the [Beginner UX (AI) Design](/courses/beginner-ux-design/) and [UX Career Track](/courses/ux-career-track/) courses at UX Academy, you work through a real client brief end-to-end, from discovery through to a tested and presented final design. The instructors who run the process with you have done it professionally at companies including Adobe, Google, and Canva. If you are [switching careers to UX design](/blog/switching-careers-to-ux-design/), that kind of grounded, supervised practice is what builds the confidence to run the process on your own.


---

# UX Portfolio Examples: Real Portfolios Reviewed & Rated

URL: https://myuxacademy.com/blog/ux-design-portfolio-examples/
Real UX portfolio examples broken down: what good case studies look like, what hiring managers notice first, and exactly what to copy.

Your CV will get you a conversation. Your portfolio will get you hired.

Most hiring managers spend two to three minutes on a portfolio on first pass. A significant number make up their minds in the first thirty seconds. Not because they are being harsh, but because most portfolios make the same mistakes immediately obvious, and experienced reviewers have learned to spot them fast.

This post breaks down what those mistakes are, what a strong UX portfolio actually looks like, and how to build one even if you are starting from scratch. We have also included examples from [UX Academy graduates](/student-work/) who built their portfolios through real client projects.

> **Build a portfolio worth showing.** Every UX Academy course includes real client briefs and structured portfolio feedback. Cohort 1 starts 21 Sep 2026 -- [secure your place with a £99 deposit](/courses/beginner-ux-design/).

---

## What hiring managers are actually looking at

When a recruiter or design lead opens your portfolio, they are not asking "does this look beautiful?" They are asking a different set of questions, usually in this order:

**Can this person solve a problem?** UX is a problem-solving discipline. The work you show needs to demonstrate that you start with understanding a problem rather than jumping to solutions.

**Is there evidence of process?** Research, user interviews, synthesis, iteration — these are the things that separate UX design from visual design. If your portfolio shows only final, polished screens, it looks like you skipped the work that matters most.

**Can they communicate their thinking?** A huge part of working in UX is explaining decisions to stakeholders, developers, and product managers. Your portfolio is the first test of whether you can do that clearly.

**Have they worked on something real?** Not necessarily a paid job — but a project with real constraints, real users, and decisions that were genuinely hard to make. The difference between a real project and a contrived exercise tends to be obvious to anyone who has hired before.

---

## The anatomy of a strong UX case study

A case study is not a design showcase. It is a documented piece of thinking. Here is what a strong one contains:

### Context

Set up the brief. What was the problem, who were the users, what were the constraints? This section should be short but specific. "I redesigned an app" is not context. "The existing checkout flow had a 68% drop-off rate on mobile, and the business needed to understand why before committing to a rebuild" is context.

### Research

What did you actually find out, and how? Walk through the methods you used — user interviews, usability testing, desk research, analytics review — and give the reader a sense of what surprised you. Research that is just listed ("I conducted five user interviews") is weaker than research that shows what you learned from it.

### Synthesis

This is the step most portfolios skip. What were the key insights that came out of your research? How did those insights shape the direction you took? If you can show the link between "this is what users told us" and "this is the design decision we made as a result", your case study will be in the top tier.

### Design process

Show the thinking, not just the output. Wireframes, early prototypes, iterations, ideas that were tried and rejected — all of this is valuable. A single polished final screen tells a hiring manager nothing about how you got there. Three rough wireframes that show your reasoning tell them a lot.

Do not be afraid to include things that did not work. Showing that you tested an idea, found it failed, and changed direction is evidence of exactly the kind of iterative thinking that companies want.

### Outcome

What was tested? What changed as a result? What would you do differently with more time or resource? If you have metrics, use them. If you do not, describe what qualitative evidence you have that the design moved in the right direction.

### Length and format

A case study should be scannable in five minutes. Use clear headings, keep your paragraphs short, and make sure every section earns its place. Long does not mean thorough. A case study that buries the interesting parts in dense paragraphs will lose readers quickly.

---

## Common portfolio mistakes (and how to avoid them)

These come up constantly in portfolio reviews. If you recognise any of them in your own work, that is useful information.

**Only showing final screens.** A portfolio full of beautiful mockups with no process looks like a visual design portfolio, not a UX one. Show the messy middle.

**Describing what you did rather than why.** "I created wireframes, then prototypes, then conducted usability tests" describes a sequence of activities. What hiring managers want to know is why you made the specific decisions you made, and what evidence you had for them.

**Fake redesigns of well-known apps.** This is the most common mistake in early-career portfolios. "I redesigned the Spotify playlist experience" as a self-initiated project with no real users, no real constraints, and no real brief is not evidence of UX skill. It shows you can copy existing patterns with a different visual treatment. If you are going to redesign a product you know well, treat it as a proper brief: recruit real users, conduct actual research, document decisions honestly.

**Too many projects.** Eight case studies, each half-finished, is much weaker than three that are properly developed. Two excellent case studies will get you further than eight mediocre ones.

**No real users anywhere.** Portfolios that show design artefacts but no evidence of talking to actual humans raise a red flag. Even a small round of interviews or a handful of usability testing sessions signals that you understand UX is not just about design decisions in isolation.

**A portfolio site that is harder to use than the projects it showcases.** The irony of a difficult-to-navigate UX portfolio is not lost on hiring managers. Keep navigation simple. Make it easy to find each case study. Do not bury the work.

---

## Portfolio formats that work

The platform you use matters far less than the clarity of the work inside it. That said, here are the formats that tend to work well:

**Notion portfolios.** Fast to build, easy to update, and perfectly functional for early-career candidates. Notion has become a genuinely accepted format — do not let anyone tell you it is not "professional enough".

**Dedicated portfolio sites.** Webflow, Squarespace, and Adobe Portfolio are all solid options if you want more visual control. Webflow in particular can itself become a portfolio piece if you build it well.

**PDF case studies.** Useful for direct outreach, where you are sending your work to a specific person rather than waiting for them to find you. A well-formatted PDF case study sent directly to a hiring manager cuts through in a way that a portfolio link sometimes does not.

Whatever format you choose, prioritise loading speed, legibility on mobile, and navigation that does not require explanation. If someone has to figure out how to read your portfolio, you have already lost them.

---

## What "no experience" actually means

Most people entering UX feel that the phrase "we want someone with experience" closes a door before it has opened. It is worth being precise about what experience actually means in this context.

A portfolio does not need paid work. It needs evidence of UX thinking applied to a real problem with real users. There are several routes to that:

**Personal projects.** Pick a product you genuinely use and find frustrating. Treat it as a real brief: define the problem, recruit users from your network, conduct interviews, run usability tests, iterate on your designs. The product does not need to be obscure. The research and process are what matter.

**Volunteer work.** Local charities, small start-ups, and non-profit organisations often have real UX problems and very little design resource. Offering to do user research or redesign a key flow in exchange for portfolio permission is a genuine exchange of value, and it gives you real constraints and real users.

**Course projects with real clients.** This is where the quality of the course matters significantly. A course that gives you a fictional brief is not the same as one that puts you in front of an actual client with an actual problem. The latter produces portfolio work that stands on its own.

See also: [how to get a UX job with no experience](/blog/ux-job-with-no-experience/) and [how to become a UX designer](/blog/how-to-become-a-ux-designer/).

---

## UX Academy graduate portfolio examples

Students at UX Academy work on real client projects throughout the course. That means actual companies, actual users, and actual problems — not fictional briefs designed to be safely solvable.

Past client projects have included Avasa, HopStair, and Welfound, among others. Students conduct their own user research, present findings to real stakeholders, and iterate based on feedback from people who actually care about the outcome. That process produces case studies that are meaningfully different from self-initiated redesigns, because the constraints were real and the decisions were genuinely hard.

You can see examples of graduate work at [myuxacademy.com/student-work/](/student-work/).

For more guidance on what reviewers look for, our [UX portfolio review checklist](/resources/templates/portfolio-review/) walks through the criteria systematically. If you are deciding where to start, the [UX portfolio guide](/blog/ux-design-portfolio-guide/) covers how to structure your work for interviews, and [how to build a UX portfolio from scratch](/blog/how-to-build-a-ux-portfolio-from-scratch/) is the place to begin if you have no design experience yet.

---

## The practical summary

If you are at the research stage and trying to understand what makes a UX portfolio good, here is the short version:

- Show your process, not just your output
- Explain why, not just what
- Include real users in every project
- Two or three strong case studies beats eight weak ones
- The platform does not matter; the clarity of the thinking does
- "No experience" is not a blocker if you treat early projects like real work

The difference between a portfolio that gets ignored and one that gets an interview is almost always process documentation, not visual polish.

---

## Build a portfolio with a real client brief

If you want to build portfolio work that looks like the examples above, the [Beginner UX (AI) Design](/courses/beginner-ux-design/) and [UX Career Track](/courses/ux-career-track/) courses at UX Academy are built around exactly that.

You will work on a real client project, conduct real user research, and receive feedback from instructors who have hired UX designers at Adobe, Google, and Canva. The brief is not invented for the course — it is a genuine company with a genuine problem, and the work you produce is yours to take into your portfolio.

The next cohort starts <CohortDate />. [Find out more about the courses](/courses/) or [see what previous students have built](/student-work/).

If you want to see what live UX training feels like before committing, the [free UX masterclass at UX Academy (myuxacademy.com)](/masterclass/free-ux-ui-masterclass/) is the place to start.


---

# UX Design Jobs UK 2026: Salaries, Sectors and Hiring

URL: https://myuxacademy.com/blog/ux-design-jobs-uk/
UX design jobs in the UK in 2026: where the roles are, which sectors are hiring, what employers look for, and a realistic job search timeline.

The UX design job market in the UK has been through a rough patch. 2023 and 2024 brought rounds of tech layoffs — Amazon, Meta, and various UK-based product companies all cut headcount, and UX was not spared. Junior roles dried up faster than senior ones as companies consolidated design teams and paused graduate hiring.

In 2025 and into 2026, things have stabilised. It is not the frenzied hiring market of 2021-2022, and it would be dishonest to frame it as one. But UX remains a viable, in-demand profession with real opportunities across the UK — particularly for candidates who have built credible portfolios and can demonstrate the skills employers actually need.

This post covers what the market looks like right now: where roles are, which sectors are hiring, what employers expect, and what a realistic job search looks like if you are transitioning into UX design.

> **Considering a career change into UX?** UX Academy (myuxacademy.com)'s [Beginner UX (AI) Design course](/courses/beginner-ux-design/) is built for career-changers and includes portfolio projects that employers actually notice. Cohort 1 starts 21 Sep 2026 -- [secure your place with a £99 deposit](/courses/beginner-ux-design/). Previously studying with CareerFoundry? See our [CareerFoundry alternative page](/careerfoundry-alternative/) for a transition offer. Or [try the free masterclass first](/masterclass/free-ux-ui-masterclass/).

## The State of the Market in 2026

The clearest way to understand the current market is to split it by experience level.

**Senior UX roles (5+ years)** are hiring steadily. Financial services, retail, healthcare, and the public sector all have ongoing demand for experienced designers who can lead projects, manage stakeholders, and navigate complex organisational environments. Competition exists, but qualified candidates are moving.

**Mid-level roles (2 to 5 years)** are competitive but accessible with a strong portfolio. Companies that paused hiring in 2023-2024 are cautiously rebuilding design capacity, and mid-level is where most of that budget is going. If your portfolio shows genuine UX work — research, synthesis, iteration — rather than just Figma mockups, you are a viable candidate.

**Entry-level and junior roles** are the tightest part of the market. Larger companies in particular have shifted their preference toward mid-level hires, reasoning that they get more output for the same headcount. This is a real pattern, not a myth, and it is worth being clear-eyed about it.

That said, junior roles do exist. Start-ups that are building out their first design function often need junior designers who can execute. Agencies hire more at entry level than product companies do — they need to scale delivery capacity, and a junior with the right foundations is useful to them. Companies in industries that are newer to UX (some parts of manufacturing, professional services, local government) also hire at junior level because they do not yet have the internal calibration to demand mid-level skills.

One other contextual factor worth mentioning: [CareerFoundry closed in 2025](/blog/careerfoundry-closed-what-happened/), displacing a wave of part-qualified students partway through their training. In the short term this increased competition — more people claiming UX credentials without a complete portfolio or qualification. Over time, it signals that the market favours better-quality, more structured training over self-paced programmes that candidates can stall on indefinitely.

## Where UX Design Jobs Are in the UK

**London** is the largest market by a significant margin. Roughly 60 to 70 percent of UK UX job listings are London-based. Financial services employers — HSBC, Barclays, Lloyds — hire UX designers at scale. Retail and e-commerce (ASOS, M&S, Ocado) have well-established design functions. The London offices of Amazon, Google, and Meta all run UX teams. Consulting firms and digital agencies add further volume. If you are willing to work in or around London, your options are widest.

**Manchester** has developed a genuine tech and digital scene. The BBC's digital operations, Co-op, AutoTrader, and The Very Group are among the employers with active UX teams. The cost of living relative to London makes it an attractive target for candidates who do not want to be based in the capital.

**Bristol** has a strong digital and creative sector. Dyson, Channel 4 Digital, and a cluster of agencies and start-ups make it one of the more active markets outside London. It also has a well-networked UX community.

**Edinburgh** punches above its size. Skyscanner, FanDuel, and Arnold Clark are among the employers with established UX practices. The financial services sector adds further demand.

**Leeds** has a growing fintech and public sector presence. Sky, Asda, and various NHS Digital roles are based there. It is an underrated market that many candidates overlook.

**Remote and hybrid** has genuinely changed the picture for candidates outside these cities. A large proportion of UX roles now advertise hybrid working, and some are fully remote. This is not a guarantee — many employers still expect at least partial office presence — but it does meaningfully expand the options for candidates based in smaller cities or rural areas.

## What UK Employers Look For

The single most consistent filter in UX hiring is the portfolio. Not the visual finish of the work, but whether it demonstrates a UX process. Employers want to see that you started with a problem, spoke to users, synthesised what you learned, made design decisions based on evidence, and iterated. Portfolios that show polished final screens without the thinking behind them do not pass the filter.

Beyond the portfolio, the practical requirements are fairly consistent across employers:

**Research skills.** Evidence that you have conducted user interviews, usability testing, or other research methods — and that you used the findings to drive design decisions rather than just filing them away.

**Figma proficiency.** Non-negotiable in 2026. You should be fluent with components, auto-layout, and prototyping at minimum.

**Communication.** Design does not exist in isolation. Employers consistently cite the ability to explain design rationale to product managers, engineers, and senior stakeholders — people who are not designers and do not share your vocabulary — as a core competency.

**Collaboration.** Understanding how to work within agile and sprint workflows, how to engage with product and engineering counterparts, and how to operate within organisational constraints rather than against them.

At senior level, the bar extends further: stakeholder management, the ability to run workshops and facilitate alignment, and design systems thinking. If you are targeting senior roles, your portfolio and interview answers need to show this range.

## Sectors with the Strongest UX Hiring

**Financial services and fintech** remain the highest-volume sector for UX roles in the UK, with some of the better salaries. The regulatory complexity of financial products — compliance requirements, accessibility obligations, the need to make complicated things understandable to consumers — makes rigorous UX genuinely valuable rather than cosmetic.

**NHS and the broader public sector** employ a significant number of UX designers, particularly through NHS Digital and various government digital transformation programmes. Hiring cycles are slower and the pay does not match the private sector, but the work is meaningful and the job security is real.

**E-commerce and retail** are data-rich environments where UX impact is measurable and appreciated. A/B testing culture means your decisions are tied to outcomes, which suits designers who want evidence of their impact.

**SaaS and B2B software** have strong demand for research skills. Complex products serving business users require deep understanding of workflows and context — the kind of work that rewards careful research over aesthetic instinct.

**Agencies and consultancies** hire at every level but particularly at junior, making them a realistic entry point for career-changers. The trade-off is variety versus depth — you will work across multiple briefs and industries, which accelerates learning, but you may not build as much domain expertise as you would in-house.

## Salary Benchmarks (UK, 2026)

These figures are indicative rather than definitive, drawn from UK sources including ITJobsWatch, Reed.co.uk, and LinkedIn Salary Insights. Salaries vary considerably by sector, company size, and specific role.

| Level | London | Outside London |
|-------|--------|----------------|
| Junior / entry level | £28,000 - £38,000 | £24,000 - £32,000 |
| Mid-level | £40,000 - £55,000 | £35,000 - £48,000 |
| Senior | £60,000 - £80,000 | £50,000 - £65,000 |
| Lead / Principal / Head of UX | £80,000 - £120,000+ | Varies significantly |

For a more detailed breakdown by sector and role type, see our post on [UX designer salaries in the UK](/blog/ux-designer-salary-uk/).

## How Long Does a Job Search Take?

The honest answer for career-changers: three to nine months from completing training, assuming you have a portfolio and are applying actively.

The range is wide because the variables matter. Portfolio quality is the biggest single factor — a portfolio with two or three real client or start-up projects will outperform one made up solely of course exercises, regardless of the visual quality. Location flexibility matters too: candidates willing to target London or to work hybrid have more options than those restricted to a specific city.

What tends to accelerate a job search:

- A portfolio that includes real work, not just bootcamp briefs
- Active networking on LinkedIn rather than passive job-board applications
- Targeting companies where UX already has internal advocates — look for job descriptions that mention research, not just wireframes
- Applying with targeted, specific cover letters that reference the company's product rather than generic applications

Volume alone does not work. Twenty well-researched applications to companies that are genuinely a fit will outperform a hundred generic submissions.

## How to Approach the Job Search Practically

**LinkedIn is the primary channel for UX hiring in the UK.** Recruiters actively search the platform, and a well-optimised profile with a clear headline, a portfolio link, and endorsements from people you have worked with will generate inbound interest over time. [Switching careers to UX design](/blog/switching-careers-to-ux-design/) covers how to frame a non-traditional background effectively.

**Go direct.** Most UX designers will take a short call with someone who is genuinely interested in their company and asks thoughtful questions. Reach out to designers at companies you want to work at. Do not ask for a job — ask to learn about their work. A significant number of junior hires originate from informal conversations rather than formal applications.

**Attend events.** The UX community in the UK is reasonably well-networked. UX London and UX Brighton are the largest annual conferences. Design Ethics Forum, local UX Crunch meetups, and London-based Design Ops events are useful for building relationships. Even if you are not based in London, attending one or two events a year is worth the travel.

**Job boards to use:** LinkedIn for volume (set up alerts for "UX Designer" in your target locations), Indeed, Wellfound (formerly AngelList) for start-up roles, Work in Startups, and Toptal if you want to consider freelance work while your full-time search runs in parallel.

For a detailed guide on breaking into the field without prior experience, see [how to get a UX job with no experience](/blog/ux-job-with-no-experience/) and [how to become a UX designer](/blog/how-to-become-a-ux-designer/). If you are weighing up training options, [are UX bootcamps worth it](/blog/are-ux-bootcamps-worth-it/) covers what to look for and what to avoid.

## What This Means If You Are Considering Training

The market in 2026 rewards specificity. Employers are not hiring on enthusiasm or credentials alone — they are hiring on evidence of UX thinking. That evidence comes from your portfolio, and your portfolio comes from the work you do during (and after) training.

The implication for anyone evaluating training programmes: the quality of the work experience component matters enormously. A programme that gives you access to real briefs, live clients, or start-up projects will produce a more competitive portfolio than one that relies solely on course exercises.

The [UX Career Track](/courses/ux-career-track/) at UX Academy is a 4-week extension for Beginner UX (AI) Design graduates: a second live client brief run as a design team — giving you a second real project to add to your portfolio — as well as structured job search support: portfolio critique, interview preparation, and LinkedIn optimisation. Cohorts are kept to a maximum of 15 students so that feedback is specific rather than generic. Graduates have secured roles at companies including Adobe and Google.

The next cohort starts <CohortDate />. If you are researching whether to make the move into UX, [starting with our guide to switching careers](/blog/switching-careers-to-ux-design/) is a good place to begin.


---

# UX Design Interview Questions: What to Expect

URL: https://myuxacademy.com/blog/ux-design-interview-questions/
UX design interview questions asked by UK employers: portfolio review, design challenges and behavioural questions, with guidance on how to answer each.

A UX design interview is not like most job interviews. There is no standard question sheet, no correct answer for "where do you see yourself in five years", and very little time spent on your CV once you are past the screening stage. Most of the evaluation happens in two places: your portfolio and your ability to walk through design decisions out loud.

If you have never been through a UX hiring process before, the format can catch you off guard. Interviewers are not just checking that you know what a user journey is. They are watching how you think, how you respond to challenge, and whether you can separate your aesthetic preferences from evidence-led decisions. This guide walks through every stage of the process, the questions you are likely to face, and how to answer each one well.

> **Build the portfolio and skills that survive interview scrutiny.** UX Academy (myuxacademy.com)'s [Beginner UX (AI) Design course](/courses/beginner-ux-design/) includes mock portfolio reviews and real client projects you can talk through in interviews with confidence. Cohort 1 starts 21 Sep 2026 -- [reserve your place with a £99 deposit](/courses/beginner-ux-design/).
> Or [try the free masterclass first](/masterclass/free-ux-ui-masterclass/).

---

## The typical UX interview process in the UK

Most mid-to-large UK employers run a 3-4 stage process. Knowing what to expect at each stage lets you prepare accordingly rather than being reactive.

**Stage 1 — Screening call (20-30 minutes)**

Usually with a recruiter or a hiring manager. This is a basic fit check: are you available, are your salary expectations in range, can you articulate what you do clearly? Have a two-minute summary of your background ready. Know your notice period and target salary.

**Stage 2 — Portfolio review (45-60 minutes)**

This is the most important stage of the process. A design manager or lead designer will ask you to walk through one or two projects in detail. The expectation is not a polished presentation — it is a conversation about how you think. We cover the specific questions you will face in this stage below.

**Stage 3 — Design challenge or task**

Either take-home (typically 2-7 days) or live (30-45 minutes in the room or on a video call). You are given a design prompt and asked to work through it. Interviewers are assessing your structure as much as your output.

**Stage 4 — Panel or stakeholder interview**

Usually involves more people: a product manager, an engineer, possibly a senior leader. The focus shifts to culture fit, how you collaborate across disciplines, and whether you can hold your own in a room with non-designers.

End-to-end, expect 2-6 weeks for the full process.

---

## Portfolio review questions

The portfolio review is where most interviews are won or lost. Being able to walk through your work clearly and respond well to follow-up questions requires specific preparation. Here are the questions you are most likely to face and what a strong answer looks like.

**"Walk me through one of your projects."**

What they want: a structured narrative — problem, research, decisions, outcome — not a tour of screens. Start with the problem you were solving and for whom. Then explain what informed your approach. Then walk through a few key decisions. Then tell them what happened.

What to avoid: starting with "So I opened Figma and..." or narrating the visual design without explaining why.

**"Why did you make that design decision?"**

What they want: evidence or reasoning. A good answer references something — a user research finding, a usability test result, a constraint, a trade-off you consciously made.

What to avoid: "It felt more intuitive" or "it looked better." These answers signal that your design process is aesthetic rather than evidence-led.

**"What would you do differently if you did this project again?"**

What they want: self-awareness and genuine reflection. This is not a trap — interviewers want to see that you learn from experience and can evaluate your own work critically.

What to avoid: "I wouldn't change anything" (overconfident) or a vague "I'd do more research" (too generic). Be specific about what you learned and what a different approach would have produced.

**"How did you validate this design?"**

What they want: evidence that you tested or evaluated the design in some form. This could be usability testing, A/B testing, analytics review, expert review, or even guerrilla testing with five users. Any of these is a valid answer.

What to avoid: "Stakeholders liked it" or "the client signed it off." Stakeholder approval is not validation. Interviewers — especially at more mature product organisations — will push back on this.

**"What was the biggest challenge on this project?"**

What they want: specifics. A real constraint, a genuine conflict, a technical limitation that required a creative solution. This question is a window into how you problem-solve under pressure.

What to avoid: "The timeline was tight" (too generic) or blaming the client without demonstrating how you navigated it. Frame the challenge as something you actively worked through, not something that happened to you.

**"What feedback did you get and how did you incorporate it?"**

What they want: evidence of iteration. Experienced designers expect design to change in response to feedback. A good answer gives a specific example: what feedback came in, from whom, what you decided to act on and why, and what the design looked like as a result.

---

## Process and knowledge questions

These questions sit alongside the portfolio review and are designed to understand how you work day-to-day, not just on a specific project.

**"How do you approach a new design project?"**

Describe your process in practical terms: discovery, define, ideate, prototype, test. The key is demonstrating that you start with understanding the problem and the users before moving to solutions. You can reference the [UX design process](/blog/ux-design-process/) here, but make it personal — describe how you actually work.

**"What research methods have you used?"**

Be specific. Name the methods: user interviews, surveys, contextual enquiry, card sorting, tree testing, usability testing, diary studies, competitor analysis. If you are earlier in your career, be honest about which methods you have used directly versus observed or studied. See our guide to [UX research methods](/blog/ux-research-methods/) for a full breakdown. Vague answers like "I do research at the start of projects" will not land well.

**"How do you work with engineers?"**

A question that reveals your maturity as a designer. Strong answers reference: sharing Figma specs and annotating edge cases, joining sprint planning to understand technical constraints early, having direct conversations with engineers during implementation rather than just handing over files and hoping for the best. If you have worked in an agile environment, describe that process specifically.

**"How do you handle stakeholder pushback on a design decision?"**

What they want: the ability to present rationale with data, not just defend your taste. A good answer describes leading with evidence ("here is what users told us"), offering to test the alternative if there is genuine uncertainty, and being willing to iterate rather than dig in. They are also checking that you are not a pushover who changes designs the moment someone raises an eyebrow.

**"Tell me about a time your design did not work as expected."**

Use the STAR method: Situation (what was the context?), Task (what were you trying to achieve?), Action (what did you do when things went wrong?), Result (what happened and what did you learn?). Every designer has examples of this. The best answers are honest and demonstrate what changed as a result.

---

## Design challenge questions

Design challenges — whether take-home or live — are used to see how you structure a problem you have never seen before. The prompt varies, but the common formats are:

- "Design an app for X" (e.g. helping elderly people manage medication)
- "How would you improve [specific product]?" (e.g. the TfL Oyster app)
- "How would you approach a redesign of this page?" (usually shown a real screen)

**What they are testing:**

Can you structure a design problem? Do you start with understanding users and constraints, or do you jump straight to sketching screens? Can you articulate trade-offs out loud? Can you work under time pressure without losing your process?

**How to approach it:**

1. Restate the brief in your own words to confirm you have understood it correctly.
2. Ask clarifying questions before you start: Who are the users? What platform is this for? What does success look like? What constraints should I assume?
3. Define the core problem before proposing solutions.
4. Start with users — who they are, what they need, what their pain points might be — before moving to ideas.
5. Show your thinking out loud. Do not go quiet and sketch for ten minutes.

**Common mistakes:**

- Jumping to UI solutions before defining the problem
- Not asking any questions (makes you look like you take briefs at face value)
- Ignoring constraints (platform, time, technical feasibility)
- Over-polishing the output at the expense of demonstrating your thinking process

---

## Behavioural and culture questions

Later-stage interviews shift toward collaboration, culture fit, and professional maturity. These questions are harder to prepare for without genuine examples.

**"What is your proudest design achievement?"**

Be specific. Name the project, the problem, the outcome. "Improved checkout conversion by 18% by redesigning the payment flow based on usability testing findings" is a strong answer. "Helped improve the user experience of a complex app" is not.

**"Describe a time you disagreed with a product manager."**

They want to see professional conflict resolution — not that you always capitulate to keep the peace, and not that you go to war over every decision. A good answer shows that you raised your concern with evidence, you listened to the PM's reasoning, and you reached a decision together (or agreed to test it). Ideally you can describe what happened after the disagreement.

**"What excites you about UX design right now?"**

They want genuine interest in the field and awareness of where it is heading. Current areas worth mentioning: AI-assisted design and what it changes about the designer's role, the UK Accessibility Regulations and the commercial pressure they create, the convergence of UX and product strategy in smaller teams. Avoid generic answers like "I love solving problems for people" — every candidate says this.

**"Why do you want to work here specifically?"**

Do your research before the interview. Know their products, their recent launches, their competitors, something about their design team if you can find it. Reference something real and specific. "I use your product daily and noticed that..." or "I read your design team's case study on..." signals that you mean it.

---

## Questions to ask the interviewer

Asking good questions at the end of an interview signals seriousness and design maturity. They also give you genuinely useful information about whether the role is right for you.

- "How does the design team work with product and engineering here? Is design involved from discovery or brought in later?"
- "What does a typical sprint look like for a UX designer on this team?"
- "How is design quality measured in this role — what does a strong first 6 months look like?"
- "What has made other designers successful here? And what has made some not work out?"

Avoid questions that could easily be answered by reading the job description or the company website. And avoid making the first question about salary or benefits if the topic has not come up yet.

---

## A 30-day prep plan

If you have a UX job search starting in the next month, here is a structured approach to interview preparation:

**Week 1 — Audit your case studies**

Go through every project in your portfolio. For each one, write down: what problem were you solving, what research did you do, what were the two or three most important design decisions and why, what was the outcome. If you cannot answer those in two sentences each, the case study is not ready for a portfolio review.

**Week 2 — Practise out loud**

Walk through your projects verbally, not just in your head. Record yourself on your phone. Watch it back. You will notice where your explanations trail off, where you say "um" and reach for words, where you are narrating screens instead of explaining decisions. Do this until the narrative feels natural and structured.

**Week 3 — Run mock interviews**

Pair with a peer, a mentor, or someone from a course or community. Ask them to play the interviewer and use the questions in this guide. The objective is to get comfortable being challenged on your decisions — "why did you do it that way?" — without becoming defensive or flustered.

**Week 4 — Research target companies and polish your files**

For each company you are actively interviewing with: know their main products, know what they have shipped recently, and have a specific question ready about their design team. Check your Figma files and portfolio for anything that looks unfinished — interviewers sometimes ask to see the actual files, not just the presentation layer.

---

## What comes next

Being prepared for UX interviews is one part of the picture. The other is having the portfolio and the practical experience to back up your answers. If you want to see what live UX training feels like before committing, the [free UX masterclass at UX Academy (myuxacademy.com)](/masterclass/free-ux-ui-masterclass/) is the place to start.

If you are making a career change into UX design, start with [Beginner UX (AI) Design](/courses/beginner-ux-design/) at UX Academy. Graduates can then extend into the [UX Career Track](/courses/ux-career-track/), a 4-week add-on with mock interview practice, portfolio critique, and interview preparation with instructors who have hired UX designers at companies including Adobe, Google, and Canva.

Next cohort starts <CohortDate />.

For more on the job search side, see our guides to [UX design jobs in the UK](/blog/ux-design-jobs-uk/) and [UX designer salaries in the UK](/blog/ux-designer-salary-uk/). If your portfolio needs work before you start applying, start with the [UX portfolio guide](/blog/ux-design-portfolio-guide/) and the [portfolio review checklist](/resources/templates/portfolio-review/).


---

# User Persona Template: Personas That Influence Design

URL: https://myuxacademy.com/blog/user-persona-template/
A user persona template that influences design decisions: what to include, what to leave out, and the common mistakes that make personas useless.

Walk into almost any product team and ask to see their personas. What you will find, almost without exception, are beautifully formatted documents with stock photos, fictional names, and bullet points that tell you someone is a 34-year-old marketing manager in Bristol who enjoys yoga and "wants to feel confident about her finances."

That persona will not help anyone make a single better design decision.

This post is a user persona template for the version that actually works -- what it contains, what research feeds it, how to write it, and how to use it so that it stays relevant past the first sprint.

**Want the fill-in-the-blanks version?** [Download the free user persona template](/resources/templates/user-persona/) and work through this post alongside it.

> **Learn to build research-backed personas on real projects.** UX Academy (myuxacademy.com)'s [Beginner UX (AI) Design course](/courses/beginner-ux-design/) covers the full synthesis toolkit, including personas, journey maps, and affinity mapping -- all with live instructor feedback. Cohort 1 starts 21 Sep 2026 -- [reserve your place with a £99 deposit](/courses/beginner-ux-design/).
> Or [try the free masterclass first](/masterclass/free-ux-ui-masterclass/).

## What a Persona Is and What It Is For

A user persona is a synthesised representation of a segment of real users, built from research. It captures shared patterns in how a group of people approach a problem: what they are trying to accomplish, what they currently do, where things break down, and what they assume about how the world should work.

The operative word is synthesised. A persona is not a transcript. It is not a survey respondent. It is a model built by identifying patterns across multiple research sessions and distilling them into something the whole team can reference and test decisions against.

Its purpose is alignment. Left to themselves, product managers, engineers, and designers will each hold a different model of who they are designing for. Personas make that model explicit and shared. When someone says "would Alex actually do this?" and the whole room knows who Alex is, the meeting gets shorter and the decision gets better.

A persona is a communication and alignment tool. It is not a research output in itself, and it is not a substitute for ongoing research. It is a snapshot of what you understood at a point in time, and it should be updated when that understanding changes.

## The Problem With Most Personas

Most personas fail for predictable reasons, and being direct about them will save you from repeating the same mistakes.

**They are built from assumptions, not research.** A team gets together for a workshop, fills in a persona template from gut feel and collective intuition, and calls it done. This is a proto-persona (more on those later) treated as if it were evidence-backed. The result is a document that reflects what the team already believed, which means it will never challenge a bad assumption.

**They are full of demographic details that do not affect design decisions.** Age, location, job title, relationship status, hobbies -- these fill up persona templates because they make the document feel like a real person. But ask yourself: does knowing that your user is 35 rather than 45 change any design decision you will make this sprint? If not, that detail is noise. Noise crowds out signal.

**They are too vague to be actionable.** "Sarah wants to feel confident about her finances" is a sentiment, not a design input. What does she currently do when she checks her balance? What breaks down in that process? What does she assume the product should tell her? Vague aspiration statements make personas feel human but useless.

**They are used as project deliverables rather than living design inputs.** A persona gets created, presented, added to a Confluence page, and never opened again. For a persona to be useful, it needs to be visible in the workspace, referenced in design critiques, and updated when research reveals something it got wrong.

## What Research Should Feed a Persona

A persona is only as good as the research behind it. The core inputs are:

**User interviews** are the primary source. One-to-one conversations with real users surface the goals, behaviours, mental models, and frustrations that should sit at the heart of every persona. If you have not conducted interviews yet, read [UX research methods](/blog/ux-research-methods/) before building any persona. Without this foundation, you are writing fiction.

**Behavioural data** -- analytics, session recordings, heatmaps -- gives you patterns at scale. If your interviews surface a hypothesis about how users navigate a flow, behavioural data can confirm whether it is an outlier or a widespread pattern. It also catches behaviours that users do not mention in interviews because they have normalised them.

**Surveys** provide quantitative context. Once you have identified themes from qualitative research, a survey can tell you how prevalent each theme is across your wider user base. This helps you decide which persona represents the largest segment and therefore should be the primary design target.

The key principle: personas should reflect patterns in behaviour, goals, and pain points -- not in demographics. Two users can be demographically identical and behaviourally opposite. The behavioural dimension is the one that actually determines how they will interact with your product.

## What a Good Persona Actually Includes

Here is what belongs in a persona that will be genuinely useful:

**Name and photo.** Not because the fictional name matters, but because it gives the team a handle. "What would Marcus do?" is a faster and more memorable reference than "what would the primary persona in segment two do?" Use a fictional name and a photo that is not a stock-photo cliche. The goal is memorability, not decoration.

**Role or context.** What situation brings this person to the product? This is not necessarily a job title. It might be "someone making their first significant financial decision without professional advice" or "a team lead trying to onboard a new designer quickly." Context matters more than credentials.

**Goals.** What is this person ultimately trying to accomplish? Keep these functional -- rooted in what they actually want to do -- rather than aspirational. "Complete the application before her lunch break" is a goal. "Feel empowered about her career" is a marketing tagline. Aim for two to three goals that directly shape design decisions.

**Behaviours.** How does this person currently approach the problem? What tools or workarounds are they using? What does their existing process look like? This is one of the most valuable sections because it reveals where your product is inserting itself into an existing workflow -- and therefore what friction it is replacing and what it must match or beat.

**Pain points.** Specific frustrations with the current experience, not general dissatisfaction. "The form times out if she leaves to check her documents" is a pain point. "Finds the process stressful" is not. Two to three specific, observable frustrations give designers something to target.

**Mental model.** What does this person already know or assume about how this type of product should work? Mental models shape how users interpret your interface before they have read a single word of copy. If your user assumes that "save" means "publish," any design that treats them as separate actions will cause confusion -- regardless of how clearly you label things.

**Representative quote.** A verbatim or carefully synthesised quote from research that captures the person's perspective in their own voice. This is the fastest way to bring a persona back to life in a design critique. "I just need to know the number, I do not care why it is that number" tells you more about a user's relationship with financial data than three paragraphs of analysis.

**What NOT to include:** hobbies, family details, tech-savviness scores on a five-point scale, and lengthy backstories. These are not design inputs. They are padding that makes a document look thorough while making it harder to use. Include demographic context only if it directly affects a design decision -- for example, if your product is primarily used on low-spec mobile devices, noting that your persona does not own a laptop is relevant. Their relationship status is not.

## Behavioural Personas vs Demographic Personas

This distinction is worth spelling out clearly because it is where most teams go wrong.

A demographic persona looks like this: "35-year-old marketing manager in London, uses Instagram daily, intermediate Excel user, has a gym membership."

A behavioural persona looks like this: "Someone making high-stakes decisions with limited time who distrusts tools that require extensive setup before delivering value."

The demographic version tells you who the person is. The behavioural version tells you how they will approach your product. Only one of those descriptions helps you design a better onboarding flow, decide how much explanation to put before the first meaningful action, or choose between a guided wizard and an open canvas.

When you are building a persona, check every field you include against this question: does this change a design decision? If the answer is no, cut it.

## How Many Personas?

Most projects need one to three primary personas. One is often not enough -- a product that serves meaningfully different user segments with different goals and behaviours cannot be accurately represented by a single model. But more than three and the team stops using them. People can hold roughly three distinct user models in their heads during active design work; beyond that, personas become a reference document rather than a design tool, and reference documents do not get consulted in the moment.

Anti-personas -- explicit descriptions of who you are not designing for -- are underused and often more valuable than additional primary personas. Defining the edge-case user you are intentionally excluding from the primary design target keeps scope honest. It prevents features being added to serve someone the product was never meant to serve well, and it gives you a principled answer when a stakeholder says "but what about users who..."

## The Persona Template: Section by Section

Rather than a downloadable file you fill in once and file away, here is what each section of a well-constructed persona template should contain and why.

**Header:** Name, photo, and a single sentence that captures the user's core context. This sentence is the persona's thesis. "Alex is a mid-career professional retraining for a new field who needs to demonstrate new skills quickly, without disrupting his current income." Everything else in the document should support or elaborate that sentence.

**Goals (2-3 bullets):** Functional goals, written as outcomes. What does this person need to have achieved by the time they leave your product? Keep them specific enough to test against. "Get an answer she trusts in under three minutes" is testable. "Have a good experience" is not.

**Current behaviours and workarounds:** How is this person solving the problem today, before your product exists for them? What tools are they cobbling together? What steps are they doing manually? This section should make the team feel the friction the product is replacing.

**Pain points (2-3 bullets):** Specific, observed frustrations -- ideally ones you can quote back to a research participant. The more concrete these are, the more directly they can drive design decisions.

**Mental model and assumptions:** What does this person expect before they have used your product? What analogies are they drawing from other experiences? Where is their mental model likely to collide with how the product actually works?

**Representative quote:** One or two sentences in the user's voice. Pull it from a real interview transcript or synthesise it carefully from multiple sessions. This is the section that should make the team feel they have met this person.

**Secondary -- key demographic context:** Only include demographics here that have a direct bearing on design decisions. Screen size, device type, connectivity constraints, and language context are often relevant. Age and postcode rarely are.

## Proto-Personas vs Research-Backed Personas

A proto-persona is built from team assumptions before any research has been conducted. It is used to align everyone on initial hypotheses: who do we think we are designing for, and what do we think they need?

Proto-personas serve a genuine purpose. Starting a project with a shared, explicit set of assumptions -- however unverified -- is better than starting with implicit and divergent ones. They also give you something concrete to challenge when research begins.

But they must be clearly labelled as assumptions. A proto-persona should carry a visible marker -- "unvalidated" or "based on assumptions" -- so no one mistakes it for research-backed insight. As you conduct interviews and gather data, update the proto-persona to reflect what you actually found, or discard it entirely if the research reveals you were designing for the wrong person. Never present a proto-persona to stakeholders without making its unverified status explicit.

The failure mode to avoid: a proto-persona built in a workshop at the start of the project that quietly loses its "proto" label by sprint three, and is thereafter treated as evidence without anyone having done the research to support it.

## Personas in the Broader Design Process

Personas sit at the foundation of the [UX design process](/blog/ux-design-process/). They inform the problem framing that happens before ideation, they guide the prioritisation decisions that happen during design, and they provide the reference point for evaluating whether a solution actually serves the people it was built for.

A persona you cannot use to evaluate a design decision is not a persona -- it is a character profile. The test is simple: can you hold up a proposed design next to a persona and ask "would this work for this person?" and get a meaningful answer? If not, the persona needs more work.

If you are newer to the discipline and want to understand where personas sit in the wider picture of what UX design involves, [what is UX design](/blog/what-is-ux-design/) covers the foundations of the field.

---

If you want to see what live UX training feels like before committing, the [free UX masterclass at UX Academy (myuxacademy.com)](/masterclass/free-ux-ui-masterclass/) is the place to start.

On the [Beginner UX (AI) Design](/courses/beginner-ux-design/) and [Advanced UX Design](/courses/advanced-ux-design/) courses at UX Academy, you build personas from real user research conducted on actual client briefs -- not invented scenarios. You interview real people, synthesise findings into a research-backed persona, and use it to drive design decisions through the rest of the project. That process -- learning to move from raw interview data to a document a whole team can use -- is what separates a designer who understands personas from one who just knows the template.


---

# Usability Testing: A Practical Guide for UX Designers

URL: https://myuxacademy.com/blog/usability-testing-guide/
How to plan and run usability testing: recruiting participants, writing test scripts, moderated vs unmoderated, tools, and reporting findings.

If you want to know whether a design works, there is only one reliable method: watch a real person try to use it.

Stakeholder opinion, designer intuition, and internal review all have their place. But usability testing is the closest thing UX has to a ground truth. Five minutes of watching someone struggle to find the checkout button tells you more than an hour of alignment meetings.

This guide covers the full process: what usability testing is, when to run it, how to recruit participants, how to write a test script, what to do during a session, and how to report what you find. It is written for designers who already know usability testing exists and want to know how to actually do it.

> **Want to practise usability testing on real projects?** UX Academy (myuxacademy.com)'s [Advanced UX Design course](/courses/advanced-ux-design/) includes moderated and unmoderated testing with live feedback from experienced practitioners. Cohort 1 starts 21 Sep 2026 -- [reserve your place with a £99 deposit](/courses/advanced-ux-design/).
> Or [try the free masterclass first](/masterclass/free-ux-ui-masterclass/).

## What usability testing is — and what it is not

Usability testing is an observational research method. You give participants realistic tasks to complete on a product, prototype, or competitor product, and you watch what happens. You are not asking people what they think of the design. You are watching what they do.

This matters because what people say and what people do are often completely different. In a focus group, participants will tell you a navigation menu "makes sense". In a usability test, you will watch them click the wrong section three times before giving up.

Usability testing is not:
- **Market research** — you are not surveying attitudes or preferences at scale
- **A focus group** — you are not gathering opinions in a group discussion
- **A demo** — you are not showing people how the product works

The point is to surface usability problems: friction, confusion, errors, and dead ends that real users encounter when they try to complete real tasks.

## When to run usability testing

Usability testing fits two different moments in the design process.

**Formative testing** happens during design, before anything ships. You test early wireframes, low-fidelity prototypes, or even paper sketches. The goal is to inform design decisions — to find problems early, when fixing them is cheap. If a navigation structure confuses participants in a wireframe, you know before you have built anything.

**Summative testing** happens after launch, or at the end of a design sprint. You are evaluating how well the design performs against defined criteria — task completion rates, error rates, time on task. This is closer to benchmarking: you want to know how the current version compares to a previous one, or to a competitor.

Most design teams run formative testing far too rarely and summative testing almost never. If you are only testing after launch, you are missing the most valuable window.

## Moderated vs unmoderated testing

The most important structural decision is whether to run moderated or unmoderated sessions.

### Moderated testing

A facilitator runs a live session with one participant at a time — in person or via video call using tools like Lookback. You introduce the session, set tasks, observe, and ask follow-up questions as the participant works.

Moderated testing produces richer data. When a participant hesitates, you can ask what they are thinking. When they take an unexpected path, you can explore why. It is the right choice for early-stage exploratory work, when you do not yet know what questions to ask or what problems to look for.

The trade-off is time. Recruiting, scheduling, and running 5 moderated sessions takes days. Analysing them takes more.

### Unmoderated testing

Participants complete tasks independently, typically via a tool like Maze or Lyssna. Their screen is recorded, clicks are tracked, and they may answer follow-up survey questions after each task. You review the recordings and data afterwards.

Unmoderated testing is faster and cheaper. You can send a test to 20 participants on a Monday morning and have results by Tuesday. It works well when you have a specific interaction to test — a checkout flow, a navigation change, a new feature — and you want breadth rather than depth.

The limitation is that you cannot follow up in the moment. If a participant does something unexpected, you will not find out why until the debrief question, if at all.

## How many participants do you need?

Jakob Nielsen's research at the Nielsen Norman Group (2000) established that 5 participants reveal approximately 85% of usability problems in a qualitative test. This is one of the most cited and most misunderstood findings in UX research.

The key word is qualitative. The 5-user rule applies when your goal is to identify usability problems — not to measure them precisely. Running 5 participants, fixing the most critical issues, and running another 5 is more valuable than running 20 participants in a single round. Each round surfaces new problems in the updated design.

For quantitative benchmarking — measuring task completion rates, error rates, or satisfaction scores with statistical confidence — 5 participants is not nearly enough. You need 20 or more, depending on the confidence intervals you need.

For most early-stage and mid-stage design work, 5 participants per round is the right starting point.

For a broader overview of research methods and when to use them, see our guide to [UX research methods](/blog/ux-research-methods/).

## Recruiting participants

### Recruitment platforms

The fastest way to reach screened participants is through a recruitment platform:

- **UserTesting** — large panel, quick turnaround, higher cost; good for unmoderated studies
- **Prolific** — academic-grade panel, excellent for demographic targeting, lower cost per participant
- **Respondent.io** — specialist and B2B panels; useful when you need domain expertise (e.g. finance, healthcare)

These platforms handle consent, payments, and no-shows, which removes significant admin overhead.

### Guerrilla and internal recruiting

For early-stage testing, speed matters more than perfect participant matching. Colleagues, friends, local coffee shop patrons, or social media followers can surface obvious usability problems in a low-fidelity prototype. This is sometimes called guerrilla testing — informal, fast, and cheap.

The caveat: guerrilla participants may not match your actual users. Do not use them to validate a final design. Use them to stress-test early concepts.

### Screener surveys

A screener is a short survey participants complete before being accepted into a study. It filters out people who do not match your target audience — by role, experience level, device use, or behaviour.

A well-written screener saves you from spending an hour with a participant who turns out to be irrelevant to your research questions. It also prevents professional "research participants" who game recruitment platforms by selecting whatever answers get them accepted.

Keep screeners short: 5 to 8 questions. Ask about behaviour ("how often do you...") rather than self-assessed skill ("are you an expert at...?").

### Incentives

In the UK, a typical rate for a 45-60 minute usability session is £30 to £50. Amazon vouchers and cash equivalents work well. For professional or specialist participants — developers, clinicians, financial advisers — rates are higher.

Pay participants fairly. Undervaluing their time affects recruitment rates and the quality of engagement you get in sessions.

## Writing a test script

The test script is the backbone of the session. Writing it badly is the most common reason usability tests fail.

### Start with your research questions

Before you write a single task, write down what you are trying to learn. "Does the checkout flow work?" is too vague. "Do participants understand the difference between the deposit payment and the full payment, and do they know what happens next?" is a research question you can write tasks around.

### Tasks vs questions

A task is something the participant does: "You want to find a UX design course that starts in September. Show me how you would do that."

A question is something you ask: "What would you expect to happen after you click that button?"

Tasks drive behaviour. Questions uncover reasoning. A good test script uses both — but tasks come first.

Write tasks in plain language. Do not use the product's own terminology in the task description (if you are testing navigation labels, do not use those labels in the task). Make tasks realistic: give participants a scenario, not an instruction.

Bad task: "Navigate to the pricing page."
Good task: "You are thinking about enrolling. You want to find out how much it costs and what is included. Show me what you would do."

### Think-aloud protocol

Ask participants to narrate their thinking as they work through tasks. This is the think-aloud protocol, and it is the most valuable source of data in a moderated session.

The instruction sounds simple: "As you work through the tasks, please say out loud what you are thinking, what you are looking at, and what you are trying to do. There are no right or wrong answers — we are testing the design, not you."

Most participants will need reminding during the session. That is normal.

### Avoid leading questions

Leading questions corrupt your data. "Did you find that button hard to find?" assumes there was difficulty. "What happened when you tried to find the button?" does not.

If a participant asks you a question during the session ("Should I click here?"), redirect: "What would you do if I weren't here?"

### Warm-up questions

Start every session with a few minutes of warm-up questions: what the participant does, how they use similar products, how confident they feel with technology. This relaxes participants and gives you context for interpreting their behaviour.

## Running the session

Your role as facilitator is to observe, not to help. This is harder than it sounds. When a participant is struggling, every instinct tells you to point them in the right direction. Resist it. Their struggle is your data.

Stay neutral. Do not react to what participants say or do in ways that signal approval or concern. If they say "I think this design is terrible," respond with "That's helpful, thank you — what specifically felt off?"

Useful facilitator phrases:
- "What are you thinking right now?"
- "What would you expect to happen next?"
- "What would you do if this were your own device?"
- "You said you expected X — can you say more about that?"

If you can, bring a second person to take notes while you facilitate. Doing both at once means you will miss things. If you are running the session solo, record it (with consent) and take sparse notes during — you can fill in detail from the recording.

## Analysing findings

Raw observations from a usability test are not findings. They are data. Analysis is what turns observations into insights.

### Affinity mapping

After testing, gather all your observations — notes, quotes, video clips — and group them by theme. This is affinity mapping. You are looking for patterns: multiple participants struggling with the same step, the same piece of terminology causing confusion, the same interaction creating errors.

Do this as a team if you can. Two people grouping observations independently will produce more robust themes than one person working alone.

### Severity ratings

Not every usability problem needs fixing before the next release. Severity ratings help you prioritise:

- **1 — Cosmetic:** minor annoyance, does not affect task completion
- **2 — Minor:** causes hesitation or confusion, but participant recovers
- **3 — Major:** causes significant difficulty; some participants fail the task
- **4 — Critical:** prevents task completion; participants cannot recover without help

Focus your immediate effort on 3s and 4s.

### Behaviour vs interpretation

Be precise about what you observed versus what you infer. "The participant clicked the wrong button" is an observation. "The participant did not understand the hierarchy" is an interpretation. Both are useful, but they belong in different parts of your analysis.

For more on complementary methods that sit alongside usability testing — particularly for identifying design problems without recruiting participants — see our guide to [heuristic evaluation](/blog/heuristic-evaluation-ux-design/).

## Reporting findings

A usability test report is only useful if it leads to action. Keep it focused.

For each finding, structure your report around three things:
1. **The problem** — what happened, and with which task
2. **The evidence** — how many participants, and what they did or said (direct quotes are powerful)
3. **The recommendation** — a specific, actionable design change

Avoid vague recommendations like "improve the navigation." Instead: "Rename 'Resources' to 'Tools and templates' — three of five participants did not expect course materials to live under 'Resources'."

### Video clips

Short clips of real users struggling are more persuasive to stakeholders than any slide deck. A 30-second clip of a participant clicking around in confusion, followed by "I have no idea where to go from here," makes a stronger case for a design change than a bar chart of task completion rates.

Tools like Dovetail let you tag and clip video highlights during analysis, then share them directly with stakeholders as a highlight reel.

## Tools

- **Maze** — unmoderated prototype testing; integrates with Figma; good for quantitative task data
- **Lyssna** — unmoderated testing; strong for first-click tests and preference tests
- **Lookback** — moderated remote sessions; observer rooms, live streaming for stakeholders
- **UserZoom / UserTesting** — enterprise-grade platforms with built-in participant panels
- **Dovetail** — qualitative synthesis; video tagging, affinity mapping, insight sharing

For a broader look at the UX design toolkit, see our guide to [UX design tools](/resources/).

Usability testing sits within a wider [UX design process](/blog/ux-design-process/) that includes [usability principles](/blog/usability-in-ux-design/) and a range of [research methods](/blog/ux-research-methods/). No single method tells the whole story — usability testing is most powerful when it is part of a regular research rhythm, not a one-off event.

## Learn by doing

Reading about usability testing is a start. Running a real test — recruiting participants, facilitating a live session, synthesising findings, presenting to stakeholders — is where the skill actually develops.

If you want to see what live UX training feels like before committing, the [free UX masterclass at UX Academy (myuxacademy.com)](/masterclass/free-ux-ui-masterclass/) is the place to start.

The [Advanced UX Design](/courses/advanced-ux-design/) and [UX Career Track](/courses/ux-career-track/) courses at UX Academy include hands-on usability testing modules. You plan and run real tests on live client briefs, with instructor coaching throughout. You leave with session recordings, a synthesised findings report, and the experience of having done it properly — not just read about it.


---

# UX Portfolio From Scratch: Beginner's Guide (No Experience)

URL: https://myuxacademy.com/blog/how-to-build-a-ux-portfolio-from-scratch/
No design experience yet? Learn how to create your first UX case study from zero, find beginner-friendly projects, and build a portfolio that gets interviews.

Most career-changers who want to move into UX design hit the same wall at some point. They understand what UX is. They have done their research. They are motivated. And then they realise: you need a portfolio to apply for jobs, and they do not have one.

This post is not about why you should build a portfolio. You already know that. It is about the practical question most resources skip over: how do you build a UX portfolio from scratch when you have never worked in UX before?

> **Build your portfolio through real client projects, not exercises.** UX Academy (myuxacademy.com)'s [Beginner UX (AI) Design course](/courses/beginner-ux-design/) gives every student genuine briefs so your case studies have real constraints and real users behind them. Cohort 1 starts 21 Sep 2026 -- [secure your place with a £99 deposit](/courses/beginner-ux-design/).
> Or [try the free masterclass first](/masterclass/free-ux-ui-masterclass/).

## The portfolio paradox — and why it is false

You have probably encountered the circular logic: you need a portfolio to get a UX job, but you need a UX job to build a portfolio. It feels like a closed loop.

It is not. The premise is wrong.

Employers are not looking for a CV of prior employers. They are looking for evidence that you can do the work — that you can identify a real problem, understand the people who have it, explore solutions, test them, and iterate. That process does not require a client relationship or a salary. It requires rigour and documentation.

A well-executed personal project, where you spoke to five real users and made visible decisions based on what they told you, is more revealing to a hiring manager than a case study that says "I worked on a mobile banking app" with no process shown. The first tells them how you think. The second tells them nothing.

## What you cannot fake

Before getting into the how, it is worth being clear about what you cannot shortcut. Three things separate a credible portfolio project from a design exercise:

**Real users.** You have to speak to people who actually use (or would use) the thing you are designing. Five conversations is a legitimate sample for a portfolio project. Zero is not research — it is speculation.

**Documented findings.** What did users tell you that was unexpected? What did you assume going in that turned out to be wrong? If your research section says "I spoke to five people and found that usability is important," that is not insight. Quote specific things people said. Show an affinity map. Explain what surprised you.

**Decisions made for reasons.** Every design decision in your case study should have a "because" attached to it. "I moved the navigation to the bottom because every user I spoke to was holding their phone one-handed and could not reach the top bar." That sentence shows UX thinking. "I moved the navigation because it looked cleaner" does not.

## Three types of projects that work for a starter portfolio

### Type 1: Personal briefs

Pick a product you genuinely use and care about — an app, a website, a physical service. The fact that you know it well is an advantage, not a cop-out. Treat it as a real design brief: what problem does it have? Who are the users? What is causing the friction?

The critical step that most people skip is research. A portfolio project based on a product you redesigned without speaking to anyone is, in the industry, called a "concept project." They are common and they are mostly ignored. To make yours count, you need to speak to real users of that product — five people, recruited through your own network, a subreddit, a local community group, wherever you can find them.

The strength of a personal brief is that you chose something you already understand deeply. The limitation is that there are no real constraints, no stakeholder pressure, and no one to push back on your assumptions. Document the constraints you set yourself to compensate.

### Type 2: Volunteer work

This is the strongest type of project you can add to a starter portfolio. Local charities, community organisations, small businesses, and early-stage start-ups regularly need UX help and have no budget for it. Offering your time pro bono gives you a real client, a real brief, real constraints, and real people to interview.

How to find opportunities: reach out directly to organisations whose work you care about. Be transparent that you are training and will do the work pro bono in exchange for the experience. [Catchafire](https://www.catchafire.org/) and [Idealist](https://www.idealist.org/) list volunteer roles in the UK, some of which are specifically UX-related. Local council community groups, mutual aid networks, and small-business owners you already know are also good places to start.

What makes volunteer work valuable in a portfolio is the same thing that makes any real project valuable: you had to navigate a relationship, explain your decisions to a non-designer, and deliver something to an actual standard. That shows more than a self-directed exercise, and hiring managers can usually tell the difference.

### Type 3: Course projects

A well-structured UX course gives you a real client brief, experienced instructor feedback, and a peer group whose work you can learn from. The best course projects are not made-up scenarios — they involve real companies with real design problems, and they require you to conduct genuine research rather than just work through a set of design templates.

The advantage over self-directed projects is the feedback loop. When you do not know what "good" looks like yet, working with an experienced UX practitioner who reviews your case study at each stage accelerates your development faster than anything else. You can see examples of the kind of projects UX Academy students produce on the [student work page](/student-work/).

## What every portfolio case study must include

A case study is not a design showcase. It is a written account of your process — the decisions you made, why you made them, and what happened when you tested them. Here is the structure that works:

**The problem.** What were you trying to solve, and for whom? Be specific. "Improving the checkout experience for first-time buyers on a small e-commerce site" is more credible than "redesigning an e-commerce app."

**Research.** Who did you speak to? How did you recruit them? What did you find that mattered? This section should not summarise your method — it should tell the reader what changed in your understanding because of what you heard.

**Insights and decisions.** What did the research tell you? Which problems did you decide to prioritise, and why? Show your reasoning. An insight is not "users found it confusing" — it is "three of five users did not realise the checkout required an account until they had already entered their payment details, which caused two of them to abandon."

**Process.** Show the work in progress: rough wireframes, explorations, discarded directions. Hiring managers want to see that you explore before you land on a solution. A case study that goes straight from research to polished screens skips the most interesting part.

**Testing.** Did you put the design in front of real users? What did they do that you did not expect? What did you change as a result? Even a lightweight usability test with three people, documented honestly, adds significant credibility.

**Outcome.** What did you deliver? If you were doing it again, what would you do differently? Showing self-awareness about the limitations of your own work is a mark of maturity, not weakness.

A case study that takes five to seven minutes to read is about right. Longer and readers drop off before they reach the outcome.

## What to leave out

The temptation when building a portfolio from scratch is to include everything you have ever touched, to bulk out the work. Resist it.

Leave out: projects you cannot explain confidently. If you cannot articulate why you made a specific decision, do not include that project — you will be asked about it in an interview and the gap will show.

Leave out: purely visual work with no UX process behind it. Illustration, graphic design, and UI styling belong in an art portfolio, not a UX one. What you include should demonstrate research, analysis, and problem-solving — not just taste.

Leave out: more than three or four projects. Depth beats volume. A portfolio with two deeply documented projects is stronger than one with six thin ones.

Leave out: the generic Twitter or Airbnb redesign with no research. Every UX portfolio course in existence prompts students to redesign one of these apps. If yours does not have research behind it, it blends in with the noise rather than standing out from it.

## Choosing a portfolio platform

The platform you choose matters far less than the quality of what you put on it. A clear, scannable Notion portfolio beats a complicated Webflow one every time. That said, here are the realistic options:

**Notion** is the fastest to build and completely free. It produces clean, readable pages and is widely accepted across the industry. For a career-changer building a first portfolio, it is the most sensible place to start.

**Squarespace** offers polished templates and requires no technical knowledge. At around £12-16 per month, it is a reasonable step up if you want a more designed feel without a learning curve.

**Adobe Portfolio** is included with Creative Cloud subscriptions. If you are already paying for CC, this is a no-cost option with reasonable templates.

**Webflow** gives you significant design control and produces impressive results, but it has a steeper learning curve. Worth considering once you have one version of your portfolio live and want to invest more in the presentation layer.

**Figma** — some designers present case studies as scrollable Figma files, linked from a simple landing page. This works particularly well for audiences who are themselves designers or work closely with design teams.

## Writing case studies that people actually read

The writing in your case studies matters. A few principles that make the difference:

Write as if you are explaining your process to a smart person who was not in the room with you. Do not assume they know what decisions you faced or why certain things were difficult. Make it explicit.

Lead with the problem, not the solution. The most common mistake in case study writing is front-loading the final design. Start with the context and the problem — earn the solution by showing the path you took to reach it.

Describe decisions as choices made for reasons, not as inevitable steps. "I used card sorting because..." is more interesting than "I used card sorting." The because is where your thinking becomes visible.

Keep it scannable. Short paragraphs, clear section headers, annotated images. Hiring managers are reading multiple portfolios. Make it easy to move through yours at speed and still grasp the essentials.

Show real artefacts. Interview notes, affinity maps, rough wireframes, sticky-note photos — these signal that the process was real, not retrospectively tidied up to look like a process. See [UX research methods](/blog/ux-research-methods/) for guidance on which artefacts to generate and document at each stage.

## Getting your portfolio seen

A portfolio that no one sees is not a portfolio. Once you have at least two case studies documented:

**LinkedIn** is the primary channel for UX roles in the UK. Put your portfolio URL in your headline and in the Featured section. Update your headline to reflect that you are actively looking — "UX Designer | Open to Junior Roles" signals availability.

Share one case study breakdown as a LinkedIn post — a short walkthrough of your process, the problem you solved, and what you learned. This signals activity and gives people a reason to click through to your portfolio.

Direct outreach works. Find UX designers and hiring managers at companies you want to join. Send a short, specific message — not a generic "I would love to work at your company" but something that shows you know their product and have relevant thinking to offer. Include your portfolio link. Personal messages with a specific hook get read.

For more on the job search side, see [how to get a UX job with no experience](/blog/ux-job-with-no-experience/) and the [UX portfolio review checklist](/resources/templates/portfolio-review/).

## The fastest path to a strong portfolio

The single biggest accelerant for a starter portfolio is working on a real design brief with experienced feedback at each stage. When you are new to UX, the hardest thing is not doing the work — it is knowing whether the work is good, and understanding why it is or is not.

If you want to see what live UX training feels like before committing, the [free UX masterclass at UX Academy (myuxacademy.com)](/masterclass/free-ux-ui-masterclass/) is the place to start.

On the [Beginner UX (AI) Design](/courses/beginner-ux-design/) course at UX Academy, you work on a real client brief with a real design problem over eight weeks of live instruction. Every stage of your process — research, synthesis, wireframing, testing — gets reviewed by a working UX practitioner before you move forward. The case study you produce becomes the strongest piece in your portfolio.

If you are targeting a full career transition and want a second client brief plus interview prep and job search support once you have graduated, the [UX Career Track](/courses/ux-career-track/) extends Beginner UX (AI) Design with exactly that -- taking you from first brief to job-ready.

You can also look at [real UX portfolio examples](/blog/ux-design-portfolio-examples/) to see what strong early-career case studies actually look like, or read the [UX portfolio strategy guide](/blog/ux-design-portfolio-guide/) if you want advice on how to structure and present your work to hiring managers once you have something to show.

The portfolio is not the obstacle. It is the first piece of work.


---

# Figma vs Sketch vs Adobe XD: Which Should You Learn in 2026?

URL: https://myuxacademy.com/blog/figma-vs-sketch/
Figma, Sketch, or Adobe XD? An honest comparison for UX designers and career-changers deciding which design tool to learn first. Spoiler: the answer is clear.

If you are new to UX design and trying to work out which tool to learn, the Figma vs Sketch vs Adobe XD question has a clear answer. This post gives you that answer upfront and then explains the context underneath it — so you can make an informed decision rather than one based on outdated advice or marketing copy.

> **Learn Figma properly through live practice.** UX Academy (myuxacademy.com)'s [Beginner UX (AI) Design course](/courses/beginner-ux-design/) uses Figma throughout -- wireframing, prototyping, and developer handoff -- with real projects and small-group feedback. Cohort 1 starts 21 Sep 2026 -- [secure your place with a £99 deposit](/courses/beginner-ux-design/).
> Or [try the free masterclass first](/masterclass/free-ux-ui-masterclass/).

## The short version

**Learn Figma.**

It is the industry standard tool for UX and product design in 2026. It runs in a browser, it is free to start, and it is what the overwhelming majority of UK design teams use. The rest of this post explains why, and covers Sketch and Adobe XD honestly so you understand the full picture.

---

## Figma: why it dominates

Figma launched in 2016 with a genuinely different model — a design tool that ran in the browser, worked on Mac and Windows, and allowed multiple people to edit the same file at the same time. That combination turned out to be exactly what product teams needed, and it has compounded ever since.

### It works on any computer

Figma runs in Chrome, Firefox, or Safari, and there is also a desktop app. It does not matter whether you are on a MacBook, a Windows laptop, or a Chromebook — you can open Figma and start working. This matters more than it sounds. Sketch (more on this shortly) is Mac-only. If you learn Sketch and then take a role at a company where designers use Windows machines, you cannot use it.

### Real-time collaboration is built in

This is the feature that accelerated Figma's dominance. Multiple people can work on the same Figma file simultaneously, see each other's cursors, and leave comments directly on designs. For distributed teams and remote-first companies — which describes a large proportion of UK product businesses after 2020 — this is not a nice-to-have, it is essential. Sketch never built this natively.

### The free tier is genuinely useful

Figma's free plan allows you to work on up to 3 Figma design files and 3 FigJam collaborative whiteboard files. For someone building a portfolio from scratch, this is enough to complete multiple real projects without spending anything. When you join a team, they will almost certainly be on a paid plan that you access as part of your role.

You can read more about getting set up in [Figma for beginners](/blog/figma-for-beginners/) and [What is Figma?](/blog/what-is-figma/).

### Prototyping is built in

You do not need a separate tool to create interactive prototypes in Figma. You can link frames together, add transitions, use Smart Animate for micro-interactions, and share a clickable prototype with stakeholders or usability test participants — all within the same file where you did the design work. This matters for UX professionals specifically: a UX workflow requires both design and prototyping, and having them in the same tool removes unnecessary friction.

### Developer handoff is built in

Figma's Developer Mode lets engineers inspect your designs directly — seeing spacing values, typography specs, CSS properties, and assets — without you having to export anything separately or buy an additional tool like Zeplin. This is the standard handoff workflow at most product companies in 2026.

### The toolkit is comprehensive

Auto-layout, component libraries, variables, interactive components, conditional logic in prototypes — Figma has matched or exceeded the professional toolkit that used to require multiple tools. If you learn Figma well, you can handle wireframing, high-fidelity UI design, prototyping, and handoff without leaving the application.

### The community is the largest of any design tool

Figma's community tab contains thousands of free UI kits, icon sets, wireframe templates, design systems, and learning resources — all made by other designers and available to copy into your own files. When you are learning, this gives you real, professional-grade assets to work with from day one.

---

## Sketch: still relevant, but declining

Sketch was the dominant design tool for much of the 2010s, and it still has genuine users — particularly in established London agencies and design teams that standardised on it before Figma reached feature parity. It is not dead. But for someone deciding what to learn first in 2026, it has some serious limitations.

### It only runs on Mac

This is an immediate dealbreaker for anyone on Windows. Sketch is a native Mac application and always has been. If there is any chance you will be using a Windows machine — now or in a future role — Sketch is not an option.

### The collaboration story is weak

Sketch added cloud-based collaboration in recent years, but it is fundamentally limited compared to Figma. Real-time simultaneous editing is not available in the same way. Sharing designs for review typically involves sharing static screens rather than live files. For a modern, collaborative product team, this is a significant gap.

### Prototyping requires additional tools

Sketch does not have a robust built-in prototyping layer. Creating interactive flows typically requires exporting to a separate tool like InVision or Marvel. That is an additional cost, an additional login, and an additional tool to learn — all of which Figma has made unnecessary.

### It costs money from day one

Sketch is a subscription product at £99 per year (approximately). There is no free tier for professional use. Given that Figma's free plan covers most of what a beginner needs, this is a meaningful difference for someone in career transition who is watching their spending.

### Verdict on Sketch

If you already know Figma and a specific job listing requires Sketch, you can learn the essentials in about a week. The concepts are the same. The interface is different but not dramatically so. Do not let a Sketch requirement put you off a role — but do not learn it first.

---

## Adobe XD: effectively discontinued

Adobe XD launched in 2017 as Adobe's direct response to Sketch and Figma. It had a reasonable feature set and benefited from integration with Adobe's Creative Cloud ecosystem. But the picture in 2026 is straightforward: Adobe paused development of XD in late 2023 and stopped selling new licences to new customers.

This happened in the wake of Adobe's failed attempt to acquire Figma. Regulators in the UK and Europe blocked the deal in late 2023, and Adobe ultimately abandoned it. Since then, Adobe has focused on integrating design features into Creative Cloud more broadly rather than developing XD as a standalone product.

Existing XD users can still access the tool, but it is receiving no new features. If you learn XD, you are learning a discontinued product with a shrinking user base and no development roadmap.

If you already use Illustrator or Photoshop extensively: Figma is still the faster path to a UX career than XD. XD knowledge does not transfer much to Figma — you are better off starting fresh.

**The verdict: do not learn Adobe XD in 2026.**

---

## What about Framer, Webflow, and Penpot?

These tools come up often enough that they are worth a brief mention.

**Framer** is a prototyping and website-building tool that produces genuinely high-fidelity interactive output. It is used by some product designers for advanced prototypes and by teams shipping marketing sites quickly. It is a specialist tool with a specific use case — not a replacement for Figma in a standard design workflow.

**Webflow** is a visual website builder and CMS. It is used by developers and no-code builders, not primarily by UX designers. It is not a UX design tool in the conventional sense.

**Penpot** is an open-source, browser-based design tool that works on both Mac and Windows. It is free, it is growing, and it has attracted interest in Europe partly because it is not dependent on a single US-based vendor. It is worth watching. But it is not mainstream yet, and it is not what most UK employers will expect you to know.

For your first tool: ignore all three. Start with Figma. You can explore the others once you have grounding in how design tools work.

---

## Comparison at a glance

| | Figma | Sketch | Adobe XD |
|---|---|---|---|
| Platform | Web (Mac + Windows) | Mac only | Mac + Windows (discontinued) |
| Price | Free tier + ~£12/mo Pro | £99/year | Discontinued |
| Collaboration | Real-time, built in | Limited | Limited |
| Prototyping | Built in | Requires plugins | Built in (no new features) |
| Industry adoption | Very high | Declining | Negligible |
| Learn first? | Yes | No | No |

---

## The summary

The tool debate is largely settled. Figma is what most UX designers in the UK use, it works on any computer, it is free to start, and it covers the full workflow from wireframe to developer handoff in one place. Sketch has legitimate users but a shrinking footprint and a Mac-only restriction that is a real constraint. Adobe XD is not being developed anymore.

If you are starting your UX career in 2026, start with Figma. You will see it in job listings, in bootcamp curricula, in design system documentation, and in the Figma community resources that will help you learn faster.

For a broader overview of the tools UX designers use and why, see [UX design tools: a practical guide](/resources/).

---

## Learn Figma on the Beginner UX (AI) Design course

If you want to see what live UX training feels like before committing, the [free UX masterclass at UX Academy (myuxacademy.com)](/masterclass/free-ux-ui-masterclass/) is the place to start.

On the [Beginner UX (AI) Design](/courses/beginner-ux-design/) course at UX Academy, you learn Figma hands-on from day one. You will build wireframes, create component libraries, design interactive prototypes, and prepare designs for developer handoff — all across a real client project that goes in your portfolio.

The course is 8 weeks, live online, with a maximum of 15 students. Taught by practising UX professionals, not recorded videos. If you are making the move into UX design, this is where you start.


---

# Accessibility in UX Design: What It Means and Why It Matters

URL: https://myuxacademy.com/blog/accessibility-in-ux-design/
Accessibility in UX design explained: WCAG 2.2, the Equality Act 2010, the European Accessibility Act, inclusive design and how to test accessibility.

Accessibility is one of those terms that UX designers encounter early in their careers and assume they understand. You need sufficient colour contrast. You need alt text on images. You need keyboard navigation. Tick, tick, tick.

But treating accessibility as a checklist misses what it actually is: a design discipline in its own right. It requires the same kind of systematic thinking you bring to [usability](/blog/usability-in-ux-design/) or information architecture. And increasingly, it is also a legal requirement that many organisations are only now waking up to.

This post covers what accessibility means in a UX context, the standards and legislation you need to know, practical techniques you can apply to your work today, and the tools designers use to test it properly.

> **Want to make accessibility a core skill?** UX Academy (myuxacademy.com)'s [Accessibility for UX course](/courses/ux-accessibility/) is built around WCAG 2.2 and real-world audit practice. Cohort 1 starts 21 Sep 2026 -- [secure your place with a £99 deposit](/courses/ux-accessibility/).
> Or [try the free masterclass first](/masterclass/free-ux-ui-masterclass/).

## What accessibility means in UX

When we talk about accessibility in UX design, we are talking about designing so that people with disabilities can use your product. That sounds straightforward, but the range of disabilities it covers is broad:

- **Visual impairments** — from low vision and colour blindness to complete blindness (users who navigate with screen readers)
- **Auditory impairments** — users who are deaf or hard of hearing and rely on captions, transcripts, and visual cues rather than sound
- **Motor impairments** — users who cannot use a mouse and navigate by keyboard, switch control, or voice input; users with tremors or limited fine motor control
- **Cognitive disabilities** — users with dyslexia, ADHD, memory difficulties, or conditions that affect how they process language and structure

What makes this interesting from a UX perspective is that the same person might experience different accessibility needs depending on context. A broken arm is a temporary motor impairment. Bright sunlight on a phone screen is a situational visual impairment. Watching a video in a quiet office without headphones creates the same need for captions as permanent hearing loss. This is the insight that drives inclusive design: solve for the edges and you improve the experience for everyone.

## The business and legal case

Around 22% of working-age adults in the UK have a disability, according to the Office for National Statistics (ONS, 2023). That is not a niche audience. Inaccessible products exclude a significant portion of potential users, which means lost customers, lost revenue, and reputational risk.

On the legal side, UK designers need to be aware of three things. First, the **Equality Act 2010** is the foundational UK law: it requires service providers to make "reasonable adjustments" so that disabled people are not put at a substantial disadvantage, and this applies to websites and apps as services. Second, the **Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018** require public sector bodies to meet WCAG 2.1 Level AA and publish an accessibility statement. Third, the **European Accessibility Act (EAA)** — EU Directive 2019/882 — applies from June 2025 to a wide range of products and services sold into the EU, including e-commerce platforms, banking services, transport ticketing, e-books, and media players.

The EAA matters for UK businesses because it applies to products and services placed on the EU market, regardless of where the seller is based. A UK company selling to EU customers needs to meet its requirements. Between the Equality Act 2010 at home and the EAA for EU-facing products, accessibility has moved from best practice to a compliance requirement across most of the private sector.

None of this means accessibility is primarily a legal exercise. Compliance-driven accessibility tends to produce the minimum viable effort. Properly accessible products are better products — for everyone.

## WCAG 2.2 explained

The primary international standard for digital accessibility is the **Web Content Accessibility Guidelines**, known as WCAG, published by the W3C (World Wide Web Consortium). The current version is WCAG 2.2, published in October 2023.

### The four principles: POUR

WCAG 2.2 is organised around four core principles. Everything in the standard flows from these:

**Perceivable** — Information and user interface components must be presentable to users in ways they can perceive. If you can only see it or only hear it, some users are excluded.

**Operable** — User interface components and navigation must be operable. If something only works with a mouse, keyboard-only users and assistive technology users are excluded.

**Understandable** — Information and the operation of the interface must be understandable. This covers language, error handling, consistency, and predictability.

**Robust** — Content must be robust enough to be interpreted by a wide variety of user agents, including assistive technologies. This is primarily a technical concern but has design implications for how components are structured.

### Conformance levels

WCAG has three conformance levels:

- **Level A** — the minimum. Addresses the most critical barriers.
- **Level AA** — the standard that most products target. Covers a wide range of disabilities without being impractical to achieve.
- **Level AAA** — the most demanding level. Not typically required as a blanket standard, but worth considering for specific components.

When someone says a product is "WCAG compliant," they almost always mean WCAG 2.2 Level AA.

### What is new in WCAG 2.2

WCAG 2.2 added nine new success criteria. The ones most relevant to UX designers are:

**Focus Appearance (2.4.11/2.4.12)** — Focus indicators must meet minimum size and contrast requirements. Thin, low-contrast focus rings that were common in older designs no longer meet the standard.

**Dragging Movements (2.5.7)** — Any functionality that uses a dragging gesture must also be achievable by a single pointer (tap or click). This matters for sliders, kanban boards, and any drag-and-drop interaction.

**Target Size Minimum (2.5.8)** — Interactive targets must be at least 24x24 CSS pixels, with adequate spacing between adjacent targets. This addresses the problem of tightly packed small buttons on mobile.

**Accessible Authentication (3.3.8/3.3.9)** — Authentication processes must not rely solely on cognitive function tests (solving puzzles, identifying objects) unless there is an alternative. This affects CAPTCHA implementations and some multi-factor authentication flows.

## Inclusive design vs accessible design

These terms are related but not identical, and the distinction matters.

**Accessible design** refers to meeting a specific technical and design standard — primarily WCAG — so that people with disabilities can use your product. It is a defined, measurable target.

**Inclusive design** is a broader design philosophy. The principle, articulated clearly by the Microsoft Inclusive Design team, is to design for people at the margins of ability and context, because solutions that work for those users tend to work better for everyone. The classic example is kerb cuts: originally designed for wheelchair users, they are now used by parents with pushchairs, delivery workers with trolleys, and cyclists. Designing for the edge case improved the experience at the centre.

The two overlap significantly. Following WCAG will make your product more inclusive. Thinking inclusively will often lead you to accessibility solutions you would not have found by running a checklist. But a product can be technically WCAG-compliant and still be awkward or excluding for many users. Inclusive design asks the broader question: who are we not designing for, and what would it take to include them?

## Practical accessibility techniques

Here is where accessibility meets the daily work of a UX designer. These are not abstract principles — they are decisions you make in Figma, in your component library, and in your design specifications.

### Colour contrast

Normal body text requires a contrast ratio of at least 4.5:1 against its background. Large text (18pt or 14pt bold and above) requires 3:1. Non-text elements like icons and form borders require 3:1.

This is not just a visual nicety. It directly affects readability for users with low vision, colour blindness, or who are using a screen in bright sunlight.

### Do not use colour alone to convey information

If your form validation uses red for errors and green for success, users who are colour-blind cannot distinguish them. Add an icon, a text label, or a pattern. This principle extends to charts, maps, and any interface element where colour carries meaning.

### Keyboard navigation

Every interactive element in your product must be reachable and operable using only a keyboard. Tab moves between focusable elements; Enter or Space activates them; Escape closes modals and dropdowns. If you have built a custom dropdown, accordion, or date picker, it needs to follow the expected keyboard interaction patterns.

This is not just about keyboard-only users. Screen reader users navigate primarily by keyboard. Voice control users issue commands based on visible labels. A keyboard-navigable interface is the foundation for all of these.

### Visible focus states

When a user navigates by keyboard, they need to see where the focus is at all times. Many designs suppress the browser default focus ring because it looks untidy, without providing an alternative. WCAG 2.2 Focus Appearance (Level AA) now requires that focus indicators meet minimum size and contrast requirements. Design explicit, on-brand focus states rather than removing them.

### Alt text for images

Every image that conveys information needs a text alternative that describes its content. Purely decorative images should have an empty alt attribute (`alt=""`) so screen readers skip them. The goal is that a screen reader user gets the same information from the alt text as a sighted user gets from the image.

### Font sizes

WCAG does not specify a minimum font size, but 16px for body text is a widely accepted practical baseline. Smaller text forces users with low vision to zoom, which can break layouts that have not been designed responsively. Set your base size in relative units (rem, em) rather than fixed pixels so that users who have increased their browser default font size still get a proportionally larger result.

### Form labels

Never use placeholder text as a form label. Placeholder text disappears when the user starts typing, leaving them with no way to check what the field is asking for. Every input needs a persistent visible label. Labels should describe what the field expects, not just its name.

### Error messages

When something goes wrong in a form, the error message needs to be specific and actionable. "Error" or "Invalid input" is useless. "Your email address must include an @ symbol" tells the user what to fix. This connects to the error prevention heuristic discussed in [heuristic evaluation](/blog/heuristic-evaluation-ux-design/) — the best error message is one the user never needs to see, but when they do need it, it should actually help.

### Heading hierarchy

Screen reader users often navigate a page by jumping between headings. If your headings are styled for visual hierarchy without following semantic order (H1, H2, H3), screen reader users get a confusing structure. One H1 per page. Headings nest logically. Do not skip levels.

## Accessibility testing tools

You do not need to audit every design manually from scratch. Automated tools catch a meaningful share of issues, but as accessibility engineers such as Sara Soueidan and the team at the W3C consistently point out, automated checks alone miss the majority of real-world barriers — manual keyboard and screen reader testing is essential. These tools cover most of the common ground:

**Colour Contrast Analyser** (free, TPGi) — A desktop application that lets you pick any two colours on screen and see their contrast ratio. Essential for checking designs in real time.

**WAVE** (browser extension, free) — Overlays your live webpage with visual indicators of accessibility issues. Good for a quick audit of an existing product.

**axe DevTools** (browser extension, free tier) — Developer-focused accessibility testing tool. The free version catches a significant proportion of WCAG issues automatically.

**VoiceOver** (built into Mac and iOS) — Apple's screen reader. Free, widely used, and the best way to understand how a screen reader user actually experiences your product. Press Command + F5 on Mac to activate.

**NVDA** (free, Windows) — NonVisual Desktop Access, the most widely used screen reader on Windows. Used by many assistive technology users in the real world.

**Stark** (Figma plugin) — Checks colour contrast, simulates colour blindness, and helps you generate accessible design documentation.

**A11y Annotation Kit** (Figma, free) — A set of annotation components for marking up accessibility requirements on designs before handoff to developers.

## How to get started

If you are working on an existing product, start with an audit. Run WAVE on your key pages. Check your colour contrast with the Colour Contrast Analyser. Tab through your most important user journey and see what happens. The issues you find will almost certainly cluster around the same recurring problems: low contrast text, missing focus states, unlabelled form fields, images without alt text.

Prioritise by impact. Fix the issues that affect the most users across the most important journeys first. An inaccessible checkout flow is more urgent than an inaccessible blog sidebar.

If you are starting a new project, build accessibility into your design process from the beginning. Include it in your design system documentation. Make contrast checking part of your colour selection process. Write alt text requirements into your content guidelines. Add keyboard navigation to your interaction specifications. Retrofitting accessibility into a finished product is expensive and frustrating. Building it in from the start is just design.

## Want to build real accessibility skills?

Understanding WCAG 2.2 is one thing. Knowing how to apply it across a real product — how to run an accessibility audit, how to annotate designs for developers, how to use assistive technology to test your own work — is a different level of competence.

If you want to see what live UX training feels like before committing, the [free UX masterclass at UX Academy (myuxacademy.com)](/masterclass/free-ux-ui-masterclass/) is the place to start.

The [Accessibility for UX](/courses/ux-accessibility/) course at UX Academy covers WCAG 2.2, the Equality Act 2010, the European Accessibility Act, inclusive design methods, and hands-on testing across a six-week live programme. You will work on real accessibility challenges with expert instructors and leave with a portfolio piece that demonstrates your skills to employers.

[View the Accessibility for UX course](/courses/ux-accessibility/)


---

# Will AI Replace UX Designers? A 2026 Reality Check

URL: https://myuxacademy.com/blog/will-ai-replace-ux-designers/
Will AI replace UX designers? The honest answer in 2026: no, but the role is shifting. Here is what changes, what does not, and what skills to build.

**The short answer: no, AI will not replace UX designers - but the role is changing fast, and designers who ignore that shift will fall behind those who embrace it.**

If you are considering a career change into UX design right now, that question probably feels urgent. You have read the headlines. You have seen what image generators and coding assistants can do. The anxiety is understandable. But the anxiety is also based on a misreading of what UX design actually is - and what AI is actually good at.

This is an honest look at where AI is genuinely useful in UX work, where it falls short, and what the role looks like for someone entering the field in 2026.

## What AI is genuinely changing in UX work

Let us start with what is real. AI tools have made a meaningful difference to several parts of the UX workflow, and pretending otherwise would not serve you.

**Research synthesis is faster.** Analysing hours of user interview recordings, pulling out themes, and writing up findings used to take days. AI transcription and synthesis tools - used carefully, with human review - can compress that to hours. That is a genuine productivity gain.

**Generating variations is much quicker.** Need six different layouts to test? Four microcopy options for the same button? A first-draft set of onboarding screens? AI tools integrated into Figma and other design environments can produce starting points in minutes. You still need to evaluate, refine, and decide - but the blank-page problem is largely solved.

**Drafting is faster across the board.** Survey drafts, research discussion guides, presentation decks, handoff notes - AI assistants can produce serviceable first drafts that a designer then shapes. The thinking still belongs to the human; the typing happens faster.

**Accessibility and quality checks are improving.** AI-powered plugins can flag contrast failures, missing alt text, and reading-level issues automatically. Checks that once required a manual pass are increasingly automated.

These are real improvements. Designers who use these tools well will do more, faster. That is not a threat to the profession - it is a productivity multiplier that makes good designers more valuable, not less.

## What AI does not replace

Here is where the "AI will replace designers" argument breaks down.

**Problem framing.** Before you design anything, someone has to identify the right problem to solve. That requires talking to stakeholders with competing agendas, understanding business constraints, and making judgement calls about what actually matters. AI can help you synthesise what you already know. It cannot tell you what questions to ask or which problem deserves your team's attention next. That is a human skill, and arguably the most important one in the toolkit.

**User empathy.** UX design is grounded in understanding how real people experience the world - their frustrations, their mental models, their workarounds. That understanding comes from direct human contact: interviews, observation, the moment someone says something unexpected and you know you need to dig deeper. AI can transcribe what people say. It cannot notice what they did not say, or read the hesitation in someone's voice when they claim a product "works fine."

**Stakeholder navigation.** Getting a good design from sketch to shipped product involves persuasion, negotiation, and relationship-building across engineering, product, legal, and leadership. AI cannot sit in a difficult meeting, read the room, and know when to push back and when to compromise. That interpersonal judgement is irreplaceable.

**Ethics and accountability.** AI systems raise genuinely hard design questions: Who is excluded by this interface? What data is this collecting, and is that disclosed clearly? Does this pattern nudge users in a direction that benefits the company at users' expense? These are not questions with algorithmic answers. They require a human being who is willing to be accountable for the choices made. As AI features become more common in products, designers who can think carefully about these questions become more essential, not less.

**The integration of all of the above.** Good UX design is not a sequence of discrete tasks - it is a continuous loop of discovery, synthesis, decision-making, and testing, running in parallel with shifting business priorities and user needs. That integration requires a kind of contextual intelligence that AI tools do not have.

For more on the fundamentals of what the role involves, see [what does a UX designer do](/blog/what-does-a-ux-designer-do/).

## How the role is shifting

The better frame is not "AI versus designers" - it is "what does the job look like now?"

The honest answer is that some of the most repetitive, lowest-judgment parts of entry-level UX work are shrinking. Pixel-pushing for its own sake. Producing endless low-fidelity wireframes without a clear rationale. Manually tagging research notes.

What is growing:

- **AI product design** - designing the interfaces, interactions, and feedback loops for products that themselves use AI. Conversational UX, error states for unpredictable outputs, managing user trust in AI recommendations - these are emerging specialisms with real demand.
- **Strategic research** - because AI can handle synthesis speed, the premium shifts to designing better research, asking better questions, and making better decisions from the findings.
- **Design systems and governance** - as teams move faster with AI assistance, the need for rigorous systems, standards, and quality oversight grows.
- **Ethics and responsible design** - organisations facing regulatory pressure around AI are actively hiring designers who can think through user impact.

The designers who will struggle are those who see their value as executing well-defined tasks quickly. The designers who will do well are those who see their value as knowing what to build, and why.

This shift is part of a broader change in what makes a good career in the field - see [is UX design a good career](/blog/is-ux-design-a-good-career/) for a fuller picture. For a grounded look at the UK job market specifically, our post on [UX design jobs in the UK](/blog/ux-design-jobs-uk/) covers where hiring is happening and what employers are looking for.

## What skills to build in 2026

If you are entering UX design now, or considering it, here is where to focus:

**Core UX fundamentals first.** Research methods, interaction design principles, systems thinking, accessibility - none of this is made obsolete by AI. It is the foundation that lets you evaluate AI output critically rather than accepting whatever gets generated.

**Practical AI tool fluency.** Learn the AI features in Figma. Explore AI-assisted research tools. Understand how to prompt well for design artefacts, and - crucially - how to recognise when the output is good enough versus when it needs significant rework. This is becoming a baseline expectation alongside the rest of the [UX design tools](/resources/) that make up a practitioner's everyday toolkit.

**Critical evaluation.** The ability to look at AI-generated designs or research summaries and spot what is wrong, missing, or subtly off. This is a skill, and it requires strong UX fundamentals to do well.

**Communication and facilitation.** As AI handles more production work, the distinctively human contribution becomes sharper: the ability to run a discovery workshop, facilitate alignment across a product team, and present a design rationale persuasively.

**AI product literacy.** Understanding how large language models behave, where they fail, and how users form mental models of AI features. You do not need to be an engineer, but you do need enough working knowledge to design responsibly for AI-powered products.

For a deeper look at how AI is changing specific parts of design practice, see [AI in UX design](/blog/ai-in-ux-design/).

## The career-changer's honest calculus

If you are mid-career and considering UX design as a transition, the question is not "will AI make this field disappear?" The question is "does this still make sense as a direction?"

The answer, in 2026, is yes - with a caveat. The field is not standing still. Programmes that were built around tools and workflows from three years ago are not preparing people for what the job looks like now. You want training that takes AI seriously as a design medium and a professional tool, not one that treats it as an afterthought.

The other thing worth saying plainly: career changers often bring something to UX that junior designers trained straight from university do not have. Domain expertise from a previous career. Stakeholder experience. Business context. An understanding of how organisations actually make decisions. These are exactly the kinds of human skills that AI amplifies rather than replaces.

---

At UX Academy (myuxacademy.com), our [Beginner UX (AI) Design course](/courses/beginner-ux-design/) is built specifically around this territory - designing with AI tools, designing for AI-powered products, and developing the judgement to do both well. It is a live online programme, UK-based, next cohort starting <CohortDate />, with places reserved from £99 (refundable deposit).

If you want to see what the course covers before committing, join our [free UX masterclass](/masterclass/free-ux-ui-masterclass/) - a live session that gives you a real sense of how we teach and what the field looks like right now.


---

# What Is Figma Used For? UX, UI, Prototyping and More

URL: https://myuxacademy.com/blog/what-is-figma-used-for/
Discover what Figma is used for - from UI design and wireframing to prototyping and developer handoff. A practical guide in plain English.

**Figma is a browser-based design tool used for everything from rough wireframes to polished UI screens, interactive prototypes, and live developer handoff - all without switching apps.** It has become the dominant tool in UX and product design teams worldwide, and understanding what it actually does is a practical first step before you decide whether to learn it.

This guide walks through each major use case so you can see where Figma fits into a real design workflow.

If you are newer to the tool itself, start with our overview of [what is Figma](/blog/what-is-figma/) before reading on.

---

## Wireframing

Wireframing is the earliest stage of a design process - rough, low-fidelity layouts that show structure without visual polish. Figma is well suited to this because it is fast to sketch in, easy to share, and does not require exporting anything to show a colleague or client.

A wireframe in Figma might be nothing more than grey rectangles, placeholder text, and basic shapes. The point is to agree on layout and content hierarchy before investing time in visual design. Because Figma is multiplayer, a designer and product manager can work on the same wireframe at the same time - something that was genuinely awkward in older desktop tools.

Wireframes live in the same file as the finished designs, so the whole journey from rough sketch to final screen is traceable in one place.

---

## UI Design

UI design - the visual layer of a digital product - is where most people think of Figma first. Designers use it to create high-fidelity screens: colour palettes, typography, spacing, icons, illustrations, and every interactive state a component might need (default, hover, focused, disabled, error).

Figma's vector tools are precise enough for professional work, and its Auto Layout feature - which lets elements resize and reflow automatically based on content - makes it practical to design responsive interfaces without duplicating frames by hand.

Teams working on large products often maintain a full UI kit inside Figma: a master file of every button, input, card, modal, and navigation pattern the product uses. Designers pull from that kit rather than recreating elements from scratch, which keeps screens visually consistent.

---

## Prototyping

A prototype is a clickable, interactive version of a design that simulates how a real product would work - without any engineering involved. Figma has a built-in prototyping mode that lets you connect screens together with transitions, define what happens on a click or hover, and share a live preview link with anyone.

This is used at several stages:

- **Concept testing** - showing stakeholders or users a rough flow before any development begins
- **Usability testing** - giving research participants something to navigate so you can observe their behaviour
- **Stakeholder sign-off** - letting a product director or client click through a feature before it is built

Figma prototypes are not coded, so they cannot replicate every interaction in a production app. For simple flows, though, they are fast to build and convincing enough to surface real usability problems early - which is the whole point.

---

## Design Systems and Component Libraries

A design system is a shared set of standards - visual, written, and behavioural - that keeps a product consistent across every screen and every team member who touches it. Figma is the tool most commonly used to build and maintain the design-side of a system.

In practice this means:

- **Components** - reusable elements (buttons, form inputs, cards) defined once and used everywhere. Change the master component, and every instance updates automatically.
- **Variables and styles** - shared colour tokens, typography scales, and spacing values that can be swapped across an entire file in seconds.
- **Libraries** - published component sets that any Figma file in an organisation can connect to.

For designers working across large products or multiple brands, a well-maintained Figma library is what prevents every new feature becoming a one-off visual experiment.

---

## Real-Time Collaboration

Before Figma, design files lived on one person's machine. Sharing meant exporting PDFs, attaching them to emails, and then losing track of which version was current. Figma replaced that entirely.

Multiple people can be inside the same file at the same time - each with their own cursor, each making edits. Comments can be left directly on a specific part of a design, with threads that can be resolved once addressed. This changes how design reviews work: instead of a scheduled meeting to look at screenshots, a product manager can drop a comment on a frame at any time and a designer can respond in context.

For distributed teams - which describes most product companies today - this is not a nice-to-have. It is a core part of how design work actually gets done.

---

## Developer Handoff

When a design is ready to be built, a developer needs to know the exact values behind what they are looking at: font sizes, hex colours, padding, border radius, spacing between elements, asset dimensions. In the past this required a separate handoff tool like Zeplin or InVision Inspect.

Figma has handoff built in. Developers can open a design file in Dev Mode, click on any element, and see its properties in code-ready format - CSS values, iOS equivalents, or Android specs depending on the platform. Assets can be exported directly from the same panel.

This does not replace developer judgement - real implementations always involve decisions Figma cannot anticipate - but it removes the friction of asking designers "what size is that button?" for every element.

---

## FigJam: Whiteboarding, Research Synthesis, and Workshops

FigJam is Figma's companion tool for open-ended, non-screen-based work. It is an infinite canvas for the kinds of activities that used to happen on a physical whiteboard:

- **Affinity mapping** - clustering research notes into themes after a round of user interviews
- **Journey mapping** - mapping a user's experience across time and touchpoints
- **Brainstorming sessions** - sticky-note ideation with a whole team, remote or hybrid
- **Retrospectives** - structured team reflection exercises
- **Workshop facilitation** - running live collaborative sessions with participants in a shared space

FigJam is intentionally simpler than Figma's design canvas - it is built for speed and participation rather than precision. A researcher can set up a synthesis session in minutes and invite the whole team to contribute without anyone needing to know how to use Figma proper.

---

## Who Uses Figma?

Figma is not just a designer's tool. In a typical product team:

- **UX designers** use it across the whole process - wireframes, flows, research synthesis in FigJam, final UI
- **UI designers** work primarily in the high-fidelity stages, building and maintaining component libraries
- **Product managers** use FigJam for roadmaps and brainstorming, and Figma files to review and comment on designs
- **Developers** use Dev Mode to inspect and export assets during implementation
- **UX researchers** use FigJam for synthesis and Figma prototypes for moderated usability testing

The skill floor is low enough that non-designers can participate meaningfully without training. The ceiling is high enough that experienced designers can spend years deepening their practice.

---

## Figma vs. Other Tools

Figma did not invent UI design software - Sketch and Adobe XD came before it - but it changed the standard. Sketch is Mac-only and requires a third-party tool for developer handoff. Adobe XD has been discontinued as a standalone product, with features folded into other Adobe apps. Neither matches Figma's native multiplayer collaboration.

For most people learning design today, Figma is the practical starting point. It is what you will find on job descriptions, what bootcamps and courses teach, and what the majority of product design teams use day to day.

If you want to go deeper on how it compares and where to start, our [Figma for beginners](/blog/figma-for-beginners/) guide covers the learning curve honestly.

---

## Learning Figma as Part of a UX Career

Knowing what Figma is used for is one thing. Being able to use it fluently - picking the right approach for each stage, communicating clearly with developers, running a prototype test - takes guided practice.

At UX Academy (myuxacademy.com), Figma is woven throughout our [beginner UX design course](/courses/beginner-ux-design/), not treated as a standalone software tutorial. You learn it in context: wireframing real briefs, building prototypes you test with real users, and handing off work the way a professional team would.

Our next cohort starts <CohortDate />, taught live online by working practitioners. If you are not sure whether UX design is the right direction yet, join our [free UX and UI masterclass](/masterclass/free-ux-ui-masterclass/) first - it runs regularly and is a good way to test the water before committing.

You can also read [what is UX design](/blog/what-is-ux-design/) for a broader introduction to the field Figma sits inside.


---

# Vibe Coding for UX Designers: AI Prototyping in 2026

URL: https://myuxacademy.com/blog/vibe-coding-for-ux-designers/
Vibe coding lets UX designers describe ideas in plain English and get working prototypes fast. Here's how to use it well - and where it falls short.

**Vibe coding is a way of building software by describing what you want in plain language, letting an AI tool translate that intent into working code. For UX designers, it changes what prototyping can mean.**

Until recently, producing a functional prototype - one with real interactions, real data, real browser behaviour - required either developer time or weeks of learning a framework. Vibe coding collapses that gap. You describe a form that validates in real time, or a dashboard that filters on click, and an AI tool generates something you can actually open in a browser and test.

This post explains what vibe coding is, why it is relevant to UX practice right now, how to use it effectively, and where it genuinely falls short.

---

## What "Vibe Coding" Actually Means

The phrase has spread quickly in 2025 and 2026, but it describes something fairly specific: you write natural language prompts that describe the behaviour, layout, or logic you want, and an AI tool generates working code. You refine iteratively by continuing the conversation - "make the button sticky on scroll", "add error states to the email field", "show a loading spinner while the data fetches" - rather than editing the code directly.

The name is deliberately casual. The implication is that you can follow a feeling or a direction without needing to know exactly how it will be implemented. That is both the power and the risk.

Vibe coding tools sit on a spectrum. Some are full app builders that deploy a working site from a description. Others generate UI component code you paste into an existing project. Others are code editors with AI assistants embedded. What they share is the same core loop: describe intent, review output, refine.

---

## Why UX Designers Should Pay Attention

UX designers already prototype. The question is what fidelity of prototype is useful at which stage of the process.

Static screens in Figma are fast to produce and easy to share. But they have a ceiling. You cannot test whether a multi-step form actually feels smooth to fill out. You cannot see how a component behaves when the content is twice as long as the placeholder text. You cannot hand a stakeholder something they can use on their phone in a meeting.

Vibe coding opens up a tier of prototyping that previously required a developer: functional, interactive, testable in a real browser. For a UX designer, that has three practical applications.

**Testing real interactions.** Clicking through a Figma prototype and using a real web form are different experiences. Vibe coding lets you build the form and test it, not simulate it. Hover states, focus behaviour, validation timing, scroll behaviour - these things are hard to fake and easy to generate.

**Prototyping faster.** For ideas that need to be evaluated quickly - a new onboarding flow, a checkout revision, a search pattern - vibe coding can produce something testable in an afternoon rather than a sprint. That changes the economics of exploration.

**Communicating with developers.** A working prototype in code is a different kind of handoff artefact. It removes ambiguity about behaviour in a way that annotations and specs often cannot. Even if the vibe-coded output is not production-ready, it demonstrates intent precisely.

For more on how AI is reshaping the toolkit, see our overview of [AI tools for UX designers](/blog/ai-tools-for-ux-designers/) and the broader picture of [AI in UX design](/blog/ai-in-ux-design/).

---

## How to Use Vibe Coding Well

The designers who get the most from vibe coding tend to share a few habits.

**Start with a clear brief, not a vague prompt.** "Build a sign-up form" produces generic output. "Build a two-step sign-up form where step one collects email and password, step two collects name and role, and the user sees a progress indicator at the top" produces something specific you can actually evaluate. The precision of your natural language prompt directly shapes the usefulness of the output.

**Treat the first output as a sketch, not a solution.** The AI will generate something that looks plausible. Your job is to review it critically: does the interaction feel right? Are the states complete? Is anything missing that a real user would encounter? Refine through conversation - "the error message appears too slowly", "the focus order skips the checkbox" - rather than accepting the first result.

**Use it for exploration, not production.** Vibe coding accelerates the part of the process where you are testing ideas. It does not replace the engineering work needed to build something accessible, performant, and maintainable. The output is a tool for learning and communication, not a finished product.

**Document what you are testing.** Because vibe coding is fast, it is easy to generate lots of variations and lose track of what you actually learned from each. Keep notes alongside the prototypes: what question were you trying to answer, what did users or stakeholders respond to, what changed as a result.

---

## Tools Worth Knowing

The vibe coding landscape is moving quickly, so specific feature claims go stale fast. But several tools have established themselves as relevant to UX work.

**Lovable** is aimed at non-developers building full web applications from natural language descriptions. It handles backend plumbing as well as UI, which makes it useful for prototyping flows that involve data.

**v0** (from Vercel) generates React component code from descriptions or screenshots. It is closer to a component-level tool than a full app builder, which suits designers who want to prototype specific UI patterns.

**Figma Make** brings AI-generation into Figma, letting you describe a component or layout and see it generated within your existing design environment. It lowers the context-switching cost for designers already working in Figma. If you are still getting to grips with the core tool, our [Figma for beginners](/blog/figma-for-beginners/) guide covers the foundations.

**Cursor** is a code editor with AI embedded throughout. It is more developer-oriented but increasingly used by designers who are comfortable in code or who want to collaborate directly on a codebase rather than producing standalone prototypes.

None of these tools are magic. The output quality depends heavily on the quality of your prompts, your ability to review what is generated, and your judgment about when the prototype is good enough to test.

---

## Where Vibe Coding Falls Short

It is worth being direct about the limits, because the current excitement around vibe coding can obscure them.

**Accessibility is not automatic.** Generated code often produces visually plausible output that fails basic accessibility requirements: poor focus management, missing ARIA labels, inadequate colour contrast, keyboard traps. If you are using vibe coding to prototype for real users, you need to audit the output - or at minimum test it with a screen reader and keyboard-only navigation.

**Edge cases get skipped.** Vibe coding tools optimise for the happy path. They produce something that looks right for typical inputs and typical states. What happens when the user's name is 60 characters long? What does the error state look like after three failed attempts? What happens on a slow connection? You have to ask for these explicitly, and even then you need to check them.

**You still need UX thinking.** Vibe coding can generate an interface quickly. It cannot determine whether that interface solves the right problem, serves the right users, or fits into a coherent experience. The design thinking that precedes the prototype - the research, the problem framing, the information architecture - is not something the AI can do for you. Fast prototyping only has value when you know what you are trying to learn.

**The code may not be usable.** If your goal is to hand off a vibe-coded prototype to a development team, be prepared for them to rebuild rather than extend it. Generated code is often functional but not maintainable, and the architectural decisions baked in may not match the production environment.

---

## Vibe Coding as Part of a Broader Skill Set

The most useful frame for vibe coding is probably this: it expands what a UX designer can test independently, without waiting for development resource. That is genuinely valuable. But it sits alongside other skills, not instead of them.

A designer who can vibe code, research effectively, structure an information architecture, test with real users, and communicate findings clearly is more capable than a designer who can only do any one of those things. Vibe coding is one tool in that set - a powerful one, but still just a tool.

What it does change is the ceiling of what solo UX work can produce. A designer exploring a complex interaction pattern no longer has to stop at a Figma simulation. They can build something real, test it, and carry that learning forward. That is a meaningful shift.

---

## Learn to Design With AI at UX Academy (myuxacademy.com)

Our [Beginner UX (AI) Design course](/courses/beginner-ux-design/) is built around exactly this kind of practice - designing with AI tools as part of a real design process, not as a gimmick. The course is live online, runs in small cohorts, and is led by working practitioners. The next cohort starts <CohortDate />.

If you want a sense of the approach before committing, our [free UX/UI masterclass](/masterclass/free-ux-ui-masterclass/) is a good place to start.


---

# UX Portfolio Review Checklist (Free)

URL: https://myuxacademy.com/blog/ux-portfolio-review-checklist/
A free UX portfolio checklist to self-review your work before applying for jobs. Check structure, case studies, visuals, and written clarity.

**Before you send your portfolio to a hiring manager, run it through this checklist.** A strong UX portfolio is not about beautiful mockups - it is evidence that you think clearly, involve real users, and make design decisions you can defend.

Use this as a self-review tool. Work through each section honestly. Flag anything that does not pass, then fix it before you apply.

**Prefer a printable version?** [Download the free UX portfolio review checklist](/resources/templates/portfolio-review/) to tick off as you go.

---

## How to Use This Checklist

Print it, copy it into a doc, or work through it on screen. For each item, mark it as:

- **Pass** - clearly in place
- **Fix** - present but needs improving
- **Missing** - not there at all

Aim for no "Missing" items before you apply anywhere. For senior roles, aim for no "Fix" items either.

---

## Section 1 - Overall Portfolio Structure

A recruiter typically spends under two minutes on a first pass. Your structure needs to do the work.

**Navigation and access**

- [ ] Portfolio URL is short, professional, and easy to share (no long random strings)
- [ ] Site loads in under 3 seconds on a mobile connection
- [ ] Navigation is immediately clear - visitor can find case studies within one click
- [ ] No broken links or placeholder pages

**First impression**

- [ ] Homepage or landing section states who you are and what kind of work you do
- [ ] It is immediately obvious this is a UX design portfolio (not a graphic design or development portfolio unless that is your angle)
- [ ] You have 2-4 case studies featured, not a grid of 10 thumbnail images
- [ ] About section is present and is 2-4 short paragraphs (not a wall of text, not a one-liner)

**Contact and credibility**

- [ ] Contact details or a contact form are easy to find
- [ ] LinkedIn profile is linked and up to date
- [ ] Any certifications, courses, or bootcamp completions are mentioned briefly

---

## Section 2 - Each Case Study (Run This for Every Project)

This is where most portfolios fall short. Work through these questions for every case study individually.

### Problem and Context

- [ ] The problem is stated in plain language in the first paragraph
- [ ] The business context is explained (what product, what company type, what user base)
- [ ] It is clear why this problem mattered - what was at stake for the user or the business
- [ ] You do not open with a paragraph about "what UX is" or your design philosophy

### Your Role

- [ ] Your specific role is stated clearly (solo designer, part of a team, lead, support)
- [ ] If it was a team project, your individual contribution is explicitly described
- [ ] The timeline and any constraints (time, budget, access to users) are mentioned briefly

### Research and Discovery

- [ ] You describe what research method(s) you used and why you chose them
- [ ] You name real methods (user interviews, usability testing, card sorting, surveys, desk research) - not just "I did research"
- [ ] You show what you learned from the research, not just that you did it
- [ ] If you had limited access to users, you acknowledge it and explain what you did instead

### Design Process and Decisions

- [ ] You show process artefacts: wireframes, journey maps, affinity diagrams, prototypes - at least some working artefacts at different fidelities
- [ ] Each major design decision has a rationale ("I chose X because...")
- [ ] You show iteration - an early version and how it changed in response to testing or feedback
- [ ] You do not just present the final polished screens as if they appeared fully formed

### Outcomes and Evidence of Impact

- [ ] The case study has a defined outcome - what happened when the design was implemented or tested
- [ ] Wherever possible the outcome is specific: a usability score, task completion rate, conversion change, time-on-task reduction, or stakeholder decision made
- [ ] If the project was academic or self-initiated and has no live outcome, you state that clearly and explain what you would measure if it shipped
- [ ] You do not use vague phrases like "improved the user experience" as the outcome

### Reflection

- [ ] The case study ends with at least a brief honest reflection
- [ ] You name something you would do differently with more time or resources
- [ ] You mention what you learned from this project
- [ ] The reflection sounds genuine, not like a cover letter sign-off

---

## Section 3 - Visual Presentation

- [ ] Mockups and screens are shown at a readable size - not tiny thumbnails
- [ ] Image quality is crisp (no blurry exports or low-resolution screenshots)
- [ ] Annotated wireframes include legible labels - zoomed in enough to read
- [ ] You are not relying entirely on Dribbble-style aesthetic shots with no process context
- [ ] Colour and layout are consistent across the portfolio (not a different visual style per project)
- [ ] Prototype links work and are tested on the device a recruiter is likely to use
- [ ] If you include video walkthroughs, they have captions or a text summary alongside

---

## Section 4 - Written Clarity

Bad writing undermines good design thinking. Your writing is part of the portfolio.

- [ ] Case study titles describe the project and problem, not just the company name ("Redesigning the checkout flow for a B2C fashion retailer" not "Nike Project")
- [ ] Paragraphs are short - three to five sentences maximum before a break
- [ ] You use plain language throughout - no unnecessary jargon
- [ ] Passive voice is minimised ("I ran five user interviews" not "five user interviews were conducted")
- [ ] You write in first person and take ownership of decisions
- [ ] No spelling errors or grammatical mistakes (ask a trusted reviewer to read it fresh)
- [ ] UK English or US English is used consistently - do not mix them

---

## Section 5 - Red Flags to Fix Before You Apply

These are the most common reasons a portfolio gets passed over. Check each one specifically.

**Process red flags**

- [ ] You are not showing only final deliverables with no process work
- [ ] You are not describing every project as "a team effort" with no individual contribution stated
- [ ] You have not included a project where you never spoke to a single real user (if you have one, acknowledge the limitation)

**Content red flags**

- [ ] You have not included more than one "redesign a famous app" speculative project as a main case study
- [ ] Your projects are not all from the same brief or bootcamp template - they show some range
- [ ] You have not described your role as "UX/UI/graphic/brand designer" with no clear positioning

**Presentation red flags**

- [ ] Your portfolio does not require a PDF download to see the work (PDF as a supplement is fine; PDF as the only format is not)
- [ ] You do not have a case study that is one page of text with no visuals at all
- [ ] You have not listed 15 tools in your skills section as a substitute for showing what you can do with them

---

## Section 6 - Final Pre-Application Check

Run this final sweep immediately before each application round.

- [ ] You have re-read every case study in the last 30 days and it still represents your best current thinking
- [ ] Any dates, timelines, or project statuses are accurate
- [ ] Your portfolio loads correctly in Chrome, Firefox, and Safari
- [ ] You have tested it on a phone - a significant proportion of recruiters will view it on mobile
- [ ] The email address or contact form on the site goes to an inbox you check regularly
- [ ] If you have a password-protected case study for confidential client work, you have included the password in your application email

---

## What to Do With Your Results

If you have a cluster of "Fix" or "Missing" marks in Section 2 (the case study criteria), that is the highest-priority area. One case study with outstanding depth and clear evidence of impact will carry a portfolio. Five thin ones will not.

If Section 4 (written clarity) has issues, treat it as a skills gap worth addressing seriously. UX designers communicate in writing constantly - to stakeholders, in design specs, in research reports. A portfolio with weak writing signals something a hiring manager cannot overlook.

For a broader view of building your portfolio from scratch, read our [UX design portfolio guide](/blog/ux-design-portfolio-guide/). If you are just starting out and need to build one from nothing, [how to build a UX portfolio from scratch](/blog/how-to-build-a-ux-portfolio-from-scratch/) walks through the process step by step. To understand what the standard looks like at different career stages, [UX design portfolio examples](/blog/ux-design-portfolio-examples/) is a useful reference before you apply. If you are just starting out, [getting a UX job with no experience](/blog/ux-job-with-no-experience/) covers how to approach the job search before your portfolio is complete. And if you are still deciding whether UX design is the right move, [what does a UX designer actually do](/blog/what-does-a-ux-designer-do/) is a good place to start.

---

## Build a Portfolio-Ready Project During Your Course

The most common gap in early-career portfolios is a real client project - one where you worked with actual users and a real brief, not a fictional scenario.

UX Academy's (myuxacademy.com) [beginner UX design course](/courses/beginner-ux-design/) includes a live client project built into the curriculum. You work with a real organisation, run your own user research, and produce a deliverable you can put straight into your portfolio. Taught live online, based in the UK, with the next cohort starting <CohortDate />.

If you want to see what the course covers before committing, the [free UX and UI masterclass](/masterclass/free-ux-ui-masterclass/) is a good first step.


---

# UX Designer vs Product Designer vs UI Designer

URL: https://myuxacademy.com/blog/ux-designer-vs-product-designer/
UX designer vs product designer: what each role actually does day-to-day, how they differ from UI design, and which path fits your background and goals.

**UX designer vs product designer is one of the most common points of confusion for anyone entering the design field - and the difference matters when you are choosing a career path or reading job ads.**

If you are researching a design career, you have almost certainly seen all three titles - UX designer, product designer, UI designer - used interchangeably, occasionally in the same job ad. These are related roles that share tools and overlap significantly, but they have distinct focuses, day-to-day responsibilities, and career trajectories. This post compares the roles themselves. For a deeper look at the underlying disciplines, see our companion post on [product design vs UX design](/blog/product-design-vs-ux-design/).

## UX designer vs product designer vs UI designer: the role definitions

To compare the roles clearly, it helps to start with what each one actually involves day-to-day.

### What does a UX designer do?

UX stands for user experience. A UX designer's job is to make products useful, usable, and satisfying for the people who use them. The focus is on the complete journey a person takes to achieve a goal - not just a single screen, but every step, decision point, and potential point of friction along the way.

A UX designer's work typically includes:

- **User research** - interviews, surveys, usability tests, and field studies that surface what people actually need and where they struggle. Our guide to [UX research methods](/blog/ux-research-methods/) covers the main approaches and when to use them.
- **Information architecture** - how content and features are organised, labelled, and navigated.
- **User flows and journey maps** - mapping the steps a person takes from entry point to goal completion.
- **Wireframing** - low-fidelity structural layouts that focus on hierarchy and logic, not aesthetics.
- **Prototyping and testing** - building rough interactive versions to validate ideas with real users before committing to build.

The north star for UX design is whether the product genuinely works for its users. A UX designer might spend weeks on a problem before a single visual decision is made. The discipline draws from psychology, cognitive science, and research methods as much as from design. See our deeper guide to [what a UX designer actually does](/blog/what-does-a-ux-designer-do/) for a fuller picture.

### What does a UI designer do?

UI stands for user interface. UI design is the craft of the visual and interactive surface - everything a user sees and directly touches. Where UX defines the structure and logic of an experience, UI defines its look, feel, and moment-to-moment interactivity.

A UI designer's work typically includes:

- **Visual design** - colour, typography, spacing, layout, and visual hierarchy.
- **Interactive elements** - buttons, form fields, toggles, menus, and their various states (default, hover, active, disabled, error).
- **Design systems and component libraries** - reusable visual components and style rules that keep a product consistent at scale.
- **Microinteractions** - the small animations and transitions that make an interface feel responsive and alive.
- **Accessibility** - ensuring contrast ratios, font sizes, and interaction patterns work for users with a range of abilities.

A useful shorthand: UX decides what goes on the screen and why; UI decides exactly how it looks and responds. A beautifully styled interface built on a confusing flow is a UX failure. A logically sound flow rendered with broken visuals and poor contrast is a UI failure. Good products get both right.

For a deeper comparison of these two disciplines, our post on [UX vs UI design](/blog/ux-vs-ui-design/) covers the distinction in full.

### What does a product designer do?

Product design is a broader remit that encompasses much of what UX and UI design involve, but extends further into business strategy, product thinking, and measurable outcomes.

A product designer still conducts research, maps flows, builds wireframes and prototypes, and owns the visual design of what ships. But they are also expected to:

- **Engage with product strategy** - contributing to decisions about what to build and why, not just how to design what has been scoped.
- **Work with business metrics** - understanding how a feature affects retention, conversion, engagement, or revenue, and letting that inform design decisions.
- **Collaborate cross-functionally** - working closely with product managers, engineers, and data analysts from early problem-framing through to post-launch measurement.
- **Own end-to-end feature delivery** - from initial problem definition through to shipped output and evaluation of whether it worked.

Where a UX designer might ask "is this flow usable?", a product designer is simultaneously asking "does this feature move the metric we care about?" and "are we solving the right problem at the right time?". The role carries more commercial accountability, which is part of why it tends to come with higher seniority and pay.

Our post on [product design vs UX design](/blog/product-design-vs-ux-design/) goes deeper on how the two roles relate and where the lines blur in practice.

## How the three roles overlap

The honest answer is: considerably. All three disciplines often use the same tools (Figma is the industry standard across all three), all three involve understanding users, and all three contribute to the same end goal of a working product. The overlaps are real, not cosmetic.

In practice, many practitioners do all three - especially at startups and smaller companies where a single designer covers research, interaction design, and visual polish end-to-end. At larger organisations, the roles are more likely to be split across specialists: a UX researcher, an interaction designer, a visual/UI designer, and a product designer who coordinates between them.

## How job titles vary by company

This is where things get genuinely confusing, because the same job can carry different titles depending on the company, its size, and its design maturity.

A few patterns that hold broadly:

- **Large tech companies** (think companies with hundreds of designers) tend to use both titles and mean different things by them. "Product designer" usually implies a more senior, commercially embedded role. "UX designer" may refer to a more specialist, research-heavy or interaction-design-heavy role. UX researchers, content designers, and interaction designers often sit alongside both as separate disciplines.
- **Mid-size product companies and scale-ups** often use "product designer" as the default title for anyone doing design work. "UX designer" titles are less common here, even when the actual work is similar.
- **Agencies and consultancies** are more likely to use "UX designer" and to value deep specialisation in research, strategy, and information architecture.
- **Startups** routinely use all three titles to describe broadly the same generalist design role. Read the job description, not just the title.

The practical implication: do not choose a career path based on a title. Look at the actual responsibilities in job ads for roles that interest you, and develop the skills that appear consistently.

## Comparison at a glance

| | UX Design | UI Design | Product Design |
|---|---|---|---|
| **Core focus** | Usability, user journeys, research | Visual and interactive surface | End-to-end product quality + business impact |
| **Key outputs** | Research findings, wireframes, prototypes, flows | Visual designs, components, design systems | Feature designs, strategy input, metrics-informed decisions |
| **Primary collaborators** | Researchers, content designers, engineers | UX designers, brand teams, engineers | PMs, engineers, data analysts, leadership |
| **Typical tools** | Figma, Maze, Dovetail, Miro | Figma, design system tools | Figma, analytics platforms, roadmap tools |
| **Scope** | User-centred | Interface-centred | User + business |
| **Common in** | Agencies, large companies | Studios, large product teams | Startups, scale-ups, large tech |

## Salary and career path

All three paths lead to well-compensated careers, with product design typically commanding the highest salaries at senior levels, reflecting the broader scope and business accountability of the role. Dedicated UI design roles tend to sit slightly lower on average, though this varies considerably by sector and company size. For verified salary figures across all three roles, see our guide to [UX designer salaries in the UK](/blog/ux-designer-salary-uk/).

Across all three, there is a consistent pattern: specialists who can demonstrate impact on real products - with portfolio evidence - progress faster than generalists with theoretical knowledge. The ability to conduct and interpret user research is increasingly valued across all three roles, not just in UX.

Career progression in all three disciplines typically follows a path from junior/mid designer, to senior designer, to lead or principal designer, with some practitioners moving into design management and others deepening their craft specialism. Product design tends to open the most direct routes toward principal IC roles at tech companies and toward design leadership.

## Which should you pursue?

The right answer depends on what draws you to design work.

**Pursue UX design if** you are most energised by understanding people - what they need, why they behave as they do, where they struggle - and you want to solve those problems through structure and logic before anything is styled. The [UX design process](/blog/ux-design-process/) gives you a practical framework for that kind of structured, evidence-based work. UX is the strongest foundation for most career-changers and gives you transferable skills regardless of which direction you specialise later.

**Pursue UI design if** you have a strong visual instinct and are drawn to the craft of how things look and feel at the interface level. A background in graphic design, illustration, or visual communication translates well here. UI as a sole specialism is more often found at larger companies and studios.

**Aim for product design if** you want the broadest remit, are comfortable with ambiguity, and are interested in how design intersects with business strategy and metrics. This is often where experienced UX or UI designers land after a few years, rather than an entry-level starting point.

For most people entering the field from a non-design background, **starting with UX is the clearest path**. It teaches you how to think about users, structure products, and justify decisions with evidence - all skills that carry into UI and product design naturally as your experience grows. Our step-by-step guide to [how to become a UX designer](/blog/how-to-become-a-ux-designer/) walks through the practical route from career-changer to first role.

---

If you are ready to build those foundations properly, UX Academy (myuxacademy.com) runs live online UX courses in the UK, taught by working practitioners. The next cohort starts <CohortDate />. You can explore the [Beginner UX (AI) Design course](/courses/beginner-ux-design/) or join a [free UX/UI masterclass](/masterclass/free-ux-ui-masterclass/) to get a feel for how we teach before committing.


---

# UX Design Classes Near Me: UK Options for 2026

URL: https://myuxacademy.com/blog/ux-design-classes-near-me/
Looking for UX design classes near me in the UK? Compare in-person, evening, and live-online options to find the right course for 2026.

**If you have searched for UX design classes near me, you already know what you want: real instruction, interaction, and structured learning - not another self-paced video library.** The good news is that the UK market in 2026 gives you more options than ever, and the best one may not be the one closest to your postcode.

## What "near me" actually means when you search for UX courses

When people type "UX design classes near me" into Google, they are rarely committed to in-person learning. They want:

- A real teacher they can ask questions
- Scheduled sessions that create accountability
- Feedback on their work, not just auto-marked quizzes
- Other learners to bounce ideas off

Those are legitimate needs, and they are worth naming clearly - because different course formats meet them in very different ways. The format that happens to be physically close to you may not be the one that meets them best.

## The main types of UX design course available in the UK

### 1. In-person evening and weekend classes

Evening classes at local colleges, design studios, or co-working spaces give you a physical room and face-to-face contact. They tend to be shorter (a few sessions rather than a full programme), lower cost, and focused on introductory content. They are a good way to test whether UX is right for you before committing to a longer course.

The downsides: availability is patchy outside London and a handful of other cities, session times are fixed and non-negotiable, and the teaching quality varies considerably. If you miss a session, there is usually no catch-up.

### 2. Weekend workshops and intensives

Some training providers run intensive one- or two-day workshops covering UX fundamentals, portfolio work, or specific skills such as user research or Figma. These are useful for adding a specific skill or for portfolio-building, but they are rarely sufficient on their own for a career change.

### 3. University and college certificates

Several UK universities and further education colleges offer UX or interaction design modules, either as evening study or short online courses. Quality and depth vary. They can carry academic credibility, but they are often built around pre-recorded content with minimal live interaction.

### 4. Self-paced online platforms

Platforms such as Coursera, LinkedIn Learning, and various bootcamp-style sites offer self-paced UX courses. These are accessible and flexible, but completion rates are low because there is no structure, no cohort, and no one waiting for your work on Thursday evening. For most career-changers, self-paced learning alone is not enough.

### 5. Live-online cohort programmes

A live-online cohort course runs to a fixed schedule - regular sessions over several weeks - with a live instructor, a small group of students, and a real project brief. You attend online (no commute, no geography), but the experience mirrors in-person study: you can ask questions, get critiqued, and build working relationships with classmates.

This is where "near me" and "live online" converge. If the instructor is live and the cohort is small, location becomes almost irrelevant.

## What to look for when comparing UX design courses

Whether you are comparing in-person classes or live-online options, these are the questions that matter most.

**Is the teaching live or pre-recorded?**
Live instruction with question time is fundamentally different from watching recorded lectures. Ask specifically: are sessions live, or do I watch videos and submit assignments?

**How many students per cohort?**
A cohort of 50 is closer to a lecture hall than a class. Aim for 15 or fewer if you want meaningful feedback on your work.

**Will I work on a real project?**
UX is a portfolio discipline. A course that ends without a portfolio piece - ideally one based on a real or realistic client brief - leaves you less employable than one that does. Ask what you will have to show at the end.

**What support is available between sessions?**
Good programmes offer some form of async support - a Slack channel, office hours, or tutor feedback between live sessions. This matters for career-changers who encounter blockers outside of class time.

**What does the price include?**
Compare like for like. A lower headline price sometimes excludes software licences, feedback sessions, or career support that a higher-priced programme includes.

**Are there past students you can speak to?**
Any credible programme should be able to put you in touch with alumni. If they cannot, or will not, that is worth noting.

## London options: what is actually available

London has the widest in-person UX course market in the UK. You will find:

- Evening taster sessions and workshops from design agencies and studios
- Short introductory courses at some further education colleges
- Occasional weekend intensives through events companies

That said, London in-person UX courses face the same constraints as elsewhere: limited places, fixed times, and teaching quality that depends entirely on who is in the room that evening. Central London venues also add cost, which often shows up in the course price.

For Londoners specifically, a live-online cohort can be easier to fit around a job than a course that requires you to be in Shoreditch or Soho by 6:30pm on a Tuesday.

If you want more detail on London-specific options, see our [UX design courses London](/ux-design-courses-london/) guide, and our overview of [UX bootcamp London](/ux-bootcamp-london/) programmes.

For a full breakdown of live online UX courses available to UK learners -- including pricing and September 2026 start dates -- see our [UX design courses London](/ux-design-courses-london/) page.

If you are new to the field and wondering whether UX is the right move, [what is UX design](/blog/what-is-ux-design/) is a good starting point.

## How to decide: a simple framework

Use this to cut through the options quickly.

**Choose in-person if:** you want a short taster to test your interest, you live near a city with good availability, and you have completely flexible evenings.

**Choose self-paced online if:** you need maximum flexibility and are highly self-motivated, you want to supplement existing skills rather than start a new career, and you are comfortable with slow progress.

**Choose a live-online cohort if:** you are making a genuine career change, you need structure and accountability to actually complete something, and you want feedback on real work from a qualified instructor.

For most career-changers, the live-online cohort is the answer - even if "near me" was the original search.

## A UK live-online option worth looking at

UX Academy (myuxacademy.com) is a UK-based live online UX school run under Nomadic User Ltd. It is built specifically for career-changers, not designers who already work in the field.

A few specifics:

- **Format:** 8 weeks of live sessions, small cohort of maximum 15 students
- **Price:** GBP 1,500, with a GBP 99 fully refundable deposit to hold your place
- **Scholarship:** 30% scholarship available - ask when you enquire
- **Next cohort:** <CohortDate />
- **Lead instructor:** a working UX practitioner with an instructor team behind her
- **Free taster:** [free UX/UI masterclass at /masterclass/free-ux-ui-masterclass/](/masterclass/free-ux-ui-masterclass/) if you want to see the teaching style before committing

The course is designed so that every student leaves with a portfolio piece built from a real project brief - not a generic exercise. Sessions are live, not recorded, so you get the interaction and feedback that "near me" searchers are really after.

If you are a career-changer in the UK looking for structured UX training with a real instructor and a small cohort, the [Beginner UX (AI) Design course](/courses/beginner-ux-design/) is worth a look. The September cohort has limited places and they fill from the deposit waitlist.


---

# Nielsen's 10 Usability Heuristics (With Examples)

URL: https://myuxacademy.com/blog/nielsens-10-usability-heuristics/
A clear guide to Nielsen's 10 usability heuristics with real-world examples - the essential framework every UX designer needs to know.

**Nielsen's 10 usability heuristics are a set of general principles for evaluating the quality of a user interface, developed by Jakob Nielsen in 1994 and still the most widely applied framework in UX practice today.**

If you are learning UX design or conducting your first [heuristic evaluation](/blog/heuristic-evaluation-ux-design/), understanding these ten principles is essential. They do not tell you exactly what to build - they give you a lens for spotting problems in what already exists. Each heuristic addresses a different dimension of [usability in UX design](/blog/usability-in-ux-design/), and together they cover the most common ways interfaces fail users.

## Why These Heuristics Still Matter

Nielsen published his original list in 1994 after analysing 249 usability problems. The heuristics were updated and refined in 2020, but the core ideas have not changed much - because the fundamental ways humans interact with systems have not changed much either. Whether you are reviewing a mobile app, a checkout flow, or a dashboard, these principles apply.

They are not a checklist. Applying them well requires judgment about context, user goals, and the severity of each problem you find. But they give you a shared vocabulary and a systematic way to move through an interface.

## Nielsen's 10 Usability Heuristics Explained

### 1. Visibility of System Status

**The principle:** The system should always keep users informed about what is going on, through appropriate feedback within a reasonable time.

**Why it matters:** Users need to know whether their actions have registered and what the system is doing. Silence creates anxiety and leads to repeated clicks, abandoned tasks, or mistaken assumptions.

**Example:** When you upload a file to Google Drive, a progress indicator appears in the bottom-right corner showing the percentage complete. When it finishes, you see a confirmation. Without this, users would have no idea whether the upload succeeded or stalled.

---

### 2. Match Between System and the Real World

**The principle:** The system should speak the users' language, using words, phrases, and concepts familiar to the user rather than system-oriented terms. Information should appear in a natural and logical order.

**Why it matters:** When interfaces use jargon or metaphors that do not match how users think about a task, they create unnecessary cognitive load.

**Example:** Apple's Notes app uses a yellow legal-pad icon and a simple text editor that resembles writing on paper. The familiar metaphor reduces the learning curve - you do not need to learn new concepts to start using it. Compare that to early word processors that used terms like "carriage return" - meaningful to typists, confusing to everyone else.

---

### 3. User Control and Freedom

**The principle:** Users often choose system functions by mistake and need a clearly marked "emergency exit" to leave the unwanted state without having to go through an extended dialogue.

**Why it matters:** Errors and accidental actions are inevitable. If users cannot easily undo or escape, they lose confidence and trust in the product.

**Example:** Gmail's "Undo Send" feature, which gives you a short window to recall an email after hitting send, is a textbook application of this heuristic. It does not prevent the mistake - it gives you a recovery path before the consequences become permanent.

---

### 4. Consistency and Standards

**The principle:** Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.

**Why it matters:** Inconsistency forces users to relearn how your interface works every time they encounter something new. It also signals a lack of care.

**Example:** If your app uses "Delete" in one section and "Remove" in another for the same action, users must pause and interpret whether there is a meaningful difference. Consistent language - across labels, icons, and interactions - lets users transfer what they already know from one part of the interface to another.

---

### 5. Error Prevention

**The principle:** Even better than good error messages is a careful design that prevents a problem from occurring in the first place.

**Why it matters:** Recovering from errors is frustrating and time-consuming. Designing to prevent them is almost always better than designing to handle them gracefully after the fact.

**Example:** When you book a flight on most airline websites, departure dates in the past are greyed out and unselectable. You cannot make that mistake. A confirmation dialogue before permanently deleting files serves the same purpose - it adds a moment of friction precisely where an irreversible action is about to happen.

---

### 6. Recognition Rather Than Recall

**The principle:** Minimise the user's memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another.

**Why it matters:** Human working memory is limited. Interfaces that require users to remember things across screens or sessions create unnecessary mental effort and increase error rates.

**Example:** Google's search bar autocomplete is a simple application of this principle - rather than requiring you to type an exact query from memory, it surfaces likely completions based on what you have started typing. Similarly, showing a user's recent orders on a returns page means they do not have to hunt for an order number before they can begin.

---

### 7. Flexibility and Efficiency of Use

**The principle:** Accelerators - unseen by the novice user - may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users.

**Why it matters:** A product that only serves beginners frustrates power users. A product that only serves experts excludes newcomers. Good interfaces offer layers that reveal themselves as users develop proficiency.

**Example:** Figma offers keyboard shortcuts for almost every action, but none of them are required - a new user can do everything through menus and toolbars. As designers become more experienced, they adopt shortcuts that dramatically accelerate their workflow. The interface does not change; what changes is how much of it each user reaches.

---

### 8. Aesthetic and Minimalist Design

**The principle:** Dialogues should not contain irrelevant or rarely needed information. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility.

**Why it matters:** More is not better in interface design. Clutter competes for attention, obscures what matters, and signals to users that the designer did not understand their priorities.

**Example:** Airbnb's search results pages are deliberately sparse - a photo, a price, a star rating, and a handful of key details. Every piece of secondary information (host language, cancellation policy, amenities) is one click away but not on the card. This is not minimalism for aesthetic reasons - it is minimalism in service of the decision users are actually trying to make.

---

### 9. Help Users Recognise, Diagnose, and Recover from Errors

**The principle:** Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.

**Why it matters:** When something goes wrong, users are already frustrated. A cryptic error message adds insult to injury. A clear, actionable one can recover the situation.

**Example:** When you enter an invalid email address in a form, a good error message says "Please enter a valid email address, for example name@domain.com" - not "Input validation error: field 3." It names the field, shows the format expected, and gives the user everything they need to fix it immediately. Compare that to the generic "Something went wrong" message that tells users nothing about what to do next.

---

### 10. Help and Documentation

**The principle:** Even though it is better if the system can be used without documentation, it may be necessary to provide help. Any such information should be easy to search, focused on the user's task, list concrete steps to be carried out, and not be too large.

**Why it matters:** Complex products inevitably have edge cases where users need guidance. Help that is buried, jargon-heavy, or generalised is almost as useless as no help at all.

**Example:** Notion's inline help tooltips appear on hover for each formatting option, and their help centre is structured around tasks ("How do I share a page?") rather than features ("About sharing"). Users searching for help during a task need task-oriented answers, not feature documentation.

---

## How to Apply the Heuristics in Practice

You do not need to be a senior UX designer to use Nielsen's heuristics - but you do need a method. The standard approach is to walk through an interface systematically, attempting key user tasks while asking yourself which heuristics each screen satisfies or violates. Work through the ten principles one at a time, or use them as a lens you shift between as you explore.

For each issue you find, record:
- Which heuristic it violates
- Where it occurs in the interface
- A severity rating (cosmetic, minor, major, or catastrophic)
- A brief description of the problem and a suggested fix

Running three to five evaluators independently and then aggregating findings dramatically improves coverage. One evaluator working alone will miss a significant proportion of issues - different people notice different things, and the heuristics are broad enough that two evaluators often apply them to different aspects of the same screen. Once you have cleared the obvious violations through heuristic review, follow up with real users - our [usability testing guide](/blog/usability-testing-guide/) covers how to plan and run those sessions.

For a deeper walkthrough of the method itself - including how to plan an evaluation session, recruit evaluators, and present findings to a product team - see our guide to [heuristic evaluation](/blog/heuristic-evaluation-ux-design/).

## What Nielsen's Heuristics Do Not Cover

The 10 heuristics are powerful but not exhaustive. They focus on interaction design principles - they do not directly address performance, content strategy, or the emotional dimensions of experience. Accessibility in particular sits alongside the heuristics rather than within them: designing for screen readers, keyboard navigation, and WCAG 2.2 compliance requires its own specialised knowledge, which our [Accessibility for UX course](/courses/ux-accessibility/) covers in depth. They also assume you already have something to evaluate. If you are in early ideation, different tools (jobs to be done, user journey mapping, co-design workshops) will serve you better.

For a broader view of the discipline and where heuristic evaluation fits within it, our introduction to [what is UX design](/blog/what-is-ux-design/) is a good starting point.

---

If you want to go beyond theory and apply frameworks like these in real design projects, UX Academy (myuxacademy.com) runs live online cohorts capped at 15 students, taught by practising designers. The next cohort starts <CohortDate />. You can get a feel for the teaching approach at the [free UX masterclass](/masterclass/free-ux-ui-masterclass/) before committing, or go straight to the [Beginner UX (AI) Design course](/courses/beginner-ux-design/) to see what the full programme covers.


---

# How to Become a UX Designer in the UK (2026 Guide)

URL: https://myuxacademy.com/blog/how-to-become-a-ux-designer/
How to become a UX designer in the UK: a practical step-by-step roadmap for career-changers, from foundations to your first job offer in 2026.

**This is the general step-by-step roadmap to becoming a UX designer in the UK in 2026 - the skills, tools, portfolio and job search that take you from zero knowledge to your first role, whatever your starting point.** It is written by **the team at UX Academy (myuxacademy.com)**, a UK live-online UX design school for career-changers.

## How to become a UX designer in the UK (step by step)

1. **Learn the foundations** (weeks 1-8): user research, information architecture, interaction design, visual design basics, and Figma - through self-study, a structured course, or a degree.
2. **Build a portfolio of two or three real case studies** (months 2-6): projects with genuine research and documented decisions, not isolated Figma mockups.
3. **Build your professional presence in parallel** (months 3-6): an active LinkedIn, community involvement, and a simple portfolio website.
4. **Run a focused job search** (months 6-12+): tailored applications aimed at junior/associate UX roles, not high-volume generic applications.
5. **Expect 6 to 18 months from starting to a first offer.** The median UK UX designer salary is around **£55,000** (ITJobsWatch, vacancy data to June 2026) - roughly 41% above the UK median full-time salary of £39,039 (ONS ASHE 2025). See the full breakdown in our [UX designer salary UK guide](/blog/ux-designer-salary-uk/).
6. **You do not have to do this alone or self-taught.** UX Academy (myuxacademy.com) runs a live-online, 8-week [Beginner UX (AI) Design course](/courses/beginner-ux-design/) built for complete beginners, or try a [free UX masterclass](/masterclass/free-ux-ui-masterclass/) first.

### At a glance: paths, timelines and cost

| Path | Typical study time | Time to first role | Cost |
|---|---|---|---|
| Self-taught (free resources) | 6-12 months, unstructured | 18-24 months+ | Low / free, high time cost |
| Live online course (part-time) | 8-12 weeks while working | 6-18 months | Approx £1,500-£2,500 |
| University degree | 3 years | 3 years+ | £9,000+ per year |

Median UK UX designer salary: **£55,000** (ITJobsWatch, vacancy data to June 2026), around 41% above the UK median full-time salary of £39,039 (ONS ASHE 2025).

If your specific situation is leaving an existing career - and you want advice on transferable skills and managing the transition - read our dedicated guide to [switching careers to UX design](/blog/switching-careers-to-ux-design/) instead.

---

## How to Become a UX Designer: What You Are Walking Into in 2026

The UX job market has changed. There are fewer entry-level openings than there were in 2021-22, and the bar for a first role has risen. At the same time, demand for designers who can work effectively with AI tools, collaborate with product and engineering teams, and demonstrate research skills is growing.

The career-changers who are breaking in right now share a few things: a focused portfolio of two or three strong projects, the ability to articulate their process, and prior professional experience they have learned to frame as an asset.

This guide is built around what is working in 2026, not advice written for the hiring climate of five years ago.

---

## Step 1: Learn the Foundations (Weeks 1-8)

Before you can build a portfolio, you need to understand what UX design actually involves. The core disciplines are:

- **User research** - interviews, usability testing, synthesis
- **Information architecture** - how content and features are structured
- **Interaction design** - how users move through a product
- **Visual design fundamentals** - hierarchy, spacing, colour, type
- **Prototyping** - building testable versions of ideas

You do not need to master all of these before you start designing. You need enough grounding to make informed decisions and enough vocabulary to discuss your work professionally.

### What to learn it on

Figma is the industry-standard tool and you need to know it. It is free to use and has extensive free learning resources. Do not spend months on tutorials. Spend enough time to be able to prototype a simple flow, then learn by doing.

For methodology, focus on the double diamond model and basic usability testing. These two things will carry you through almost every project you encounter as a junior designer.

### Choosing how to learn

You have three realistic options:

1. **Self-taught via free resources** - YouTube, Google UX Design Certificate, community mentors. Low cost, high time investment, limited feedback on your work.
2. **Online course or bootcamp** - Structured curriculum, real feedback, faster path to a portfolio-ready project. Quality varies significantly.
3. **University degree** - Three years, significant cost, not required for a junior role.

For most career-changers, a structured short programme is the most efficient path. If you want to see what live, cohort-based UX training looks like, UX Academy (myuxacademy.com)'s [Beginner UX (AI) Design](/courses/beginner-ux-design/) course is built for complete beginners with no prior design experience - it runs over 8 weeks, 100% live online, with a maximum of 15 students and a real client project. The next cohort starts <CohortDate />. You can also attend a [free UX masterclass](/masterclass/free-ux-ui-masterclass/) to get a feel for it first.

For context on where this can take you financially, see our guide to [UX designer salaries in the UK](/blog/ux-designer-salary-uk/): the median UK UX designer salary is £55,000 (ITJobsWatch, vacancy data to June 2026).

> **Want to learn live, with a real tutor, rather than self-taught?** UX Academy (myuxacademy.com)'s [Beginner UX (AI) Design course](/courses/beginner-ux-design/) is 100% live online, small-group (max 15), and built for career-changers with no design background. Cohort 1 starts <CohortDate /> -- [reserve your place with a £99 deposit](/courses/beginner-ux-design/). Prefer to try before you commit? [Book the free masterclass](/masterclass/free-ux-ui-masterclass/) first.

---

## Step 2: Build a Portfolio With Real Projects (Months 2-6)

Your portfolio is the single most important thing in your job search. Not your CV, not your LinkedIn - your portfolio.

A strong entry-level portfolio needs two or three case studies. Each case study should show:

1. The problem you were solving and who you were solving it for
2. Your research process - what you did to understand users
3. Your design decisions - why you made the choices you made
4. The outcome or what you would do next

### What counts as a real project

A real project does not have to be a paid client project. It can be:

- A redesign of an existing product (with documented research, not just visual changes)
- A project from a course that involved real user interviews and testing
- A volunteer project for a charity or community organisation
- A solution to a problem you personally identified through research

What does not work: isolated Figma mockups with no research behind them, pixel-for-pixel app redesigns with no rationale, or portfolio pieces that look like UI exercises rather than UX work.

The most common mistake at this stage is building too many projects instead of making two or three excellent ones. Depth beats breadth.

Read our full [UX design portfolio guide](/blog/ux-design-portfolio-guide/) for a detailed breakdown of what each case study should contain, or [how to build a UX portfolio from scratch](/blog/how-to-build-a-ux-portfolio-from-scratch/) if you are starting with nothing.

### AI era skills: where they fit in

In 2026, hiring managers are starting to expect junior designers to have working knowledge of AI tools. This does not mean replacing your process with AI - it means knowing where AI adds value:

- Generating early-stage design variations to explore directions faster
- Synthesising research notes and interview transcripts
- Creating realistic content for prototypes
- Accessibility checking

Designers who use AI tools fluently while still owning their research and decision-making are ahead of those who either ignore AI entirely or use it as a substitute for thinking.

---

## Step 3: Develop Your Professional Presence (Months 3-6, in parallel)

You do not need to wait until your portfolio is finished to start building your professional presence.

### LinkedIn

Update your headline. "Career changer | Learning UX design" is fine. Share what you are working on - a research method you tried, a usability test you ran, a tool you found useful. UX hiring managers and recruiters are active on LinkedIn, and a consistent, genuine presence helps.

Do not over-engineer this. One post every week or two about something you actually learned is more effective than a strategy.

### Community

The UK UX design community is active and generally welcoming to newcomers. UX book clubs, local meetups (London, Manchester, Edinburgh, Bristol all have them), and online communities like the UX Design Institute's Slack are worth joining early.

The goal is not to network in a transactional sense - it is to be around working practitioners so you understand what the job actually involves and start to become a recognisable face in the community.

### Portfolio website

Keep it simple. Your name, a short summary of who you are and what you have done before, two or three case studies, and contact details. A well-structured Notion page or a basic site on Cargo or Framer is fine. Do not spend weeks on the website design.

---

## Step 4: Run a Focused Job Search (Months 6-12+)

The most common mistake in the UX job search is volume without focus. Applying to 50 roles with a generic CV and cover letter is less effective than applying to 15 with tailored applications that show you have read the job description and understood the company.

### How to find roles

- LinkedIn jobs filtered to junior/associate UX designer, UK
- Glassdoor, Indeed
- Direct applications to companies you respect (often more effective than job boards for smaller agencies)
- Your network - tell people you are looking, including people from your previous career

For a fuller picture of where UX roles are concentrated and what the market looks like in 2026, our guide to [UX design jobs in the UK](/blog/ux-design-jobs-uk/) is worth reading before you start applying.

### What the application should contain

- A one-page CV with your previous experience reframed around transferable skills (research, stakeholder communication, problem-solving, domain knowledge)
- A cover letter that is specific to the role and explains why your background is relevant
- Your portfolio link, prominently placed

For a detailed breakdown of how to get your first interviews with no professional UX experience yet, read our guide to [getting a UX job with no experience](/blog/ux-job-with-no-experience/).

### The interview process

Most junior UX roles involve:

1. A screening call (15-30 minutes)
2. A portfolio presentation or case study walkthrough
3. A design task or take-home brief
4. A final interview, often with a hiring manager and a team member

The portfolio presentation is where most candidates win or lose the process. Practice presenting your case studies out loud. Know your decisions, know your trade-offs, know what you would do differently. Our guide to [UX design interview questions](/blog/ux-design-interview-questions/) covers the most common questions and how to prepare for each stage.

---

## Step 5: Keep Going Through Rejection

This is not a step that most guides include, but it should be.

Most career-changers who break into UX design go through a period of rejection before they land their first role. This is normal and expected. The timeline is not linear.

What tends to move people forward:

- Getting feedback on applications or portfolio presentations where you can
- Continuing to develop your portfolio while searching
- Staying connected to the community
- Taking on a small freelance or volunteer project to keep building experience

The career-changers who do not make it are usually those who stopped when it got slow, not those who lacked ability.

---

## Realistic Timelines

There is no single timeline that applies to everyone, but here is a realistic range based on what people who make this transition commonly experience:

- **Months 1-2:** Core learning, Figma basics, first project underway
- **Months 2-4:** First case study complete, starting to engage with community
- **Months 4-6:** Portfolio at two case studies, applications beginning
- **Months 6-12:** Active job search, interview practice, portfolio refinement
- **Months 9-18:** First role offer (range - some people move faster, some take longer)

The biggest factors that affect where you land in that range: hours available per week, quality of feedback on your portfolio, how focused your job search is, and the strength of your prior professional experience as a differentiator.

---

## Common Mistakes to Avoid

**Starting with the wrong question.** "What tools do I need to learn?" is less useful than "What kind of UX work do I want to do?" Research-heavy in-house roles, agency work, and product design roles reward different skills.

**Building a UI portfolio instead of a UX portfolio.** If your case studies show screens without showing the research and decisions behind them, you have a visual design portfolio, not a UX one.

**Waiting until you are ready.** There is no point at which you will feel ready. Start applying when you have one solid case study, use the feedback from rejections to improve, and build the second case study while you search.

**Ignoring your prior career.** Your background in healthcare, finance, education, retail, or anything else is not irrelevant experience. It is domain knowledge that makes you more valuable in roles that touch those sectors. Learn to frame it.

---

If you are earlier in your research, our guide to [becoming a UX designer without a degree](/blog/become-a-ux-designer-without-a-degree/) covers the full picture of non-traditional pathways into the profession.

The foundations, the portfolio, the job search - none of it is beyond a motivated career-changer. The people who break into UX design are not those with the most innate design talent. They are those who build methodically and keep going.

---

## FAQ

### How do I become a UX designer with no experience?

Yes. Most UX designers come from other careers - teaching, marketing, customer service, healthcare. Your prior domain knowledge is often an asset. What matters is your portfolio: real projects that show you can research user needs, identify problems, and design solutions. You build that portfolio during training, not after.

### Do I need a degree to become a UX designer?

No. There is no degree requirement to work in UX design. Hiring managers look at your portfolio, your ability to explain your design decisions, and how you handle a brief. A short, intensive programme focused on real projects will get you there faster than a three-year degree - and it already has for many working UX designers.

### How long does it take to become a UX designer?

Most career-changers land their first UX role between 6 and 18 months after starting training, depending on how much time they can commit, how strong their portfolio is, and how focused their job search is. An 8-week intensive followed by 3-6 months of applications and portfolio refinement is a realistic timeline for many people.

### Is it too late to switch to UX design?

No. UX is one of the few design disciplines where being older, with more life experience, is genuinely useful. You bring empathy, domain knowledge, and professional maturity that recent graduates often lack. Career-changers in their 30s and 40s make the transition successfully every year.

### How to become a UX designer in the UK?

Learn the foundations (user research, information architecture, interaction design, and Figma), then build two or three real portfolio case studies with documented research and design decisions. Build a professional presence on LinkedIn and in the UK UX community, then run a focused, tailored job search aimed at junior or associate roles. Most career-changers land their first UX role 6 to 18 months after starting, whether they learn self-taught, through a structured course such as UX Academy (myuxacademy.com), or via a degree.

### Can I learn UX in 3 months?

You can learn the foundations and complete an intensive course, such as UX Academy (myuxacademy.com)'s 8-week Beginner UX (AI) Design programme, within roughly 3 months. But "learning UX" and being job-ready are different things - most people need a further 3 to 6 months after training to build a full portfolio, refine it, and run a job search. Treat 3 months as the start of the process, not the finish line.

### Is UX design in demand in the UK?

Yes, though the market has tightened since 2021-22 and there are fewer pure entry-level openings than there used to be. Demand remains strong for designers who can demonstrate real research skills, work effectively with product and engineering teams, and show they can use AI tools without letting AI replace their thinking. Employers are hiring - the bar for a first role has simply risen.

### Is UX replaced by AI?

No. AI tools speed up parts of the UX process - generating early design variations, synthesising research notes, drafting prototype content - but they do not replace the judgement, user research, and stakeholder work that sits at the core of the job. In 2026, hiring managers increasingly expect junior designers to use AI tools fluently while still owning their research and decisions. Designers who ignore AI or who use it as a substitute for thinking are the ones falling behind, not the profession itself.

### How much do UX designers get paid in the UK?

The median UK UX designer salary is around £55,000 (ITJobsWatch, vacancy data to June 2026) - roughly 41% above the UK median full-time salary of £39,039 (ONS ASHE 2025). Senior UX and product designers in London with five or more years of experience typically earn £70,000 to £80,000 (Morgan McKinley 2026 UK salary guide). See the full breakdown in our [UX designer salary UK guide](/blog/ux-designer-salary-uk/).


---

# Heuristic Evaluation Template and Checklist (Free)

URL: https://myuxacademy.com/blog/heuristic-evaluation-template/
A practical heuristic evaluation template and checklist covering severity ratings, evaluator setup, and a copy-ready findings sheet. UK English.

**A heuristic evaluation is one of the highest-value things a UX designer can do in a single day - but only if you record findings consistently. This template gives you the exact setup, scoring sheet, and step-by-step process to run one from scratch.**

Heuristic evaluations are popular because they are fast, inexpensive, and do not require recruiting participants. They work by having trained evaluators inspect an interface against a set of established usability principles - most commonly [Nielsen's 10 usability heuristics](/blog/nielsens-10-usability-heuristics/). If you want the theory first, read our [heuristic evaluation guide](/blog/heuristic-evaluation-ux-design/) and our overview of [usability in UX design](/blog/usability-in-ux-design/).

This post gives you the practical side: who runs the evaluation, what goes in the spreadsheet, and how to score findings so they actually influence product decisions.

**Want the ready-made scoring sheet?** [Download the free heuristic evaluation worksheet](/resources/templates/heuristic-evaluation/) and use it as you read.

---

## What you need before you start

Before anyone opens the interface, agree on three things:

**Scope.** Define which flows or screens are in scope. "The whole app" is too vague. "The sign-up flow, the onboarding checklist, and the account settings page" is actionable.

**Heuristics reference.** Every evaluator uses the same set of principles. Nielsen's 10 heuristics are the industry standard. Print them or share them in a shared doc so evaluators are not paraphrasing from memory.

**Evaluator team.** Recruit 3-5 people with UX knowledge - ideally a mix of generalist UX designers and, where possible, someone with domain expertise in the product area. They must evaluate independently before comparing notes.

---

## The findings sheet: columns you need

The findings sheet is the core of your heuristic evaluation template. Every row is one issue. Keep the columns below - they cover everything you need to prioritise and present findings.

| Column | What to record |
|---|---|
| Issue ID | Sequential number (HE-001, HE-002, etc.) |
| Screen / Flow | The specific page or step where the issue was found |
| Heuristic violated | Which of Nielsen's 10 heuristics applies (use the number and name) |
| Description | A plain-language description of the problem |
| Screenshot or annotation | File name or link to the annotated screenshot |
| Evaluator | Initials of the person who found it |
| Frequency | How often does a user encounter this? (Rare / Occasional / Frequent) |
| Impact | How hard is it to recover? (Low / Medium / High) |
| Persistence | Does it recur across the session? (Once / Recurring) |
| Severity score | 0-4 (see scale below) |
| Recommended fix | A short, concrete suggestion |
| Status | Open / In progress / Resolved |

You do not need anything more complicated than a shared Google Sheet with these columns. Avoid elaborate colour-coding schemes - they slow you down and do not add information.

---

## Nielsen's severity rating scale (0-4)

Severity is the most important number in your sheet. It determines what gets fixed before launch and what goes in the backlog.

| Score | Label | What it means |
|---|---|---|
| 0 | Not a problem | Evaluator considered it but decided it does not affect usability |
| 1 | Cosmetic | Minor issue; fix only if time allows |
| 2 | Minor | Low priority; user can work around it |
| 3 | Major | Important to fix; will cause significant frustration or errors |
| 4 | Catastrophe | Must be fixed before release; blocks users or causes serious errors |

When multiple evaluators have scored the same issue, average their scores. If scores diverge by more than 1 point, discuss before averaging - disagreement usually signals that the problem description is ambiguous or that evaluators interpreted the heuristic differently.

Severity is a composite of three factors:

- **Frequency** - does this happen to most users or only in an edge case?
- **Impact** - if a user hits this problem, how badly does it disrupt their task?
- **Persistence** - does the user encounter it once or every time they use that part of the interface?

A problem that is frequent, high-impact, and persistent is almost certainly a 3 or 4. A problem that is rare, easy to recover from, and non-recurring is usually a 1.

---

## Step-by-step process

### Step 1 - Brief the evaluators (30 minutes)

Share the scope document, the heuristics reference, and the blank findings sheet. Walk through one example issue together so everyone understands how to fill in each column. Agree a deadline for individual review (usually 2-3 working days).

### Step 2 - Individual evaluation (1-2 hours per evaluator)

Each evaluator works through the defined scope alone. They should move slowly and deliberately - this is not a speed test. Typical output: 10-30 issues per evaluator for a moderately complex interface.

Encourage evaluators to capture screenshots as they go. An issue with no screenshot is harder to act on, especially for developers.

### Step 3 - Consolidate findings (1 hour)

One person (the facilitator) merges all individual sheets into a master list. Duplicate issues - where two or more evaluators spotted the same problem - are collapsed into a single row. Note how many evaluators flagged each issue: an issue found by four out of five evaluators is likely more serious than one found by only one.

### Step 4 - Severity scoring session (1 hour)

Run a short group call to agree severity scores. Work through the consolidated list together. For each issue: read the description aloud, look at the screenshot, and ask each evaluator for their score. Average the scores or discuss to consensus.

### Step 5 - Prioritise and present

Sort the findings sheet by severity score, descending. Group 4s and 3s as immediate fixes; 2s as next sprint; 1s as backlog. Present to stakeholders with the screenshots - visual evidence makes it far easier to get sign-off on design changes.

---

## Quick-reference checklist

Use this before and after each evaluation to make sure nothing is missed.

**Setup checklist**

- [ ] Scope defined in writing and shared with all evaluators
- [ ] Nielsen's 10 heuristics printed or linked for every evaluator
- [ ] Blank findings sheet shared (with all columns above)
- [ ] Evaluators confirmed as independent (no group review before individual pass)
- [ ] Screenshot tool agreed (Figma annotation, Lightshot, OS screenshot, etc.)

**During evaluation**

- [ ] Working through each screen in the defined scope
- [ ] Logging every issue, even minor ones (severity scoring comes later)
- [ ] Recording which heuristic is violated for every issue
- [ ] Capturing a screenshot or annotation for every issue
- [ ] Not discussing findings with other evaluators until the consolidation step

**After individual evaluation**

- [ ] Individual sheet submitted to facilitator by agreed deadline
- [ ] Facilitator has merged all sheets and removed exact duplicates
- [ ] Each remaining issue has at least one screenshot
- [ ] Group severity scoring session is booked

**After scoring**

- [ ] Every issue has a severity score (0-4)
- [ ] Issues are sorted by severity, descending
- [ ] Recommended fix column completed for all 3s and 4s
- [ ] Findings presented to product/design/engineering with visual evidence
- [ ] Status column updated as fixes are made

---

## Common mistakes to avoid

**Skipping the independent phase.** If evaluators discuss findings before completing their individual pass, they anchor on each other's issues and miss problems that a single pair of eyes would catch. Keep evaluation independent until the consolidation step.

**Conflating description and fix.** The description column should describe the problem from the user's perspective. The recommended fix column is where you suggest a solution. Mixing them makes it harder to discuss trade-offs with engineers.

**Treating all 10 heuristics as equally applicable.** Some heuristics - particularly "Error prevention" and "Help users recognise, diagnose, and recover from errors" - tend to surface more issues in transactional flows. "Aesthetic and minimalist design" tends to surface more in information-heavy dashboards. Evaluators should still check all 10, but calibrate attention to the type of interface.

**Over-scoring to get stakeholder attention.** Every issue marked as a 4 dilutes the urgency of genuine catastrophes. Reserve 4 for problems that genuinely block users. If everything is a catastrophe, nothing is.

---

## Further reading

- [Heuristic evaluation guide](/blog/heuristic-evaluation-ux-design/) - how heuristic evaluation fits into a UX research toolkit
- [Nielsen's 10 usability heuristics](/blog/nielsens-10-usability-heuristics/) - the full list with examples
- [Usability in UX design](/blog/usability-in-ux-design/) - the broader principles behind usability work

---

## Learn heuristic evaluation in a live UX course

Heuristic evaluation is a core skill in professional UX practice - and one of the methods you will apply hands-on in our [Beginner UX (AI) Design course](/courses/beginner-ux-design/).

UX Academy (myuxacademy.com) runs live online UX courses from the UK, with a maximum of 15 people per cohort so you get direct feedback on your own work. The next cohort starts **<CohortDate />**.

Want to see the course in action first? Join our [free UX masterclass](/masterclass/free-ux-ui-masterclass/) - a live session where you can ask questions and get a feel for how we teach.


---

# Heuristic Evaluation Example: A Step-by-Step Walkthrough

URL: https://myuxacademy.com/blog/heuristic-evaluation-example/
See a heuristic evaluation example in action: a step-by-step walkthrough of a checkout flow rated against Nielsen's 10 heuristics, with severity scores.

**A heuristic evaluation is one of the fastest ways to surface usability problems without recruiting a single participant - but the method only clicks once you see it applied to a real interface.** This walkthrough takes a hypothetical e-commerce checkout flow and evaluates it against Nielsen's 10 heuristics, producing the kind of findings table you would hand to a product team.

If you want the theory first, start with our [heuristic evaluation guide](/blog/heuristic-evaluation-ux-design/) and the full list of [Nielsen's 10 usability heuristics](/blog/nielsens-10-usability-heuristics/). If you want a blank template to fill in yourself, grab our [heuristic evaluation template](/resources/templates/heuristic-evaluation/). This post focuses on the example itself.

## The interface we are evaluating

For this walkthrough we will use a fictitious e-commerce site called "ShopFlow" - a purely hypothetical teaching example created to illustrate the method. The flow covers four screens: cart review, delivery details, payment details, and order confirmation. Nothing here refers to any real company or client.

We are playing the role of a single evaluator. In practice you would run 3-5 evaluators independently and then consolidate findings - that spread catches significantly more issues than one person alone.

## How the severity scale works

Before we look at findings it helps to have the severity scale in mind:

| Rating | Label | What it means |
|--------|-------|----------------|
| 0 | Not a problem | Cosmetic observation only; no action needed |
| 1 | Cosmetic | Fix only if time allows |
| 2 | Minor | Low priority fix |
| 3 | Major | High priority; fix before next release |
| 4 | Catastrophe | Must fix before launch |

Severity combines two factors: how frequently users will encounter the problem, and how badly it affects their ability to recover. A problem that appears once and has an obvious workaround is a 1 or 2. A problem that blocks task completion for most users is a 4.

## Walking through the checkout: heuristic by heuristic

Not every heuristic will produce a finding in every interface. Below we go through all ten and record what we observe in ShopFlow.

### 1. Visibility of system status

**Finding:** After the user clicks "Place order", the button shows no loading state. There is no spinner, no progress indicator, and no feedback for approximately four seconds while the payment processes.

Users in this situation often click the button a second time, risking a duplicate charge.

**Severity: 3**

**Recommendation:** Disable the button immediately on click, show a spinner inside it, and add a brief text label such as "Processing your order..." so users know something is happening.

### 2. Match between system and the real world

**Finding:** The payment screen uses the label "Card verification value" rather than "CVV" or "Security code". Research consistently shows that everyday users recognise the shorter abbreviation more quickly than the expanded form.

**Severity: 1**

**Recommendation:** Change the label to "Security code (CVV)" - the abbreviation first, the expanded form in parentheses for those who need it.

### 3. User control and freedom

**Finding:** There is no way to edit the delivery address once the user has moved from the delivery screen to the payment screen. The only option is to use the browser back button, which clears the payment form they have already filled in.

**Severity: 3**

**Recommendation:** Add an "Edit" link next to the delivery summary on the payment screen. This lets users correct mistakes without losing their payment entry.

### 4. Consistency and standards

**Finding:** The "Continue" button is right-aligned on the cart and delivery screens but centred on the payment screen. This inconsistency creates a brief moment of disorientation as users scan for the next action.

**Severity: 1**

**Recommendation:** Standardise the primary CTA button to right-aligned across all checkout screens, which also aligns with the convention on most major e-commerce sites.

### 5. Error prevention

**Finding:** The email field on the delivery screen accepts any string that contains "@". A user who types "me@" with nothing after it passes validation and only learns about the error after submitting the form.

**Severity: 3**

**Recommendation:** Apply RFC-compliant email validation on blur (when the user leaves the field) so they can correct the mistake before they attempt to continue. Inline validation at the field level is far less disruptive than a full-page error after submission.

### 6. Recognition rather than recall

**Finding:** On the order confirmation screen, the order reference number is shown once and there is no prompt to save or copy it. Users who need to contact support must remember it or scroll back through their email inbox.

**Severity: 2**

**Recommendation:** Add a "Copy order number" button next to the reference, and make the confirmation email subject line include the order number prominently.

### 7. Flexibility and efficiency of use

**Finding:** There is no option to save delivery details for returning customers. Every purchase requires re-entering the full address.

**Severity: 2**

**Recommendation:** After a successful order, prompt logged-in users to save their address for next time. This is a table-stakes feature for repeat purchase flows.

### 8. Aesthetic and minimalist design

**Finding:** The cart screen displays six promotional banners alongside the cart contents. The banners compete visually with the "Proceed to checkout" button and create a cluttered layout that slows the eye toward the primary action.

**Severity: 2**

**Recommendation:** Limit promotional content in the checkout flow to a single, low-contrast banner at most. Users who have already added items to their cart have signalled intent - interrupting them with cross-sells at this stage increases abandonment.

### 9. Help users recognise, diagnose, and recover from errors

**Finding:** When a card payment fails, the error message reads: "Transaction unsuccessful. Error code: 5412." The error code means nothing to the user and no guidance is given on what to do next.

**Severity: 4**

**Recommendation:** Replace technical error codes with plain-language messages. For a declined card, something like: "Your card was declined. Please check your card details or try a different card." If the failure reason from the payment processor suggests a specific fix (wrong CVC, expired card), surface that. Always provide a clear next step.

### 10. Help and documentation

**Finding:** There is no live chat, FAQ link, or help tooltip visible anywhere in the checkout flow. If a user is confused about delivery costs, returns, or payment security, they have to leave the checkout to find an answer - and many will not return.

**Severity: 2**

**Recommendation:** Add a persistent "Need help?" link in the footer of every checkout screen, opening a support page or chat widget without navigating away from the checkout.

## Full findings table

Here is all ten findings consolidated into the format you would use in a real deliverable:

| # | Screen | Heuristic violated | Finding summary | Severity | Recommendation |
|---|--------|--------------------|-----------------|----------|----------------|
| 1 | Payment | Visibility of system status | No loading state on "Place order" button | 3 | Add spinner and disable button on click |
| 2 | Payment | Match between system and real world | "Card verification value" unfamiliar to most users | 1 | Use "Security code (CVV)" |
| 3 | Payment | User control and freedom | Cannot edit delivery address without losing payment entry | 3 | Add "Edit" link to delivery summary on payment screen |
| 4 | Payment | Consistency and standards | Primary CTA button alignment varies across screens | 1 | Standardise to right-aligned |
| 5 | Delivery | Error prevention | Email validation too permissive; errors caught too late | 3 | Inline validation on blur |
| 6 | Confirmation | Recognition rather than recall | Order number shown once with no copy option | 2 | Add "Copy order number" button |
| 7 | Delivery | Flexibility and efficiency | No address save option for returning users | 2 | Prompt to save after successful order |
| 8 | Cart | Aesthetic and minimalist design | Six promotional banners compete with checkout CTA | 2 | Limit to one low-contrast banner in checkout |
| 9 | Payment | Help users recognise and recover from errors | Payment failure shows opaque error code only | 4 | Plain-language error messages with next steps |
| 10 | All screens | Help and documentation | No help access during checkout | 2 | Persistent "Need help?" link in footer |

## What to do with findings once you have them

Gathering findings is only half the job. The next step is to prioritise them.

Start with all severity 4 findings - these are blockers. In this example, that is the payment error message (finding 9). No user should encounter a cryptic error code when their payment fails; that finding would go straight to the top of the sprint backlog.

Severity 3 findings (1, 3, and 5 in our table) form the second tier. They will cause visible friction for a meaningful proportion of users and should be fixed before the next release if at all possible.

Severity 1 and 2 findings can be triaged alongside other backlog items. They are real problems but not urgent ones.

If you ran 3-5 evaluators independently rather than one, you would merge all their findings before assigning final severity scores. A problem spotted by four out of five evaluators almost certainly warrants a higher severity than one only one person noticed - frequency of detection is useful signal even before you get real user data.

## Heuristic evaluation as a starting point, not a verdict

A heuristic evaluation tells you where problems are likely to exist. It does not tell you how much those problems actually affect real users, or why. That is why experienced UX designers use it as a fast, low-cost input into a broader research programme rather than a replacement for usability testing.

Used well, a heuristic evaluation - like the one we have just walked through - can surface a decade's worth of known usability problems in a morning, giving teams a clear, prioritised list before a single participant walks in the door.

---

If you want to practise heuristic evaluation yourself with expert guidance, the [UX Academy (myuxacademy.com) Beginner UX (AI) Design course](/courses/beginner-ux-design/) covers the full research and evaluation toolkit in a live online format. The next cohort starts <CohortDate />, and you can get a feel for the teaching style first at a [free UX/UI masterclass](/masterclass/free-ux-ui-masterclass/).


---

# Figma for Beginners: A Step-by-Step Guide

URL: https://myuxacademy.com/blog/figma-for-beginners/
New to design tools? This Figma for beginners guide walks you through the interface, frames, components, auto layout, and prototyping in plain English.

**Figma is the design tool the industry has converged on - and the good news is that it is genuinely approachable for beginners.** This step-by-step guide takes you from creating your first account to building a simple interactive prototype, with no prior design experience assumed.

If you want background on what Figma is and why it matters, read our [what is Figma](/blog/what-is-figma/) primer first. Otherwise, let us get started.

## What Figma Actually Is

Figma is a browser-based design tool used by UX designers, product designers, and teams to create wireframes, interfaces, and interactive prototypes. Because it lives in the browser, there is nothing to install and your files are automatically saved to the cloud. You can share a link and collaborators can view or comment in real time - no exports needed.

It is used across the full design process: from rough sketches and wireframes all the way to pixel-perfect handoff files for developers.

---

## Step 1 - Create Your Figma Account

Go to [figma.com](https://www.figma.com) and sign up for a free Starter account using your email address or a Google account. The free plan is genuinely useful and gives you enough room to learn and build a portfolio.

Once you are in, you will land on the Figma home screen, sometimes called the dashboard. This is where your files and projects are organised.

Click "New design file" to open the editor.

---

## Step 2 - Get Familiar with the Interface

The Figma editor has four main areas:

### The Canvas

The large central area is the canvas - an infinite white space where all your design work happens. You can zoom in and out with Ctrl + scroll (or Cmd + scroll on Mac) and pan by holding the spacebar and dragging.

### The Layers Panel (Left Sidebar)

Every element you place on the canvas appears in the layers panel on the left. Layers are stacked top to bottom, with elements higher in the list appearing in front. Grouping and naming layers well becomes important as your designs grow more complex.

### The Properties Panel (Right Sidebar)

When you select an element, the right panel shows its properties: position, size, fill colour, stroke, corner radius, and more. This is where you make precise adjustments.

### The Toolbar (Top)

Along the top you will find tools for selecting, drawing frames, placing shapes, adding text, drawing vector paths, and inserting components. The keyboard shortcuts shown here are worth learning early - they speed up your workflow considerably.

---

## Step 3 - Create a Frame

In Figma, a frame is the container for your designs - roughly equivalent to an artboard in other tools such as Sketch or Illustrator (for a full comparison, see our [Figma vs Sketch](/blog/figma-vs-sketch/) breakdown). Frames represent a screen, a page, or any bounded area.

Press F (or select the Frame tool from the toolbar). You can either drag a custom size on the canvas, or click the Frame tool and then choose a preset from the right panel - iPhone, Android, desktop browser, and so on are all listed there.

Give your frame a name by double-clicking its label in the layers panel. Good naming habits save a lot of confusion later.

---

## Step 4 - Add Shapes and Text

With your frame selected, you are ready to place elements inside it.

**Shapes:** Press R to draw a rectangle, O for an ellipse, or L for a line. Click and drag on the canvas to place them. Once placed, adjust fill colour, stroke, corner radius, and opacity in the right panel. Holding Shift while dragging constrains proportions to a square or circle.

**Text:** Press T, then click anywhere on the canvas to place a text element. Type your content, then use the right panel to set font family, size, weight, line height, and alignment. Figma connects to Google Fonts, so you have a broad range available on the free plan.

A practical exercise: try recreating a simple button - a rounded rectangle with a label centred inside it. This small task touches selection, sizing, colour, corner radius, and text alignment all at once.

---

## Step 5 - Use Components and Styles

Once you start designing more than one screen, copy-pasting the same button over and over becomes a problem. Change one instance and you have to update them all manually. Components solve this.

### Components

Select any element (or group of elements) and press Ctrl + Alt + K (Cmd + Option + K on Mac) to convert it into a component. It will appear in the Assets panel on the left with a purple diamond icon.

When you drag a copy of a component onto the canvas, you create an "instance". Change the main component - its colour, label, size - and every instance updates automatically.

### Styles

Styles let you save a colour or text setting and apply it consistently across your file. For example, create a colour style called "Brand Blue" and apply it to multiple elements. If the brand colour changes, you update the style once and everything updates.

To create a style, select an element, click the four-dot icon next to Fill in the right panel, and save as a new style.

Components and styles together form the foundation of a design system - the building blocks that keep large projects consistent.

---

## Step 6 - Auto Layout Basics

Auto layout is one of the most useful features in Figma and the one beginners most often skip. It lets frames and groups resize automatically as their contents change - essential for designing buttons, cards, lists, and navigation bars that need to behave responsively.

To apply auto layout, select a frame or group and press Shift + A. The right panel will show auto layout controls for direction (horizontal or vertical), gap between items, padding, and alignment.

A good exercise: create a button with a text label inside a frame, apply auto layout, then change the label text. Watch the button width adjust automatically. That single behaviour saves enormous amounts of manual resizing later.

---

## Step 7 - Build a Simple Prototype

Figma has a built-in prototyping mode that lets you link screens together and preview interactions - no code needed.

Click the "Prototype" tab in the right panel (visible when nothing is selected, or when you have a frame selected). Now hover over an element on your frame. A blue handle appears on the right edge. Drag that handle to a second frame to create a connection. Set the trigger (on click, on hover) and the animation type (dissolve, slide, etc.) in the connection settings.

Press the Play button at the top right to preview your prototype in a new browser tab. You will see your design as a clickable mock-up.

For sharing with others, click "Share prototype" to generate a link that anyone can open in their browser - no Figma account required to view it.

---

## Step 8 - Collaborate

Figma's collaboration features are a key reason the industry adopted it so widely.

Share your file via the "Share" button at the top right. You can invite specific people by email or generate a link. Set permissions to "can view" for stakeholders and clients, or "can edit" for fellow designers.

Viewers can leave comments by pressing C and clicking anywhere on the design. This makes design reviews much simpler than sending screenshots back and forth over email.

If you are working with a developer, point them to the Inspect panel (accessible in view mode on the right sidebar). It shows CSS-style specs, spacing values, and assets they can copy directly - no need to document measurements manually.

---

## Beginner Tips Worth Knowing Early

- **Name your layers as you go.** Figma names things "Rectangle 47" by default. Rename as you place them - you will thank yourself when the file grows.
- **Use the keyboard shortcuts.** V (select), F (frame), R (rectangle), T (text), H (hand/pan), Z (zoom) - learning ten shortcuts cuts your working time noticeably.
- **Zoom to fit with Shift + 1.** If you get lost on the canvas, this brings everything back into view.
- **Group related layers.** Select multiple layers and press Ctrl + G to group them. This keeps the layers panel manageable.
- **Save component variants early.** If you have a button that needs a hover state or a disabled state, use Figma's Variants feature to keep them tidy under one component.
- **Use the Community.** Figma's Community tab (accessible from the home screen) has thousands of free UI kits, icon sets, and templates. Studying how experienced designers structure their files is one of the fastest ways to improve.

---

## What to Learn Next

Getting comfortable with the basics above puts you in good shape for building simple screens. From here, the skills worth developing are:

- **Variables and tokens** - Figma's newer approach to storing design decisions like colour and spacing at scale.
- **Advanced prototyping** - conditional logic, scroll behaviour, overlays.
- **Component properties** - exposing controls on instances so you can swap icons or toggle visibility without editing the main component.
- **Handoff to developers** - understanding how developers read Figma files and how to structure yours to make their work easier.

Figma is a tool, not the whole skill. UX designers use Figma to solve problems - and the design thinking behind what you build matters as much as the execution. To see how Figma fits within the broader [UX design tools](/resources/) landscape, that guide covers the full design tool stack. For a broader view of the discipline, read [what is UX design](/blog/what-is-ux-design/) and our [UX design portfolio guide](/blog/ux-design-portfolio-guide/) when you are ready to start documenting your projects.

---

## Learn Figma Hands-On at UX Academy

Reading about Figma is useful. Using it on real briefs with expert feedback is how the skill actually sticks.

At [UX Academy](https://myuxacademy.com), our live online UX design courses teach Figma as part of a structured curriculum - not as a standalone tool tutorial, but as the medium for solving real design problems. Cohorts are capped at 15 people so every student gets direct time with the instructors.

The next cohort starts <CohortDate />. If you want to see what the course covers before committing, join our [free UX/UI masterclass](/masterclass/free-ux-ui-masterclass/) - a live session where you can ask questions and get a feel for how we teach.

View the [Beginner UX (AI) Design course](/courses/beginner-ux-design/) for the full syllabus, outcomes, and pricing.


---

# Are UX Bootcamps Worth It in 2026? An Honest Guide

URL: https://myuxacademy.com/blog/are-ux-bootcamps-worth-it/
Are UX bootcamps worth it in 2026? An honest look at what bootcamps deliver, who they suit, what to watch out for, and how to choose well in the UK.

**Whether UX bootcamps are worth it has no single answer - it depends on what you are comparing them to, what quality of programme you choose, and what you are realistically trying to achieve.** This post gives you the honest version, not the recruitment pitch.

## What a UX bootcamp actually is (and what it is not)

The word 'bootcamp' gets applied to a very wide range of products. At one end: a genuinely intensive, structured programme with live instruction, a small cohort, tutor feedback, and a real project that ends in a usable portfolio piece. At the other end: a self-paced video library with a certificate at the end, marketed with the word 'bootcamp' to sound more credible.

These two things are not comparable. Before you evaluate whether a bootcamp is worth it, you need to know which kind you are looking at.

Signs you are looking at a genuine structured programme:

- Scheduled live sessions with a real instructor, not just video content you can watch any time
- A fixed cohort of students who go through the programme together
- Tutor or mentor feedback on your actual work
- A capstone project that produces a real portfolio case study
- A capped class size (small enough that you can ask questions and get answers)

Signs you are looking at a content library dressed up as a course:

- "Learn at your own pace" with no live sessions
- Unlimited enrolment or no cohort structure
- Auto-graded quizzes rather than tutor review
- A certificate of completion with no project to show for it

This distinction matters more than any other factor when you are deciding whether to spend money.

## The real pros of a good UX bootcamp

**Structure and accountability.** Most adults who try to learn UX design through free resources give up. Not because they are not capable, but because self-directed learning without deadlines or a cohort is genuinely hard to sustain alongside a job, a family, and the rest of life. A programme with scheduled sessions and a group of peers creates the external pressure that makes completion much more likely.

**Compressed learning.** A well-designed intensive course covers in eight to twelve weeks what might take you a year to piece together from blog posts, YouTube tutorials, and fragmented free content. It is not just faster - it is often more coherent, because the curriculum was built as a sequence rather than assembled from unrelated sources.

**Portfolio output.** The practical outcome of a good programme is a case study you can show to employers. This is the thing that gets you interviews. Self-study can get you there, but only if you deliberately set up real projects, document your process, and present your work - skills that a structured course teaches explicitly. For a full guide to building that portfolio from the ground up, see [how to build a UX portfolio from scratch](/blog/how-to-build-a-ux-portfolio-from-scratch/).

**Feedback on your work.** Reading about UX and doing UX are different. Feedback from a working designer who can look at your wireframes, your research synthesis, or your prototype and tell you what is weak is not something you get from a video course. It is one of the most valuable things a structured programme offers.

**Peer learning.** Working through a brief alongside other career-changers is underrated. You see different approaches to the same problem, you practice giving and receiving design critique, and you build a small network of people who are at the same stage as you.

## The real cons - and where bootcamps fall short

**No programme guarantees a job.** This needs saying plainly because some marketing implies otherwise. A bootcamp does not place you in a role. It gives you skills, a project, and (if it is a good one) some support with your job search. The rest is on you. The UX job market in 2026 is competitive. You will still need to apply widely, iterate your portfolio, and invest time in networking and interview preparation after you finish.

**Quality is inconsistent.** Unlike a university degree, the word 'bootcamp' is not regulated. Anyone can offer one. The range of quality is enormous, and the marketing language used by weak programmes is often indistinguishable from strong ones. Due diligence is essential.

**Intensity suits some people and not others.** A short intensive course is not the right format for everyone. If you need more time to absorb and experiment, a longer programme with lighter weekly commitments may serve you better. 'Faster' is not the same as 'better' for every learner.

**You will need to do work after you finish.** The course is not the end. Portfolio refinement, job applications, networking, and continued self-development are all required. People who treat the certificate as the destination tend to be disappointed with the outcome.

## Who a UX bootcamp is worth it for

A structured UX programme tends to work well for people who:

- Are career-changers with five or more years in a professional role who want to retrain without doing a three-year degree
- Learn well in a structured environment with scheduled sessions and a group
- Have a specific outcome in mind (portfolio, job application) and are motivated to reach it
- Can dedicate the time the programme requires - not just the scheduled sessions but the practice between them

It tends to work less well for people who:

- Want a certificate as a shortcut, without the underlying work
- Are not sure yet whether UX is right for them (a free or low-cost taster is a better first step)
- Cannot realistically commit the time - a programme you cannot keep up with is money wasted
- Are looking for a passive learning experience

If you are not sure whether UX design is the right direction, the [free UX masterclass](/masterclass/free-ux-ui-masterclass/) is a lower-stakes starting point before committing to a full programme.

## What separates a good programme from a weak one

Ask these questions before you enrol anywhere:

- **Are sessions live or pre-recorded?** Live instruction with a real designer who can answer your specific questions is fundamentally different from recorded video.
- **How many students are in each cohort?** A cohort of 150 is not the same as a cohort of 15. Ask directly.
- **Will you get feedback on your work?** Specifically: who reviews it, how often, and in what format?
- **What is the project?** You should graduate with a portfolio case study you built during the programme, not just a completion certificate.
- **Who teaches it?** Instructors who are working designers bring current industry context. Check their background.
- **What support exists after the programme?** Some programmes offer career coaching, portfolio review, or community access post-graduation. This matters if you are making a career change.

## The ROI case: are UX bootcamps worth it financially?

This is the question that often sits behind the broader one. If a structured programme costs GBP 1,500 to GBP 3,500, is the salary uplift real enough to justify the spend?

Here is what the verified data shows.

The UK median full-time salary is GBP 39,039 (ONS Annual Survey of Hours and Earnings, 2025 -- full-time employees in post at least a year). By contrast, the median salary for a UX designer in the UK is GBP 55,000 (ITJobsWatch, vacancy-based market rate to June 2026). That is roughly 41% above the UK median wage. The gap is meaningful, and it is not a cherry-picked outlier - it reflects where employers are pricing the skill.

At the senior end, London-based UX and product designers with five or more years of experience are typically paid in the GBP 70,000 to GBP 80,000 range (Morgan McKinley 2026 UK salary guide). Entry-level starting points are harder to pin down precisely - one directional figure is around GBP 27,476 (PayScale), though this is based on a small self-reported sample of around 35 salaries and should be treated as indicative rather than definitive. The jump from entry-level to mid-level is where the financial case for the investment starts to land clearly.

It is also worth noting that the market softened slightly over the past year - the UX designer median was around GBP 57,500 in 2025 and has come down to GBP 55,000 in 2026. That is a real shift, and including it is more useful than pretending the market only moves in one direction.

For a fuller picture of the pay landscape, see our detailed guide to [UX designer salary in the UK](/blog/ux-designer-salary-uk/).

## Bootcamp vs self-taught vs university

These are genuinely different paths, and the right one depends on your situation.

**Self-taught** is the cheapest route and requires the most discipline. It works well for people who are already employed in an adjacent field (product management, graphic design, front-end development) and are building UX skills incrementally. It works less well for people making a complete career change from an unrelated background, because the absence of structure makes it easy to develop gaps without realising it.

**University** (postgraduate conversion course or a design degree) gives you the most time, the broadest exposure, and the most recognised credential. It also takes the longest and costs the most - often GBP 10,000 to GBP 20,000+ for a postgraduate programme, plus living costs and lost earnings if you are studying full-time. It makes sense for people who want to go deep, have the time, and for whom the credential matters in their target market.

**A structured short programme** sits between the two. It is faster than a degree and more structured than self-teaching. The trade-off is depth: you get enough to be job-ready, not everything there is to know. For most adult career-changers, that trade-off is a reasonable one.

For more on navigating this decision, see [switching careers to UX design](/blog/switching-careers-to-ux-design/), our step-by-step guide to [how to become a UX designer](/blog/how-to-become-a-ux-designer/), and [getting a UX job with no experience](/blog/ux-job-with-no-experience/).

## Realistic expectations on jobs

The honest picture: UX is a competitive market. Entry-level roles attract a lot of applicants. A programme - however good - does not put you at the front of the queue automatically. Our guide to [UX design jobs in the UK](/blog/ux-design-jobs-uk/) gives an honest picture of where demand sits and what employers are hiring for. What does help:

- Two or three strong, well-documented portfolio case studies
- Evidence of user research, not just visual design
- The ability to talk clearly about your process in interviews - our guide to [UX design interview questions](/blog/ux-design-interview-questions/) covers what to expect at each stage
- Applying widely and persistently, not waiting for the perfect role
- Networking, including LinkedIn activity and attending community events

The best-placed graduates from any structured programme are the ones who treated it as the beginning of their job search preparation, not the end of it.

For a fuller picture of the job market and what employers are looking for, the [best online UX design courses UK](/best-online-ux-design-courses-uk/) roundup covers options across the market, including what distinguishes programmes at different price points.

## What to look for if you are comparing programmes

When you are comparing options, weight these factors in roughly this order:

1. Live instruction vs pre-recorded - this is the single biggest quality differentiator
2. Cohort size - smaller is better for feedback and interaction
3. Project work - specifically whether you build a portfolio piece during the programme
4. Instructor background - working designers, not just educators
5. Post-programme support - community, career coaching, portfolio review
6. Price relative to what is included - not just the absolute cost

A more expensive programme that delivers live instruction, a small cohort, real feedback, and a genuine portfolio outcome is usually better value than a cheaper one that delivers video content and a PDF certificate.

## UX Academy: one option worth knowing

UX Academy (myuxacademy.com) is a UK live online school built around exactly the format described above. The [Beginner UX (AI) Design course](/courses/beginner-ux-design/) runs in cohorts of maximum 15 students, with live teaching every session and a real client project that becomes a portfolio piece. The programme runs for 8 weeks and costs GBP 1,500, with a GBP 99 refundable deposit to secure your place. The next cohort starts <CohortDate />.

It is not the right fit for everyone - no single programme is. But if you are looking for a structured, live, small-cohort option built for UK-based career-changers, it is worth considering alongside whatever else you are comparing.


---

# Best AI Tools for UX Designers in 2026

URL: https://myuxacademy.com/blog/ai-tools-for-ux-designers/
A practical guide to AI tools for UX designers in 2026 - from research synthesis to accessibility, with honest advice on what to trust and what to question.

**AI has moved from novelty to everyday toolkit for UX designers - but knowing which tools actually help, and where they quietly mislead you, is the skill that matters most in 2026.**

The landscape has exploded. Every design platform now has an AI feature, and new standalone tools appear monthly. Rather than ranking brands that may have changed by the time you read this, this guide organises AI tools by what you actually need to get done - the job, not the logo. For each category you will find what AI genuinely helps with, what to be cautious about, and the kinds of tools worth exploring.

If you want a deeper look at how AI is reshaping the discipline, see our piece on [AI in UX design](/blog/ai-in-ux-design/). And if you are wondering about job security, the honest answer is in [will AI replace UX designers](/blog/will-ai-replace-ux-designers/).

## Research Synthesis

Qualitative research generates mountains of data - interview transcripts, usability session notes, survey responses. Manually coding and clustering that data is time-consuming, and it is precisely the kind of pattern-recognition work that AI is well-suited to assist with.

AI research synthesis tools can transcribe recordings, tag themes across transcripts, surface recurring pain points, and summarise findings into structured outputs. Some are standalone platforms; others are built into research repositories or collaboration tools.

**What to watch out for:** AI synthesisers reflect the biases in your source data. If your participant sample is narrow, the AI summary will confidently describe a narrow truth. Hallucination is also a real risk - some tools invent quotes or conflate statements from different participants. Always read the source material before trusting a summary. Treat the output as a first draft, not a deliverable.

**Privacy consideration:** Interview recordings often contain sensitive personal data. Check where the tool processes and stores audio before uploading anything. EU GDPR compliance matters, especially if you are conducting research with UK or European participants.

## UX Writing and Content

Microcopy - button labels, error messages, empty states, onboarding tooltips - has an outsized impact on conversion and usability. AI writing assistants can generate multiple variants in seconds, helping you explore tone and wording without starting from a blank page.

These tools are also useful for checking reading level, identifying jargon, and rewriting dense legal or technical copy in plain language. Some are integrated directly into design tools; others work as browser extensions or standalone apps.

**What to watch out for:** AI-generated copy tends toward generic. The first suggestion is rarely the best one. Use AI to generate options, then apply your own judgement about which variant fits the product voice. Also watch for US English defaults - if you are designing for a UK audience, check spelling and phrasing carefully.

**Over-reliance risk:** If you use AI to write all your microcopy without reviewing it against the user's mental model, you risk polished-sounding text that does not actually help people. Good UX writing requires understanding context, not just generating fluent sentences.

## Ideation and Concept Exploration

One of the most genuinely useful applications of AI in UX is rapid ideation. When you are early in a project and need to explore a wide solution space quickly, AI tools can help you generate a broad range of concepts to react to - navigation structures, feature ideas, interaction patterns, user flow variations. To understand where ideation sits within the broader [UX design process](/blog/ux-design-process/), it is worth reading how that process unfolds before integrating AI into it.

Large language models work well here as thinking partners. You can describe a problem and ask for ten different approaches, then use those as prompts for your own divergent thinking rather than accepting them as answers.

**What to watch out for:** AI tends to suggest conventional solutions. It is drawing on what has already been done, so its suggestions will cluster around existing patterns. This is fine for orientation but can constrain creativity if you treat the AI output as the endpoint rather than the start. Push past the first batch of suggestions.

Also be aware that AI has no knowledge of your specific users, your product constraints, or your business context. Ideas generated without that grounding will need significant filtering.

## Design Generation and Wireframing

Several tools can now generate wireframes, UI layouts, or design components from a text prompt or a rough sketch. These range from dedicated AI design platforms to features built into established design tools. You describe what you want - a checkout flow, a mobile onboarding screen, a dashboard layout - and the tool produces a starting point.

For experienced designers, this is useful for rapid low-fidelity exploration. For people learning UX, it is worth being careful - generating a wireframe is not the same as understanding why that layout works for users.

**What to watch out for:** AI-generated layouts often look plausible but contain subtle usability problems - poor visual hierarchy, inaccessible tap targets, or interaction patterns that do not match user expectations. Always evaluate generated designs against design principles and, where possible, user feedback. Do not skip straight from AI output to high fidelity.

**Intellectual property:** Some AI image and design generators have unclear or contested positions on the ownership of outputs. If you are working on commercial products, check the tool's terms of service before using generated assets in production.

## Prototyping and Interaction

AI is beginning to appear in prototyping workflows in a few different ways: generating prototype code from design files, suggesting micro-interaction patterns, and animating static designs automatically.

Tools that convert designs to functional prototypes or code have become meaningfully more capable. This reduces the gap between design intent and working prototype, which speeds up usability testing.

**What to watch out for:** Generated code often works for simple components but breaks down with complex states, edge cases, or accessibility requirements. Treat generated prototypes as a testing artefact, not a production asset, unless a developer has reviewed the output. The goal is to get something in front of users faster - not to skip engineering entirely.

## Accessibility Checking

Accessibility checking is one of the clearest wins for AI in UX. Tools in this category can scan designs or live interfaces for contrast ratio failures, missing alt text, unlabelled form fields, focus order problems, and WCAG compliance gaps.

Some are integrated into design tools as real-time linters; others are browser-based auditing tools you run against a built interface. Either way, they catch the easy-to-miss mechanical errors before they reach users.

**What to watch out for:** Automated accessibility checking catches a significant proportion of WCAG 2.1 failures but not all of them. Cognitive accessibility, clear language, and logical structure require human judgement. An interface that passes an automated audit can still be genuinely hard to use for people with disabilities. Combine automated checks with manual review and, ideally, testing with disabled users.

## Analytics and Behavioural Insights

AI-powered analytics tools help UX designers move from raw session data to actionable insight faster. Heatmaps, session replay, funnel analysis, and anomaly detection are all areas where AI is making tools more useful - surfacing which screens have the highest drop-off, which interactions cause confusion, or which user segments behave differently.

For a discipline that sometimes struggles to connect design decisions to measurable outcomes, this category is worth investing time in. See also [what does a UX designer do](/blog/what-does-a-ux-designer-do/) for a fuller picture of how analytics fits into the role.

**What to watch out for:** Behavioural data tells you what users do, not why. AI-generated insight summaries can overstate causation. A spike in rage-clicks on a button is a signal to investigate, not a confirmed diagnosis. Always triangulate analytics findings with qualitative research before making significant design decisions.

**Privacy:** Session replay tools record real user behaviour. Make sure consent is properly obtained, data retention is limited, and personally identifiable information is masked. This is both a legal requirement and a matter of user trust.

## Building a Thoughtful AI Toolkit

The designers getting the most from AI in 2026 are not the ones who adopted every new tool. They are the ones who identified specific friction points in their workflow, tested tools against those problems, and built habits around the ones that genuinely helped. For a broader view of the [full UX design tool stack](/resources/) - AI and non-AI - our dedicated guide covers what practising designers actually use.

A practical starting point: pick one category from above that represents a real bottleneck in your current work. Try two or three tools in that category. Evaluate them not on impressiveness but on whether they actually save time and improve output quality. Then move on to the next bottleneck.

AI tools amplify the work of a skilled designer. They do not substitute for understanding users, thinking clearly about problems, or making sound design decisions.

---

If you want to learn UX design in a curriculum that treats AI as a core professional tool - not a gimmick and not a threat - UX Academy (myuxacademy.com)'s [Beginner UX (AI) Design course](/courses/beginner-ux-design/) covers practical AI integration across the full design process. It is a live online programme designed for career-changers, running as a UK cohort with the next intake on <CohortDate />.

Not sure if UX is right for you? Join our [free UX/UI masterclass](/masterclass/free-ux-ui-masterclass/) to see how we teach and whether the field fits where you want to go.


---

# What Is UX Design? A Complete Guide (2026)

URL: https://myuxacademy.com/blog/what-is-ux-design/
UX design explained from first principles: definition, day-to-day work, the UX process, tools, skills, and how to break into the field in the UK.

**UX design** (user experience design) is the practice of designing products and services so they are useful, easy to use, and genuinely satisfying for the people who use them. It covers websites, apps, software, and increasingly physical and service experiences too.

If you're asking **what is UX**: UX (user experience) is the overall experience a person has using a product or service; UX design is the deliberate, research-led practice of shaping that experience. If you have ever abandoned a website because the checkout was confusing, or loved an app because it just made sense, you have felt UX design at work — or the absence of it.

## What is UX design?

The term "user experience" was popularised by Don Norman in the 1990s while at Apple. He meant something deliberately broad: every aspect of a person's interaction with a company, its services, and its products. Today, in a digital context, UX design usually refers to the process of researching, structuring, and shaping how a product works so that it meets real human needs.

The key word is **user**. UX design starts from the people who will use a product — not from the technology, not from business preferences, and not from what the design team thinks looks good. A UX designer's job is to understand those people deeply, then make decisions that serve them, while still meeting business goals.

Good UX is often invisible. When a product works smoothly, you do not notice the design — you just get your task done. You notice UX when it fails.

## What does a UX designer actually do?

The job varies by organisation, but a working week for a UX designer typically includes some combination of:

- **User research:** conducting interviews, running usability tests, reviewing analytics data, and synthesising findings into patterns
- **Problem framing:** turning research into a clear, specific problem statement that the design work will address
- **Ideation and wireframing:** sketching ideas (often on paper first), then building wireframes and lo-fi prototypes in Figma to explore possible solutions
- **Prototyping and testing:** building clickable [prototypes](/blog/what-is-prototyping/) and testing them with real users to see what works
- **Stakeholder communication:** presenting decisions, explaining the "why" behind design choices to product managers, engineers, and business leads
- **Handoff:** working with developers to make sure the designed experience is built correctly

Most of the job is thinking, communicating, and making decisions — not visual production. UX designers rarely work alone; they work closely with product managers, engineers, researchers, and content designers. For a deeper look at day-to-day responsibilities, see our dedicated post on [what a UX designer does](/blog/what-does-a-ux-designer-do/).

## UX vs UI design: the key difference

In one line: **UX is how it works; UI is how it looks.**

UX design is about structure, flow, and whether the product solves the right problems in the right way. UI (user interface) design is about visual decisions — colour, typography, layout, and the style of individual components. On many teams the roles overlap, and one person does both. They are distinct disciplines, but the boundary is not always sharp in practice. For a full comparison, see our guides to [UX vs UI design](/blog/ux-vs-ui-design/) and [what user interface design involves](/blog/what-is-user-interface-design/).

## The UX design process

There is no single fixed process, but most UX work moves through a recognisable cycle. A common framework is the double diamond: diverge to explore, then converge to decide, twice over.

### 1. Discover (research)

Learn about users, their context, and their problems before designing anything. Interviews, surveys, analytics, contextual inquiry, and competitor analysis all feed this stage. The research informs everything that follows. Choosing the right [UX research methods](/blog/ux-research-methods/) for each project is itself a skill.

### 2. Define

Synthesise the research into clear insights and a focused problem statement. This is where personas, journey maps, and jobs-to-be-done frameworks come in. A well-defined problem is worth more than a brilliant solution to the wrong problem.

### 3. Develop (ideate and design)

Generate ideas, sketch, wireframe, and prototype. Explore several directions before committing to one. This is the stage most people picture when they think of "design" — but it only works well when it is grounded in solid research and a clear problem statement.

### 4. Deliver (test and refine)

Test designs with real users, measure what works, fix what does not, and hand off to development. Then learn from the live product and improve. For a structured approach to evaluation, [heuristic evaluation](/blog/heuristic-evaluation-ux-design/) is one of the most reliable and low-cost methods.

The process is iterative, not linear. You loop back as you learn. A good UX designer treats every first solution as a hypothesis, not an answer. Our guide to the [UX design process](/blog/ux-design-process/) walks through each stage in detail.

## Key UX design skills

You do not need to be a brilliant visual designer or a coder. The core skills are:

- **Empathy and curiosity:** a genuine interest in how other people think and behave, including people whose lives look nothing like yours
- **Research skills:** asking good questions, listening carefully, and interpreting what you learn without projecting your own assumptions onto it
- **Structured thinking:** organising information, breaking problems down, and communicating logic clearly
- **Communication and persuasion:** UX designers spend as much time explaining decisions as making them — to product managers, engineers, and stakeholders who may be sceptical
- **Tool fluency:** Figma is the industry standard for wireframing and prototyping; research tools, collaboration tools, and analytics tools round out the toolkit

Many of these transfer directly from other careers. People move into UX from marketing, teaching, psychology, project management, customer support, and software development — which is one reason UX is such an accessible field for career changers.

## UX design tools

The core toolkit is smaller than people expect. For most UX work, you need:

- **Figma** — the industry standard for wireframing, high-fidelity design, and prototyping; used by the vast majority of UK product teams
- **Miro or FigJam** — for virtual workshops, affinity mapping, and journey mapping
- **A research tool** — Maze or Lyssna for unmoderated usability testing; Lookback for moderated sessions; Dovetail for research synthesis
- **Analytics** — Hotjar for heatmaps and session recordings; GA4 for traffic and conversion data

If you are just starting out, learn Figma first. It is free to use, covers the full workflow from rough wireframe to clickable prototype, and is expected in nearly every UK UX job listing. For a full breakdown of the stack, see our guide to [UX design tools](/resources/).

## Why UX matters: the business case

UX is not a nice-to-have. It has direct, measurable business impact:

- **Conversion:** clearer flows mean more people complete sign-ups, purchases, and key actions. A confusing checkout costs real revenue.
- **Retention:** products that are pleasant to use keep their users. Frustrating ones get abandoned.
- **Cost reduction:** fixing usability problems early, with research and testing, is far cheaper than fixing them after launch.
- **Accessibility and trust:** thoughtful UX makes products usable by more people, including those with disabilities — a legal requirement in many contexts.
- **Competitive advantage:** when two products solve the same problem, the one that is easier to use wins.

This is why UX roles are in demand across sectors, and why UX has become a viable career path for people switching from entirely different fields.

## How to become a UX designer in the UK

A practical path:

1. **Learn the fundamentals** — understand the process, the methods, and the vocabulary before you touch any tools
2. **Learn Figma** — get comfortable by recreating and redesigning interfaces you already use
3. **Do real projects** — a portfolio of real, brief-driven work is what gets you hired, far more than certificates
4. **Get feedback from practitioners** — working with experienced designers shortens the learning curve dramatically; this is where self-paced video courses fall short
5. **Build a portfolio** — three to four strong case studies that show your thinking process, not just your final screens

For more on the career-change path, see our detailed guide on [how to become a UX designer](/blog/how-to-become-a-ux-designer/).

Most career changers can build a credible junior portfolio in six to nine months of focused work alongside other commitments.

## UX designer salary in the UK

The median UK UX designer salary is **£55,000** (ITJobsWatch, vacancy data to June 2026) — roughly 41% above the UK median full-time salary. Entry-level roles run £24,000-£38,000 depending on location; senior London roles reach £60,000-£85,000. For full figures by experience band and location, see our [UX designer salary UK guide](/blog/ux-designer-salary-uk/).

## FAQ

### What is UX design?

UX design is the practice of designing products and services so they are useful, easy to use, and satisfying for the people who use them. It covers digital products — websites, apps, software — as well as physical and service experiences. It starts from research into real users, not from assumptions or aesthetics.

### What does a UX designer do day-to-day?

Day-to-day, a UX designer might run a user interview, synthesise research findings, sketch a new flow on paper, build a wireframe in Figma, present a design decision to stakeholders, or review a prototype with a developer. Most of the job is thinking and communicating, not visual production.

### What is the difference between UX and UI design?

UX is about how a product works — structure, flow, and solving the right problems. UI is about how it looks — colour, typography, layout, and visual style. The roles often overlap in practice, but they are distinct disciplines. For a full side-by-side breakdown, see our guide to [UI vs UX design](/ui-vs-ux/).

### What skills do you need to be a UX designer?

Empathy, curiosity about how people think, research skills, structured thinking, and strong communication. Figma is the main tool to learn. Many of these skills transfer directly from other careers — marketing, teaching, psychology, project management.

### How do I become a UX designer in the UK?

Learn the fundamentals, learn Figma, do real brief-driven projects, get feedback from working practitioners, and build a portfolio of three to four case studies. Most career changers can build a credible junior portfolio in six to nine months of focused work. If research is where your strengths lie, the [UX researcher](/ux-researcher/) route is worth exploring, and our guide to [choosing a UX design course](/ux-design-course/) breaks down the options.

---

At [UX Academy](https://myuxacademy.com), our [UX design courses](/courses/) are live, small-group (max 15 students), taught by working UX professionals, and built around a real client project. Our [Beginner UX (AI) Design course](/courses/beginner-ux-design/) is designed for career changers with no prior experience. Cohort 1 starts **<CohortDate />** — places are reserved with a **£99 refundable deposit**. To see how it works first, [book a free masterclass](/masterclass/free-ux-ui-masterclass/).


---

# What Is Figma? The Design Tool Every UX/UI Designer Uses

URL: https://myuxacademy.com/blog/what-is-figma/
Figma is the browser-based design tool used by most UX and UI designers. Here's what it does, why it became the industry standard, and how to get started.

If you've been researching a career in UX or UI design, you've probably heard the name Figma come up more than any other tool. Hiring managers list it. Job descriptions require it. Design portfolios are built with it. But if you're new to the field, you might be wondering: what is Figma, and why does everyone use it?

This guide answers that question properly - covering what Figma is, what it can do, how designers use it across a real project, and how you can start learning it even if you've never designed anything before. If you're still figuring out the bigger picture, our [what is UX design](/blog/what-is-ux-design/) guide is a good place to start - Figma is the tool; UX design is the discipline it supports.

## What Is Figma?

Figma is a browser-based design tool used to create user interfaces, interactive prototypes, and design systems. Unlike older software that you install on your computer, Figma runs in your web browser (or a lightweight desktop app). That means you can open it on any machine, share work with a link, and collaborate with teammates in real time - all without emailing files back and forth.

It was launched in 2016 and spent its first few years as a challenger to established tools like Adobe XD and Sketch. By the early 2020s it had become the dominant tool in the industry, used by design teams at companies ranging from small startups to Google, Airbnb, and Spotify. That shift wasn't accidental - it happened because Figma solved a set of practical problems that earlier tools didn't.

## Why Figma Became the Industry Standard

Before Figma, designers typically worked in desktop apps that saved files locally. To share work with a developer or get feedback from a stakeholder, you'd export an image, send it over email or Slack, and wait. If revisions were needed, the process started again. Version control was a mess. Developers would often build from an outdated file because nobody noticed a newer version had been saved.

Figma changed the workflow fundamentally. Because it lives in the browser, a design file has a single URL. Everyone looks at the same file. When the designer updates something, the change is live immediately. Comments happen directly on the canvas. Developers can inspect any element and copy the CSS values without the designer needing to write a spec document. This shift from 'static files being passed around' to 'shared, live design space' is why adoption happened so quickly and so completely.

There's also the matter of the free tier. Figma allows individuals to create and work on design files at no cost. For anyone learning the tool or building a portfolio, that removes a meaningful barrier. You do not need to pay anything to get started.

## What Figma Can Do

Figma covers most of what a UX or UI designer needs across a typical project. For a deeper breakdown of specific use cases, our guide on [what Figma is used for](/blog/what-is-figma-used-for/) covers each capability with real-world examples. Here are the main capabilities worth understanding - and it's exactly this toolkit that students build on in our [Beginner UX (AI) Design course](/courses/beginner-ux-design/).

### UI Design

The core of Figma is a vector-based canvas where you design screens and interfaces. You work with frames (which represent screens or components), shapes, text, images, and icons. Everything is editable and adjustable. Because it's vector-based rather than pixel-based, designs can be scaled to any size without losing quality.

If you've ever used a graphic design tool before, the fundamentals will feel familiar - though Figma has specific features built for UI work rather than print or illustration.

### Prototyping

Figma lets you link screens together to create interactive prototypes. You can simulate user flows - tapping a button on one screen takes you to another, a drawer slides in, a modal appears. These prototypes can be shared with stakeholders and tested with real users without writing a single line of code.

This is a core part of the UX process. Rather than guessing whether a design will work, you prototype it, put it in front of users, observe where they get confused, and iterate. Figma makes this loop fast.

### Components and Design Systems

One of Figma's most important features for professional work is the components system. A component is a reusable design element - a button, a card, an input field. You create it once, and then use instances of it throughout your designs. When you update the main component, every instance updates automatically.

This is how real design teams maintain consistency across a product. A design system is essentially a library of components combined with rules about how they're used. Figma is the tool where most design systems are built and maintained. Understanding how components work is one of the things that separates beginners from job-ready designers.

### Real-Time Collaboration

Multiple people can work in the same Figma file at the same time. You can see other users' cursors moving on the canvas. Stakeholders can leave comments pinned to specific elements. Designers can do live review sessions by sharing their screen within the tool itself.

For remote teams - which now includes the majority of design teams - this capability is genuinely transformative. It's the reason Figma became the default tool so quickly after remote work became widespread.

### Developer Handoff

When a design is ready to be built, developers need to know the exact measurements, fonts, colours, spacing, and behaviour of every element. Figma has an inspect panel that surfaces all of this automatically. A developer can click on any element and see its properties, copy the relevant code values, and access any assets they need.

This reduces back-and-forth between design and development significantly, and it reduces the chance of designs being implemented incorrectly.

### FigJam

FigJam is Figma's whiteboarding and collaboration tool - separate from the main design canvas but part of the same product. It's used for brainstorming, user journey mapping, affinity diagrams, and workshop facilitation. Teams use it in discovery phases before any visual design work begins.

If you've been in a session where someone shares a virtual sticky-note board, there's a reasonable chance it was FigJam.

## How Designers Actually Use Figma in a Project

It helps to see how Figma fits into a real UX/UI process rather than thinking of it as a list of features.

**Discovery and research** - A UX designer might use FigJam to map out a user journey or synthesise research findings with a team.

**Wireframing** - Low-fidelity wireframes are often sketched in Figma using simple shapes and placeholder text. These aren't meant to look finished; they're used to test structure and layout before investing time in visual design.

**UI design** - Once the structure is agreed, a UI designer builds out the full visual design in Figma - applying the brand, typography, colour, and imagery.

**Prototyping and user testing** - The designer links screens together and shares the prototype for user testing. They watch how people navigate, identify friction points, and revise.

**Developer handoff** - The finished designs sit in Figma for developers to reference throughout the build. Annotations can be added directly in the file.

This isn't a rigid sequence - in practice these stages overlap and loop back. But it illustrates that Figma is used across the entire design process, not just at one stage of it.

## Figma vs. Other Tools

You may come across other design tools: Adobe XD (largely discontinued as a standalone product), Sketch (Mac-only, still used by some teams - see our [Figma vs Sketch](/blog/figma-vs-sketch/) comparison for a direct breakdown), and more recently Penpot (an open-source alternative). There are also specialised tools like Axure for complex prototyping and Maze for user testing. For a fuller picture of how these tools fit together, our guide to [UX design tools](/resources/) covers the broader design tool stack.

Figma is not the only tool that exists, but it is the tool you will encounter most consistently in job descriptions, bootcamp curricula, and design team workflows. Learning it first is the practical choice. The skills transfer to other tools; the underlying design thinking transfers even more completely.

## Starting Out: How to Learn Figma as a Beginner

Figma has a reasonably gentle learning curve if you start in the right place. Our [Figma for beginners](/blog/figma-for-beginners/) guide walks through the first steps in detail - from setting up your account to building your first frame. A few practical notes:

- **Create a free account.** Go to figma.com and sign up. No payment required to get started.
- **Follow Figma's own tutorials.** Their official learning resources cover the basics clearly and are kept up to date.
- **Practise by rebuilding things.** Take a screen from an app you use - a login page, a settings screen - and try to recreate it in Figma. You'll learn faster by doing than by watching.
- **Learn components early.** Most beginners skip over components and later have to unlearn bad habits. It's worth understanding them properly from the start.
- **Use community files.** Figma has a community section where designers share free files. Exploring how experienced designers have structured their work is one of the fastest ways to improve.

The tool itself is learnable. What takes longer to develop is the design judgement behind the tool - knowing why you're making a particular layout decision, how to structure a user flow, what makes an interface intuitive. That's where structured learning makes a real difference.

## Learning Figma Properly on a UX/UI Course

If you're serious about moving into UX or UI design, learning Figma in isolation only gets you so far. Employers aren't just hiring for tool proficiency - they're hiring for the ability to conduct user research, make decisions based on evidence, and design systems that work for real people.

At [UX Academy](/) (myuxacademy.com) - a live online UX design school based in the UK - Figma is the primary tool used throughout the curriculum. Every project, prototype, and portfolio piece is built in Figma, so by the time you complete the course you have genuine working experience with the tool in a realistic context. The course is taught live, not pre-recorded, by working practitioners.

You can explore the [Beginner UX (AI) Design course](/courses/beginner-ux-design/) to see how Figma fits into the broader programme. If you're not yet sure whether UX or UI design is the right direction, the [free UX/UI masterclass](/masterclass/free-ux-ui-masterclass/) is a good place to start - it covers the landscape of the industry, the differences between disciplines, and what a career transition actually looks like in practice.

Figma is free to start. So is the masterclass. If you're curious about either, there's no reason to wait.

---

*Not sure whether UX or UI design is the right fit? Read [what is UX design](/blog/what-is-ux-design/) or [UX vs UI design](/blog/ux-vs-ui-design/) to get your bearings first.*


---

# What Is a Design Sprint? The Five-Day Process Explained

URL: https://myuxacademy.com/blog/what-is-a-design-sprint/
A design sprint is a five-day framework for solving big problems fast. Learn the phases, when to use one, and what it means for your UX practice.

The phrase "design sprint" gets thrown around a lot in product and UX circles. Sometimes it means a focused week of structured work. Sometimes it just means "we moved quickly." This post is about the real thing: the five-day sprint process developed at Google Ventures, what happens in each phase, when it is worth using, and when it is not.

If you are studying UX or moving into the field, understanding design sprints is genuinely useful. They come up in job interviews, they appear in team culture at many product companies, and they illustrate some of the best ideas in applied UX work.

## Where Design Sprints Come From

The design sprint was created by Jake Knapp while he was working at Google, and later codified during his time at Google Ventures (GV), the investment arm of Alphabet. His 2016 book *Sprint*, co-written with John Zeratsky and Braden Kowitz, made the method widely accessible.

GV used the sprint to help portfolio companies answer high-stakes questions quickly - without building a full product first. The core proposition was straightforward: compress months of back-and-forth into five focused days, end with a realistic prototype, and test it with real users before spending serious money.

The method drew from design thinking, agile, and behavioural science. But unlike design thinking, which is a broad mindset and process framework, a design sprint is a specific, timed structure with named activities for each day. It is closer to a recipe than a philosophy.

For more on how design thinking relates to this work, see our post on [design thinking in UX](/blog/design-thinking-ux/).

## The Five Phases

A classic GV design sprint runs Monday through Friday. Each day has a clear purpose. Here is what happens and why it matters.

## Phase 1: Understand and Map

**Day one is about aligning the team on the problem.**

Before anyone sketches anything, the sprint opens with a structured effort to surface what everyone knows - and does not know. The team talks to internal experts, maps the user journey end to end, and defines the long-term goal.

A key tool here is the "How Might We" format: turning problems into open questions. "Users abandon checkout" becomes "How might we make checkout feel less risky?" This small linguistic shift keeps the focus on possibility rather than blame.

By the end of Monday, the team picks one specific target moment on the map - the part of the journey they will focus on for the rest of the week.

**Example:** A team at an online estate agent runs a sprint on their property listing experience. On day one, they map the journey from search to booking a viewing. They identify that the moment users read the property description is where most of them leave. That moment becomes the sprint target.

## Phase 2: Sketch

**Day two is individual, divergent idea generation.**

Rather than a group brainstorm - which research consistently shows is less effective than individual thinking - each person on the team works alone to sketch solution ideas. The format is structured: first you review what competitors and analogous products do, then you produce detailed sketches of your proposed solution.

The output is not a polished wireframe. It is a "solution sketch": a three-panel storyboard showing how a user would experience the proposed solution. Crucially, each sketch is anonymous at this stage. That removes the pull toward group consensus and the tendency to defer to the most senior person in the room.

**Example:** The estate agent team each sketch their own version of a redesigned property description. One person proposes a "key facts" summary at the top. Another suggests a "questions answered" section drawn from common buyer queries. A third focuses on social proof - showing how many people have viewed and saved the property.

## Phase 3: Decide

**Day three is about making a choice and planning what to build.**

All the sketches from Tuesday go up on the wall. The team reviews them systematically - using dot voting, structured critique, and a final decision by the sprint's "Decider" (usually the project owner or a senior stakeholder). The goal is to pick the strongest idea, or to identify compatible ideas that can be combined.

By the end of Wednesday, the team has a storyboard: a step-by-step plan of the prototype they will build the next day. This is not optional. You need a detailed storyboard before you build anything, or Thursday becomes chaos.

The Decider role is important and deliberate. Design sprints resist consensus decision-making. Someone has to own the call. That person is named in advance.

**Example:** The estate agent team vote on the sketches. The "key facts" summary and the "questions answered" section both get high scores. The Decider chooses to combine them into a new property page layout. The storyboard maps out exactly what a user will see from search result through to booking.

## Phase 4: Prototype

**Day four is focused execution.**

The team builds a realistic-looking prototype - not a fully functional product, but something good enough to put in front of a real user and get genuine reactions. The standard in GV sprints is to use tools like Figma, Keynote, or even recorded screen walkthroughs.

The key principle is "fake it until you test it." You are not building for engineers. You are building for your test participants. A clickable Figma prototype that looks like a real website is sufficient.

Thursday is intense. It works because the storyboard is already done - you are executing a plan, not making decisions.

**Example:** The estate agent team build a Figma prototype of the new property listing page. It includes the key facts summary, the questions section, and real photos from an existing listing. It is not connected to their database. It does not need to be. It needs to look right and feel real to someone clicking through it on a laptop.

## Phase 5: Test

**Day five is where you find out if the idea actually works.**

On Friday, the team watches five real users interact with the prototype in one-to-one usability sessions (for a full guide on how to structure and run these, see our [usability testing guide](/blog/usability-testing-guide/)). The interviews follow a structured format: a short warm-up, then task-based exploration, then debrief questions.

Five users is a deliberate choice. Research by Jakob Nielsen showed that five qualitative sessions surface the majority of significant usability issues. You do not need a large sample to spot patterns - you need the right participants and careful observation.

The team watches the sessions together (often via a shared video link or observation room) and takes structured notes. By end of day, they have a clear picture: does the idea solve the problem, partially solve it, or miss the mark?

**Example:** Three of the five estate agent users immediately engage with the key facts summary. Two read the "questions answered" section in full before clicking through to book a viewing. One user is confused by the layout on mobile. The team has a clear steer: the concept works; mobile layout needs rework.

## When a Sprint Is the Right Tool

Design sprints work best in specific conditions.

- The team is aligned that there is a real problem but genuinely uncertain about the solution.
- The problem is concrete enough to test in a five-day window - a specific user journey, a key decision point, a product feature.
- Real users are accessible for Friday's testing.
- A decision-maker (the Decider) can commit five days and make a call.
- The stakes justify the investment - a significant product decision, a new market entry, a redesign of a high-traffic flow.

Sprints are particularly valuable when a team has been stuck in prolonged discussion without resolution. The structure forces a decision. That alone is often worth the week.

## When a Sprint Is Not the Right Tool

Sprints are not a cure-all.

**Exploratory research.** If you do not yet understand your users' lives, needs, or mental models, a sprint is premature. You need discovery work first - interviews, field research, diary studies. A sprint assumes you have enough understanding to sketch solutions.

**Complex, multi-faceted systems.** A sprint tests one specific slice of a problem. If the challenge is structural - a broken information architecture, a fragmented service, a multi-channel experience - a single sprint will not cover it.

**Purely technical problems.** Sprints are for human-centred design questions. If the blocker is a legacy API or a data pipeline, a design sprint is not the answer.

**Ongoing improvement work.** Sprints are high-effort and time-boxed. Continuous iteration on a live product usually calls for lighter methods: A/B testing, analytics review, short rounds of usability testing.

## The Benefits

When the conditions are right, design sprints offer real advantages.

**Speed.** Five days from question to user-tested insight is genuinely fast. The alternative is often months of meetings, misaligned assumptions, and a product launch that reveals problems that could have been caught earlier.

**Alignment.** Bringing a cross-functional team through the same process - map, sketch, decide, build, test - creates shared understanding. Everyone has seen the same user responses. Disagreements become easier to resolve.

**Reduced risk.** A prototype test on day five costs a fraction of building the full product. If the idea does not land, you have lost a week - not six months of engineering time.

**User evidence over opinion.** Sprints end with data. Not a survey, not stakeholder intuition - real humans using something that looks like your product.

## The Limitations

Honest assessment matters here.

Five users on Friday does not constitute definitive research. It surfaces patterns and identifies obvious problems - which is valuable - but it is not a statistically robust study. Decisions based on sprint findings should still be validated over time.

Sprints also require genuine commitment. If the team cannot protect five full days, or if the Decider is not present for key moments, the process degrades. A "sprint" in name only - where people dip in and out, skip Thursday, and present to stakeholders instead of testing with users - is not a sprint.

And sprints can create a false sense of resolution. The test on day five shows whether your solution idea is broadly on track. It does not mean the work is done.

## Compressed and Remote Sprints

The classic five-day format has spawned many variations.

**Three-day and four-day sprints** compress the original by combining some phases or reducing the number of sketches and decision rounds. They work when the team has strong existing research and a well-defined problem.

**Remote sprints** became standard during and after the pandemic. Tools like Miro, FigJam, and Maze make remote sketching, voting, and even prototype testing viable. Remote sprints require more structure and discipline - it is harder to sustain energy over video calls - but they are now a normal part of how product teams work.

Some organisations run "mini sprints" of two or three days focused only on a specific phase - for example, a decision day and a prototype-and-test day when the problem is already well understood.

## How Design Sprints Relate to UX

A design sprint is not a substitute for ongoing UX practice. It is a focused intervention for a specific kind of question.

In a mature product team, sprints typically sit alongside continuous discovery work: user interviews, usability testing, analytics, and [design thinking](/blog/design-thinking-ux/) as a broader orientation. Sprints are the power tool you reach for when speed and alignment are both critical.

If you want to understand where sprints fit in the wider picture, our introduction to [what UX design is](/blog/what-is-ux-design/) covers the full scope of the discipline - research, design, prototyping, and testing - and how these methods connect. For a step-by-step view of how UX work is typically structured outside a sprint context, see our guide to the [UX design process](/blog/ux-design-process/).

Understanding [usability](/blog/usability-in-ux-design/) is also worth your time before you run your first sprint. Testing a prototype without a clear framework for evaluating what "works" often leads to vague feedback that is hard to act on.

## Where to Go From Here

If you want to run a design sprint, Jake Knapp's book *Sprint* is the primary source. The full facilitation guide is also available free at the GV website. The method is well-documented and genuinely learnable.

If you want to build the broader UX skills that make sprints more effective - research methods, facilitation, prototyping, usability testing - that is what we teach at UX Academy (myuxacademy.com).

Our [Beginner UX (AI) Design course](/courses/beginner-ux-design/) covers the core process end to end, including hands-on prototyping and research, and is taught live by our lead instructor, Natalia Veretenyk, and her team. If you want to see what the curriculum looks like before committing, join one of our [free UX masterclasses](/masterclass/free-ux-ui-masterclass/).

Design sprints are a powerful method. Used in the right context, with the right preparation, they consistently produce insights that months of internal debate cannot. That is why they have become a fixture in product and UX teams - and why understanding them matters if you are serious about a career in the field.


---

# What Does a UX Designer Actually Do?

URL: https://myuxacademy.com/blog/what-does-a-ux-designer-do/
From user research to prototypes and design reviews, here is what UX designers do day to day - and how the role changes by company size and seniority.

If you are thinking about switching into UX design, you have probably asked yourself: what do these people *actually* do all day? The job title sounds broad. The LinkedIn posts make it look like endless sticky notes and Figma files. The truth is more interesting - and more varied - than either of those images suggests.

This post gives you a concrete, honest picture of the day-to-day work: the activities that fill a UX designer's week, the tools involved, how the role shifts depending on where you work, and what you will probably *not* be doing (despite what some job ads imply).

If you are earlier in your research and still working out what UX design even is, [start here](/blog/what-is-ux-design/) before reading on.

---

## The core job, in plain English

A UX designer's job is to make sure a product - an app, a website, a piece of software - works well for the people who use it. Not just technically works, but feels intuitive, achieves what users are trying to do, and does not cause unnecessary frustration along the way.

To do that, you need to understand users, translate that understanding into design decisions, and then communicate those decisions to the engineers and product managers who build the thing. That loop - research, design, test, refine - is the engine of the role. For a clear breakdown of how that process unfolds across a project, see our guide to the [UX design process](/blog/ux-design-process/).

---

## What fills a UX designer's week

### User research

This is where good design starts. Before you draw a single screen, you need to understand who you are designing for and what problems they are actually facing.

In practice, that means:

- Running **user interviews** - one-to-one conversations where you ask people about their goals, habits, and frustrations
- Sending out **surveys** to gather broader patterns across a larger group
- Conducting **contextual enquiry** - watching people use a product in their natural environment, not in a lab
- Reviewing **existing data**: analytics, support tickets, customer feedback, session recordings

There are many approaches to choose from depending on your stage and budget. Our guide to [UX research methods](/blog/ux-research-methods/) covers the main options and when to use each.

Research is not always a big formal project. At many companies, it happens in smaller bursts throughout the design process. You might spend a morning doing three short interviews to pressure-test an assumption before you commit to a design direction.

### Synthesis and sense-making

Raw research data does not give you answers. It gives you material to work with.

After research, UX designers spend time organising what they found - grouping observations, identifying patterns, and pulling out the insights that actually matter. Common methods include affinity mapping (clustering related notes together), creating user personas, and writing up "how might we" questions that frame the design problem clearly.

This phase is often less visible than the design work, but it is where a lot of the thinking happens. Getting it wrong here means solving the wrong problem - which is expensive to fix later.

### Workshops and collaboration

UX designers regularly run workshops with colleagues: product managers, engineers, marketers, customer service teams. The goal is usually to align on a problem, generate ideas together, or get buy-in on a direction.

You do not need a background in facilitation, but you do need to get comfortable running a room. Workshops range from short ideation sessions ("let's all sketch solutions for 20 minutes") to longer design sprints that compress weeks of work into a few days.

### User flows and information architecture

Before you start designing individual screens, you need to map out the overall structure of the experience. This means:

- **User flows**: step-by-step diagrams showing how a user moves through a product to complete a task
- **Information architecture**: how content and features are organised and labelled, so users can find what they need

These are often created in tools like Figma or Miro, and they look deceptively simple. Getting them right requires holding a lot of complexity in your head: what the user knows at each step, what they are trying to do, and where things could go wrong.

### Wireframing

Wireframes are low-fidelity sketches of screens - no colour, no final copy, no polished visuals. They show layout, structure, and basic content hierarchy, without the distractions of a finished design.

Good wireframing is fast and disposable. The point is to explore options quickly and get feedback before you invest time in a high-fidelity design. You might go through five or six versions of a layout before one feels right.

### Prototyping

A prototype is a clickable, interactive version of your design that simulates how the final product will work. It does not need to be built in code - Figma prototypes are the industry standard, and they let you connect screens together, add transitions, and create a realistic user experience without involving engineers.

Prototypes range from very rough (a few screens linked together to test a single flow) to near-production quality (a fully interactive mock-up that looks finished). The level of fidelity depends on what you are trying to learn.

### Usability testing

Once you have a prototype, you test it with real users. Usability testing is not about asking "do you like it?" - it is about watching people try to complete tasks and seeing where they get stuck, confused, or frustrated.

A typical session lasts 30-60 minutes. You observe, take notes, and resist the urge to help when a participant struggles (that struggle is the data). Afterwards, you synthesise the findings and use them to improve the design.

This cycle - design, test, learn, revise - can repeat many times before a feature ships.

### Design reviews and handoff

When a design is ready to move forward, it goes through review. That might mean a critique with other designers, a sign-off conversation with your product manager, or a presentation to senior stakeholders.

After sign-off, you work with engineers to hand over the design. In Figma, that means annotating your designs with specifications: spacing, typography, interaction states, edge cases. Good handoff documentation saves a lot of back-and-forth during development.

### Meetings and collaboration (the unglamorous part)

UX designers sit at the intersection of product, engineering, and business. That means a fair number of meetings: sprint planning, roadmap reviews, stakeholder check-ins, cross-functional syncs.

Some of this is genuinely useful. Some of it is overhead. The ratio depends heavily on the company culture. Either way, it is part of the job - the ability to communicate your thinking clearly to non-designers is as important as the design work itself.

---

## How the role varies by company size

One of the most misunderstood things about UX design is how different it looks depending on where you work.

**At a startup**, you will probably be a generalist. Research, wireframing, prototyping, usability testing, visual polish - it all lands on you. You might also be doing some UI design, writing UX copy, and feeding into product strategy. The scope is wide, the resources are limited, and you will learn quickly.

**At a mid-size company**, there is usually more structure. You will have a team, possibly a design system, and clearer processes. There is more room to go deep on individual projects.

**At a large tech company**, UX roles often specialise. You might be a UX researcher who does not design screens at all. Or a product designer focused narrowly on a single part of a complex product. Collaboration with engineers and product managers is more formal, and the pace of change is slower.

Neither is better. They suit different working styles. If you like variety and autonomy, a startup or agency might appeal. If you prefer depth, clear process, and a strong design team to learn from, a larger company may be a better fit.

For more on how UX and UI responsibilities split across these contexts, [this post on UX vs UI design](/blog/ux-vs-ui-design/) covers the distinction in detail.

---

## How seniority changes the work

**Junior designers** tend to focus on execution - taking a problem that has been framed for them and producing good design work. The expectation is strong craft skills and a willingness to take direction and iterate.

**Mid-level designers** are expected to own problems end to end: frame the problem through research, design the solution, test it, and ship it with limited supervision.

**Senior designers** spend more time in ambiguity - they help define what the right problems are, influence product strategy, mentor others, and make the case for design investment at a leadership level. The work shifts from "producing designs" to "shaping how the team thinks about design."

---

## What UX designers typically do NOT do

A few things that often come up in job ads, but are not always part of the UX role:

- **Graphic design or brand work.** UX design is about how things work. Visual design - brand identity, illustration, marketing materials - is a different discipline, though the skills can overlap.
- **Front-end development.** Most UX designers do not write production code. A basic understanding of HTML and CSS is useful context, but it is not a requirement.
- **Writing all the product copy.** UX designers often write placeholder copy and may have input on tone, but dedicated content designers or copywriters usually own the final words.
- **Running the business.** You are not responsible for deciding what to build - that sits with product managers. You are responsible for designing it well, advocating for users, and flagging when a proposed direction has problems.

---

## The tools of the trade

Figma is the industry standard for wireframing, prototyping, and design handoff - almost every UX team uses it. For a full breakdown of what is in a practising designer's toolkit, see our guide to [UX design tools](/resources/). Beyond that:

- **Miro or FigJam** for workshops, affinity mapping, and journey mapping
- **Maze, Maze, or UsabilityHub** for remote usability testing
- **Notion or Confluence** for documentation
- **Slack and Jira** for communication and project tracking

Tools change. The underlying skills - research, problem-framing, clear communication, design judgment - do not. If you are learning UX today, focus on those, not on becoming a Figma power user from day one.

---

## Is this the right career for you?

UX design suits people who are curious about how other people think, comfortable sitting with ambiguity, and good at explaining their reasoning. You do not need a design degree or a technical background - many of the best UX designers came from psychology, teaching, customer service, marketing, or other fields entirely.

If you are wondering whether it is a good career move financially and professionally, [this post on whether UX design is a good career](/blog/is-ux-design-a-good-career/) covers demand, salaries, and realistic timelines.

---

## Ready to go deeper?

If this picture of the day-to-day resonates, the next step is seeing it in practice. At UX Academy (myuxacademy.com), our free UX/UI masterclass walks you through a live design challenge so you can experience the process - not just read about it.

[Join the free masterclass](/masterclass/free-ux-ui-masterclass/) and see what the work actually feels like.

Or if you are ready to explore the full programme, [take a look at our courses](/courses/) - including the [Beginner UX (AI) Design course](/courses/beginner-ux-design/), taught by our lead instructor, Natalia Veretenyk, and her team, which is built for people making exactly this kind of career change.


---

# UX Research in Agile Development: Keeping Up

URL: https://myuxacademy.com/blog/ux-research-agile-development/
Learn how to run effective UX research inside agile sprints - from continuous discovery to dual-track agile - without becoming a bottleneck.

Agile development moves fast. Two-week sprints, daily standups, pressure to ship. For UX researchers and designers, that pace creates a genuine tension: good research takes time, but the team cannot wait three weeks for a findings report before deciding what to build next.

This is one of the most common frustrations for UX practitioners working in product teams. You either rush the research and it feels hollow, or you do it properly and miss the sprint. Neither is acceptable.

The good news is that neither outcome is inevitable. Teams that handle this well have stopped treating research as a gate - something that happens before development - and started treating it as a continuous thread running alongside delivery. This post explains how that works in practice.

## Why research and agile feel like they conflict

The tension is real, not imagined. Traditional waterfall research assumed you had months to study users, synthesise findings, and inform a detailed specification before a line of code was written. Agile compresses that. It assumes requirements will evolve, that learning happens through shipping, and that the team adapts in short cycles.

Those are not incompatible with research. But they do require a different mindset. Research in agile is not about producing a comprehensive report that justifies a design decision. It is about generating just enough insight, fast enough, to inform the next decision. The standard shifts from "complete understanding" to "reduced uncertainty."

That shift makes many trained researchers uncomfortable. It should. Done badly, it becomes an excuse for skipping rigorous work. Done well, it is a discipline of its own.

## Lean research: smaller, faster, still valid

Lean UX research is not sloppy research. It is research scoped tightly to a specific question, run at a cadence that matches the team's decision cycle.

The core principle is: define the most important assumption the team is currently making, then find the fastest way to test it. If the assumption is "users will understand this new navigation without explanation," you do not need a six-week diary study. You need five usability sessions, or an unmoderated test with a prototype, run this week.

Some methods that work well inside agile (for a broader overview of research approaches, see our guide to [UX research methods](/blog/ux-research-methods/)):

**Guerrilla testing.** Informal sessions in a cafe, at a desk, or via a quick video call. Not a replacement for rigorous research, but genuinely useful for fast directional feedback on a prototype or concept. Five participants in two hours will surface most critical usability failures. If even that is too slow, a [heuristic evaluation](/blog/heuristic-evaluation-ux-design/) - a structured expert review against established usability principles - can identify likely friction points in hours without recruiting participants at all.

**Unmoderated remote testing.** Tools that let you send a prototype to users who complete tasks and record themselves. You get results in 24-48 hours. The data is shallower than a moderated session, but the speed is unmatched when you need a quick read on a specific interaction.

**Lightweight interviews.** A 30-minute conversation with two or three users per week, focused on a specific decision the team faces. This is not exploratory research - it is targeted. You go in with a clear question and you come out with a directional answer.

**Analytics and session recordings.** Not a substitute for speaking to users, but a fast way to identify where behaviour deviates from expectation. If a page has an 80 percent drop-off, that is a research question waiting to be asked.

None of these methods replace deeper qualitative or quantitative work. But they keep research alive inside a fast-moving team without requiring the team to stop and wait.

## Continuous discovery: research as a habit, not an event

Teresa Torres popularised the term "continuous discovery" to describe a practice where the team maintains an ongoing cadence of user contact - typically weekly - rather than running occasional research projects. The aim is to make user insight a constant input to product decisions rather than a periodic report.

In practice this often means one or two short user conversations every week, with the researcher sharing a brief summary at the sprint review or in a shared Slack channel. Over time, the team builds a richer picture without any single research effort needing to carry all the weight.

This approach works because it changes the relationship between research and decision-making. When the team knows there will be more user conversations next week, they feel less pressure to over-engineer the current round. Research becomes a conversation rather than a verdict.

The challenge is maintaining the discipline. Weekly user conversations require a pipeline of willing participants, a lightweight process for recruiting and scheduling, and a team that actually reads the summaries. If those conditions are not in place, continuous discovery becomes a well-intentioned idea that quietly dies after two months.

## Dual-track agile: separating discovery from delivery

One of the most useful structural ideas for UX in agile teams is dual-track agile. The concept is simple: run a discovery track and a delivery track in parallel, with the discovery track always a sprint or two ahead of delivery.

In the delivery track, engineers are building features that have already been validated through research and design. In the discovery track, the UX team is exploring and testing the ideas that will feed the next round of delivery.

This separates the two timelines that keep colliding in single-track agile. Discovery does not block delivery; delivery does not rush discovery. Each track has its own cadence.

In practice, dual-track requires genuine buy-in from product and engineering leadership. It means accepting that not everything in the discovery track will make it into delivery - some ideas will be invalidated and discarded. Teams that have not made peace with that find the discovery track gradually squeezed out when delivery pressure rises.

The model also requires a researcher or designer who is confident enough to say "we do not have enough evidence to build this yet" - and a product manager who will back that position with stakeholders. That combination is less common than it should be.

For more on how UX design integrates with product and engineering work, the [Advanced UX Design course](/courses/advanced-ux-design/) at UX Academy covers this in depth, including how to navigate team dynamics and research prioritisation inside real product organisations.

## Collaborating with product managers and engineers

Research findings that sit in a Figma file or a shared doc are not research findings. They are good intentions. The work only matters if it changes what the team builds.

That means UX researchers need to build relationships with product managers and engineers, not just hand over outputs. A product manager who trusts the researcher's judgement will defend research time in sprint planning. One who sees research as a black box that produces slide decks will deprioritise it the moment the roadmap gets tight.

Some practical things that help:

**Involve engineers in research sessions.** Even one session per quarter where an engineer watches a user struggle with a feature changes how they think about design decisions. It is hard to dismiss usability issues you have witnessed yourself.

**Translate findings into decisions, not observations.** "Users were confused by the terminology" is an observation. "We should replace 'workspace' with 'project' throughout the interface" is a decision. Give the team something they can act on without another meeting.

**Be honest about confidence levels.** If you ran three sessions and have a directional hypothesis, say so. Do not present it as settled. Teams that trust researchers trust them because they have been honest about the limits of their data.

**Attend sprint planning.** If you want research to influence what gets built, you need to be in the room where priorities are set. That means understanding the constraints the product manager is working with and being ready to make a case for why a specific research question is worth time.

## Common pitfalls

**Research theatre.** Running research to satisfy a process requirement rather than to answer a genuine question. The team goes through the motions, a report gets written, nothing changes. This is worse than not doing research because it creates the illusion that user needs have been considered.

**No time to act on findings.** Research that surfaces a critical usability problem two days before a feature ships has limited value. Build in lead time. If findings need to influence a sprint, they need to exist before sprint planning.

**Asking the wrong question.** Fast research on the wrong topic is still a waste. Before running any study, ask: what decision will this inform, and is that decision actually on the table? If the decision is already made, you are doing archaeology, not research.

**Over-relying on quantitative data.** Analytics tell you what is happening. They do not tell you why. Teams that optimise heavily on metrics without qualitative research often fix the wrong thing efficiently.

**Letting discovery die under delivery pressure.** The dual-track model requires protection. When a release is approaching and everyone is heads down, the discovery track is the first thing to go. Build it into team agreements, not just good intentions.

## What this looks like in a junior role

If you are early in your UX career and joining an agile product team, you will likely find yourself navigating some version of these pressures from day one. Teams vary enormously in how much they value research. Some have a mature continuous discovery practice; others treat research as an occasional luxury.

Your job is to make research useful and visible without becoming a bottleneck. That means being pragmatic about methods, honest about what the data can and cannot tell you, and relentless about connecting insights to decisions.

It also means learning when to push back. "We do not have time to talk to users" is sometimes true and sometimes a habit. Part of your value as a UX practitioner is helping the team understand the cost of building on assumptions - and offering a fast, proportionate alternative to filling that gap.

If you want to see how this works in practice before you are in a job, the free [UX/UI masterclass at UX Academy](/masterclass/free-ux-ui-masterclass/) covers live product team dynamics alongside research and design fundamentals.

For a broader grounding in the discipline - including how to structure research approaches for different types of projects - explore the [UX Academy courses](/courses/) or read more on [what UX design actually involves](/blog/what-is-ux-design/), the [UX design process](/blog/ux-design-process/) end to end, and how [data shapes UX decisions](/blog/data-driven-ux-design/).

---

UX Academy (myuxacademy.com) runs live online UX design training for career-changers, led by our lead instructor, Natalia Veretenyk, and her team. We are not affiliated with Designlab or any other provider using similar names. Our [price-match guarantee](/courses/) applies to comparable live-taught courses.


---

# How to Get a UX Job With No Experience (A Practical Guide)

URL: https://myuxacademy.com/blog/ux-job-with-no-experience/
No UX experience yet? Here's how to build real skills, create a portfolio that gets interviews, and land your first junior UX role in the UK.

Breaking into UX without experience feels like a catch-22. Employers want someone who has done the work. But you cannot do the work without someone giving you the chance. It is one of the most common things career-changers say to us, and it is a genuine frustration - not an excuse.

The good news: the catch-22 is solvable. You do not need a previous UX job title to demonstrate UX thinking. You need evidence of the process, the decisions, and the outcome. This post explains how to build that evidence from scratch.

This guide focuses on landing that first role without experience; for the full path from zero knowledge, see our main guide on [how to become a UX designer](/blog/how-to-become-a-ux-designer/).

## The Chicken-and-Egg Problem - and How to Break It

The reason the loop exists is that hiring managers are risk-averse. A junior hire who turns out to be a bad fit costs time and goodwill. They want signal that you can do the work before they pay you to do it.

The answer is not to fake the signal. It is to create real signal outside a job.

That means real projects. Real briefs. Real constraints. Real decisions documented honestly. When a recruiter asks "have you done this before?", your answer is "yes - here, let me show you."

Everything that follows is about how to build that proof.

## Build Real Experience Before You Have a Job

**Structured learning with live briefs**

The fastest route to genuine experience is a course that puts you on real design problems rather than theoretical exercises. At UX Academy (myuxacademy.com), our [Beginner UX (AI) Design course](/courses/beginner-ux-design/) is built around exactly that: you work on real briefs with structured mentor feedback, not isolated tutorials. By the time you finish, you have documented case studies from work that was actually hard - not a series of polished but hollow mockups.

When you are evaluating any course, ask: will I produce case studies I can show a hiring manager? If the answer is vague, treat that as a warning sign. It is also worth checking that the school you choose is financially stable - CareerFoundry, one of the larger online UX providers, closed in early 2026 and left students mid-course; see our [CareerFoundry alternative](/careerfoundry-alternative/) page for more background.

**Redesign case studies**

Pick an app or website you use regularly and find something genuinely broken about it. Not "I do not like the colour scheme" - something with a real usability problem or unmet user need. Then run a lightweight version of the UX process: heuristic review, a handful of user interviews, synthesis, wireframes, prototype, test.

Document every step. The decisions are what matter most. Why did you frame the problem the way you did? What did you discover that surprised you? What did you try that did not work?

A well-documented redesign case study demonstrates more competence than a portfolio of beautiful screens with no context.

**Volunteering and pro bono work**

Charities, community groups, and early-stage startups often need UX help and cannot afford to pay for it. Offer to do a usability review or a discovery sprint in exchange for a real brief and permission to include the work in your portfolio.

The brief matters. An unpaid project where you had real constraints, a real stakeholder, and had to make real trade-offs is worth far more than a polished fictional project with no pressure on it.

**Freelance micro-projects**

You do not need to position yourself as a full-service UX consultant. Small, scoped pieces of work - a usability audit, a set of user interview sessions, a set of annotated wireframes - are achievable early on and genuinely useful to small businesses. Platforms like Contra and Worksome can be a starting point, or you can reach out directly to businesses you have a connection to.

Charge something, even a small amount. It changes the dynamic and teaches you how to manage client relationships, which is a real skill.

## Build a Portfolio That Shows Your Thinking

Most early portfolios make the same mistake: they lead with the finished design and bury the thinking. Hiring managers, especially those who will interview you, care deeply about how you got there.

**Structure each case study around decisions**

For every project, answer these questions clearly:
- What was the problem, and how did you know it was the right problem to solve?
- What did you find out from research that changed your direction?
- What options did you consider, and why did you choose the one you did?
- What would you do differently next time?

That last question is important. Showing that you can critique your own work demonstrates maturity. It also makes your case study feel honest rather than like a sales pitch.

**Show your process, not just the output**

Include rough sketches, early wireframes, synthesis notes, and test findings alongside the finished designs. Process screenshots from Figma, photos of sticky notes from an affinity mapping session, excerpts from user interview notes - these are all evidence.

The polish of the final design is less important than the rigour of what came before it. A recruiter looking at two portfolios will often be more impressed by the one that shows real thinking than the one with the better visual execution.

**Keep it focused**

Two or three strong case studies beat eight thin ones. If you have more projects than that, pick the ones where you made the most interesting decisions and where the outcome is clearest.

For a deeper walkthrough of portfolio structure, our post on [building a UX design portfolio](/blog/ux-design-portfolio-guide/) covers this in detail. If you are building from nothing, [how to build a UX portfolio from scratch](/blog/how-to-build-a-ux-portfolio-from-scratch/) walks through the exact steps. And if you want to calibrate what a strong early-career portfolio looks like, [UX design portfolio examples](/blog/ux-design-portfolio-examples/) shows real-world benchmarks.

## Network Without Being Annoying About It

Most junior UX roles are not filled through job boards. They come through warm introductions, people who remember a conversation, or candidates who reached out before a role was even posted.

This does not mean you need to spam LinkedIn connections with templates. It means showing up in the spaces where UX practitioners gather and being genuinely useful or curious.

- Attend UX events (many are free - UX Brighton, Design Swansea, local meetups, Eventbrite has dozens)
- Contribute to Slack communities like UX Mastery, Designer Hangout, or ADPList
- Comment thoughtfully on articles and case studies, not just "great post"
- Ask for a 20-minute conversation with someone doing the role you want, with specific questions - not "pick your brain" (everyone hates that phrase)

The goal is not to collect contacts. It is to have real conversations that make you a known quantity in the field. When someone in your network hears of a junior role, you want to be the person who comes to mind.

## Target the Right Roles

**Junior UX Designer** is the obvious target, but competition is high and many junior postings are aimed at people who already have some commercial experience.

**UX-adjacent roles** are often an easier first step and give you real commercial experience fast:

- **UX researcher** - if your background is in psychology, social science, or market research, this is a natural bridge
- **Content designer or UX writer** - if you have writing skills, this is undervalued and increasingly essential in product teams
- **Product analyst or data analyst** - if you are comfortable with data, this puts you inside a product team where you can start influencing UX decisions
- **UX coordinator or research ops** - less common but genuinely useful for getting inside the discipline

Once you are inside a product organisation, internal moves to a UX designer role are far easier than trying to enter from outside.

Our post on [switching careers to UX design](/blog/switching-careers-to-ux-design/) has more on how to frame your existing skills as UX-relevant rather than irrelevant baggage.

## Tailor Every Application

Generic applications for junior roles get ignored. There are too many of them.

Before you apply, read the job description carefully and identify:
1. What problem is this company trying to solve with this hire?
2. What does the hiring manager actually care about - research rigour, collaboration with developers, visual execution?
3. What in my portfolio is most relevant to this specific context?

Then tailor your cover letter to answer those questions directly. Lead with the most relevant case study. Reference their product or service specifically. Show that you have thought about their users, not just UX in the abstract.

It takes longer. It is worth it.

## Be Honest About the Market

The junior UX market is competitive. That is not a reason to give up - it is a reason to be strategic and patient.

Most career-changers who land their first UX role do so after 6-12 months of deliberate effort: building, applying, refining, applying again. Our guide to [UX design jobs in the UK](/blog/ux-design-jobs-uk/) covers where roles are advertised, what hiring managers are looking for, and how the market is shaping up in 2026. Rejection is not usually a signal that you are wrong for the field. It is often a signal that your portfolio needs another strong case study, or that your applications need more tailoring, or that you are targeting companies that rarely hire juniors.

The people who succeed tend to have three things in common: they keep building, they ask for honest feedback rather than validation, and they stay in the community even when it is discouraging.

None of that is glamorous advice. But it is the accurate version.

For a realistic timeline on how long the overall journey takes, our post on [how long it takes to become a UX designer](/blog/how-long-to-become-a-ux-designer/) sets honest expectations.

## The Short Version

The experience catch-22 is real but breakable. Build real projects through structured learning, volunteering, or scoped freelance work. Document your process and decisions, not just your outputs. Target the right roles - including UX-adjacent ones - and tailor every application. Show up in the community consistently.

A job title does not make you a UX designer. Doing the work does. Start doing the work now.

---

If you want to build the foundations properly, our [free UX masterclass](/masterclass/free-ux-ui-masterclass/) is a good place to start - no commitment, just a solid grounding in what UX actually involves and whether it is the right move for you. The full Beginner UX (AI) Design course is taught live by our lead instructor, Natalia Veretenyk, and her team.


---

# Can You Be a UX Designer If You Are Not Creative?

URL: https://myuxacademy.com/blog/ux-designer-without-being-creative/
Think UX design requires artistic talent? It does not. Here is what UX actually rewards and why your non-design background is more relevant than you think.

## The question almost everyone asks before switching to UX

You have been reading about UX design as a career. The role sounds genuinely interesting - understanding users, solving problems, making digital products easier to use. But then a quiet doubt creeps in.

"I am not creative. I cannot draw. I have no eye for design. Is this even possible for someone like me?"

If that is you, you are in good company. It is probably the single most common concern we hear from people considering a career change into UX. And the honest answer is: the concern is based on a misunderstanding of what UX design actually is.

Let us clear that up properly.

## What most people mean when they say "creative"

When people say they are not creative, they usually mean one of two things. Either they cannot draw or paint to a high standard, or they do not have a natural instinct for colour, typography, and layout.

That is artistic skill. It is real, it is learnable, and some designers have it in abundance. But it is not what makes someone a good UX designer.

UX design - user experience design - is fundamentally about understanding how people think, what they need, and why they get confused or frustrated. It is about research, logic, and structured problem-solving. You are building a case for decisions, not painting a canvas.

The field has its own word for the artistic side: UI design, or user interface design. UI is about how things look. UX is about how things work and how they feel to use. In practice the two overlap, and many practitioners do both. If you want a clearer picture of where [UX design and graphic design differ](/blog/ux-design-vs-graphic-design/), that distinction is worth understanding before you start. But if you are wondering whether you need a fine arts background to get into UX, the answer is clearly no.

## What UX design actually rewards

Here is what experienced UX designers, hiring managers, and bootcamp graduates consistently say matters most in practice:

**Curiosity about people.** Why did that user click the wrong button? What were they actually trying to do? What assumptions did the designer make that turned out to be wrong? UX designers who ask these questions obsessively - and who are genuinely interested in the answers - tend to do well.

**Empathy.** The ability to hold someone else's mental model in your head. To look at a screen through their eyes rather than the designer's. This is not a soft skill in the dismissive sense; it is the core cognitive task of user research.

**Logical problem-solving.** Every design project is a constraint satisfaction problem. You have user needs, business requirements, technical limitations, and accessibility obligations. You have to find solutions that work across all of them. This is analytical work.

**Structured communication.** UX designers spend a large proportion of their time writing - user research reports, usability findings, design rationale documents. They also present their work to stakeholders and explain why one design decision is better than another. Clear, organised thinking communicated well is essential.

**Systematic research skills.** Interviewing users, writing discussion guides, synthesising findings, identifying patterns, avoiding confirmation bias. These are research skills, not art skills.

**Attention to detail.** The difference between a frustrating user experience and a smooth one is often tiny - a label that is slightly ambiguous, a button that is in the wrong place, a form that asks for information in the wrong order. Noticing these things requires care and precision.

Does any of that sound like it requires a background in fine art? None of it does.

## Where your existing career actually transfers

Career changers often underestimate how much they already know that is relevant to UX.

If you have worked in customer service, you have spent years listening to what people actually need versus what they say they need. You have developed a thick skin for honest feedback. You know how systems fail real people.

If you have worked in project management or operations, you know how to break a complex problem into steps, manage competing priorities, and communicate with different stakeholders using different registers. That is a core UX workflow.

If you have worked in healthcare, teaching, or social work, you have deep practice in understanding how people from different backgrounds experience situations differently. You know that the expert's view of a system and the user's experience of it are often completely different things.

If you have a background in marketing or research, you already understand how to design studies, gather data, and make evidence-based recommendations. You know how to frame insights for a business audience.

If you have come from finance, law, or consulting, you are used to building structured arguments and handling ambiguity rigorously. UX design needs exactly that.

The [career-change path into UX](/blog/switching-careers-to-ux-design/) is well-trodden precisely because so many skills transfer. The people who struggle most with UX are not the ones who cannot draw - they are the ones who are not genuinely curious about users, or who resist questioning their own assumptions.

## The honest part: what you do need to learn

It would not be fair to tell you that nothing new is required. There are specific things you will need to pick up:

**UX methods and process.** How to run a user interview properly. How to build a usability testing plan. How to create wireframes and prototypes. How to run a heuristic evaluation. These are learnable skills with clear techniques - they are not innate gifts.

**Design tools.** Figma is the industry standard. You will need to get comfortable using it to create wireframes and interactive prototypes. Figma has a gentle learning curve - most people with no prior experience can produce working prototypes within a few weeks of consistent practice.

**Visual design fundamentals.** Notice this is "fundamentals", not "fine art". You need to understand the basic principles of layout, hierarchy, spacing, and contrast well enough to create clean wireframes and to work alongside UI designers. You do not need to produce polished visual design yourself, though many UX designers do develop that skill over time.

**Research synthesis.** Taking raw notes from five user interviews and turning them into three clear, actionable insights is harder than it sounds. It is a skill you develop through practice and feedback.

**Stakeholder communication.** Presenting design decisions in a way that connects user needs to business goals. This is different from presenting to a supportive audience - you often need to defend a design choice against pushback from someone who has not read the research.

None of this requires artistic talent. All of it is teachable. If you are wondering what a structured path through these skills looks like, have a look at our [Beginner UX (AI) Design course](/courses/beginner-ux-design/).

## The "creative problem-solving" reframe

There is one sense in which UX design absolutely is creative, and it is worth naming directly.

When you are given a problem - "our checkout abandonment rate is high and we do not know why" or "users keep missing the navigation on mobile" - you need to generate hypotheses, design research to test them, and then come up with solutions that are not obvious. That requires creative thinking.

But this kind of creativity is not the same as artistic creativity. It is the creativity of a detective piecing together evidence. Or a scientist designing an experiment. Or a consultant seeing the structural issue behind a client's stated problem. If you have done any of those things - even informally - you have the creative capacity that UX needs.

The myth that UX requires artistic talent does real harm. It puts off exactly the kind of people who would be excellent UX designers: methodical thinkers, strong communicators, people with genuine curiosity about human behaviour. If you have spent the last ten years in a career that rewards analytical rigour, clear communication, and understanding people, you are not starting from scratch. You are starting with a significant advantage.

## Where visual craft does matter (and where it does not)

To be clear-eyed about this: if you want to work specifically as a UI designer - the person responsible for the final visual appearance of a product - then visual talent and a developed aesthetic sense do matter more. UI design is closer to graphic design. Many people find it deeply satisfying and build strong careers in it. If you are assessing your career prospects across these roles, our guide to [UX design jobs in the UK](/blog/ux-design-jobs-uk/) covers what employers are actually hiring for.

But UX design as a discipline is not UI design. A UX researcher, a service designer, a UX writer, a product designer focused on information architecture - none of these roles require you to produce beautiful visuals. What they require is the ability to understand a user problem well enough to design a good solution.

You can read more about what the field covers in our [introduction to UX design](/blog/what-is-ux-design/) if you want a fuller picture of the different directions a UX career can take.

## What to do if you are still not sure

The best way to test whether UX design is right for you is not to read more articles about it - it is to try it.

At [UX Academy](https://myuxacademy.com) we run a free live online masterclass specifically designed for people who are considering a career change into UX. It is practical, not a sales pitch. You will get a real sense of what the work involves, how UX designers think, and whether it fits the way your mind works. You can [book a place here](/masterclass/free-ux-ui-masterclass/).

If you are ready to go further, our [Beginner UX (AI) Design course](/courses/beginner-ux-design/) is built for people with no prior design experience. It covers research, wireframing, prototyping, and the design process from scratch, taught by our lead instructor, Natalia Veretenyk, and her team - with live teaching and real feedback on your work, not recorded videos you watch alone.

You do not need to be artistic. You need to be curious, analytical, and willing to question your own assumptions. If you have those things, the rest is learnable.


---

# UX Designer Salary UK 2026: What You Can Really Earn

URL: https://myuxacademy.com/blog/ux-designer-salary-uk/
Verified UK UX designer salary data by experience band and location - from entry level to senior London roles - with sources named for every figure.

**The median UK UX designer salary is £55,000 (ITJobsWatch, vacancy data to June 2026) - roughly 41% above the UK median full-time salary of £39,039 (ONS ASHE 2025). For a career change, that gap matters.**

Whether you search for it as UX designer salary, salary of UX designer, or user experience designer salary, the underlying figures are the same: this page tracks them by experience band, location, sector, and contract rate, with every number sourced. Data compiled and reviewed by the team at **UX Academy (myuxacademy.com)**.

**Key UK UX salary figures at a glance (2026):**

- **UK median (all levels):** £55,000 — ITJobsWatch, vacancy data to June 2026
- **Entry level (0-2 yrs):** £24,000-£38,000 (£28,000-£38,000 in London) — Morgan McKinley 2026
- **Mid level (2-5 yrs):** £35,000-£58,000 (£42,000-£58,000 in London) — Morgan McKinley 2026
- **Senior (5+ yrs):** £50,000-£85,000 (£60,000-£85,000 in London) — Morgan McKinley 2026
- **London premium:** roughly 15-25% above equivalent roles outside London
- **Contractor day rate (senior):** £500-£700/day; principal/lead £700-£1,000/day

## How much do UX designers get paid in the UK?

UX designers in the UK are paid a median of **£55,000** (ITJobsWatch, vacancy data to June 2026) — around 41% above the UK median full-time salary of £39,039 (ONS ASHE 2025). Pay ranges from roughly £24,000 at entry level to £130,000+ at principal or Head of UX level, with London roles paying 15-25% more than equivalent roles elsewhere. The full breakdown by experience band, location, sector, and contract rate follows below.

## What is the starting salary for a junior UX designer in the UK?

A junior UX designer in the UK typically starts on **£28,000-£38,000 in London** or **£24,000-£32,000 outside London**, according to the Morgan McKinley 2026 UK Digital Salary Guide. At this stage, portfolio quality matters more than years of experience — a strong portfolio with one year of relevant work can command a higher starting salary than a weak one with three years behind it. Most junior designers reach mid-level pay within two to three years.

## Do UX designers earn more in London?

Yes — London-based UX designers typically earn **15-25% more** than equivalent roles elsewhere in the UK, according to the Morgan McKinley 2026 UK Digital Salary Guide (for example, senior London UX pay of £60,000-£85,000 versus £50,000-£68,000 outside London). Remote-first roles have complicated this since 2020: some London-listed roles pay London salaries UK-wide, others apply location-adjusted pay, so it is worth checking which model a specific listing uses. Cities such as Manchester, Bristol, Edinburgh, and Birmingham have growing UX markets with solid pay and lower living costs than London.

## UX designer salary UK: table by experience band

The sources below measure different things - job-ad vacancy rates, self-reported surveys, and placement data - so treat each figure in its own context. A one-line method note sits below the table.

| Band | London | Outside London | Source |
|---|---|---|---|
| Entry level (0-2 yrs) | £28,000-£38,000 | £24,000-£32,000 | Morgan McKinley 2026 |
| Mid level (2-5 yrs) | £42,000-£58,000 | £35,000-£50,000 | Morgan McKinley 2026 |
| Senior (5+ yrs) | £60,000-£85,000 | £50,000-£68,000 | Morgan McKinley 2026 |
| Principal / Lead / Head of UX | £85,000-£130,000+ | varies | Morgan McKinley 2026 |
| UK-wide median (all levels) | £55,000 | - | ITJobsWatch, Jun 2026 |
| Average advertised (all levels) | £52,000 | - | Reed.co.uk, 2025 |
| ONS ASHE median (SOC 2137) | £39,100 | - | ONS ASHE 2024 |

**A note on the ONS figure:** the ONS ASHE £39,100 median covers SOC 2137 "Graphic and UX designers" — a combined category that includes graphic designers, many of whom earn less than UX specialists. Treat it as the market floor, not the midpoint for UX roles specifically.

**London vs regional:** London roles command roughly 15 to 25 per cent more than equivalent roles outside the capital. Major cities — Manchester, Bristol, Edinburgh, Birmingham — have growing UX markets and solid pay without London costs.

**Methodology note:** these sources each measure a different slice of the market. ITJobsWatch counts advertised vacancies and is the most current signal. Reed.co.uk reports average listed salaries. Morgan McKinley surveys placed candidates. ONS ASHE is a broad employment survey covering a mixed category. None is a complete picture on its own; read them together.

For the full sourced dataset behind these numbers — salary percentiles, medians by job title and region, and the skills employers advertise alongside UX — see our [UK UX Careers Report](/uk-ux-careers-report/), updated annually.

---

## By experience band

### Entry level (0-2 years)

Entry-level UX designers in London typically earn **£28,000-£38,000**; outside London the range is **£24,000-£32,000** (Morgan McKinley 2026 UK Digital Salary Guide). The UK-wide average advertised salary across all UX levels is £52,000 (Reed.co.uk, 2025), which sets a useful anchor for what to aim toward. At this stage the portfolio is the primary lever on starting pay — a strong portfolio with one year of relevant work can outperform a thin one with three years.

Many people coming from lower-paid roles find even entry UX pay a meaningful step up. For those coming from well-paid careers, it is a short-term step back with a clear trajectory upward.

### Mid level (2-5 years)

Mid-level UX designers earn **£42,000-£58,000** in London and **£35,000-£50,000** outside London (Morgan McKinley 2026). The UK-wide median across all locations is **£55,000** (ITJobsWatch, vacancy data to June 2026) — this is the most reliable current benchmark for the profession as a whole. This is where the profession starts to feel comfortable financially, particularly outside London. At this level employers expect you to run projects with limited supervision, lead research sessions, and present your thinking to stakeholders without hand-holding.

### Senior level (5+ years)

Senior UX designers in London with five or more years of experience typically earn **£60,000-£85,000**, according to the Morgan McKinley 2026 UK Digital Salary Guide. Outside London, the equivalent band is **£50,000-£68,000**. At this level you are shaping how a team works, contributing to research strategy, and usually mentoring more junior colleagues.

Lead, principal, and Head of UX roles — which sit above the senior band at larger organisations — typically earn **£85,000-£130,000+** (Morgan McKinley 2026), particularly in fintech and enterprise SaaS where demand for experienced design leadership remains strong.

---

## By location

London roles in UX design typically pay noticeably more than equivalent roles elsewhere in the UK — the premium is often cited at 15 to 25 per cent. The Morgan McKinley 2026 UK Digital Salary Guide puts senior London UX at £60,000-£85,000, compared with £50,000-£68,000 outside London — a gap that widens further at lead and head-of level.

Remote-first roles have complicated the picture since 2020. Some London-listed roles offer London salaries to fully remote workers anywhere in the UK; others apply location-adjusted pay. Read the listing carefully before assuming which model applies.

Cities outside London — Manchester, Bristol, Edinburgh, Birmingham — have growing UX markets and are genuinely viable alternatives if you are not based in the south-east.

---

## By sector

Salary ranges quoted above are averages across all industries. Sector matters a great deal in practice:

- **Financial services and fintech** pay the highest premiums. Senior UX designers in London working in banking, payments, or fintech can reach **£90,000+**, and demand for UX skills in regulated, complex product environments is consistently strong.
- **Agency vs in-house** — UX designers at agencies typically earn 5 to 10 per cent less than equivalent in-house roles. The trade-off is breadth of work and faster portfolio development.
- **NHS and public sector** typically pay 10 to 15 per cent below private-sector equivalents. Roles are more stable and often more mission-driven; pay progression follows structured pay scales rather than market negotiation.
- **Tech and enterprise SaaS** sit close to the market median with strong total compensation packages (equity, bonus, benefits) that are not reflected in base salary figures.

When comparing offers, check the full package — bonus, pension contribution, and remote flexibility — not just headline salary.

---

## Contractor and freelance day rates

Many experienced UX designers move into contract work for higher day rates, greater flexibility, or to maintain variety across clients. UK UX contractor day rates in 2026:

| Level | Typical day rate | Notes |
|---|---|---|
| Mid level (2-5 yrs) | £350-£500/day | Inside IR35 roles common at this level |
| Senior (5+ yrs) | £500-£700/day | Core London market rate |
| Principal / Lead | £700-£1,000/day | Specialist skills command upper end |

Financial services and fintech clients typically pay at or above the upper end of each band. Rates for outside-IR35 contracts are higher but come with greater tax and administrative overhead — factor in accountancy costs and the absence of employer pension and holiday pay.

Converting a day rate to annual: multiply by roughly 220 billable days (accounting for holidays, admin, and gaps between contracts). A £600/day rate equates to roughly £132,000 billed — though take-home will be substantially less after taxes, NI, and costs.

---

## Why did UX salaries dip year on year?

The ITJobsWatch median moved from around **£57,500 in 2025 to £55,000 in 2026** - a fall of roughly 4 per cent. This kind of softening is worth acknowledging rather than ignoring. The likely drivers:

- Tech sector hiring slowed in 2024-25, reducing competition for senior candidates.
- More UX professionals became available as redundancies hit US big tech with knock-on effects in the UK.
- Some companies merged UX and product design roles, compressing the title spread and pulling the median down.

The softening does not change the fundamental picture. A £55,000 median still sits 41% above the UK median full-time wage, and demand for UX skills - particularly for designers who work with AI-assisted products - remains strong heading into 2027.

---

## How to increase your UX salary

### Build a portfolio that shows outcomes

The biggest lever on your first salary - and each subsequent one - is portfolio quality. Employers want to see that you understood the problem, made considered decisions, and can articulate what changed as a result. Quantified outcomes help where you have them. Honest qualitative outcomes matter too. A strong portfolio with one year of experience routinely beats a thin one with five.

### Specialise deliberately

Generalism is fine early on. Research-heavy roles, interaction design for complex data, service design, and UX for regulated industries (finance, healthcare) all sit above the general market rate. Picking a specialism and building a visible body of work in it makes you easier to hire and easier to pay well.

### Negotiate - it is expected

Most initial offers have room. Research current vacancy rates before any conversation, know your number, and be prepared to make a case based on specific skills. The worst realistic outcome of a well-handled negotiation is that the offer stays where it was.

### Move intentionally

The fastest salary progression in most UX careers comes from moving roles at the right moments rather than waiting for annual reviews. This is not a reason to job-hop recklessly, but staying aware of the market - and not assuming loyalty alone will get you to senior pay - is worth building into your career planning from day one.

If you are further along and want a structured push into senior pay bands, [UX Strategy](/courses/ux-strategy/) is built for designers moving from mid-level toward senior, lead, and Head of UX roles.

---

## Further reading

- [UX design jobs UK: what the market looks like in 2026](/blog/ux-design-jobs-uk/) - job market overview, where roles are, and what employers are hiring for
- [Are UX bootcamps worth it?](/blog/are-ux-bootcamps-worth-it/) - the ROI case for structured training vs self-teaching
- [How to become a UX designer](/blog/how-to-become-a-ux-designer/) - the skills, portfolio, and job-search path
- [UX designer vs product designer](/blog/ux-designer-vs-product-designer/) - title differences, overlap, and pay implications

---

## Ready to start?

If you are working through the numbers on a career change into UX design, the short-term picture is an entry salary in the £24,000-£38,000 range (depending on location) — with a clear, well-trodden path to the £55,000 UK median and beyond.

> **Want a structured path from these numbers to your first UX role?** UX Academy (myuxacademy.com)'s [Beginner UX (AI) Design course](/courses/beginner-ux-design/) is 100% live online, small-group (max 15), and built for career-changers with no design background. Cohort 1 starts **<CohortDate />** — [reserve your place with a £99 refundable deposit](/courses/beginner-ux-design/). Not sure yet? [Book the free masterclass](/masterclass/free-ux-ui-masterclass/) first — one hour covering the career path, the skills, and what professional UX training actually looks like.


---

# UX Portfolio Guide: Structure & Strategy to Get Hired (2026)

URL: https://myuxacademy.com/blog/ux-design-portfolio-guide/
How to structure your UX portfolio to get interviews in 2026: case study format, what hiring managers look at, and how to present your work strategically.

If you are switching careers into UX design, you have probably heard the same advice repeated endlessly: "build a portfolio." What you hear far less often is what that actually means, what hiring managers are looking for, and how to build one when you have no client work yet.

This guide cuts through the noise. It covers what to include, how to structure case studies, what most junior portfolios get wrong, and how to present work that makes a real impression - even if you are [starting from zero](/blog/how-to-build-a-ux-portfolio-from-scratch/).

## Why Your Portfolio Matters More Than Your Certificate

Certificates confirm that you completed a course. A portfolio demonstrates that you can do the work.

Most UX roles - from junior designers at agencies to in-house product teams - ask for a portfolio link before they ask about qualifications. That is not an accident. Design is a practice-based discipline. Hiring managers want evidence that you can frame a problem, make decisions under constraint, and explain your reasoning clearly.

This does not mean certificates are worthless. Structured learning builds your vocabulary, your toolkit, and your confidence. But the certificate opens doors; the portfolio is what gets you through them.

A useful benchmark: when a hiring manager reviews a junior portfolio, they typically spend under five minutes on it. Your job is to make those five minutes count. If you want to see what good looks like in practice, our roundup of [UX design portfolio examples](/blog/ux-design-portfolio-examples/) shows real-world benchmarks across different experience levels, and the [UX Academy student work page](/student-work/) shows real portfolios built by career-changers on a live client brief.

## How Many Projects Should You Include?

The answer almost every working designer will give you is: fewer than you think.

Three to five strong, well-documented case studies are the target. Not eight half-finished projects. Not every concept you sketched during a course. Three focused pieces of work that show your process, your thinking, and your decisions.

The instinct to show everything is understandable - especially when you feel like you do not have much yet. Resist it. A portfolio padded with weak work signals a lack of editorial judgement, which is itself a design skill. Curate ruthlessly.

If you have done a live-course project with a real client brief (more on this below), that counts as your strongest piece and should lead your portfolio.

## What to Include in a Case Study

Each case study should tell a coherent story. The structure does not need to be rigid, but it should cover:

**The problem.** What were you trying to solve, and for whom? Describe the user need and the business or organisational context. If you inherited a brief, explain what was given to you and what questions you asked.

**Your process.** What research did you do? What methods did you use and why - not just "I did user interviews" but what you were trying to find out and what you learned. Show wireframes, affinity maps, journey maps, or sketches where they are relevant. Do not include every artefact - include the ones that shaped a decision. If you need a starting point for structuring research artefacts like [user personas](/resources/templates/user-persona/), there are templates that can help.

**The decisions you made.** This is the part most junior portfolios skip, and it is the most important section. What options did you consider? What did you choose and why? Where did you compromise? A candidate who can articulate a decision under constraint - "we had two weeks and three competing user needs, so I prioritised X because Y" - is far more compelling than one who presents a polished final screen with no context.

**The outcome.** What happened? If you tested your designs, what did you find? If the project was a course exercise, describe what you would do next if you had more time or resources. Honesty about limitations reads well.

One rule of thumb: if a section of your case study does not help someone understand how you think, cut it.

## Show Your Thinking, Not Just Your Screens

The most common mistake junior designers make is treating a portfolio like a design showcase - beautiful final screens, polished mockups, professional typography. That is not what hiring managers are assessing.

They are assessing your problem-solving process. They want to see messy wireframes alongside final designs. They want to understand why the navigation ended up the way it did. They want evidence that you spoke to users, changed direction based on what you heard, and made considered trade-offs.

A case study that shows a scrappy mid-fidelity prototype and explains why you made three different structural decisions is more valuable than one that shows only pixel-perfect final screens.

This does not mean production quality does not matter. It does, and it improves with practice. But at junior level, the thinking is the differentiator.

## Common Portfolio Mistakes

**Too many weak projects.** See above. Three focused pieces beat eight thin ones every time.

**No narrative.** A portfolio is not a gallery. Each piece needs a beginning, a middle, and an end. "Here is the homepage I designed" is not a case study.

**No outcomes.** Even approximate outcomes matter. "We tested with five users and found that two navigation patterns caused confusion; we revised and retested" is a real outcome. "The design was completed" is not.

**Ignoring accessibility and mobile.** If your case studies never mention accessibility considerations or how designs adapt across screen sizes, that is a gap. You do not need to have solved every edge case; you need to show you considered them.

**An impenetrable homepage.** Your portfolio site (or PDF, or Notion page) should load fast, be easy to navigate on mobile, and make it immediately clear what you do and where your work is. Do not make a hiring manager hunt for the case studies.

**Copying a template without adapting it.** Portfolio templates are a useful starting point but they produce a recognisable visual language. Customise enough that your work is front and centre, not the template.

## Format and Presentation Options

There is no single correct format. The options each have trade-offs:

**A dedicated website (Webflow, Squarespace, Framer, or hand-coded)** gives you the most control and signals a higher level of commitment. It is worth the effort if you are comfortable with the tools.

**A PDF** is easy to share and readable without any login. It is a reasonable starting point for career changers who want to start applying quickly. The downside is that it does not lend itself to interaction or video.

**Notion or a similar tool** is increasingly common, especially for early-stage portfolios. It is quick to set up and easy to update. The trade-off is that it looks low-effort to some hiring managers at larger organisations.

**Figma presentations** are a natural fit if your work lives in Figma already. They work well for sharing in interviews; less well as a standalone public portfolio.

Pick the format you can maintain and update. A polished PDF you actually keep current is better than a Webflow site you abandoned eight months ago.

If you want to learn [what UX design is and how it differs from UI](/blog/ux-vs-ui-design/), read our explainer first - it will help you frame your case studies with the right language.

## Advice for Career Changers with No Client Work

This is the most common question we hear at UX Academy (myuxacademy.com): "How do I build a portfolio when I have nothing to put in it?"

The short answer is that you create the work.

**Self-initiated projects.** Pick a product you use regularly and find something broken, confusing, or underserved. Document the problem. Do your own research - even lightweight guerrilla interviews with friends or family. Design a solution. Write up the case study using the structure above. This is entirely legitimate. Senior designers do this regularly as creative practice.

**Redesign projects.** Take an existing product or service - a local council website, a subscription app, a booking flow - and redesign a specific part of it. Be clear that it is a redesign exercise, not commissioned work. The point is to demonstrate your process, not to claim a client relationship that does not exist.

**Live-course briefs.** This is the most underrated option. A structured course with a real client project gives you work you can actually own and discuss in interviews. At UX Academy, students work on a live project as part of the [beginner UX design course](/courses/beginner-ux-design/), which means you finish with a real case study to anchor your portfolio - not a hypothetical exercise.

**Volunteer or pro-bono work.** Charities, community organisations, and small local businesses often have genuine design problems and no budget to address them. A real brief with real constraints and a real user base makes for a stronger case study than most classroom exercises.

Whatever the source of the project, the standards are the same. Document the problem. Show your process. Explain your decisions. Describe the outcome or what you would test next.

If you are still figuring out whether UX design is the right career move for you, our guide on [switching careers to UX design](/blog/switching-careers-to-ux-design/) covers the practical considerations honestly - including what the transition actually looks like from different professional backgrounds.

## A Note on Portfolio Reviews

Before you start applying, ask for portfolio feedback from people who hire designers - not just fellow students or friends. A working UX designer, a mentor, or a career coach with design industry experience will give you feedback that matters.

Pay particular attention to feedback on your case study narratives. The visuals are often the last thing experienced reviewers notice; the story is usually what stalls or advances a candidate.

If you are on a structured course, portfolio review should be part of the curriculum. At UX Academy, it is - because a portfolio without feedback is a missed opportunity.

## Getting Started

Building a portfolio feels overwhelming when you have nothing in it. The way through is to start with one case study, however imperfect, and iterate from there.

Document everything as you go - your sketches, your dead ends, your research notes. It is far easier to build a case study from notes taken in the moment than to reconstruct a process from memory six months later.

You do not need to have worked with paying clients. You need to have thought carefully about a problem, made decisions, and be able to explain them. That is the standard, and it is achievable from a standing start.

If you want to understand the full picture of [what a UX design career looks like](/blog/what-is-ux-design/) - including the skills, tools, and day-to-day reality - that is a good companion read to this one. If you are still in the early stages, [how to build a UX portfolio from scratch](/blog/how-to-build-a-ux-portfolio-from-scratch/) covers the beginner path step by step. And if you want to see what finished portfolios look like before committing to a structure, the [UX portfolio examples breakdown](/blog/ux-design-portfolio-examples/) shows real case studies reviewed against the criteria above.

---

If you are ready to build portfolio-ready work as part of a structured programme, the [beginner UX design course at UX Academy](/courses/beginner-ux-design/) includes a live client project, portfolio review, and weekly live sessions taught by our lead instructor, Natalia Veretenyk, and her team.

Not ready to commit yet? The [free UX/UI masterclass](/masterclass/free-ux-ui-masterclass/) is a no-cost way to see how we teach and whether the approach suits you.


---

# UX Design Laws and Principles: 18 Rules With Examples

URL: https://myuxacademy.com/blog/ux-design-laws-principles/
UX design laws and principles (2026): 18 research-backed rules explained with practical examples, from Jakob's Law to the Goal-Gradient Effect.

UX design is sometimes treated as pure intuition - you either have an eye for it or you don't. That's not quite right. Over decades of cognitive science, psychology, and usability research, a set of principles has emerged that explains *why* certain design decisions work better than others. These aren't rigid commandments. They're research-backed rules of thumb that help you make better decisions faster, explain your reasoning to stakeholders, and avoid common traps.

None of them replace user research. All of them become more useful the more you practice applying them. Here are 18 you'll use constantly.

## UX Design Laws at a Glance

| Law | What it says | Apply it when |
|-----|--------------|----------------|
| Jakob's Law | Users expect your product to work like others they already know | Designing navigation, checkout, or any familiar flow |
| Hick's Law | More choices means slower decisions | Building menus, pricing pages, onboarding steps |
| Fitts's Law | Larger, closer targets are faster to hit | Sizing and placing buttons and touch targets |
| Miller's Law | Working memory holds roughly 7 (plus or minus 2) items | Structuring lists, forms, and navigation |
| Law of Proximity | Elements placed close together are seen as related | Grouping labels, fields, and related controls |
| Law of Common Region | A shared boundary groups elements, even if spaced apart | Designing cards, panels, and containers |
| Peak-End Rule | Experiences are judged by their peak moment and their end | Designing confirmation, error, and offboarding screens |
| Aesthetic-Usability Effect | Pleasing designs are perceived as easier to use | Prioritising visual polish alongside functionality |
| Doherty Threshold | Productivity rises when response times stay under 400ms | Deciding where to invest in perceived performance |
| Tesler's Law | Complexity can be moved, not removed | Deciding whether the system or the user absorbs a step |
| Postel's Law | Be liberal in what you accept, strict in what you produce | Designing input validation and error handling |
| Serial Position Effect | People best remember the first and last items in a list | Ordering navigation, menus, and onboarding steps |
| Von Restorff Effect | An item that stands out from its peers is remembered best | Highlighting a single primary action or plan |
| Zeigarnik Effect | Unfinished tasks are remembered better than finished ones | Designing progress indicators and re-engagement prompts |
| Law of Pragnanz | People perceive the simplest possible interpretation of a shape | Simplifying icons, illustrations, and layouts |
| Occam's Razor | The simplest solution that works is usually the right one | Choosing between a simple flow and a clever one |
| Parkinson's Law | Work expands to fill the time available for it | Setting deadlines, limits, and time-boxed steps |
| Goal-Gradient Effect | Motivation increases as people get closer to a goal | Designing progress bars, loyalty schemes, checkout steps |

## Jakob's Law

**Users spend most of their time on other websites, so they expect yours to work the same way.**

Jakob Nielsen coined this one, and it's deceptively simple. When someone arrives on a new website or app, they bring a mental model built from every product they've used before. Understanding who your users are and what mental models they bring is the job of a [user persona](/resources/templates/user-persona/) - a structured way to document that research before applying it to design decisions. Navigation at the top. Logo links home. Search in the top-right. Checkout in a basket icon. Break these conventions and you force users to learn something new - which takes effort, creates friction, and erodes trust.

Practically: before reinventing a UI pattern, ask whether the novelty serves the user or just makes the product feel distinctive. A uniquely-styled navigation might win a design award. It might also lose you conversions. When you do deviate from convention, test it - don't assume clever equals better.

If you want to understand how these principles show up in real evaluations, read our post on [heuristic evaluation in UX design](/blog/heuristic-evaluation-ux-design/).

## Hick's Law

**The more choices you give someone, the longer it takes them to decide.**

W.E. Hick (and Ray Hyman) formalised this in the 1950s: decision time increases logarithmically with the number of choices. The practical implication is that overloading users with options doesn't feel generous - it feels paralysing.

This is why good onboarding flows surface one decision at a time. It's why pricing pages often have three tiers, not seven. It's why a well-designed hamburger menu that reveals a focused list of options often outperforms an exposed navigation with fifteen links.

Practically: audit any screen where you're asking users to choose something. Can you reduce the number of options? Can you sequence choices so they appear only when relevant? Progressive disclosure - revealing complexity gradually - is Hick's Law applied as a pattern.

## Fitts's Law

**The time to reach a target depends on how far away it is and how small it is.**

Paul Fitts published this in 1954, and it remains one of the most empirically solid principles in human-computer interaction. A large button close to the user's current position is faster to hit than a small button far away. Obvious when stated, but routinely violated in practice.

Practically: primary call-to-action buttons should be large and positioned where users are likely to be looking or pointing. On mobile, touch targets should be at least 44x44 pixels (Apple's guideline) or 48x48dp (Google's Material guidance). Destructive actions - delete, cancel, clear - should be smaller or further away, making them harder to trigger accidentally. The corners and edges of a screen are special: the pointer stops there, effectively making them infinitely large targets on a desktop.

## Miller's Law

**The average person can hold roughly 7 (plus or minus 2) items in working memory at once.**

George Miller's 1956 paper "The Magical Number Seven" gave designers a shorthand for cognitive load. Working memory is limited - when you overwhelm it, people make errors, miss things, and disengage.

The key practical application is chunking: grouping related pieces of information so they register as a single unit rather than several separate items. A phone number written as 07700900123 is harder to process than 07700 900 123. A navigation with twelve ungrouped links is harder to scan than one where links are organised under four clear headings.

Practically: wherever you have a list, a form, or a set of options, look for natural groupings. Chunking respects working memory limits without hiding information.

## The Law of Proximity (and Gestalt Principles)

**Elements that are close together are perceived as related.**

This is one of the Gestalt principles - a set of perceptual rules developed by German psychologists in the early twentieth century describing how humans group visual elements. Proximity is the most directly applicable to interface design: if two elements are near each other, users assume they're connected.

This is why form labels should sit directly above (or beside) their input fields, not ambiguously positioned between two fields. It's why a button placed next to a paragraph is assumed to act on that paragraph. It's why whitespace between sections is a design decision, not wasted space - it signals where one group ends and another begins.

The other Gestalt principles worth knowing are **similarity** (elements that look alike are grouped together), **continuity** (the eye follows lines and curves), **closure** (we complete incomplete shapes), and **figure-ground** (we separate objects from their backgrounds). All of them shape how users perceive layout before they consciously read a single word. You can explore how these feed into usability thinking in our post on [usability in UX design](/blog/usability-in-ux-design/).

## The Law of Common Region

**Elements within a clearly defined boundary are perceived as a group.**

This extends Gestalt proximity. Even if elements are spread apart, placing them inside a shared container - a card, a box, a shaded region - groups them in the user's perception. It's why card-based layouts work: the card boundary creates a distinct unit.

Practically: if you want users to understand that a set of elements belongs together, the most reliable signal is a shared enclosure - a border, a background colour, or a consistent container. Don't rely on proximity alone if the grouping is genuinely critical to comprehension.

## The Peak-End Rule

**People judge an experience primarily by how they felt at its most intense moment and at the end, not by the average across the whole experience.**

This comes from Daniel Kahneman's research on remembered utility. The implication for UX is significant: a checkout flow that is smooth throughout but ends with a confusing confirmation screen will be remembered as worse than the effort involved. Conversely, a process with some friction that ends with a moment of delight - a well-crafted success screen, a personal confirmation email, an unexpected small reward - will be remembered more positively.

Practically: pay particular attention to the end states of your flows. Success screens, error pages, confirmation emails, and offboarding moments are disproportionately important to how users remember your product. Don't rush them. Make them feel intentional.

## The Aesthetic-Usability Effect

**Users perceive more aesthetically pleasing designs as easier to use, even when they aren't.**

This was demonstrated by Masaaki Kurosu and Kaori Kashimura in 1995 and has been replicated since. A polished, visually considered interface creates a halo effect: users assume it works better, are more forgiving of problems they encounter, and rate it more highly.

This doesn't mean aesthetics substitute for usability - they don't, and the effect erodes quickly when a beautiful interface genuinely fails to work. But it does mean visual craft is not just decoration. A well-designed product earns more patience and goodwill from users before they give up.

Practically: take visual polish seriously as a design deliverable, not a finishing touch someone else handles. Typography, spacing, colour consistency, and icon quality all signal professionalism - and that signal has measurable effects on perceived usability.

## The Doherty Threshold

**Productivity increases when a computer and its users interact at a pace of under 400 milliseconds each.**

Walter Doherty and Ahrvind Thadani published this in 1982. When response times drop below 400ms, users enter a state of flow - the interface feels responsive, fluid, and under control. Above that threshold, users notice the wait, lose their train of thought, and disengage.

Practically: perceived performance is as important as actual performance. Skeleton screens, progress indicators, and optimistic UI updates (showing a change immediately before the server confirms it) all reduce perceived latency even when actual response times haven't changed. On the development side, this principle justifies investment in performance work: slow interfaces aren't just annoying, they reduce engagement and completion rates.

## Tesler's Law

**Every process has an irreducible amount of complexity - the only question is who handles it, the system or the user.**

Also called the Law of Conservation of Complexity, this was articulated by Larry Tesler while working on human-computer interaction at Xerox PARC and Apple. Complexity doesn't disappear when you simplify an interface - it moves. The question a designer has to answer for every feature is: does the system absorb this complexity, or does the user?

Practically: when a checkout form asks for a card number, good UX auto-detects the card type and formats the digits as you type, rather than asking the user to format it correctly themselves. When an address field geocodes a partial entry instead of demanding a rigid format, the system is absorbing complexity the user would otherwise have to manage. Every time you're tempted to add a setting, a step, or a field, ask whether the system could handle it instead.

## Postel's Law

**Be liberal in what you accept, strict in what you produce.**

Postel's Law comes from early internet protocol design (Jon Postel, RFC 761), but it maps directly onto form and input design. Systems that are rigid about what they accept from users create friction; systems that are sloppy about what they output create confusion.

Practically: a phone number field should accept spaces, dashes, and parentheses rather than rejecting anything that isn't eleven bare digits - normalise it after the fact. A date field should parse "21 Sep 2026", "05/09/2026", and "2026-09-21" rather than forcing one format. On the output side, be strict: what you show back to the user - confirmation numbers, formatted totals, validation messages - should be unambiguous and consistent every time.

## The Serial Position Effect

**People remember the first and last items in a list far better than the ones in the middle.**

This comes from memory research by Hermann Ebbinghaus, later refined into the primacy effect (first items are rehearsed and moved to long-term memory) and recency effect (last items are still active in short-term memory). Middle items get the least attention and the weakest recall.

Practically: put your most important navigation items, product options, or onboarding steps at the start or the end of a list, not buried in the middle. If you have a five-step onboarding flow, the first step sets the tone and the last step is what people remember when deciding whether the whole thing felt easy. A pricing page with the plan you want customers to choose in the first or last position outperforms the same plan placed second or third.

## The Von Restorff (Isolation) Effect

**An item that stands out visually from its surrounding peers is more likely to be remembered.**

Named after psychiatrist Hedwig von Restorff, who documented it in 1933, this is the principle behind why a single differently-coloured item in a list draws the eye and sticks in memory more than any item that looks like all the others.

Practically: this is why the recommended plan on a pricing page is usually highlighted with a different colour or a "Most popular" badge, and why a single primary call-to-action button should look visually distinct from every secondary button on the same screen. Use isolation sparingly - if everything is highlighted, nothing is, and the effect collapses.

## The Zeigarnik Effect

**People remember incomplete or interrupted tasks better than tasks they've already finished.**

Soviet psychologist Bluma Zeigarnik observed that waiters could recall unpaid orders in detail but forgot them the moment the bill was settled. The tension of an unfinished task keeps it active in memory in a way a completed one isn't.

Practically: progress bars, "your profile is 80% complete" widgets, and step counters ("Step 2 of 4") all exploit this - the visible gap between where a user is and where they'll be done creates a pull to finish. Onboarding flows and multi-step forms that show remaining steps, rather than hiding them, tend to see higher completion, because the incompleteness itself becomes motivating rather than discouraging.

## The Law of Pragnanz

**People perceive and interpret ambiguous or complex shapes in the simplest form possible.**

The Law of Pragnanz - German for "conciseness" - is the umbrella Gestalt principle underlying proximity, similarity, closure, and continuity. Faced with visual complexity, the human eye and brain default to the simplest, most orderly interpretation available.

Practically: icons, logos, and illustrations read faster and are remembered better when they resolve to simple, recognisable shapes rather than ornate detail. A cluttered dashboard with a dozen visual styles fighting for attention forces the brain to do work it would rather not do. Simplifying the visual language of a product - fewer shapes, more consistent forms - reduces cognitive effort even before anyone reads a word of content.

## Occam's Razor

**Among competing solutions that solve the problem equally well, the simplest one is usually the right one.**

Occam's Razor originates in medieval philosophy (William of Ockham), not psychology, but it's a working principle for UX decision-making: don't multiply design complexity beyond what's needed to solve the user's actual problem.

Practically: when two design directions solve the same user need, and one requires more screens, more copy, or more custom interaction patterns than the other, the simpler one is usually the better bet - unless there's specific evidence the complexity earns its keep. This is a useful check against "clever" designs that solve a problem nobody had, or solve a real problem in a needlessly elaborate way.

## Parkinson's Law

**Work expands to fill the time available for its completion.**

Cyril Northcote Parkinson coined this about bureaucracy in 1955, but it applies directly to task design. Give someone an unlimited amount of time to complete a task and the task will take longer - not because it's harder, but because there's no pressure forcing a decision.

Practically: this is why limited-time offers, countdown timers on checkout sessions, and time-boxed trial periods change user behaviour - they impose a constraint that forces action. It also applies internally: a form with no field limits and no clear end point feels more effortful than a short form with a visible finish line, even if the total amount of information requested is the same.

## The Goal-Gradient Effect

**Motivation to complete a task increases as people get closer to the goal.**

Clark Hull's research on rats running mazes, later confirmed in human behaviour by Ran Kivetz's coffee-loyalty-card studies, found that effort and speed both increase as the finish line approaches. Early progress motivates less than late progress does.

Practically: progress bars that start pre-filled (a loyalty card that begins with two stamps already given, not zero) accelerate completion because the goal feels closer from the outset. Multi-step checkouts, onboarding wizards, and course-completion trackers all benefit from showing users how close they are to done, especially in the final stretch - that's the point where a small nudge has the most effect.

## How to Apply These Without Over-Applying Them

The risk with a list like this is treating each law as a trump card to be played in design critiques. "Hick's Law says fewer choices" is not a complete argument. Context matters. A recipe website with a large ingredient list isn't violating Miller's Law - it's serving a user who came specifically for that information. A form with many fields might be unavoidable given business requirements.

Use these principles as a starting point for asking better questions. Why does this feel hard to navigate? Is Fitts's Law telling us the tap targets are too small, or is it something else? What's the peak moment in this flow, and are we designing it with the care it deserves? Our guide to the [UX design process](/blog/ux-design-process/) is a good companion here - it shows where each of these principles tends to matter most across the different stages of a project.

The designers who use these principles well are the ones who've internalised them enough to apply them quickly and set them aside when the evidence says something different. That kind of fluency comes from practice - real projects, real feedback, real iteration.

If you want to build that fluency alongside a structured curriculum and live instruction, look at what we cover on our [beginner UX design course at UX Academy (myuxacademy.com)](/courses/beginner-ux-design/), taught by our lead instructor, Natalia Veretenyk, and her team. Or if you want a low-commitment starting point, our [free UX/UI masterclass](/masterclass/free-ux-ui-masterclass/) covers the fundamentals in a single session - no prior experience required.

You can also browse [all our courses](/courses/) to see how we approach UX design education.


---

# UX Design in Healthcare UK: NHS Examples and Salaries (2026)

URL: https://myuxacademy.com/blog/ux-design-in-healthcare/
Healthcare UX in the UK: what makes it different, an NHS App case study, healthcare UX salary data, and how to build a career in UK health tech in 2026.

Healthcare is the domain where UX design stops being a nice-to-have and becomes a matter of genuine consequence. A confusing interface in a music app is annoying. A confusing interface in a clinical system can contribute to a medication error, a missed diagnosis, or a patient who gives up on managing a chronic condition because the app was too hard to use. That is the reality of healthcare UX, and it is why the field attracts designers who want their work to matter.

This post covers what makes healthcare UX distinct, the challenges you will face, the skills that matter most, and the career opportunities opening up in health tech.

## Why Healthcare UX Is High Stakes

Most digital products fail gracefully. If a user cannot figure out how to complete a task, they abandon it and try again later, or find an alternative. In healthcare, abandonment has consequences. A patient who cannot navigate a booking system might delay seeing a doctor. A nurse who misreads a medication screen because of poor information hierarchy might administer the wrong dose. A person with low digital literacy who cannot complete an online referral form simply does not get referred.

This raises the stakes for every design decision. It also means that healthcare organisations have started taking UX seriously in a way that many were slow to do a decade ago. Electronic health records, patient-facing apps, telehealth platforms, clinical decision support tools, NHS digital services - all of these require designers who understand the specific pressures of the healthcare environment.

If you are thinking about [what UX design is and where it applies](/blog/what-is-ux-design/), healthcare is one of the clearest examples of UX as a professional discipline with real-world accountability attached to it.

## A UK Example: What the NHS App Gets Right (and Where It Struggles)

The clearest UK case study in healthcare UX is the **NHS App**, the patient-facing service that lets people book GP appointments, order repeat prescriptions, view their GP health record, and manage organ donation preferences from one account. NHS Digital's own service standard reporting shows the app has been one of the fastest-adopted government digital services in UK history, in large part because it solved a genuinely painful problem: before it existed, most of these tasks required a phone call to a GP receptionist during a narrow opening window.

The UX lesson is in how identity and access were solved. **NHS Login**, the identity verification layer behind the app, has to satisfy a hard constraint most consumer products never face: it must be usable by people who do not have a passport or driving licence, do not have a smartphone with NFC, or do not trust the idea of uploading photo ID to an app at all. NHS Digital's response was a tiered verification model - basic access with lower identity assurance, full access (including prescriptions and the full record) with stronger verification via NHS number, GP registration lookup, or in-person proof at a pharmacy. That tiering is a direct application of inclusive design: rather than one identity bar that excludes anyone who cannot clear it, the service offers a lower-friction path to partial value and a higher-friction path to full value, and lets the user choose.

Where the wider NHS digital estate still struggles is **fragmentation between services**. NHS Login, the **e-Referral Service** (used to book hospital and specialist appointments), and individual NHS Trusts' own patient portals do not share a single consistent interaction pattern, and patients frequently have to re-enter the same information - or re-verify their identity - across services that all sit under the same "NHS" brand. For a UX designer, this is a textbook case of Jakob's Law working against you: patients bring the mental model "I am dealing with the NHS, this should behave like the one NHS thing I already used," and every inconsistency between services reads as a bug rather than a different team's design decision. It is also a strong illustration of [Tesler's Law](/blog/ux-design-laws-principles/) - the complexity of NHS service fragmentation does not disappear; without careful design, it gets pushed onto the patient in the form of repeated forms and duplicated verification.

## The Distinct Challenges of Healthcare UX

### Regulation and Compliance

Healthcare products often fall under regulatory frameworks that have no equivalent in consumer software. In the UK, software that qualifies as a medical device must comply with MHRA regulations. In the US, the FDA has its own requirements. Even products that do not meet the threshold for medical device classification often need to comply with data protection laws (GDPR in the UK and EU, HIPAA in the US) that constrain what you can collect, store, and display.

This means design decisions are not made in isolation. Changes to a clinical interface may require formal validation, documentation, and sign-off before they can be deployed. As a UX designer, you will work within those constraints rather than around them, which requires patience and a different kind of rigour than you find in fast-moving product teams at consumer startups.

### Clinician-Facing vs Patient-Facing Systems

Healthcare UX broadly splits into two very different problem spaces. Clinician-facing systems - electronic health records, prescribing tools, clinical dashboards - are used by trained professionals, often under time pressure, often in chaotic environments. The goal is efficiency, accuracy, and error prevention. These users know what they are doing; they need the system to keep up with them and not get in their way.

Patient-facing systems - booking portals, chronic disease management apps, remote monitoring tools, mental health platforms - are used by people who vary enormously in age, digital literacy, health status, and emotional state. A patient using a cancer treatment tracker is not in the same headspace as someone browsing a shopping app. The design has to account for that.

Both are hard. They require very different research approaches, different prototyping priorities, and different definitions of success. Our guide to [UX research methods](/blog/ux-research-methods/) covers contextual enquiry, diary studies, and other approaches that are particularly well-suited to understanding complex, high-stakes user contexts like these.

### Legacy Systems and Technical Constraints

Much of the healthcare technology estate is old. Hospitals run systems that were built in the 1990s and have been patched and extended ever since. As a UX designer working in health, you will regularly encounter situations where the ideal design is not possible because the underlying system cannot support it. Working with legacy constraints is a skill in itself - knowing how to make meaningful improvements within what exists rather than proposing a ground-up rebuild that will never get budget.

This is one area where healthcare UX differs sharply from designing new consumer products. You will spend a lot of time on incremental improvement, and you need to find that valuable rather than frustrating.

### Data Sensitivity and Trust

Healthcare data is among the most sensitive personal data that exists. Users know this, and trust is fragile. A patient who does not trust that their mental health app data is private will not use it honestly. A person from a community with historical reasons to distrust medical institutions will approach a digital health tool with scepticism.

This has direct design implications. Transparency about data use must be built into the interface, not buried in a privacy policy. Consent flows need to be clear without being bureaucratic. The visual language of the product should communicate professionalism and security without being cold or clinical in a way that alienates people.

[Usability in UX design](/blog/usability-in-ux-design/) is about more than ease of use - in healthcare it includes whether users trust the system enough to engage with it at all.

## Accessibility and Inclusive Design as a Core Requirement

In most product contexts, accessibility is treated as a compliance checkbox. In healthcare, it is a fundamental design requirement. The user base for a health service is, by definition, the entire population - including older adults, people with visual or cognitive impairments, people who are acutely unwell, people with low literacy, and people who have never owned a smartphone.

WCAG 2.2 compliance, published by the W3C, is a floor, not a ceiling. For UK public-facing health services specifically, the **GOV.UK Service Manual** goes further than WCAG alone - it sets accessibility and plain-language expectations for any government or NHS-adjacent digital service, including its well-known content design standard of writing for a reading age of around 9 (the Plain English Campaign's benchmark, which the GOV.UK Service Manual adopts directly). Good healthcare UX goes further still: it designs for one-handed use (relevant when someone is physically unwell or holding something), and tests with users who are representative of the actual population rather than the most tech-savvy version of it. Our post on [accessibility in UX design](/blog/accessibility-in-ux-design/) covers the principles and practical techniques that apply across all contexts, including healthcare. If accessibility work like this appeals to you, our [UX accessibility course](/courses/ux-accessibility/) goes deep on inclusive design methods and WCAG in practice.

Inclusive design also means designing for moments of stress and cognitive overload. A person in an urgent care situation, or someone managing a serious diagnosis, is not reading carefully. They are scanning, and they are scared. Content needs to be short, clear, and actionable. Instructions need to be impossible to misread.

## Designing for Stress and Low Digital Literacy

One of the most practically important shifts when moving into healthcare UX is accepting that your users may not be in a good state when they use your product. Anxiety, pain, grief, and exhaustion all reduce cognitive capacity. Users under stress make more errors and have less patience for confusing interfaces.

This shapes how you write, how you structure information, and how you design error states. Error messages in a healthcare product should be especially clear and calm - "We could not verify your date of birth. Please try again" rather than a generic error code. Confirmation steps matter more, not less. Progress indicators in multi-step flows reduce anxiety.

Low digital literacy is common across all sectors, but healthcare sees it concentrated in the people who often need services most - older adults, people with limited education, people who are newly arrived in a country. Plain language standards (typically aiming for a reading age of around 9-11 years in the UK) apply to all interface copy, not just long-form content.

## What Good Healthcare UX Looks Like

Good healthcare UX is invisible in the same way all good UX is invisible - the user completes their task without noticing the design. But in healthcare, there are a few specific qualities that define it:

**It reduces errors.** The design makes it hard to do the wrong thing and easy to do the right thing. Medication names are displayed clearly with appropriate size and contrast. Confirmation steps prevent accidental submissions. High-risk actions require explicit confirmation.

**It supports clinician workflows.** For clinical tools, good UX means fitting into how people actually work - not how a product manager imagined they work. This requires deep contextual research: observing clinicians in real environments, understanding what information they need at each moment, and designing for the interruptions and distractions that are a constant feature of clinical settings.

**It builds trust gradually.** Patient-facing products that ask for a lot upfront tend to fail. Good healthcare UX earns trust through small interactions - a clear onboarding, a well-handled first use, privacy explained in plain terms - before asking users to engage with more sensitive functionality.

**It is tested with real users.** This sounds obvious but is frequently skipped in healthcare. Usability testing with clinical staff and patients, including people with relevant health conditions and lower digital literacy, is how you find the problems that matter.

## The Career Opportunity in Health Tech

Health tech is one of the fastest-growing sectors in the UK. NHS digital transformation programmes, a large and growing remote monitoring and telehealth industry, health and wellness apps, and a thriving medtech sector all need UX designers with domain knowledge.

Many designers move into healthcare UX from other sectors and find they can apply their existing skills while developing new ones - specifically around regulatory environments, clinical workflows, and accessible design. The transition is demanding but well-supported by a strong community of practice in the UK.

Salaries in healthcare UX tend to reflect the complexity of the work rather than undercutting the wider market. Indicative UK figures from ITJobsWatch put mid-level UX/product designers in health tech and NHS-adjacent digital roles in a similar band to the general UX market - roughly £40,000-£55,000 - with senior UX roles at established health tech companies and NHS digital transformation programmes reaching £65,000-£85,000+, and specialist accessibility or research roles within health commanding a premium given how few designers have both the domain knowledge and the skillset. These figures are indicative rather than definitive and will vary by employer, location, and seniority; see our [UX designer salaries in the UK](/blog/ux-designer-salary-uk/) post for the fuller sector-by-sector breakdown. The work is also, by most accounts, more meaningful than typical commercial UX. That is not nothing.

If you are career-changing into UX and drawn to work that has direct human impact, healthcare is a direction worth thinking about from the outset rather than as something you grow into later. The foundational skills are the same regardless of sector: research, synthesis, prototyping, testing, communication. What you add on top is domain knowledge, and that you can build.

## Where to Start

If healthcare UX appeals to you, the path in is the same as any other UX career path: build your foundational skills, do projects that demonstrate your process, and develop domain knowledge alongside your portfolio.

Our [free UX/UI masterclass](/masterclass/free-ux-ui-masterclass/) is a practical starting point - it covers the core methods that underpin good UX work in any sector, including healthcare. If you are ready to commit to a structured learning path, our [beginner UX design course](/courses/beginner-ux-design/) covers research, wireframing, prototyping, and usability testing in a live format, taught by our lead instructor, Natalia Veretenyk, and her team.

[Browse all courses at UX Academy (myuxacademy.com)](/courses/) to see what fits your schedule and starting point.

Healthcare UX is demanding work. It is also some of the most consequential work in the field. If that sounds like the right trade-off to you, it probably is.


---

# UX Design for Startups: How to Get It Right From Day One

URL: https://myuxacademy.com/blog/ux-design-for-startups/
Why UX design matters from the first sprint, how to do lean research on a tiny budget, and the most common startup UX mistakes to avoid.

Most startup founders treat UX design as something to tidy up after the product is built. That is one of the most expensive mistakes you can make - not in designer fees, but in wasted engineering time, churn, and failed fundraising rounds. Getting UX right early is almost always cheaper than fixing it later.

This post covers why UX matters from day one, how to practise lean UX with limited resources, and the specific mistakes that trip up early-stage teams most often.

## Why UX Matters Before You Have Customers

There is a common belief that UX is a polish layer - something you apply once the core product works. In reality, UX is how you figure out what "working" even means.

Poor UX at the MVP stage does not just annoy users; it produces misleading signals. If people drop off during onboarding, you do not know whether they rejected your value proposition or just could not navigate to it. That ambiguity wastes your next three months.

Good UX research at the start answers the question investors will eventually ask: do people actually want this, and can they use it? A product that converts well and retains users is a stronger fundraising story than one with impressive technical architecture and a high drop-off on the signup screen.

## Lean UX and MVP Thinking

Lean UX is not about doing less design - it is about doing design faster and treating assumptions as testable hypotheses rather than settled facts.

The core loop is:

1. State your assumption clearly ("users will want to track X because Y")
2. Design the minimum that would prove or disprove it
3. Put it in front of real people
4. Update your thinking based on what you observe

This is different from building a feature, shipping it, and measuring engagement weeks later. Lean UX frontloads the learning so you build less of the wrong thing.

For an MVP specifically, the question is not "what is the simplest version of the product?" but "what is the least we can build to test whether users get value from this?" Sometimes that is a prototype that does not actually work. Sometimes it is a landing page with a waitlist. Sometimes it is a wizard-of-oz flow where you manually fulfil what the system appears to automate.

The goal is evidence, not code.

## Balancing Speed With Usability

Speed is real. Startups do not have the luxury of six-week research cycles. But speed and usability are not opposites - they are in tension, and managing that tension is the actual skill.

A few practical principles:

**Set a usability floor, not a ceiling.** Define the minimum standard your product must meet before any feature ships. For most consumer products that means: a new user can complete the core task without asking for help. For B2B tools it might be: a user can complete the task within a reasonable time on their first attempt. Everything above the floor is a nice-to-have.

**Separate "good enough for now" from "never revisit this".** Some UX debt is intentional and sensible. The danger is when it becomes invisible. Keep a running list of what you knowingly shipped with rough edges and why. That list becomes your UX backlog.

**Design in parallel with engineering, not after.** The biggest source of wasted sprint cycles in early-stage teams is handing a half-formed idea to an engineer, watching them build it, and then discovering in testing that it does not work. Even two days of design thinking before a sprint begins pays back in engineering hours saved.

## Doing Meaningful Research on a Tiny Budget

"We do not have budget for user research" usually means "we have not figured out how to do cheap research yet." Most of the highest-value research methods cost almost nothing.

**Guerrilla testing.** Five users, a prototype, a quiet corner of a coffee shop or a Zoom call. You will surface the most obvious usability problems in the first session. You do not need a lab or an agency. Our guide to [UX research methods](/blog/ux-research-methods/) covers guerrilla testing and the other lean approaches that work well when time and budget are tight.

**Jobs-to-be-done interviews.** One-to-one conversations asking people to walk you through a recent time they tried to do the thing your product helps with. You are not asking "what would you want?" - you are listening to the story of what they actually did, what frustrated them, and what they used instead. Twenty conversations will give you more than most surveys.

**First-click testing.** Show someone a screenshot and ask them where they would click to do X. Free tools exist for this. It reveals navigation and hierarchy problems in minutes.

**Usability testing of existing competitors.** Watch someone try to use a competitor product to solve their problem. You will learn what the category does badly and where your opportunity is.

The point is not to gather data for its own sake. It is to reduce the number of guesses your team makes before building something.

## The Most Common Startup UX Mistakes

### Building Before Validating

The most costly pattern in early-stage product work: the team builds a feature in full because it seems obviously useful, and only then discovers users do not want it or cannot find it. The fix is to test the concept - even in a rough sketch - before a single line of production code is written. It feels slower. It is not.

### Copying Competitors

Competitors are not your design specification. Their product reflects their constraints, their legacy decisions, and their user base - not yours. Copying them means inheriting their mistakes along with their patterns. Learn from what they do well, but start your design from your user's actual problem, not from a clone of an existing interface.

### Ignoring Onboarding

Onboarding is where most products lose the majority of new users. It is also where most teams underinvest because it feels unglamorous. A user who signs up and does not reach the core value proposition in their first session may never come back. Mapping and improving that first five minutes of the experience is often the highest-return design work you can do.

### Designing for Yourself

Founders know their product inside out. That knowledge is a UX liability. You cannot unsee what you know, which means you will consistently overestimate how much users understand about your product and underestimate how confusing your interface is to a first-time visitor. The only cure is regular, structured contact with people who are not you.

### Treating Feedback as Validation

Users say positive things in interviews because they are polite. Watch what they do, not what they say. If someone tells you the product is great but cannot complete a core task, the task is broken. Qualitative feedback is useful for generating hypotheses; observed behaviour is what tests them.

## When to Hire a Designer vs Upskill Your Team

This is a real decision that depends on your stage and what you are trying to learn.

**Early-stage (pre-product-market fit):** You probably do not need a full-time designer yet. What you need is someone on the team who can do user research, sketch interfaces, and facilitate testing. If that person does not exist, upskilling a founder or a product-minded engineer is often the right move. The goal at this stage is speed of learning, not design craft.

**Post-traction, pre-scale:** Once you have a product that converts and you are trying to optimise it, a dedicated designer becomes genuinely valuable. Hire for UX research ability first - someone who can run studies and translate findings into decisions - then for craft.

**Scaling:** At this stage you likely need a design team with specialisms. But most startups reading this post are not there yet.

The middle path that many early-stage teams underuse: bringing in someone part-time or fractional for a specific sprint - a usability audit, a redesign of one critical flow, a round of customer interviews. It is cheaper than a hire and faster than an agency retainer.

If you are a founder who wants to handle more of this in-house, learning the fundamentals of UX properly is worth the investment. Understanding what questions to ask in a user interview, how to read a usability test, and how to frame design decisions as testable hypotheses will make you a sharper product thinker regardless of whether you ever open a design tool yourself. Knowing your way around the core [UX design tools](/resources/) also helps you collaborate with designers or evaluate freelance work more confidently. Our [product design course](/courses/product-design/) is built specifically for people making that transition.

## How Good UX Supports Growth and Fundraising

Investors are pattern-matching for evidence of demand and retention. A well-designed product signals several things simultaneously: that you understand your user, that you can execute, and that you have done the work to reduce churn. None of those signals come cheap, but UX is one of the most direct levers you have on all three.

Word-of-mouth growth - still the most efficient acquisition channel for most early-stage products - is largely a function of whether people have a good experience. You cannot buy your way to strong referral rates if the product is confusing or painful to use.

If you are heading into a fundraising round, your product demo is a UX test. Investors are watching whether the thing makes sense, whether the journey is coherent, and whether they can follow what you are doing without coaching. A product that is visibly well-thought-through is a stronger pitch artifact than a deck full of projections.

## Where to Go From Here

If you are serious about UX for your startup - whether as a founder wanting to sharpen your product instincts or as someone looking to move into a UX role - the best next step is to learn the discipline properly, not just pick up isolated tactics.

At UX Academy (myuxacademy.com), we run live, cohort-based UX design training designed for people who want practical skills they can apply immediately. The training is led by our lead instructor, Natalia Veretenyk, and her team. If you want to see how we teach, the free [UX and UI masterclass](/masterclass/free-ux-ui-masterclass/) is the right starting point - a live session covering the core concepts with time for questions.

You can also [browse our courses](/courses/) to see what fits your current stage, or read our related posts on [what UX design actually is](/blog/what-is-ux-design/) and [how data-driven UX works in practice](/blog/data-driven-ux-design/).

UX is not a phase you reach. It is the way you think about problems - and the earlier you start, the less you have to undo.


---

# UX Design Courses in London: What to Look For

URL: https://myuxacademy.com/blog/ux-design-courses-london/
A clear guide to UX design courses in London: live online vs in-person, what good courses include, how much they cost, and who UX Academy suits.

London has no shortage of options if you want to study UX design. Bootcamps, evening classes, short workshops, and multi-month programmes all compete for your attention and your money. The problem is that the range is enormous: from weekend tasters at a few hundred pounds to intensive bootcamps costing upwards of £9,000. Knowing what to look for matters before you spend anything.

This guide covers the key things to evaluate, what "in London" actually means in 2026, how [UX Academy](/) fits into that landscape, and a few honest answers to the questions we hear most.

## What to look for in a UX design course

Not all UX courses are equivalent. Here are the criteria that actually predict whether you will come out ready to work.

**Live instruction vs self-paced video**

Self-paced video courses are cheap and flexible, but they have a well-documented problem: most people do not finish them. More importantly, UX design is a practice you develop through feedback, not through watching someone else do it. A course where you never get your work reviewed is not a UX course - it is a content library.

Live instruction, where a practitioner works through your decisions with you in real time, is how you develop actual judgment. Look for courses where live sessions are the core, not an add-on.

**Class size**

Large cohorts make it easy for providers to scale their revenue. They make it hard for you to get meaningful feedback. A course with 40 or 60 students and one tutor cannot give your work the attention it needs. Smaller groups - ideally under 20 - allow real critique and genuine back-and-forth.

**Real projects, not simulated briefs**

Many courses use the same fictional brief for every student: redesign a coffee shop app, improve a travel booking flow. These exercises are fine for practising tools, but they do not prepare you for the ambiguity, stakeholder complexity, and real constraints of client or employer work.

A course that involves a real client project, one where the brief is not pre-solved and the client has actual opinions, gives you something meaningfully different. It also gives you a case study you can speak to honestly in interviews.

**A credible, assessed certificate**

Look for a course that actually assesses your work and issues a certificate you can point to, ideally one tied to a real project rather than just attendance. A certificate backed by a portfolio piece carries far more weight with employers than a participation badge, whatever logos sit next to it.

**Price in context**

UX courses in London range from a few hundred pounds for short workshops to £9,000 or more for premium bootcamp programmes. The correlation between price and quality is not strong. What matters is what you get for the money: live instruction, small groups, real projects, career support, and whether the outcome - a job in UX - is realistic at your current stage.

## What "in London" means in 2026

For most working Londoners, "in London" no longer means commuting to a physical room two or three evenings a week. It means live, real-time online learning where the cohort is London-based (or UK-based) and the schedule fits around a full-time job.

The shift happened during the pandemic and has not reversed for professional development. The reason is simple: commuting to a class after work in London is expensive and exhausting. A 90-minute commute each way, plus tube fares, on top of a full working day, is a significant extra load - and it does not make the learning better.

Live online learning, done well, delivers the same real-time feedback and cohort connection without the commute overhead. The question to ask is not "is it in a room?" but "is it live and interactive?" - because that is what the research on adult learning consistently supports.

That said, some people do prefer in-person study. If that is you, options in London include General Assembly (their full-time UX immersive runs at around £9,000), various short workshops at Escape Studios and similar providers, and occasional evening programmes through industry bodies. We mention these not to recommend them, but because an honest comparison requires acknowledging they exist. For a broader look at the UK market, our [comparison of the best online UX design courses in the UK](/best-online-ux-design-courses-uk/) covers several options across formats and price points.

## How UX Academy London fits in

[UX Academy at myuxacademy.com](/courses/) is a live online programme built specifically for people who are working and want to move into UX design. Here is what that looks like in practice.

**Format:** Live sessions run on weekday evenings, part-time, so you do not have to quit your job or take a career break. Sessions are real-time, not pre-recorded.

**Class size:** Maximum 15 students per cohort. That is a deliberate cap, not a marketing claim. It is small enough for your work to get actual attention each week.

**Real client project:** Every cohort works on a live client brief. You will present your work to a real stakeholder, handle a real brief, and leave with a case study you did not make up. This is a meaningful differentiator from courses built around simulated exercises.

**Price:** From £1,500, with a £99 deposit to secure your place. This is a fraction of what General Assembly charges for their London UX programme (around £9,000). We also offer a price-match guarantee on comparable live, tutor-led UX courses - if you find one with equivalent structure at a lower price, we will match it.

**Who it suits:** Career changers with no design background who want structured, supported progression into a UX role. It is not a course for people who want to watch videos in their own time - it is for people who want to actually do the work with guidance.

**Who it does not suit:** If you need a full-time immersive and can afford to be out of work for three months, a bootcamp format may work better for your timeline. If you want pure self-paced flexibility, a platform like Coursera or Google's UX certificate is cheaper and less demanding. We would rather be honest about this than oversell.

To understand what you will actually learn, the [Beginner UX (AI) Design course page](/courses/beginner-ux-design/) has the full curriculum breakdown.

You can also attend a [free live UX masterclass](/masterclass/free-ux-ui-masterclass/) before committing to anything - a two-hour session that covers the fundamentals and gives you a real sense of how we teach.

## A note on naming

There is a US company called Designlab that also runs a product called "UX Academy." It is not affiliated with us. We are [UX Academy London at myuxacademy.com](/) - a UK-based live online school run by Nomadic User Ltd. If you are researching courses and see references to "UX Academy," check the URL. We are myuxacademy.com.

## Frequently asked questions

## Are there in-person UX courses in London?

Yes, though fewer than people expect. General Assembly offers a full-time UX design immersive in London at around £9,000. Some industry bodies and design studios run short workshops or one-day intensives. Evening in-person programmes are rarer, partly because the commute overhead makes them harder to sustain.

For most working Londoners, live online learning is the practical equivalent: real-time, interactive, and without the cost and friction of getting across the city after work. If you need the physical classroom experience specifically, it is worth checking what is currently available through General Assembly and London design meetup communities.

## How much do UX courses cost in London?

The range is wide. Short workshops and tasters can cost £100-500. Part-time evening programmes typically run from £1,500 to £3,000. Full-time bootcamps from established providers like General Assembly sit at £8,000-9,000 or more.

Price does not reliably predict quality. The more useful question is what you are getting: live instruction or video, small group or large cohort, real projects or simulated briefs, career support or none. A £1,500 live programme with small groups and a real client project may give you more than a £9,000 course with 40 students and pre-packaged briefs.

UX Academy starts from £1,500 and includes a price-match guarantee on comparable live, tutor-led courses.

## Can I study UX in London while working?

Yes - and for most people starting out, that is the right approach. Quitting your job to study full-time is a significant financial and professional risk. A structured part-time programme lets you develop the skills, build your portfolio, and make the transition without burning your savings.

The key is choosing a programme with live sessions (so you are held to a schedule and get feedback) and a realistic weekly time commitment. UX Academy runs on weekday evenings with a time commitment that working adults can sustain. For more on what the career change path looks like, [switching careers to UX design](/blog/switching-careers-to-ux-design/) covers the realistic timeline and what hiring managers actually look for.

## Is it worth doing a UX course in London specifically?

The job market for UX designers is national and increasingly remote - London employers hire from across the UK, and many UX roles are hybrid or fully remote. You do not need to be based in London to get a London UX job, and you do not need to study in a London classroom to work in London. If you are outside the capital, our guide to finding [UX design classes near me](/blog/ux-design-classes-near-me/) covers what to look for wherever you are based.

What matters is the quality of your training, the strength of your portfolio, and whether you can speak confidently about your process in interviews. Those things come from good instruction and real projects, not from a postcode.

---

If you are ready to take the next step, [view the full course details](/courses/beginner-ux-design/) or join a [free live masterclass](/masterclass/free-ux-ui-masterclass/) to see how we teach before you commit to anything. Both are available to Londoners and anyone across the UK. All courses are taught by our lead instructor, Natalia Veretenyk, and a team of working UX professionals.


---

# What Is Usability in UX Design? A Practical Guide

URL: https://myuxacademy.com/blog/usability-in-ux-design/
Usability is the foundation of good UX design. Learn Nielsen's five components, how usability is measured, and practical ways to improve it in your projects.

Usability is one of those words that gets thrown around constantly in UX circles, yet its meaning often gets blurred. Is it just about making things easy to use? Is it the same as good UX? And why do so many products still feel frustrating to use, even when a team of designers worked on them?

This guide answers those questions directly. We cover what usability actually means, how it relates to the broader user experience, how to measure it, and what you can do to improve it in your own design work.

## What Usability Actually Means

Usability refers to how effectively, efficiently, and satisfactorily a person can use a product to achieve a specific goal in a specific context.

That definition comes from ISO 9241, the international standard for human-centred design, and it does the job well because it keeps three things in balance: effectiveness (can the user complete the task?), efficiency (how much effort does it take?), and satisfaction (did the experience feel acceptable?).

A product can score well on one dimension and fail on the others. A cash machine is usually effective - most people get their money out - but the efficiency can be terrible if the interface forces you through five screens to check your balance. A government form might be completable but so unpleasant that people avoid it altogether.

Usability is not about aesthetics, brand, or delight. It is a functional property of a product: does it work well for the people who need to use it?

## Usability vs User Experience: Not the Same Thing

Many people use "usability" and "UX" interchangeably. They should not.

User experience is broader. It includes how a person feels about a product before they use it, during use, and after. It covers brand perception, emotional response, the quality of customer support, and even the packaging a product arrives in. If you want to explore this in more depth, [what is UX design](/blog/what-is-ux-design/) covers the full picture.

Usability sits inside user experience as one critical component. You cannot have a great user experience without acceptable usability - a product that confuses or frustrates people fails at the most basic level. But excellent usability alone does not guarantee a great experience. A product can be easy to use and still feel cold, untrustworthy, or irrelevant to the person using it.

Think of usability as the floor. Without it, nothing else matters. With it, you have a foundation to build something genuinely good on top of.

## Nielsen's Five Components of Usability

Jakob Nielsen, one of the most influential figures in usability research, identified five quality components that together describe how usable an interface is - the same thinking underpins [Nielsen's 10 usability heuristics](/blog/nielsens-10-usability-heuristics/), a related framework for evaluating interfaces against established design principles. These five components remain the clearest framework available.

**Learnability**

How easy is it for users to accomplish basic tasks the first time they encounter the design?

A learnability problem is one of the most common issues in real products. Users arrive with a mental model built from other software they have used. If your navigation, terminology, or interaction patterns diverge sharply from their expectations, they have to learn a new system before they can do anything useful.

Example: a project management tool that uses completely non-standard icons for "archive", "delete", and "move" will force every new user to spend time decoding the interface before they can get any work done.

**Efficiency**

Once users have learned the design, how quickly can they perform tasks?

This component matters most for products that people use repeatedly. A first-time visitor to an e-commerce site can tolerate a slightly longer path to checkout. A warehouse picker using a stock management system fifty times a day cannot afford a slow or convoluted workflow - every extra tap has a real cost.

Example: keyboard shortcuts, saved preferences, and smart defaults all improve efficiency for experienced users without necessarily complicating things for newcomers.

**Memorability**

When users return after a period of not using the product, how easily can they re-establish proficiency?

This is distinct from learnability. A user might learn a system thoroughly, go away for three months, and then struggle to remember how to do things that were once second nature. Consistent, predictable layouts and familiar interaction patterns reduce the cognitive effort required to re-engage.

Example: if a software product moves its main navigation between versions, returning users will spend time relearning something they had already mastered. That relearning cost is a memorability failure.

**Errors**

How many errors do users make, how severe are those errors, and how easily can they recover?

This component covers two things: error prevention (designing so that mistakes are hard to make) and error recovery (making it easy to undo or correct a mistake when it does happen). Nielsen's [heuristic evaluation](/blog/heuristic-evaluation-ux-design/) framework dedicates two of its ten heuristics specifically to error handling - a sign of how important this area is.

Example: a "delete account" button placed next to "edit profile" without a confirmation step is a preventable error risk. A destructive action with no undo is a recovery failure.

**Satisfaction**

How pleasant is it to use the design?

This is the component closest to UX in the broader sense, but Nielsen frames it narrowly: satisfaction here refers to the subjective experience of using the interface, not the emotional arc of the whole product relationship. Is it frustrating? Confusing? Does it feel clunky?

Example: a form that clears all your input when you make a validation error creates real dissatisfaction. Small irritants like this compound quickly and leave users with a lasting negative impression of the product.

## How Usability Is Measured

Usability is not a feeling. It is measurable, and measuring it properly is one of the most valuable skills a UX designer or researcher can have.

**Usability testing**

The gold standard. You recruit participants who represent your target users, give them realistic tasks to complete, and observe. You are not asking them what they think about the interface; you are watching what they do with it. Where do they hesitate? Where do they go wrong? Where do they give up? Our [usability testing guide](/blog/usability-testing-guide/) covers how to plan and run these sessions in detail.

Moderated testing (where a researcher is present to ask follow-up questions) gives richer data. Unmoderated remote testing scales further and can reach users in their natural context. Both have their place.

**Task success rate**

What percentage of users complete a given task successfully? This is the most direct measure of effectiveness. You define what "success" looks like before the test - not afterwards - and record whether each participant gets there.

**Time on task**

How long does it take a user to complete a task? Faster is not always better - some tasks benefit from reflection - but if users are spending significantly longer than expected on something that should be simple, that is a signal worth investigating.

**Error rate**

How often do users make mistakes during a task? Which steps generate the most errors? High error rates on specific steps point directly to design problems that need attention.

**Post-task questionnaires**

Standardised scales like the System Usability Scale (SUS) let you quantify subjective satisfaction in a way that is comparable across products and over time. As a rough guide, a SUS score above around 68 is often treated as above average, though context matters - check the original SUS literature for interpretation guidance. A score well below that is a clear signal that usability work is needed.

## Practical Ways to Improve Usability

Identifying usability problems is useful. Fixing them is the point.

**Start with user research, not assumptions**

Designers and developers are almost never representative of their users. The assumptions you bring to a design problem - about what is obvious, what is familiar, what is easy - will not match the experience of someone coming to the product fresh. Primary research, even a small number of usability test sessions, will surface problems that no amount of internal review would catch. For a broader look at the methods available, our guide to [UX research methods](/blog/ux-research-methods/) covers the main approaches and when to use each.

**Apply established conventions**

Users have expectations built from years of using other products. Navigation at the top or left. Links in blue or underlined. Search in the top-right. Deviating from these conventions creates unnecessary learning load. Originality has its place in design, but usability is not usually improved by reinventing patterns that already work. Accessibility standards such as WCAG 2.2 encode many of these conventions in a form that also makes products usable for people with disabilities - our [Accessibility for UX course](/courses/ux-accessibility/) covers how to apply them in practice.

**Reduce cognitive load**

Every choice, every piece of unfamiliar terminology, and every visual element a user has to process takes effort. Progressive disclosure (showing only what is needed at each step), clear labels, and sensible defaults all reduce the cognitive effort required to use a product.

**Test early and often**

Usability testing does not need to wait for a polished prototype. Paper sketches and low-fidelity wireframes can reveal fundamental navigation and labelling problems. Testing a rough version early is far cheaper than fixing a polished version late. See [UX design laws and principles](/blog/ux-design-laws-principles/) for the underlying principles that inform these decisions.

**Make errors hard and recovery easy**

Review your interface for places where a user could make a costly mistake. Add confirmation steps for destructive actions. Provide clear error messages that explain what went wrong and how to fix it - not just "error 400" or a red border with no explanation. Autosave and undo are two of the most user-friendly features any product can offer.

**Pair usability testing with heuristic evaluation**

Usability testing tells you where real users struggle. [Heuristic evaluation](/blog/heuristic-evaluation-ux-design/) is a structured expert review against established usability principles that can identify likely problems faster and without recruiting participants. The two methods complement each other well: heuristic evaluation helps you prepare a cleaner prototype for testing; testing reveals issues that expert review misses.

## Usability Is a Learnable Skill

None of this is mysterious. Usability thinking is a set of principles and habits that any designer can develop - knowing the frameworks, building the habit of observing real users, and being honest about where a design is not working.

If you are early in your UX career, developing a strong usability instinct is one of the most transferable skills you can build. It applies to every product type, every industry, and every team.

At UX Academy (myuxacademy.com), usability research and testing are woven into the [beginner UX design course](/courses/beginner-ux-design/) from day one - not tacked on as theory, but practised on real design problems with guidance from working practitioners. Browse our [courses](/courses/) to see how the curriculum is structured, or join a [free UX/UI masterclass](/masterclass/free-ux-ui-masterclass/) to see whether the way we teach matches how you want to learn.


---

# How to Switch Careers to UX Design in the UK

URL: https://myuxacademy.com/blog/switching-careers-to-ux-design/
Thinking about switching careers to UX design? This honest guide covers transferable skills, training options, timeline, and your first role in the UK.

Changing careers is never a small decision. This guide is written specifically for the career-changer: how to recognise the transferable skills you already have, weigh the move against your current job, and manage the transition without burning out. If you have been wondering whether UX design is actually achievable for someone without a design degree, without an art background, and without years of spare time - the honest answer is yes. Thousands of working adults have made this switch, and this guide walks you through what it actually takes.

For the general step-by-step roadmap into UX - the skills, tools and portfolio sequence that applies to anyone, not just career-changers - see our guide on [how to become a UX designer](/blog/how-to-become-a-ux-designer/).

## Who switches into UX design - and why

UX designers come from almost every professional background imaginable. The field is relatively young, which means the majority of practitioners did not start there. At UX Academy (myuxacademy.com), the people who join our [Beginner UX (AI) Design course](/courses/beginner-ux-design/) have typically spent between five and fifteen years in roles like:

- **Marketing and communications** - already comfortable with audience thinking, messaging, and data
- **Teaching and training** - strong on empathy, explaining complexity clearly, and reading a room
- **Customer support and service** - fluent in user frustration, expectations, and the gap between what products promise and what they deliver
- **Psychology and counselling** - brings genuine understanding of how people think and behave
- **Project management and operations** - organised, process-minded, good at working across teams
- **Software development** - understands technical constraints and can speak credibly to engineers
- **Admin and office roles** - often underestimated, but these people know workflow pain intimately

What do all of these have in common? They involve understanding other people, solving problems, and communicating clearly. Those are the foundations of UX work.

The reasons people switch are equally varied. Some are burned out in their current role. Some have been made redundant and are using the disruption as a pivot point. Others have been quietly jealous of UX designers for years and finally decided to do something about it. All of these are valid starting points.

## Do you need a degree? Do you need to be creative?

No to both.

There is no licensing requirement for UX design. Employers hire based on portfolio, problem-solving ability, and communication skills - not on what degree you hold or whether you have one at all. A psychology graduate, a school leaver who self-taught, and a former nurse who retrained in their forties can all be competitive candidates if their portfolio demonstrates the right thinking.

The 'creative' concern trips people up more than it should. UX design is not about making beautiful things from scratch - that is closer to UI or [graphic design](/blog/ux-design-vs-graphic-design/). UX is about understanding users, mapping their journeys, identifying friction, and designing solutions to real problems. The deliverables (wireframes, prototypes, research findings) need to be clear and usable, not artistic. You will learn to use Figma to produce these. Most people with no prior design tool experience are producing competent wireframes within a few weeks of focused practice.

If you want to understand more about what the discipline actually involves, the post [what is UX design](/blog/what-is-ux-design/) covers it without the jargon.

## Transferable skills are real - but context matters

Your existing skills are assets. The important thing is knowing how to translate them.

A former teacher who can articulate 'I ran usability tests with 12 students and redesigned the onboarding flow based on where they got stuck' is describing UX work. A former marketing manager who says 'I used customer journey mapping to redesign our email nurture sequence and reduced drop-off by a measurable amount' is demonstrating UX thinking even if they never called it that.

The skill is not just having the background - it is learning to frame it in UX language and connect it to a portfolio project. This is something a good structured course will help you do deliberately, not accidentally.

## A realistic step-by-step path

There is no single route, but most successful career changers follow something close to this sequence:

**1. Learn the fundamentals**
Understand the UX process: research, define, ideate, prototype, test. Learn what user interviews look like, what affinity mapping is, what a journey map shows. This is the conceptual foundation. Without it, Figma is just a drawing tool.

**2. Learn Figma**
Figma is the industry standard tool. You do not need to master every feature - you need to be able to produce wireframes, simple prototypes, and a clean, readable layout. Most beginners reach a working level within four to six weeks of regular use.

**3. Work on real projects**
Portfolio projects are the single most important output of your training period. 'Real' does not mean paid client work - it means projects with a genuine problem, real or realistic users, and a documented process. Redesigning a frustrating app you actually use, solving a problem for a local charity, or tackling a brief from a public design competition all count.

**4. Build your portfolio**
Two or three strong case studies beat ten shallow ones. Each case study should show your process - not just the final screens. What was the problem? Who were the users? What did your research reveal? What did you test, and what did you change? This is what hiring managers are looking for. The [UX design portfolio guide](/blog/ux-design-portfolio-guide/) covers this in detail.

**5. Network and apply**
LinkedIn is important. Attend UX meetups (there are active communities in London and most major UK cities). Tell people what you are doing. Many junior UX roles are filled through referral or informal networks before they are advertised. Apply to roles even when you feel you are not quite ready - the process of applying and interviewing is itself a learning loop.

## A realistic timeline

Most career changers who complete structured training and put in consistent work are job-ready within six to twelve months of starting from scratch. That range is wide because it depends heavily on:

- How much time you can commit per week (10 hours per week is a minimum; more accelerates progress)
- How quickly you complete and iterate on portfolio projects
- The market you are entering and how actively you network and apply

It is worth being honest: the junior UX market is competitive. You will likely not get the first role you apply for, and that is normal. The people who succeed are the ones who treat rejection as data, keep refining their portfolio, and stay consistent.

That said, UX is a field with strong long-term demand. Once you are past the junior hurdle, career progression tends to be solid - and the range of industries you can work in is genuinely wide.

## Why live small-group teaching beats self-paced for career changers

Self-paced online courses are cheap and flexible. They are also the format where most people quietly stop. For someone in a busy life with an existing job, children, or other commitments, 'do it whenever you want' usually becomes 'do it never'. The closure of CareerFoundry in early 2026 - a large self-paced UX school - left many mid-course students without support or a recognised qualification; if you are weighing up providers, it is worth checking the [CareerFoundry alternative](/careerfoundry-alternative/) page for context on what to look for in a course.

Live, small-group teaching addresses the two things that actually stop career changers from finishing:

**Accountability.** When a cohort is moving through material together and an instructor is expecting you to show up, you show up. The social contract is a genuine motivator.

**Feedback.** Self-paced video courses cannot tell you that your wireframe is ignoring a key accessibility principle, or that your research questions are leading the participant. A live instructor, and peers who are at the same stage as you, can. The feedback loop is what converts learning into skill.

This is the reason UX Academy runs live, instructor-led cohorts in small groups rather than offering pre-recorded content. If you want to see the teaching format in action before committing, the [free UX/UI masterclass](/masterclass/free-ux-ui-masterclass/) is the right starting point.

You might also find it useful to read [you do not need to be creative to become a UX designer](/blog/ux-designer-without-being-creative/), which addresses one of the most common pieces of self-doubt that holds career changers back.

## Landing the first role

The first role is the hardest. Once you have twelve months of professional experience, the market opens up considerably.

A few things that consistently help:

- **Apply broadly.** In-house design teams, agencies, startups, and the public sector all hire junior UX designers. Do not limit yourself to one sector or company type. Our overview of [UX design jobs in the UK](/blog/ux-design-jobs-uk/) covers where roles are concentrated and what employers are looking for right now.
- **Be specific about your background.** If you came from healthcare, a health tech company is a genuine asset for you. If you came from education, edtech companies should be on your list. Your prior domain knowledge is a differentiator at junior level.
- **Accept that a hybrid role may come first.** Some people land a dedicated UX role immediately. Others start in a role that is 50 per cent UX and 50 per cent something else. Both get you the experience you need to move forward.
- **Keep building.** Your portfolio should grow after you finish training, not sit still. New projects, new methods, new tools - hiring managers can see whether someone stayed curious. When you are ready to start applying, it is worth reading up on [common UX design interview questions](/blog/ux-design-interview-questions/) so you can speak confidently about your process and decisions.

## Is this right for you?

Career changes are hard. This one is achievable, but it requires real time investment, persistence through a competitive junior market, and the willingness to keep going when progress feels slow.

If you are reading this because you are genuinely curious about whether UX is the right move, the best next step is to experience the subject properly before committing money to training. Our [free UX/UI masterclass](/masterclass/free-ux-ui-masterclass/) is a live session designed exactly for that - no obligation, no pitch pressure, just a chance to see whether the thinking resonates.

When you are ready to go further, the [Beginner UX (AI) Design course](/courses/beginner-ux-design/) is where career changers in the UK start their structured training with UX Academy. You can also browse all [courses and learning options](/courses/) to understand what is available.

The switch is possible. It takes effort. And it is worth doing properly.


---

# Product Design vs UX Design: The Difference

URL: https://myuxacademy.com/blog/product-design-vs-ux-design/
Product design vs UX design: clear definitions, how the roles overlap, where they differ in scope and pay, and which path suits your goals.

This post compares product design and UX design as disciplines - what each field covers, how their scope, mindset and pay differ, and which direction to aim your career in. If you have spent any time researching a design career, you have almost certainly run into both terms and wondered whether they describe the same thing. Sometimes they do. Sometimes they do not. The honest answer is that the line between product design and UX design is blurry, varies by company, and has shifted significantly over the last decade. This guide gives you a clear framework for understanding both disciplines, where they genuinely differ, and how to decide which to aim for.

If instead you want a side-by-side breakdown of the job titles and day-to-day responsibilities, read our companion post on [UX designer vs product designer](/blog/ux-designer-vs-product-designer/).

## What is UX design?

UX stands for user experience. A UX designer's core focus is how people experience a product - how easy it is to understand, how efficiently it lets users complete tasks, and how it makes them feel along the way.

The day-to-day work typically includes user research (interviews, usability testing, surveys), defining user journeys and flows, wireframing, prototyping, and handing off detailed specifications to engineers. The north star is usability and user satisfaction: does the product work well for the people using it? If you want to see how this plays out step by step, our guide to the [UX design process](/blog/ux-design-process/) covers each phase in detail.

UX design is deeply rooted in research methods and iterative testing. A strong UX designer can articulate *why* a design decision serves users, not just what it looks like. The discipline draws heavily from psychology, cognitive science, and human factors research.

If you want to understand UX design from the ground up, our post on [what UX design is and what UX designers actually do](/blog/what-is-ux-design/) is a good starting point.

## What is product design?

Product design is a broader remit. A product designer still does much of what a UX designer does - research, flows, wireframes, prototypes - but they are expected to think beyond the user experience layer and into business outcomes, product strategy, and metrics.

Where a UX designer might ask "is this flow usable?", a product designer is also asking "does this feature move the retention metric we care about?" and "does building this now make sense given the product roadmap?". They work more closely with product managers, engineers, and sometimes data analysts. They are often involved in defining what to build, not just how to design what has already been scoped.

Product designers typically own the full design of a feature end-to-end: from the initial problem framing, through interaction design, visual/UI design, and into measuring whether the shipped thing actually worked.

The visual design layer - UI design - also falls more explicitly under the product designer's remit in most companies. If you want to understand how UX and UI relate to each other separately, our post on [UX vs UI design](/blog/ux-vs-ui-design/) covers that clearly.

## The large overlap - and why job titles vary so much

Here is the complicating factor: at a huge number of companies, the titles "UX designer" and "product designer" are used interchangeably to describe the same job. You will find companies where the senior UX designer role is functionally identical to a product designer role at a different company. Titles follow company convention, not a universal standard.

In practice, the distinction is most meaningful when you compare:

- **Large tech companies (Google, Meta, Amazon):** Often have both titles, with product designers tending to be more senior, more embedded with product teams, and more commercially oriented. UX researchers, UX writers, and interaction designers sit alongside them as specialist roles.

- **Mid-size product companies and scale-ups:** Often use "product designer" as the default title for everyone doing design work, end-to-end. UX designer titles are less common here.

- **Agencies and consultancies:** More likely to use "UX designer" and to specialise by discipline (research, strategy, interaction design).

- **Early-stage startups:** Often just call everyone a designer and expect them to cover everything.

The safest way to understand any role is to read the actual job description rather than rely on the title alone.

## How the day-to-day differs in practice

Despite the overlap, there are consistent practical differences worth understanding before you commit to a direction.

**Scope of responsibility.** A UX designer in a larger organisation may hand over to a visual or UI designer once the interaction design is done. A product designer typically owns the work through to final visual polish. This means product designers need to be comfortable with typography, colour systems, component libraries, and high-fidelity UI - not just wireframes.

**Proximity to business metrics.** Product designers are routinely expected to understand conversion rates, activation rates, retention, and similar product metrics. They attend sprint reviews, contribute to roadmap discussions, and may be asked to present design rationale in terms of business impact. This is less often expected of a UX designer in a specialist role.

**Research depth.** Specialist UX roles (particularly at larger companies) may go deep into research methods - running longitudinal studies, diary studies, or large-scale quantitative research. A product designer usually does lighter-touch research (quick user interviews, usability tests) and moves faster. Neither approach is better; they suit different contexts. Our overview of [UX research methods](/blog/ux-research-methods/) covers the full range, from quick guerrilla testing to longer-form studies.

**Collaboration pattern.** UX designers in larger teams often collaborate with a dedicated product designer who handles the UI and handoff. Product designers tend to be a single point of contact for an entire product area, working directly with engineers and PMs.

## Seniority and pay

Product designer roles in the UK tend to attract higher salaries than entry-level UX designer roles, though this is partly because the title is more often applied at mid-to-senior levels. At junior level, the pay gap is smaller. At senior and lead level, product designers with a strong track record of shipping features that moved metrics can command significantly more.

For a detailed look at what UX designers earn at different levels in the UK, see our post on [UX designer salaries in the UK](/blog/ux-designer-salary-uk/).

## Which should you aim for?

This depends on what motivates you and where you want your career to go.

**Aim for UX design (as a specialism) if:**

- You are genuinely excited by research - talking to users, analysing behaviour, and turning findings into insights is the part of the work you find most interesting
- You want to become a deep specialist (UX researcher, UX strategist, content designer) rather than a generalist
- You are interested in agency work, where UX consulting and research projects are common
- You prefer to focus on one layer of the problem deeply rather than owning a feature end-to-end

**Aim for product design if:**

- You want to own the full outcome of your work, from problem definition through to shipped UI
- You are interested in working inside product teams and understanding how the business works, not just how users behave
- You want to move into product management or design leadership later - product design is a more natural bridge
- You are motivated by measurable impact (did this feature actually work?) rather than process quality alone

For most people entering the field in 2026, product design is the more commercially valuable direction. It is broader, it pays more at senior levels, and it keeps more doors open. That said, strong specialist UX researchers are in genuine demand at companies large enough to need them - it is not a lesser path, just a narrower one.

## How to move from UX into product design

Many people start in UX and move into product design as they gain seniority. The transition usually requires:

**Building visual/UI fluency.** If your background is research-heavy UX, you will need to get comfortable working in design systems, producing high-fidelity UI in Figma, and understanding component libraries. This is learnable - it is a craft skill, not an innate ability.

**Getting closer to the metrics.** Volunteer to sit in on product reviews, ask to be included in OKR discussions, and start framing your design decisions in terms of what they are trying to move. Product designers who can talk about their work in business terms are valued disproportionately.

**Shipping.** The most common gap between UX designers and product designers is that the former sometimes lack evidence that their designs actually shipped and had an impact. Build a portfolio that shows you took projects from research through to final delivery and, where possible, what happened after launch.

**Expanding scope deliberately.** When you are given a brief, push back on the framing as well as solving the brief. Ask whether the problem is correctly defined. Propose alternatives. This is the mindset shift that marks the transition from execution to product thinking.

## A note on job searching

When you are looking for your first or second role, do not filter too hard by title. A "junior UX designer" role at a product company where you would own end-to-end design is more valuable career experience than a narrow "product designer" title at a company where you are doing one small part of the process. Read job descriptions carefully and ask in interviews what design ownership actually looks like in practice.

The titles will keep shifting. The underlying skill of understanding users deeply, making design decisions that serve business goals, and shipping work that improves people's experience - that is stable regardless of what the industry calls it next.

---

If you want to build the skills that cover both UX and product design in a practical, live environment, take a look at the [UX Academy (myuxacademy.com) Product Design course](/courses/product-design/) or explore all [courses at UX Academy](/courses/). The course is taught live by our lead instructor, Natalia Veretenyk, and her team. If you are not sure where to start, the [free UX and UI masterclass](/masterclass/free-ux-ui-masterclass/) is a no-commitment way to see how we teach and whether it is the right fit for you.


---

# Is UX Design a Good Career in 2026? An Honest Answer

URL: https://myuxacademy.com/blog/is-ux-design-a-good-career/
Is UX design a good career in 2026? We cover the real upsides, the honest downsides, how AI is changing the role, and who this career actually suits.

The short answer is yes - but only if you go in with your eyes open.

UX design offers real demand, good pay, remote-friendly work, and the chance to solve genuinely interesting problems. It also has a competitive junior market, requires continuous learning, and is being reshaped by AI in ways that matter. This post gives you the honest picture, not the sales pitch.

## What "good career" actually means

Before we get into UX specifically, it is worth being clear about what makes any career worth pursuing. Most people weigh up three things: is there paid work available, does it pay reasonably well, and will I find it meaningful day to day? UX design holds up on all three - but the weight of each depends on where you are in your career.

A junior designer in their first year will feel the competitive market acutely. A mid-weight designer with three years of solid portfolio work will find themselves in a much more comfortable position. A senior designer with a specialism - accessibility, fintech, healthcare, enterprise software - will find consistent demand and strong earning power. The career rewards staying in it.

## The genuine upsides

**Demand for skilled designers is real.** Every digital product - app, website, internal tool, checkout flow - needs someone thinking about how users experience it. Companies that tried to skip UX years ago are mostly the ones with support tickets piling up and conversion rates they cannot explain. Demand is not uniform (more on the junior market below), but it is not manufactured either. For a grounded look at where roles are advertised and what employers are hiring for, see our guide to [UX design jobs in the UK](/blog/ux-design-jobs-uk/).

**Pay is genuinely good for a non-technical role.** Mid-career UX salaries in the UK sit comfortably above the national median. In London, senior roles regularly reach into the sixties and seventies. The [UX designer salary UK](/blog/ux-designer-salary-uk/) post covers this in detail, but the headline is: if you make it past the junior stage, you are in decent financial territory.

**The work is remote-friendly by default.** UX is screen-based work. Figma, Zoom interviews, Miro, Notion - the entire toolkit runs in a browser. Many UX roles are fully remote or hybrid as a standard offering, not a hard-won perk. For anyone who needs flexibility around family, health, or geography, that matters.

**You work across industries.** UX skills transfer. A designer who has worked in e-commerce can move into healthcare SaaS. Someone from a consultancy can go in-house at a fintech. The discipline is consistent enough that your skills are portable in ways that, say, a deep specialist in one legacy software platform is not.

**The problems are genuinely interesting.** UX work is fundamentally about understanding people and designing systems that work better for them. If you are curious about human behaviour, enjoy solving puzzles, and find satisfaction in making something easier to use - the work is engaging. Not every day, and not every project. But as careers go, it is more often intellectually alive than not.

## The honest downsides

**The junior market is competitive.** This is the most important thing to say honestly. There are many people training into UX right now, and there are not unlimited entry-level roles. Many junior applications go unanswered. The candidates who break through have portfolios that show genuine thinking - real research, documented decisions, explained tradeoffs - not just polished mockups. If you train and expect the work to come to you, it will not. If you treat your job search as a campaign and your portfolio as a continuous project, your chances are significantly better.

**You need to keep learning.** The tools, the methods, and the expectations shift. What passed for a portfolio in 2020 does not pass in 2026. AI tools are changing how research synthesis, content generation, and prototyping work. Figma's feature set changes year on year. What does not change is the underlying skill of understanding users and designing for them - but the surface layer keeps moving. If continuous learning sounds like a burden rather than a given, any knowledge-work career will feel the same way.

**Portfolio pressure is real.** UX is a portfolio profession. Employers hire based on what you can show them, not what you claim you can do. Building a strong portfolio takes time, feedback, and honest self-assessment. Bootcamp graduates who rush out a portfolio of course projects and call it done often struggle. Those who take their portfolio seriously - do additional projects, document real thinking, treat each case study as something worth reading - stand out. (If you were training with CareerFoundry when it closed in early 2026, our [CareerFoundry alternative](/careerfoundry-alternative/) page covers realistic options for continuing your training.)

**Freelancing as a junior is hard.** Some people come into UX hoping to freelance immediately. In practice, clients hire freelance designers when they trust their judgment - which requires a track record. Most successful UX freelancers built that track record through employed roles first. There are exceptions, but they are exceptions.

## How AI is changing UX design - and what it is not doing

AI is reshaping the role. It is not ending it.

The tasks AI handles well: generating first-draft copy for UI, producing multiple variations quickly, transcribing and synthesising research interviews, writing alt text, building basic design system components. These are real efficiency gains. A designer who uses AI well can move faster and focus more time on the parts that require genuine judgment.

The tasks AI does not replace: deciding what problem to solve, running a user research session that gets beneath the surface, facilitating a workshop with stakeholders who disagree, making judgment calls about competing user needs, and explaining your decisions to a sceptical product manager. These require context, communication, and the kind of reading-a-room intelligence that current AI tools do not replicate.

The designers who will struggle are those who were doing rote work - copy-pasting from design systems, producing assets without much thought - and calling it UX. The designers who will thrive are those who genuinely understand users and can apply that understanding in a range of contexts. AI is, if anything, raising the bar for what counts as real UX contribution.

This shift is happening now, in 2026. If you are thinking about entering the field, go in with strong fundamentals - research methods, interaction design principles, portfolio thinking - not just tool proficiency. Tools change. Judgment compounds.

## Who this career suits

UX design genuinely works well for people who:

- Are curious about how and why people behave the way they do
- Enjoy working across teams (research, product, engineering, content, commercial) rather than alone
- Are comfortable with ambiguity - problems do not come with clear briefs attached
- Can communicate clearly in writing and in conversation
- Are willing to iterate rather than defend their first idea
- Have patience for the gap between seeing a problem and being able to fix it

It does not require a design degree. It does not require being "creative" in the artistic sense. [UX and UI design are different disciplines](/blog/ux-vs-ui-design/) - UX is far more about thinking than aesthetics. Most of the people who build successful careers in UX came from somewhere else entirely, and their previous experience - psychology, customer service, teaching, project management, engineering - turned out to be an asset.

Read more about what the day-to-day actually looks like in [what does a UX designer do](/blog/what-does-a-ux-designer-do/).

## Who it does not suit

It is worth being honest here too. UX design is not a great fit if you:

- Want to work largely in isolation and find collaboration draining
- Prefer a role where there is a correct answer and you can execute it cleanly
- Are not interested in the "why" behind design decisions - only the "what"
- Expect to pick up the tools and immediately be employable without significant portfolio work
- Are hoping to freelance immediately without building a track record first

None of these make you a less capable person. They just mean a different career might suit you better.

## A grounded outlook for 2026

UX design is not the "10x salary in six months" story some bootcamps implied a few years ago. It is a skilled knowledge-work career with real demand, decent pay, and meaningful work - that requires real effort to enter and real commitment to sustain.

The junior market is competitive. AI is raising the bar. The portfolio matters more than the certificate. These are not reasons to avoid the field; they are reasons to go in prepared.

The people who regret entering UX are usually those who were sold a shortcut that did not exist. The people who are glad they made the move are usually those who took it seriously from the beginning - who did the thinking, built the portfolio, treated the job search as part of the work, and stayed curious once they were in.

## What to do if you are seriously considering it

If you want to understand what the career involves before committing to training, our free [UX/UI Masterclass](/masterclass/free-ux-ui-masterclass/) at UX Academy (myuxacademy.com) is a good place to start. It covers what UX designers actually do, how the industry works, and what the entry path looks like - without the sales pressure.

If you want to go further, our [Beginner UX (AI) Design course](/courses/beginner-ux-design/) is built for career-changers. Small cohorts, live sessions taught by our lead instructor, Natalia Veretenyk, and her team, real project work, and a portfolio you can actually use. [See all our courses](/courses/) and compare what suits where you are right now.

If you are weighing this against other options - including whether to retrain at all - the post on [switching careers to UX design](/blog/switching-careers-to-ux-design/) covers the practical questions: timeline, cost, transferable skills, and what the first year looks like.

The career is worth it if you are suited to it and go in prepared. That is as honest an answer as we can give.


---

# What Is Information Architecture in UX Design?

URL: https://myuxacademy.com/blog/information-architecture-ux-design/
Learn what information architecture is in UX design, why it matters, and how to use card sorting, tree testing, and sitemaps to build better products.

If you have ever landed on a website and spent several minutes hunting for something that should have been obvious, you have experienced the consequences of poor information architecture. The content was probably there. The problem was that nobody had thought carefully about how to organise it.

Information architecture - often shortened to IA - is the practice of organising, structuring, and labelling content so people can find and understand it. It sits at the foundation of almost every UX project, yet it is one of the disciplines beginners hear about last. This guide explains what IA is, why it matters, and how to do it well.

## What Information Architecture Actually Means

The term comes from a 1976 book by Richard Saul Wurman, who used it to describe the science of organising information so it is usable. In UX, it has a more practical meaning: deciding what content exists, how it is grouped, what it is called, and how users move through it.

IA is not about visual design. It is not about which shade of blue a button should be or how much white space to use. Those decisions come later. IA happens before that - at the stage where you are asking: what does this product need to contain, and how should all of that be arranged?

A solid IA means users can predict where things will be. They develop a mental model of the product that matches reality. When IA is weak, users get lost, give up, or lose confidence in the product entirely.

## Why IA Matters for Real Products

Good IA affects two things directly: findability and understandability.

**Findability** is whether a user can locate what they are looking for. On an e-commerce site, can they get to the right product category without a search? On a banking app, can they find where to set up a direct debit? If the answer is "only if they already know where to look," the IA has failed.

**Understandability** is whether users can make sense of what they find. Labels matter here. If a navigation item says "Resources" when the user is looking for "Templates," they may not click it even though the templates are inside. The content exists; the label does not communicate it.

Both matter because users judge products quickly. If a site is confusing in the first thirty seconds, most people leave. They do not file a support ticket. They just go somewhere else.

## The Four Core Components of IA

Peter Morville and Louis Rosenfeld, whose book "Information Architecture for the Web and Beyond" became a standard reference, defined IA using four main systems. These are still a useful framework.

**Organisation systems** are the schemes that determine how content is grouped. Content can be organised by topic, by task, by audience, by time, or by location. Most products use several schemes at once - a news site might organise by topic in the main navigation but by date on an individual author page.

**Labelling systems** are the words used to represent categories and actions. Labels should match the language users actually use, not internal business terminology. A company might call something "Client Acquisition" internally; users call it "Get new customers." The label should follow the user.

**Navigation systems** are the mechanisms that let users move through the content - menus, breadcrumbs, tabs, filters, contextual links. Navigation is what makes the IA visible to the user. It is the surface expression of the underlying structure.

**Search systems** handle how users query content and how results are returned. On large or content-heavy sites, search is often the primary way people find things. The quality of search depends partly on how well the underlying content has been tagged and categorised - which brings it back to IA.

## How IA Relates to Site Structure and Navigation

People sometimes use the terms IA, site structure, and navigation interchangeably. They are related but not the same.

**Site structure** is the actual hierarchy of pages and content - the parent/child relationships between sections. It is often represented as a sitemap. Structure is a product of IA decisions.

**Navigation** is the interface layer: the menus, links, and wayfinding cues that let users move through the structure. Good navigation reflects good IA, but you can have technically functional navigation built on a confused structure. Users will still get lost.

Think of IA as the architectural blueprint, site structure as the building that results, and navigation as the signage inside it.

## Key Research Methods for IA

You cannot guess at a good information architecture. You discover it through research with real users. The three methods most commonly used are card sorting, tree testing, and sitemapping.

### Card Sorting

Card sorting is a method where you write content topics or page names on individual cards (physical or digital) and ask users to group them in a way that makes sense to them. There are two main types.

**Open card sorting** gives users blank cards and asks them to create their own groups and name them. This is useful early in a project when you do not yet know how users think about the content. It reveals the mental models people bring.

**Closed card sorting** gives users a pre-defined set of categories and asks them to sort cards into those categories. This is useful for testing whether an existing or proposed structure makes sense to users. It answers the question: are my categories working?

Card sorting does not give you a final answer. It gives you patterns. If most users consistently group the same items together, that is a strong signal. If responses are scattered, the content may be ambiguous or the categories may need rethinking.

### Tree Testing

Tree testing evaluates an existing or proposed navigation structure. You present users with a text-only version of the navigation - no visual design, no images, just the hierarchy of labels - and give them specific tasks. "Where would you go to find information about cancelling your subscription?" The user clicks through the text tree to find their answer.

Because there is no visual design, tree testing isolates the structure itself. You can see exactly where people go, where they hesitate, and where they give up. It is particularly good for identifying mislabelled or misplaced items. Tools like Maze and Optimal Workshop support tree testing studies.

Tree testing is most useful after card sorting has informed a proposed structure, and before you invest heavily in visual design.

### Sitemaps and User Flows

A **sitemap** is a diagram showing all the pages or screens in a product and how they relate hierarchically. It is not the same as a user flow. A sitemap shows the structure; a user flow shows a path through it.

**User flows** map out the steps a user takes to complete a specific task - signing up, making a purchase, finding a specific piece of information. Flows help you check whether the IA supports the tasks users actually need to complete, and where the structure might create unnecessary steps or dead ends.

Both are working documents, not finished deliverables. They exist to help the team agree on structure and spot problems before anything is built.

## Principles of Good Information Architecture

There is no single right way to structure information, but there are principles that consistently produce better outcomes.

**Clear hierarchy.** Users navigate more confidently when there is an obvious top level, a clear set of second-level sections, and a predictable depth. When everything feels like it is at the same level, nothing feels navigable.

**Consistent labels.** Use the same term everywhere for the same thing. If you call something "Billing" in the navigation, do not call it "Payments" in the page title and "Subscription" in the help docs. Inconsistency forces users to guess whether they are in the right place.

**Scalable structure.** IA that works for twenty pieces of content may collapse when the product grows to two hundred. Design with growth in mind. Category schemes should be able to accommodate new content without requiring a full restructure every six months.

**Match user mental models.** The structure should reflect how users think about the subject matter, not how the business is organised internally. This is why research matters. Your internal logic is invisible to users. Building a [user persona](/resources/templates/user-persona/) before starting IA work is one of the most effective ways to keep that user perspective grounded in real data rather than assumptions.

**Minimal overlap between categories.** When items could plausibly live in multiple places, users have to guess where to look. If overlap is unavoidable, provide clear signposting or cross-links so users are not penalised for making a reasonable but wrong choice.

## Signs of Poor Information Architecture

If any of the following describe a product you are working on, IA is worth revisiting.

Users rely almost entirely on search rather than navigation - often a signal that the navigation structure does not reflect how users think. Frequent calls or messages asking where something is. High drop-off rates on pages that should be intermediate steps in a journey. Analytics showing users visiting the same page multiple times before completing a task. Stakeholders regularly debating where new content should "live" because there is no clear logic.

None of these problems are solved by a redesign that only touches visual design. They require going back to the structure.

## IA as a Foundation Skill

Learning IA makes you a better UX designer because it forces you to think structurally before you think visually. Many junior designers jump straight to wireframes. Designers with IA skills spend time before that stage asking harder questions: what does this product actually need to contain, who needs to find what, and what is the clearest way to organise it? Understanding where IA sits within the broader [UX design process](/blog/ux-design-process/) helps you know when to do this work and how to hand it forward.

That thinking shows up in every deliverable afterwards - more purposeful wireframes, navigation patterns that actually match user behaviour, fewer structural redesigns six months after launch.

If you want to understand where IA fits in the broader picture of UX, [what is UX design](/blog/what-is-ux-design/) is a good place to start. For how IA connects to whether products are actually easy to use, see our post on [usability in UX design](/blog/usability-in-ux-design/). Once a structure is in place, a [heuristic evaluation](/blog/heuristic-evaluation-ux-design/) is a practical way to audit whether the navigation labels and hierarchy hold up against established usability principles before investing in user testing. And if you are curious about the research and problem-framing process that usually precedes IA work, [design thinking in UX](/blog/design-thinking-ux/) covers the full approach.

## Learning IA Through Practice

IA is one of those disciplines where reading about it only gets you so far. The real learning happens when you do a card sort with actual users and see that your assumed groupings make no sense to anyone but you. Or when a tree test reveals that nobody can find the most important page on the site because the label is a piece of internal jargon.

At UX Academy (myuxacademy.com), IA is taught as a hands-on skill across our [beginner UX design course](/courses/beginner-ux-design/) - not as an isolated theory lecture, but integrated into real project work with feedback from our lead instructor, Natalia Veretenyk, and her team. You can see a full overview of what we cover on the [courses page](/courses/).

If you want a taste of how we teach before committing, our [free UX/UI masterclass](/masterclass/free-ux-ui-masterclass/) is a good starting point. It is a live, interactive session - not a recorded video - and covers core UX concepts including how structure and research feed into real design decisions.


---

# How UX Affects SEO: Why Good Design Is Now a Ranking Factor

URL: https://myuxacademy.com/blog/how-ux-affects-seo/
Google increasingly rewards good user experience. Learn how Core Web Vitals, mobile design, IA, and accessibility directly improve your search rankings.

For years, SEO and UX were treated as separate disciplines. SEO teams chased keywords and backlinks; designers focused on usability and aesthetics. The two worlds rarely overlapped, and when they did, it was usually a turf war over page layouts and heading structures.

That separation is now largely obsolete. Google has spent the last several years building user experience signals directly into its ranking systems. The clearest proof of this is the Page Experience update and the formal introduction of Core Web Vitals as ranking factors. Understanding how UX affects SEO is no longer optional knowledge for designers - it is central to the job.

This post explains the connections clearly, without invented statistics or vague claims. If you want to build sites that rank and convert, keep reading.

## Why Google Cares About User Experience

Google's business model depends on sending its users to pages that satisfy their queries. If people click a search result, bounce immediately, and come back to Google looking for something else, that is a signal that the page failed. Google has always wanted to reward pages that genuinely help people - the shift in recent years is that it has developed increasingly sophisticated ways to measure that.

The result is that technical UX quality now has a direct and measurable relationship with search visibility. Better UX does not guarantee better rankings, but poor UX creates friction that suppresses them.

## Core Web Vitals: The Metrics That Matter

Core Web Vitals are a set of performance metrics that Google uses to assess the real-world experience of loading and interacting with a page. As of 2024, three metrics are used in ranking:

**Largest Contentful Paint (LCP)** measures how long it takes for the largest visible element on the page - usually a hero image or heading block - to load. A slow LCP signals to users and to Google that the page is sluggish.

**Interaction to Next Paint (INP)** replaced the older First Input Delay metric in 2024. It measures the responsiveness of a page across all interactions, not just the first click. If buttons feel laggy or forms are unresponsive, INP will reflect that.

**Cumulative Layout Shift (CLS)** measures visual stability. If elements jump around while a page loads - because images have no declared dimensions, or ads load late and push content down - CLS will be poor. Layout instability is a usability failure that Google now penalises.

These are not abstract engineering metrics. They describe real user frustrations: pages that load slowly, feel unresponsive, or jump around mid-read. Improving them requires close collaboration between developers, designers, and performance engineers. A designer who understands Core Web Vitals can make decisions earlier in the process that prevent problems downstream.

## Mobile-Friendliness Is a Baseline Requirement

Google uses mobile-first indexing for the vast majority of sites. This means the mobile version of your page is what Google crawls, indexes, and uses to determine rankings - even for users searching on desktop.

A site that works perfectly on a large screen but is difficult to use on a phone will be ranked based on that poor mobile experience. Touch targets that are too small, text that requires zooming, or layouts that break on narrow viewports are not just usability problems - they directly affect how Google assesses the page.

Mobile-friendliness is now a baseline, not a bonus. It is worth noting that "mobile-friendly" is also a higher bar than it used to be. A page that technically passes Google's mobile usability test but is difficult or frustrating to navigate on a phone is still a problem from a ranking perspective, because engagement signals will suffer.

## Engagement Signals: Dwell Time and Pogo-Sticking

Google does not publish a precise list of behavioural signals it uses in ranking, and any specific percentages you see quoted online should be treated with scepticism. What is well-documented and widely accepted is the concept of pogo-sticking: when a user clicks a search result, returns quickly to the search results page, and clicks a different result. This pattern strongly suggests the first page did not satisfy the query.

Good UX reduces pogo-sticking in several ways:

- **Matching content to intent.** If someone searches "how to conduct a UX audit", they want a practical guide - not a landing page selling UX audit services. If the page matches what the person actually needed, they stay.
- **Readability and scannability.** Users do not read web pages - they scan them. Clear headings, short paragraphs, bullet points where appropriate, and adequate contrast all reduce friction and keep people engaged.
- **Fast loading.** Even a well-designed page loses users if it takes four seconds to appear. Performance is part of UX.

Dwell time - the length of time someone spends on a page before returning to search - is a related concept. Google has not confirmed it as a direct ranking signal, but longer dwell time generally correlates with content that actually helped someone, which is exactly what Google wants to reward.

The practical implication: a designer who understands what users need from a given page, and structures content to deliver it clearly and quickly, is contributing directly to SEO outcomes.

## Information Architecture, Site Structure, and Crawlability

[Information architecture](/blog/information-architecture-ux-design/) is the practice of organising and labelling content so that users can find what they need. Good IA helps real users navigate a site - and it also helps search engines crawl and understand it.

A logical, shallow site structure means that important pages are reachable within a few clicks from the homepage. This helps Google discover and index them efficiently. Deep, tangled hierarchies make it harder for crawlers to find content, and harder for users to navigate to it. Both outcomes are bad.

Internal linking - connecting related pages to each other with descriptive anchor text - reinforces site structure. It distributes page authority across the site, signals topical relationships to Google, and gives users natural pathways through related content. This is why well-structured UX content sites tend to perform better in search than poorly connected collections of standalone pages.

On UX Academy's own [beginner UX design course](/courses/beginner-ux-design/) pages, for example, connecting related topics (usability, IA, research methods) through contextual links creates a better experience for someone exploring the subject - and a clearer topical map for Google to read.

## Accessibility: Better for Users, Better for Search

Web accessibility and SEO share a substantial amount of technical ground. Many of the practices that make a site more accessible also make it more crawlable and indexable.

Alt text on images, for example, exists primarily to help users with visual impairments understand image content via screen readers. It also gives Google text to associate with images, helping with image search and providing additional context for the page. A blank alt attribute fails both audiences.

Semantic HTML - using heading elements in a logical hierarchy, using `<nav>` for navigation, `<main>` for primary content, `<button>` for interactive controls - helps screen readers interpret page structure. It also helps Google understand which parts of the page are most important.

Colour contrast, keyboard navigability, and descriptive link text all contribute to a more accessible page that is also easier for search engines to parse. Treating accessibility as a checkbox compliance task misses this point. Good accessibility is good UX, and good UX increasingly correlates with better search performance.

## Content Readability and Matching Search Intent

Two of the most important SEO principles are also UX principles: write clearly, and give people what they actually came for.

Readability matters. Walls of dense text, passive constructions, and jargon without explanation all reduce comprehension and increase bounce rates. Plain English - particularly in UK contexts, where direct and no-nonsense writing is expected - serves readers and search engines alike.

Intent matching is arguably more important. Google classifies search queries by intent: informational (the person wants to learn something), navigational (they want to find a specific site), transactional (they want to buy or sign up), or commercial (they are researching before a decision). A page that correctly identifies and serves the intent behind a query will outperform a technically optimised page that misreads what the user actually wanted.

This is where UX research methods connect directly to SEO strategy. Understanding users - what they know, what they want, what they are trying to achieve - is the foundation of [UX design](/blog/what-is-ux-design/). It is also the foundation of content that ranks, because that content genuinely helps the people searching for it.

## UX and SEO Are Increasingly the Same Job

The practical implication of all of this is straightforward: the skills that make a good UX designer - understanding users, structuring information clearly, optimising performance, designing for accessibility, and creating content that matches real needs - are the same skills that improve search visibility.

This does not mean UX designers need to become SEO specialists. It means the two disciplines share enough common ground that a working knowledge of both makes you significantly more effective. A designer who understands Core Web Vitals will make better decisions about image loading and layout. One who understands search intent will write better page copy and structure content more effectively.

For anyone looking to build a career in UX, understanding this overlap is increasingly valuable. Organisations want designers who can contribute to outcomes - not just deliverables. Search visibility and conversion rates are outcomes. Knowing how your design decisions affect them is a real professional advantage.

If you want to learn UX design with practical skills built in from the start, the [UX Academy courses](/courses/) teach the methods that matter across real-world projects, led by our lead instructor, Natalia Veretenyk, and a team of working UX professionals. You can also [join a free masterclass](/masterclass/free-ux-ui-masterclass/) to see how we teach before committing to anything.

UX Academy is a live online UX design school based in the UK, run by Nomadic User Ltd. Find us at myuxacademy.com.


---

# How Long Does It Take to Become a UX Designer?

URL: https://myuxacademy.com/blog/how-long-to-become-a-ux-designer/
No single answer exists, but here's an honest look at the main paths, realistic timeframes, and what 'job-ready' actually means in UX design.

There is no single, honest answer to this question. Anyone who tells you "become a UX designer in 12 weeks, guaranteed" is selling you something. But that does not mean the question is unanswerable - it just means the timeframe depends on you, your starting point, and what you actually want at the end.

This post lays out the main paths, approximate timeframes, and what "ready" genuinely looks like. No fluff. No false promises.

This is the timeline question specifically; for the full roadmap - the skills, portfolio, and job search that get you there - see our main guide on [how to become a UX designer](/blog/how-to-become-a-ux-designer/).

## Why the timeframe varies so much

Before looking at specific paths, it helps to understand why estimates differ so wildly across the internet.

A lot of it comes down to how "becoming a UX designer" is defined. Some count only structured learning hours. Others count the months from first lesson to first job offer. Some only count full-time intensive study; others include the long tail of job searching. These are all measuring different things.

The other big variable: you. Not in a vague motivational sense - in a practical one. Someone moving across from product management, psychology, or graphic design is starting with a different foundation than someone coming from, say, retail or teaching. Neither background is disqualifying. But they affect how quickly certain concepts click, and how much of a portfolio you need to build from scratch before employers take you seriously.

## The three main paths

### 1. Intensive bootcamp (3-6 months full-time)

A full-time UX bootcamp typically runs somewhere between 12 and 24 weeks, with structured curricula, live instruction, and project deadlines that keep you moving. If you go in focused, keep up with the coursework, and build a strong portfolio during the course itself, some people are applying for junior roles within a month or two of finishing.

The honest caveat: the job market adds time. Even strong bootcamp graduates often spend 2-6 months job searching before landing their first role. So "bootcamp to employed" is realistically 6-12 months for many people.

This path suits you if you can afford to step away from work, or work part-time, and you learn better with structure, accountability, and other humans around you. Self-discipline still matters, but you have less scope to drift. When comparing bootcamps, it is also worth checking programme stability: CareerFoundry, one of the larger online UX schools, closed in early 2026, disrupting students mid-course. Our [CareerFoundry alternative](/careerfoundry-alternative/) page covers what happened and what to look for in a provider.

### 2. Part-time structured course (6-12 months)

This is the path most career-changers actually take. You keep your current job, study evenings and weekends, and work through a structured curriculum over a longer period. The learning is just as rigorous - it just fits around your life.

A realistic part-time commitment is roughly 8-12 hours a week. At that pace, a well-designed course takes 6-9 months to complete. Add portfolio refinement and job searching, and 12-18 months from first lesson to first UX role is a reasonable expectation for most people.

The risk with part-time study is inconsistency. Weeks go by without progress. You lose momentum. Then you restart, and the course feels harder than it should. The people who take longer on this path are rarely the ones who lack talent - they are the ones who keep stopping and starting.

Consistency, not speed, is the most important variable here.

[Our beginner UX design course](/courses/beginner-ux-design/) at UX Academy (myuxacademy.com) is designed for exactly this path - live sessions you attend in real time, so there is a rhythm built in, not just a pile of videos to watch whenever you get around to it.

### 3. Fully self-taught (variable, often 18+ months)

The self-taught path is real. Plenty of working UX designers never took a formal course. But the honest picture is that it usually takes longer than people expect, and the attrition rate is high - not because people lack ability, but because the lack of structure and feedback makes it very easy to spend a lot of time learning things in the wrong order, or practising without ever knowing whether what you are producing is actually good.

If you go self-taught, you will typically need to:

- Piece together your own curriculum from free and paid resources
- Seek out feedback on your work proactively (most people do not do this enough)
- Build a portfolio entirely under your own steam
- Develop a clear narrative around your work without any external frame of reference

It is possible. It requires genuine discipline and a willingness to seek out critique. And it often takes 18-24 months to get to a portfolio that holds up in interviews - longer if you are working in isolation without feedback from people who actually know the field.

## What "job-ready" actually means

Here is something that gets glossed over in a lot of course marketing: the number of hours or months you have studied is not what employers are hiring for.

They are hiring for:

- **A portfolio with 2-3 case studies** that show your thinking, not just your outputs. Not wireframes for their own sake. Evidence that you can identify a problem, make decisions, and explain them clearly.
- **The ability to talk through your work** in an interview without needing the slides to do the heavy lifting.
- **Basic proficiency in Figma** (and some understanding of how your designs will actually be built - you do not need to code, but "I don't really think about that" is a red flag).
- **Research fundamentals** - interviewing users, synthesising findings, knowing the difference between qualitative and quantitative data and when each is useful.
- **Collaboration and communication** - UX is not a solo discipline. Every job involves working with product managers, developers, and stakeholders with competing priorities.

You can develop all of this in a structured course of 6-9 months of consistent part-time work. The raw hours are less important than whether the work you produce demonstrates genuine thinking.

If you are unsure what good looks like, our [free UX masterclass](/masterclass/free-ux-ui-masterclass/) is a practical starting point - a real session, not a sales pitch, where you can see the kind of work we expect from students and decide whether this is the right next step.

## The variables that actually move the needle

Beyond path and starting point, a few other things have a significant effect on how quickly you get to your first role.

**Hours per week.** This sounds obvious, but the difference between 5 hours and 12 hours a week is not just pace - it is whether the learning compounds. UX thinking gets easier when you are doing it regularly enough that concepts stay fresh. Under a certain threshold, you spend too much time re-learning rather than building on what you already know.

**Transferable skills.** If you come from a role that involved presenting to stakeholders, writing clearly, or working with data, some of the hardest parts of UX - not the craft parts, the professional-practice parts - will feel more natural earlier. If you have worked in customer-facing roles, you probably already have sharper instincts about user needs than you realise. If you are switching from [another career](/blog/switching-careers-to-ux-design/), that background is not dead weight. It is context.

**The feedback loop.** One of the biggest things that separates people who improve quickly from those who plateau: regular, honest feedback on their work from people who know UX. This is why live courses, or any structure with a human in the loop, tend to produce stronger portfolios faster than purely self-directed learning. You cannot see your own blind spots.

**Finishing things.** Unfinished projects do not go in portfolios. An enormous number of people spend months on a case study that is "almost done" and never quite make it over the line. A completed project at 80% polish is more valuable than a perfect one that exists only in your head.

## A realistic picture of time-to-first-job

Here is an approximate summary, assuming consistent effort:

- **Full-time intensive study, strong portfolio:** first applications at 4-6 months; first role at 6-12 months
- **Part-time structured course, consistent:** first applications at 9-12 months; first role at 12-18 months
- **Self-taught, disciplined, active feedback:** first applications at 12-18 months; first role at 18-24+ months

These are approximations, not guarantees. The job market matters. Luck matters. How well you interview matters. Some people move faster; some take longer. Anyone who tells you otherwise does not know your situation.

What we can say honestly: the people who get there quickest are rarely the ones who studied the most intensively in a short burst. They are the ones who maintained consistent effort, sought out feedback, finished their projects, and kept going when it was slow.

You do not need to be exceptional. You need to be consistent.

## The bigger question underneath this one

People often ask "how long will it take?" when what they really want to know is: "is this worth it for me?"

That is a different question, and it is a reasonable one. Changing careers takes time, money, and energy. You are right to want a clear-eyed picture before committing.

If you are still working out whether UX design is the right direction, [our post on what UX design actually involves day-to-day](/blog/what-is-ux-design/) is a better starting point than any timeframe discussion. And if you are already reasonably sure but worried you have no relevant experience, [we have written honestly about that too](/blog/ux-job-with-no-experience/).

If you are ready to look at what a structured live course looks like, you can [browse all our courses](/courses/) or come along to a free masterclass session and see the teaching for yourself - led by our lead instructor, Natalia Veretenyk. No pressure, no countdown timers.

The honest version of this pitch: if you are prepared to put in consistent effort over 6-12 months, UX design is an achievable career change. Not for everyone, and not without real work - but achievable.


---

# Heuristic Evaluation: Nielsen's 10 Heuristics (2026)

URL: https://myuxacademy.com/blog/heuristic-evaluation-ux-design/
Nielsen's 10 usability heuristics with two examples each, a worked checkout evaluation, 0-4 severity ratings and a free evaluation template.

Heuristic evaluation is a usability inspection method in which a small group of evaluators independently reviews an interface against a set of established usability principles - called heuristics - and flags where the design breaks them. It does not require users, a lab, or a big budget. Done well, it surfaces the majority of obvious usability issues before they ever reach a real user, often in a single day.

This guide explains what heuristic evaluation is, walks through Nielsen's 10 usability heuristics with practical examples and common mistakes to watch for, gives you a repeatable step-by-step process, includes a worked example on a real checkout flow, and compares heuristic evaluation with usability testing so you know when to use which.

## What is heuristic evaluation?

Heuristic evaluation is a form of "discount usability". A handful of evaluators independently review an interface and judge it against recognised usability principles. It was introduced by Jakob Nielsen and Rolf Molich in 1990, and it remains a staple of practical UX work because it is quick to run and consistently good value.

It does not replace usability testing with real users, but it complements it. Heuristic evaluation catches the obvious, rule-breaking problems early, so that the more expensive user testing can focus on subtler, behavioural questions. Think of it as clearing the noise before the signal.

A widely cited finding from Nielsen's research is that around five evaluators tend to find roughly 75% of the usability problems in an interface. A single evaluator finds far fewer, because each person notices different things. This is why heuristic evaluation is usually done by a small group rather than one person.

## Nielsen's 10 usability heuristics

The most widely used set of heuristics is Jakob Nielsen's 10 general principles for interaction design, covered in depth in our guide to [Nielsen's 10 usability heuristics](/blog/nielsens-10-usability-heuristics/). They are broad rules of thumb rather than strict guidelines, which is exactly why they apply across almost any interface - web, mobile, dashboard, or physical kiosk.

### 1. Visibility of system status

The design should always keep users informed about what is going on, through appropriate, timely feedback. If you tap a button, something should acknowledge it. Progress bars, loading spinners, "saved" confirmations, and order-tracking pages all serve this principle.

**Second example:** A file upload that shows a percentage counter and a thumbnail preview as it processes. Without it, users click the button again, causing duplicate uploads - a completely avoidable failure caused solely by invisible status.

**Common mistake:** Showing a spinner with no time estimate for a process that takes 30+ seconds. The spinner satisfies the heuristic at the letter but not the spirit - users still feel stranded.

### 2. Match between the system and the real world

The design should speak the user's language, with words, phrases, and concepts familiar to them rather than internal jargon. Information should appear in a natural, logical order. A shopping cart icon works because it maps to a real-world concept.

**Second example:** A booking platform that shows availability as "1 slot remaining" rather than a database state code like "STATUS: PARTIAL_AVAIL". One is human; the other is a leaking implementation detail.

**Common mistake:** Using domain-specific internal terms that the product team say every day but users have never encountered. Run a quick vocabulary check - if your help desk gets questions about what a term means, it fails this heuristic.

### 3. User control and freedom

Users often choose actions by mistake and need a clearly marked "emergency exit". Support undo and redo. Let people cancel a long operation, leave a flow without losing their work, and back out of states they did not mean to enter.

**Second example:** An email client that gives users 10 seconds to undo a "Send" - a simple feature that has become standard because it addresses one of the most common and painful user mistakes.

**Common mistake:** Forcing users to complete a multi-step form in order before allowing them to go back and correct an early field. The inability to revise without starting over is a classic control failure.

### 4. Consistency and standards

Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform and industry conventions. A link should look like a link, the primary action should sit where people expect it, and the same word should mean the same thing everywhere in the product.

**Second example:** A product that uses "Delete" on one screen and "Remove" on another for the same destructive action. Users have to re-read both carefully to confirm they mean the same thing - cognitive load caused purely by inconsistency.

**Common mistake:** Designing "creatively" for its own sake - placing the primary button on the left when every comparable tool has it on the right, or using icon-only navigation on mobile without any labels. Originality is not a UX virtue when it costs the user effort.

### 5. Error prevention

Even better than good error messages is a careful design that prevents problems from occurring in the first place. Disable buttons that cannot yet be used, confirm destructive actions, use sensible input formats, and design forms that make invalid states hard to reach.

**Second example:** A date picker that greys out past dates when booking a future appointment, so it is literally impossible to select an invalid date. The problem never reaches the error-message stage.

**Common mistake:** Relying on error messages to catch mistakes rather than designing the form to prevent them. If your analytics show a particular field generates a high error rate, the answer is rarely a better error message - it is a better input design.

### 6. Recognition rather than recall

Minimise the user's memory load by making elements, actions, and options visible. People should not have to remember information from one part of the interface to another. Recently viewed items, autocomplete, and visible menus all reduce recall.

**Second example:** A code editor that shows the function signature in a tooltip as you type an argument, so you do not have to hold the parameter names in working memory or switch tabs to look them up.

**Common mistake:** Hiding key actions behind unlabelled icons and expecting users to learn what each one does. Icons without labels force recall; icons with labels support recognition. When in doubt, add a label.

### 7. Flexibility and efficiency of use

Shortcuts, hidden from novices, can speed up interaction for expert users, so the design serves both. Keyboard shortcuts, saved searches, templates, and the ability to tailor frequent actions let experienced users move quickly without getting in the way of newcomers.

**Second example:** A CRM that lets power users create custom saved filters for their most common views, while casual users still navigate the default filter panel without noticing the option exists.

**Common mistake:** Removing shortcuts and customisation options under the banner of "keeping it simple". Simplicity for novices and efficiency for experts are not mutually exclusive - they require different layers of the design, not a single lowest-common-denominator interface.

### 8. Aesthetic and minimalist design

Interfaces should not contain information that is irrelevant or rarely needed. Every extra unit of content competes with the relevant content and reduces its visibility. This is not about being visually plain - it is about keeping the focus on what matters and removing noise.

**Second example:** A checkout page that strips away the site header, navigation, and promotional banners - reducing distraction during the most critical conversion step. Many e-commerce sites see a measurable uplift from this change alone.

**Common mistake:** Treating "minimalist" as a visual style rather than a content decision. A stark white page with three vague labels is not minimalist UX - it is under-labelled. Real minimalism means every element earns its place by serving the user's goal.

### 9. Help users recognise, diagnose, and recover from errors

Error messages should be expressed in plain language, precisely indicate the problem, and constructively suggest a solution. "Something went wrong" is unhelpful. "Your card was declined - please check the expiry date or try another card" tells the user what happened and what to do next.

**Second example:** A form that highlights exactly which fields failed validation in red, with a short sentence under each explaining why - not a generic banner at the top of the page that forces the user to hunt for the offending field.

**Common mistake:** Generic error messages written by engineers ("Error 422: Unprocessable entity") that ship unchanged to production. Every user-facing error message should be reviewed by a UX writer or designer before launch.

### 10. Help and documentation

It is best if the system does not need explanation, but documentation may still be necessary. When it is, make it easy to search, focused on the user's task, list concrete steps, and keep it concise. Contextual help, tooltips, and a well-structured help centre all count.

**Second example:** Contextual tooltips on a complex settings screen that appear on hover, explaining each option in one sentence without requiring the user to leave the page. Documentation embedded where it is needed beats a separate help article every time.

**Common mistake:** Writing documentation that describes what the interface does rather than what the user is trying to achieve. Good help content is task-oriented ("How do I invite a team member?"), not feature-oriented ("About the Members screen").

## Worked example: evaluating a checkout flow

To make this concrete, here is a brief heuristic review of a typical three-step checkout - cart review, delivery details, payment.

**Cart review screen.** A user adds three items, then notices no running total on the cart screen - only individual prices. That violates heuristic 1 (visibility of system status). They cannot see what they will be charged until they reach the payment step. Severity: 3 (major).

**Delivery details screen.** The address form has no postcode lookup. Users must type a full address from scratch, with no format guidance on what "Address Line 2" means. Violates heuristic 6 (recognition over recall) and heuristic 2 (match with real world). Severity: 2 (minor - users can work around it, but errors increase).

**Payment screen.** The "Place order" button is active even before card details are entered. Clicking it triggers a vague inline error: "Required field missing." This violates heuristics 5 and 9 - the error was preventable, and the message does not say which field. Severity: 3 (major).

**Absence of emergency exit.** There is no obvious way to return to the cart from the payment screen without using the browser back button, which wipes the delivery fields. Violates heuristic 3. Severity: 4 (catastrophe - users who want to amend their order are likely to abandon).

Four issues, three heuristics, a clear priority order for the development team - found in under an hour, with no users recruited.

## Heuristic evaluation vs usability testing

These two methods are partners, not alternatives. Understanding when to use each is a core UX skill.

**Use heuristic evaluation when:**
- You need findings fast - a heuristic evaluation can run in a day; recruiting and scheduling users takes at least a week.
- You are working with an early prototype, a competitor's product, or a design that has not yet been built.
- Budget is constrained and you need to triage quickly before deciding where to invest in deeper research.
- You want to clear the obvious problems before user testing, so that sessions focus on subtler questions.

**Use usability testing when:**
- You need to understand how real users actually think and behave with the product - including workarounds, mental models, and emotional reactions that no expert can fully predict.
- You are making a high-stakes design decision and need behavioural evidence rather than expert opinion.
- You want to validate that a fix you made after a heuristic evaluation has actually resolved the problem.
- You are testing with a specific audience (older adults, screen-reader users, non-native speakers) whose behaviour deviates from expert assumptions. Note that heuristic evaluation alone is not a substitute for accessibility testing - WCAG 2.2 compliance and the requirements of the European Accessibility Act need dedicated evaluation methods covered in our [Accessibility for UX course](/courses/ux-accessibility/).

A reliable pattern: run a heuristic evaluation first to remove the obvious barriers, then run usability testing to understand what remains. For more on the broader landscape of UX research methods, see our guide to [usability in UX design](/blog/usability-in-ux-design/).

## How many evaluators do you need?

Three to five, for most projects. Nielsen's research found that five evaluators catch around 75% of usability issues. Beyond five, each additional evaluator finds a diminishing number of new problems - the return on time and cost drops sharply.

A single evaluator catches around 35% of issues on average. Two evaluators reach roughly 60%. The jump from one to three is the most valuable. For a quick gut-check on a small component, one experienced evaluator is better than nothing; for a full product review, three is the practical minimum.

If your evaluators are domain experts in the product area - as well as UX-trained - they will catch issues that pure usability generalists might miss. Mix both types where you can.

## How long does a heuristic evaluation take?

A focused evaluation of a single key flow (say, the onboarding or checkout) takes each evaluator one to two hours of independent review time. Add an hour to consolidate findings and agree severities as a group, and you have a full, actionable report in a single working day for a small team.

A full product evaluation - multiple flows, multiple device breakpoints - typically takes each evaluator half a day. Schedule the consolidation session the same day so context is fresh.

The time investment is considerably lower than a round of usability testing, which explains why heuristic evaluation is standard practice at the start of a design iteration cycle. It is also why many UX practitioners learn to run quick solo evaluations of a specific screen as a normal part of their design review process - it does not always need to be a formal team exercise.

For a broader look at the design principles that underpin this kind of thinking, see our guides to [UX design laws and principles](/blog/ux-design-laws-principles/) and [what UX design actually is](/blog/what-is-ux-design/).

## Strengths and limitations

Heuristic evaluation is fast, low cost, and can be applied at any stage - even to a rough prototype or a competitor's product. It does not require users, so there are no recruitment delays or scheduling constraints.

Its limitations are equally important to understand. It depends on the skill of the evaluators, it can surface false alarms (problems that would not actually trouble real users), and it reflects expert opinion rather than real user behaviour. It is best at catching obvious, rule-based problems and weaker at revealing how real people actually think and behave. For that, you still need usability testing - our [usability testing guide](/blog/usability-testing-guide/) explains how to plan and run sessions effectively. The two methods are partners, not substitutes: evaluate first to clear the obvious issues, then test with users to learn the rest.

## Putting it into practice

The fastest way to get good at heuristic evaluation is to do one. Pick a product you use often, take Nielsen's 10 heuristics, and work through a single flow such as signing up or checking out. Note every issue, tag the heuristic, and rate the severity. You will be surprised how much you find.

To structure your review, a [heuristic evaluation template](/resources/templates/heuristic-evaluation/) gives you a ready-made spreadsheet and scoring system so you can start immediately rather than building one from scratch. If you want to see the method applied end to end before running your own, a [worked heuristic evaluation example](/blog/heuristic-evaluation-example/) walks through a real interface with findings and severity ratings.

At [UX Academy](https://myuxacademy.com), heuristic evaluation is part of how we teach usability on our live, small-group [UX design courses](https://myuxacademy.com/courses/). You learn the principles, then apply them to a real client project with feedback from a working UX professional every week. If you want to build this skill properly, [book a free masterclass](https://myuxacademy.com/masterclass/free-ux-ui-masterclass/) to see how we teach.


---

# What Is Design Thinking in UX? The Five Stages Explained

URL: https://myuxacademy.com/blog/design-thinking-ux/
Design thinking is a human-centred problem-solving framework used in UX. Learn the five stages, how they work in practice, and their limits.

Design thinking gets mentioned constantly in UX job descriptions, bootcamp syllabi, and workshop agendas. It has become one of those phrases that sounds important but often goes unexplained. This post cuts through the noise: what design thinking actually is, where it came from, how the five stages work in practice, and - crucially - where it falls short.

## What Is Design Thinking?

Design thinking is a human-centred approach to problem solving. Rather than starting with a technology or a business requirement and working outwards, you start with the people who have the problem and work inwards toward a solution.

The approach was popularised by IDEO and the Stanford d.school from the 1990s onwards, building on earlier ideas from engineering and architecture about how designers actually think when they work. The core insight is that the most durable solutions come from deeply understanding what people need - not just what they say they want - and then testing ideas cheaply before committing to them.

In a UX context, design thinking gives you a structured way to avoid building the wrong thing. It is not a rigid process. It is closer to a mindset: stay curious, challenge assumptions, involve real people early, and iterate.

If you are new to the discipline, our post on [what UX design is](/blog/what-is-ux-design/) gives useful grounding before you dig into design thinking specifically.

## The Five Stages of Design Thinking

The Stanford d.school model describes five stages: Empathise, Define, Ideate, Prototype, and Test. These are often presented as a neat linear sequence. In practice they rarely are - but understanding each stage on its own terms is still the right place to start.

## Empathise

Empathise is about developing a genuine understanding of the people you are designing for. This means observing behaviour, conducting interviews, and setting aside your own assumptions about what the problem is.

**Practical example:** A team is redesigning a GP appointment booking system. Before touching a wireframe, they spend two days at the surgery watching how patients interact with the existing system. They notice that older patients consistently ask the receptionist for help even when the online booking portal is technically available. The assumption that "people just need a cleaner interface" is already under pressure before a single sketch has been made.

Methods at this stage include contextual interviews, observation, diary studies, and empathy mapping. The goal is not data collection for its own sake - it is building a felt sense of what life looks like from your user's perspective. Our guide to [UX research methods](/blog/ux-research-methods/) covers these approaches in detail so you can choose the right one for your context.

## Define

Define is where you synthesise what you learned during Empathise into a sharp, actionable problem statement. A good problem statement focuses on a user need, not a feature request.

A common format is the "How Might We" question: "How might we help [user] achieve [goal] in [context]?" This keeps the team focused on the person and opens space for creative solutions rather than locking you into a predetermined fix.

**Practical example:** From the GP booking research, the team identifies a pattern: patients over 60 are not failing to use the portal because the interface is confusing - they do not trust that their appointment has been confirmed without a human acknowledging it. The problem statement becomes: "How might we help patients feel confident their appointment is confirmed without requiring a phone call?"

That reframe changes everything. The solution is no longer about UI polish - it might be a confirmation SMS, a callback option, or a clearer success state in the portal. Define is where you earn the right to ideate.

## Ideate

Ideate is structured divergent thinking. The goal is quantity and variety before quality. Teams use techniques like brainstorming, worst possible idea (which surfaces assumptions by inverting them), mind mapping, and "Crazy 8s" - sketching eight rough ideas in eight minutes.

The discipline here is separating generation from evaluation. Judging ideas too early kills the unusual ones, and the unusual ones are often where the best solutions live.

**Practical example:** The GP booking team runs a 90-minute ideation session. Ideas range from sensible (automated SMS confirmation) to far-fetched (a receptionist avatar that appears on screen after booking). Most ideas will not survive contact with constraints - budget, technical feasibility, NHS governance - but the breadth of the session surfaces three genuinely testable directions that would not have emerged from a standard requirements meeting.

Information architecture - how you organise and label content - is often shaped heavily during ideation. Our post on [information architecture in UX design](/blog/information-architecture-ux-design/) explores that in more depth.

## Prototype

Prototype means making your ideas tangible as quickly and cheaply as possible. A prototype is not a finished product - it is a hypothesis made visible. The purpose is to create something you can put in front of a real person and learn from, before you have spent weeks or months building it properly.

Prototypes range from paper sketches to clickable Figma mockups to role-played service scenarios. The fidelity should match the question you are trying to answer. If you want to test navigation logic, a rough wireframe is enough. If you want to test whether a confirmation message feels reassuring, you might need something higher fidelity.

**Practical example:** The team creates three paper prototypes of different confirmation flows - one with a prominent green tick and a summary, one with a plain text confirmation, and one that includes a "call us to confirm" link as an opt-out. Each takes about an hour to produce. They are testing a feeling, not a finished UI.

## Test

Test is where you put your prototype in front of real users and observe what happens. The goal is not to validate your design - it is to learn what is wrong with it so you can improve it.

Good testing at this stage is qualitative. You are watching for moments of hesitation, confusion, or surprise. You are asking "why did you do that?" not "did you like it?" For more structured expert-led evaluation alongside user testing, [heuristic evaluation](/blog/heuristic-evaluation-ux-design/) is a method worth knowing - it applies a set of established usability principles to identify problems systematically before or alongside test sessions.

**Practical example:** Five patients are shown the three confirmation flow prototypes. Four of them respond most positively to the version with the prominent summary and a clear "you will receive a text message" note. The opt-out phone link, which the team thought would reassure anxious users, actually makes two participants more anxious - they wonder whether the booking has worked at all. That insight changes the final design.

## Design Thinking Is Non-Linear

One of the most important things to understand about design thinking is that the five stages are not a waterfall. In real projects, you move back and forth constantly.

Testing reveals something you did not understand about users? You go back to Empathise. Prototyping exposes a gap in your problem statement? You return to Define. Ideation uncovers an assumption that was never tested? You commission a few more interviews.

This iterative quality is what makes design thinking useful. It is a structure for staying honest about what you know and what you do not, rather than a checklist to tick off once and move on from.

## How Design Thinking Relates to the UX Design Process

Design thinking and UX design are closely related but not the same thing.

Design thinking is a problem-solving philosophy. UX design is a professional practice with specific methods, deliverables, and craft skills - user research, information architecture, wireframing, interaction design, usability testing, accessibility.

In practice, design thinking tends to operate at the upstream end of a project: defining the problem worth solving, generating and testing early-stage ideas, and aligning stakeholders around user needs. UX design then takes those validated directions and turns them into detailed, buildable solutions. Our guide to the [UX design process](/blog/ux-design-process/) shows how these phases connect in a professional workflow.

Many UX designers work within a broader design thinking framework and use its language - particularly the five-stage model - as a shared vocabulary with product managers and developers who do not have a design background. If you are moving into UX from another field, understanding design thinking fluently is a genuine advantage in cross-functional teams.

Our [beginner UX design course](/courses/beginner-ux-design/) covers how design thinking fits into a full UX workflow, with hands-on practice across each stage.

## When Design Thinking Helps - and When It Does Not

Design thinking is most valuable when the problem is genuinely ill-defined, when assumptions about users are untested, and when multiple solutions are plausible. It is particularly useful at the start of a new product, during a significant redesign, or when a product is not performing and the team does not know why.

It is less useful when the problem is already well understood and the constraint is execution rather than discovery. Running a full empathise-define-ideate cycle before fixing a broken form validation is overkill. Design thinking scales to the complexity and uncertainty of the problem.

There are also legitimate criticisms. Design thinking can be used as a theatre of participation - workshops that generate sticky notes without changing anything. It can be treated as a substitute for genuine user research rather than a frame for it. And the five-stage model, in the wrong hands, becomes exactly the rigid linear process it was designed to replace.

The answer is not to abandon design thinking but to use it honestly: stay genuinely curious, test with real people, and let what you learn change what you do.

## Getting Started

If you want to practise design thinking rather than just read about it, the fastest way is to work through a structured brief with feedback. Our [free UX masterclass](/masterclass/free-ux-ui-masterclass/) is a good first step - it covers how design thinking maps to the practical work of UX design, and gives you a taste of how we teach at UX Academy (myuxacademy.com).

If you are ready to go deeper, take a look at our [UX design courses](/courses/) - all taught live online with small cohorts, led by our lead instructor, Natalia Veretenyk, and her team.


---

# Data-Driven UX Design Without Losing the Human Element

URL: https://myuxacademy.com/blog/data-driven-ux-design/
Learn what data-driven UX design really means, which metrics matter, and how to combine quantitative and qualitative data to make better design decisions.

Every UX designer hears the phrase "data-driven" thrown around constantly. Product teams want it. Job descriptions demand it. But what does it actually mean in practice - and is being purely data-driven even the right goal?

This post covers what data-informed UX design looks like in the real world: the types of data that matter, the tools that generate them, the metrics worth tracking, and the very real risks of over-relying on numbers at the expense of design judgement.

## Data-Driven vs Data-Informed: Why the Distinction Matters

"Data-driven" implies that data makes your decisions for you. If the numbers say button A outperforms button B, you ship button A. Full stop.

The problem is that data tells you *what* is happening - not *why*, and not *what to do next*. A checkout abandonment rate of 70% is a fact. Whether the fix is simplifying the form, adding a guest checkout option, or surfacing trust signals is a design question that data alone cannot answer.

The more useful framing is **data-informed**: you use data as one of several inputs into your thinking, alongside user research, business context, accessibility requirements, and yes - designer judgement. This is how experienced UX practitioners actually work, and it is what [learning UX design](/blog/what-is-ux-design/) well looks like in practice.

## The Two Types of Data You Need

Good UX decisions almost always require both quantitative and qualitative data. Each answers a different question.

**Quantitative data** tells you *what* is happening at scale. It is measurable and statistical. You can see that 60% of users drop off on step three of your onboarding flow. You can see that mobile users convert at half the rate of desktop users. You can see that a particular page has a 90-second average session time.

What quantitative data cannot tell you is *why* any of that is happening.

**Qualitative data** fills that gap. It comes from watching real users interact with your product, reading their survey responses, listening to them in interviews. It is messier and harder to generalise from, but it surfaces the human reasoning behind the numbers. Our guide to [UX research methods](/blog/ux-research-methods/) covers the main qualitative and quantitative approaches and when each is appropriate.

The two types reinforce each other. Quantitative data helps you prioritise where to look. Qualitative data helps you understand what you find. A team that relies solely on analytics is flying half-blind - and so is one that only runs user interviews without any sense of scale or frequency.

## Types of Data and the Tools That Generate Them

You do not need to master every tool. But you do need to know what category of data each type produces.

**Web and product analytics** (Google Analytics, Mixpanel, Amplitude) capture user behaviour at scale - page views, session duration, funnel drop-off, feature usage. They answer broad questions about where users go and what they do. The limitation is that they track clicks and scrolls, not intent or confusion.

**Heatmaps and session recordings** (Hotjar, Microsoft Clarity, FullStory) show you where users click, how far they scroll, and - in recordings - how they actually navigate your interface in real time. Watching a session recording of someone struggling to find a search bar is often more persuasive to a product team than any slide of analytics data.

**Surveys and feedback tools** (Typeform, Google Forms, in-product prompts) let you ask users direct questions at relevant moments. Exit surveys on a pricing page, NPS follow-up questions, and post-purchase feedback all generate qualitative signal at modest scale.

**Usability testing** is structured observation - you give users a task and watch them complete (or fail to complete) it. Remote or in-person, moderated or unmoderated, usability testing surfaces specific friction points that no amount of analytics will reveal. Before recruiting participants, many teams run a [heuristic evaluation](/blog/heuristic-evaluation-ux-design/) to identify obvious violations of usability principles - this cleans up low-hanging problems so testing sessions focus on subtler issues. For a practical walkthrough of how to plan and run sessions, see our [usability testing guide](/blog/usability-testing-guide/). If you want to understand the broader context, [this overview of usability in UX design](/blog/usability-in-ux-design/) is worth reading.

**A/B testing and experimentation platforms** (Optimizely, VWO, built-in tools in many product stacks) let you run controlled comparisons between two versions of a design. They are genuinely powerful - but they require meaningful traffic volumes to reach statistical significance, and they test *variations of existing solutions*, not radically new directions.

## Metrics That Matter vs Vanity Metrics

Not all metrics deserve equal attention. Some tell you something meaningful about user experience. Others feel impressive but do not actually indicate whether people are succeeding at what they came to do.

**Vanity metrics** include things like total page views, social media followers, and app download counts. They can go up even as the actual experience deteriorates. A high page view count on a help article might mean your content is popular - or it might mean your product is so confusing that everyone needs to look up how to use it.

**Metrics worth tracking** are tied to user goals and business outcomes:

- **Task completion rate**: can users actually do what they came to do?
- **Time on task**: are users completing flows efficiently, or struggling?
- **Error rate**: how often do users make mistakes, and where?
- **Conversion rate** at specific funnel steps: not just overall, but broken down by segment, device, and traffic source
- **Customer satisfaction scores** (CSAT, NPS) tied to specific interactions, not just overall sentiment
- **Retention and engagement over time**: are users coming back? Are they progressing through features or stalling?

The test of a useful metric is whether a change in it tells you something actionable about the experience. If you cannot imagine a design decision that would improve the number, it probably is not worth optimising for.

## Turning Data Into Design Decisions: A Practical Process

Data does not automatically become decisions. There is a translation step that requires skill and judgement. Here is a framework that works in practice.

**1. Start with a question, not a dashboard.** Before opening any analytics tool, be clear about what you are trying to learn. "Why are users not completing registration?" is a useful question. "Let us look at the data" is not - it leads to pattern-matching without purpose.

**2. Use quantitative data to identify where the problem is.** Funnel analysis, drop-off points, and session recordings can narrow your focus to specific flows or screens. You are not solving anything yet - you are deciding where to look more closely.

**3. Use qualitative data to understand what is causing it.** Run usability sessions on the specific flow. Review session recordings with that step in mind. Look at any existing survey data about that part of the experience. Talk to your support team - they often know exactly where users get stuck.

**4. Generate hypotheses, not solutions.** Based on what you have learned, form a specific hypothesis: "Users are abandoning the form because they do not understand why we need their phone number." That hypothesis points toward a testable design change.

**5. Design and test.** Build the change and test it - through usability testing first to check that it resolves the underlying confusion, and then through an A/B test if traffic volume allows for statistical comparison.

**6. Document your reasoning.** Design decisions backed by data are far easier to defend in cross-functional teams. But the reasoning - the chain from data to insight to hypothesis to design - is what makes that defence credible.

This kind of structured, evidence-led process is exactly what [UX research in agile development](/blog/ux-research-agile-development/) looks like in practice.

## The Risk of Over-Relying on Data

Here is what nobody tells you when they ask for "data-driven designers": data has limits, and ignoring those limits produces bad products.

**Data reflects the past, not the future.** Analytics tell you how existing users interact with your current product. They cannot tell you what entirely new users need, what unmet needs your product is failing to address, or what a fundamentally different approach might unlock.

**Data can entrench existing patterns.** If you only optimise what you can measure, you risk missing the bigger opportunity to redesign the experience from scratch. Some of the most significant product improvements in UX history came from ignoring what the data said existing users wanted and rethinking the problem entirely.

**A/B testing optimises within a local maximum.** If version A and version B are both variations of a mediocre design, the winner is still mediocre. Testing is not a substitute for good design thinking.

**Data can reflect bias.** If your analytics only capture behaviour from users who already got through your acquisition funnel, you are invisible to the people who bounced before engaging. Your data tells you nothing about them.

The designers who create genuinely great experiences combine data fluency with strong design intuition, domain knowledge, and empathy for the full range of users - including those who are not yet in your product.

## What This Means for Your Career

Employers hiring junior and mid-level UX designers increasingly expect some data literacy. That does not mean you need a statistics degree. It means being comfortable with:

- Reading an analytics dashboard and identifying where users drop off
- Setting up a basic usability test and synthesising findings
- Framing design decisions in terms of user goals and measurable outcomes
- Talking to engineers and product managers in the language of hypotheses and metrics

This is learnable. It is a skill set, not a personality type. And it sits at the heart of how professional UX design is practised in product teams today.

If you want to see how we approach data-informed design in a structured, practical curriculum, the [UX Academy (myuxacademy.com) Advanced UX Design course](/courses/advanced-ux-design/) covers exactly this - alongside portfolio projects you can use to demonstrate the skill to employers.

Not ready to commit yet? The [free UX masterclass](/masterclass/free-ux-ui-masterclass/) is a good starting point to see how we teach and whether it fits the way you learn. It is free, live, and taught by our lead instructor, Natalia Veretenyk, and her team.

Data will not design the product for you. But learning to use it well is one of the fastest ways to move from junior to confident professional.


---

# CareerFoundry Has Closed: What to Do Next

URL: https://myuxacademy.com/blog/careerfoundry-closed-what-happened/
CareerFoundry announced it is ceasing operations in early 2026. Here is what happened, what it means for students, and what your options are now.

If you were studying UX design with CareerFoundry, or were about to enrol, the news that the school is winding down will have come as a shock. You may have been mid-course, deep into your portfolio, or simply researching your next step when the announcement landed.

This post covers what we know factually, what it means for people affected, and what practical options exist - including how UX Academy can help.

## What happened with CareerFoundry

CareerFoundry was one of the larger online UX and design bootcamps, operating globally for a number of years. In early 2026, the company announced it is ceasing operations and winding down its programmes.

The specifics of why - financial pressures, market conditions, or other factors - have not been fully disclosed publicly, and we will not speculate. What is clear is that a significant number of students found themselves mid-programme or with incomplete qualifications through no fault of their own.

This is genuinely difficult, and it is worth acknowledging that plainly before moving on to practical steps.

## What this means if you were a current student

If you were enrolled at the time of the closure announcement, your immediate concerns are likely:

- **Whether your certificate or completed coursework has any value**
- **Whether you can transfer credits or learning to another programme**
- **Whether you are owed a refund for unused tuition**

On refunds: contact CareerFoundry directly through whatever channels remain active, and document everything. If you paid by credit card, you may have consumer protection options worth exploring with your card provider. Citizens Advice and the Financial Ombudsman Service are useful UK resources if you are struggling to get a response.

On certificate value: a certificate from a closed school is not worthless. Employers in UX care far more about your portfolio and your ability to talk through your process than about which institution issued a piece of paper. The work you did, the methods you learned, the case studies you started - that knowledge does not disappear when a school closes.

On transferring learning: the core skills taught in a UX bootcamp - user research, wireframing, prototyping, usability testing - are largely the same across providers. If you were 60% through a programme, you are 60% further along than someone starting from scratch. Any reputable programme you continue with should be able to assess where you are and build from there.

## What this means if you were about to enrol

If you were researching CareerFoundry and now find yourself back at square one, the loss is smaller in practical terms - but the disruption to your plans is real. You had momentum, you had a decision almost made, and now you need to start that evaluation process again.

That is frustrating, but it is also an opportunity to ask some questions you might not have asked before: how stable is the provider you choose? What happens to you if they stop operating? Is the teaching live and responsive, or pre-recorded and largely self-directed?

## How to evaluate a replacement provider

The closure of any school - CareerFoundry or otherwise - is a reminder that stability and structure matter, not just curriculum. When you are vetting your next option, it is worth asking:

**About the teaching model.** Is instruction live or pre-recorded? Live teaching means you can ask questions in the moment, adapt to your specific situation, and build a relationship with an instructor. Pre-recorded content can be valuable but offers no flexibility.

**About cohort size.** Smaller cohorts mean more attention per student. A 200-person cohort and a 10-person cohort are very different learning experiences, even if the curriculum looks similar on paper.

**About outcomes.** What do graduates actually go on to do? Can the school point to real people in real roles? Generic testimonials are easy to manufacture; specific named graduates with verifiable job histories are harder to fake.

**About the organisation itself.** Who runs it? Is it venture-backed and dependent on continued fundraising, or does it operate at a sustainable scale? Neither model is inherently better, but understanding what you are signing up to helps you make an informed choice.

**About what happens mid-course.** This is a question most people do not think to ask until something goes wrong. If a school closes, what is the refund policy? What happens to your work?

## Continuing your UX journey

If CareerFoundry's closure has interrupted your learning, the most important thing is to not let the momentum stop entirely. The demand for UX skills has not changed. The [job market for UX designers in the UK](/blog/ux-design-jobs-uk/) remains active. What changed is the vehicle you were using to get there - not the destination.

For people at an early stage, a structured programme with live instruction is likely to give you more than trying to piece together free resources alone. There is a lot of excellent free content online - YouTube tutorials, articles, community forums - but it does not replicate the accountability, feedback, and structured progression of a proper course.

If you are further along and had a portfolio project underway, consider finishing it even without formal instruction. A nearly-complete case study is a lost opportunity; a complete one, however rough, is an asset you can iterate on. Our guide on [how to build a UX portfolio from scratch](/blog/how-to-build-a-ux-portfolio-from-scratch/) is useful if you need to rebuild your evidence base from the ground up.

The article [switching careers to UX design](/blog/switching-careers-to-ux-design/) covers the realistic timeline and what actually matters when you are making this move - worth reading if you are reassessing from scratch.

## How UX Academy can help

UX Academy (myuxacademy.com) runs live, small-group UX design courses in the UK. We are a trading name of Nomadic User Ltd, a UK company (Companies House company number 09556531), and the trading name is also a UK registered trade mark (UK00003542830, Class 41). We teach live online - meaning real instructors, real questions answered in real time, and a cohort you actually interact with. Our courses are taught by our lead instructor, Natalia Veretenyk, and her team. Note: Designlab, a separate US company, also runs a self-paced product it calls "UX Academy" - it has no connection to us. If you want a live, evening, UK-based, GBP-priced course, myuxacademy.com is the one you are looking for.

Our [Beginner UX (AI) Design course](/courses/beginner-ux-design/) is built for people making a career change. It covers the full UX process - research, wireframing, prototyping, testing - and ends with a portfolio-ready case study. Cohort 1 begins on <CohortDate />, and enrolments are open now.

We have put together a dedicated page for people who have been affected by the CareerFoundry closure, including a transition offer for displaced students. You can find the details, along with honest answers to questions you are likely to have, at [/careerfoundry-alternative/](/careerfoundry-alternative/).

If you are not yet sure whether a structured course is right for you, or you want to get a feel for how we teach before committing to anything, our free live masterclass is a good starting point. It is a real session, not a sales presentation. [Book a place at the free UX masterclass](/masterclass/free-ux-ui-masterclass/).

## A note on what you have already built

If you completed modules with CareerFoundry, you learned things. You worked through problems. You probably produced something - a wireframe, a research plan, a prototype. Do not write that off.

Bring those artefacts into your next programme, or into your portfolio. Show your thinking. UX hiring is not about perfect output; it is about whether you can demonstrate a coherent process. Work you did at a school that no longer exists is still work you did.

The situation is genuinely unfortunate. But it is not the end of your UX journey - it is an interruption. How quickly you get moving again is largely up to you.

---

**If you were affected by the CareerFoundry closure**, the best next step is to visit our [CareerFoundry alternative page](/careerfoundry-alternative/) to see the transition offer and read answers to questions from people in your position. Or [join the free masterclass](/masterclass/free-ux-ui-masterclass/) to see how we teach before you commit to anything.


---

# Can You Become a UX Designer Without a Degree?

URL: https://myuxacademy.com/blog/become-a-ux-designer-without-a-degree/
You don't need a degree to become a UX designer. What employers actually look for, and how to build the skills and portfolio to get hired.

The short answer is yes. You can become a UX designer without a degree - and plenty of working UX designers did exactly that.

But "yes you can" is not the same as "it's easy" or "it doesn't matter at all." This post gives you the honest version: why portfolio and skills carry more weight than formal qualifications in UX hiring, what employers actually look for, how to build credibility without a degree, and the real caveats you should know going in.

For the full step-by-step roadmap - foundations, portfolio, and job search, whatever your background - see our main guide on [how to become a UX designer](/blog/how-to-become-a-ux-designer/).

## Why UX Hiring Focuses on Portfolio, Not Credentials

UX design is a practice-based discipline. What you can do matters far more than what institution you attended - or whether you attended one at all.

Most UX job postings list a degree as "preferred" rather than "required." Many hiring managers have been in the field long enough to remember when there were no dedicated UX degrees at all. They learnt on the job, built their craft through projects, and hired people the same way.

What gets you through the door is being able to show your thinking. That means:

- A portfolio that documents your design process, not just your finished screens
- Evidence that you can run user research, synthesise findings, and translate them into design decisions
- The ability to talk through your work confidently in an interview

A psychology degree, a graphic design HND, or ten years in customer service can all be relevant background for UX. What ties it together is the UX work you have done since.

This is also why a structured course matters. Not because a certificate replaces a degree, but because it gives you the frameworks, vocabulary, and supervised project work that employers recognise. A qualification from a credible, tutor-led programme signals to a recruiter that your training was structured and assessed - which carries more weight than "I watched some tutorials."

## What Employers Actually Look For

When a recruiter opens your application, here is what they are looking at:

**1. Your portfolio**

This is the single most important thing. A strong portfolio shows two or three end-to-end projects that walk through your process: the problem, your research approach, key insights, design iterations, and what you learnt. Personal projects, course projects, and volunteer work all count - especially at junior level.

**2. Core UX skills, demonstrated**

Can you conduct a user interview? Write a usability test plan? Create wireframes and prototypes in Figma? Understand accessibility basics? These are the fundamentals. You do not need to be expert-level in all of them when you are starting out, but you need to show you know how to apply them.

**3. Understanding of the end-to-end process**

Employers want to see that you understand how UX fits into a product team - not just that you can produce deliverables in isolation. Knowing when to do research vs. when to move straight to prototyping, how to work with developers, how to handle conflicting stakeholder requirements: this is the applied judgement that courses and real projects develop.

**4. Communication and presentation**

UX designers spend a lot of their time explaining their decisions to people who are not designers. In interviews, this shows up as your ability to talk through your portfolio clearly and answer questions about why you made certain choices.

Notably absent from this list: the specific institution where you studied, or whether you have a degree at all.

## How to Build Credibility Without a Degree

Here is a concrete path that works for career changers.

**Start with structured learning**

Self-taught resources can get you started, but a structured course accelerates the process significantly. You get a curriculum that covers the full UX toolkit, feedback from experienced instructors, and a cohort of people going through the same transition. You also come out with a recognised qualification rather than a loose collection of YouTube videos. (CareerFoundry, one of the more prominent online UX schools, closed in early 2026 - a reminder that it is worth researching programme stability as well as curriculum; our [CareerFoundry alternative](/careerfoundry-alternative/) page covers what to look for.)

Our [Beginner UX (AI) Design course](/courses/beginner-ux-design/) is taught live online by practising UX designers. It covers everything from research and information architecture to wireframing, prototyping, and accessibility - with real projects throughout. If you want to see whether it's the right fit before committing, the free [UX and UI Masterclass](/masterclass/free-ux-ui-masterclass/) is a good starting point.

**Build portfolio projects deliberately**

Your portfolio does not need real clients to be credible. The key is choosing problems that are genuinely interesting, running proper UX process on them, and documenting your thinking honestly - including what did not work and what you changed.

Good project sources for beginners:

- Redesign an app or website you actually use and find frustrating
- Volunteer your UX skills with a charity, local business, or community project
- Take on a brief from a course or design challenge community

Three well-documented projects are worth more than eight shallow ones. Quality over quantity.

**Get comfortable with Figma**

Figma is the industry-standard design tool. You do not need to be a visual design expert, but you do need to be able to produce wireframes, prototypes, and basic UI mockups without slowing down a team. It is free to use and has extensive documentation - there is no reason to put this off.

**Network actively**

Most junior UX roles are not filled through job boards alone. Get into UX communities, go to events (many are online), connect with people on LinkedIn, and engage in conversations. When you are looking for your first role, a warm introduction from someone in the industry is worth a lot.

The UX community is generally welcoming to career changers. People remember what it felt like to be new.

**Document your learning publicly**

Writing about what you are learning - a blog, LinkedIn posts, even a public Notion page - does two things. It forces you to consolidate your thinking (which deepens the learning), and it creates a visible trail of your progress that employers can find. You do not need to be an expert to share useful observations.

## Honest Caveats

This post would be incomplete without the things that are actually hard.

**The junior market is competitive**

It is not a secret that junior UX roles are in high demand. Companies are often looking for two to three years of experience even for entry-level positions - which is frustrating and, frankly, contradictory. Getting your first role requires persistence, a strong portfolio, and often a willingness to take on work that is not purely "UX" at first (think UX research assistant, product ops, junior product designer, or UX within a broader digital marketing role).

This is not a reason not to make the switch. It is a reason to be strategic: invest in a quality course, build a genuinely strong portfolio, and be patient in the job search.

**Some employers and visa applications still ask for degrees**

Certain large enterprises, especially in financial services and the public sector, have blanket degree requirements in their HR systems that have not caught up with how the field actually works. This is less common in tech, agencies, and startups, but it exists.

If you are applying for a UK Skilled Worker visa for a UX role, degree requirements can affect your eligibility depending on the specific occupation code and how the employer has structured the role. Worth checking before you commit to a particular path.

**Your background matters more than you might think - lean into it**

Career changers often underestimate how much their previous experience counts. If you worked in healthcare, you have domain knowledge that a UX team working on health products would find valuable. If you worked in retail or hospitality, you understand customer behaviour in ways that a recent graduate does not. That context belongs in your portfolio and your interviews.

The transition to UX is not about erasing your past - it is about reframing it.

## A Concrete Path Forward

If you are a career changer who wants to move into UX without a degree, here is what a realistic path looks like:

1. Take a structured, live course with experienced instructors and real project work
2. Build two or three portfolio projects that document genuine UX process
3. Get competent in Figma - not expert-level, competent
4. Start networking before you finish the course
5. Apply broadly, expect some rejection, iterate on your portfolio based on interview feedback
6. Look for your first role in companies that hire based on skills, not credentials

It typically takes six to twelve months from starting a course to getting a first junior role - sometimes less, sometimes more. The people who get there fastest are not the ones who learn the most theory. They are the ones who build real projects, show their thinking clearly, and stay consistent through the job search.

For more on making the transition, take a look at [switching careers to UX design](/blog/switching-careers-to-ux-design/) - it covers the mindset shifts and practical steps in detail. And if you have ever worried that you are not creative enough to work in UX, [this post](/blog/ux-designer-without-being-creative/) addresses that directly.

When you're ready to think seriously about your portfolio, [the UX design portfolio guide](/blog/ux-design-portfolio-guide/) walks through exactly what to include and how to structure it.

## Ready to Take the First Step?

UX Academy (myuxacademy.com) runs live online cohorts for career changers - real instructors, real projects, and a small group so you actually get feedback. The course is taught live by our lead instructor, Natalia Veretenyk. No degree required. If you want to see whether it's for you before committing to anything, start with the free masterclass.

[Explore our UX courses](/courses/) or [join the free masterclass](/masterclass/free-ux-ui-masterclass/) to get a feel for how we teach.


---

# AI in UX Design: What Actually Changes (and What Does Not)

URL: https://myuxacademy.com/blog/ai-in-ux-design/
How AI is reshaping UX design in 2026 - as a workflow tool and as a design challenge. What changes, what stays human, and how to adapt.

AI is doing something genuine to UX design. Not destroying it, not replacing designers, but shifting what the job looks like in practice - and raising the stakes on the skills that have always mattered most.

This post covers two distinct things that often get muddled together: AI as a tool inside the UX workflow, and AI as a product challenge that UX designers now have to solve for. Both matter. They require different thinking.

## AI as a tool in the UX workflow

Let's be direct about what AI tools are actually useful for right now.

**Research synthesis** is where designers are seeing the biggest gains. Analysing interview transcripts, spotting patterns across survey responses, organising affinity data - these are tasks that used to take hours and can now take minutes. Tools like Dovetail, Notion AI, and general-purpose LLMs can surface themes, suggest codes, and flag contradictions in raw data at a speed no human can match.

The important caveat: the synthesis is only as good as the research. AI cannot tell you whether you asked the right questions, whether your participant sample was representative, or whether you missed something critical because you were looking in the wrong place. The judgement call still belongs to you.

**Ideation and concept generation** is genuinely useful at the divergent phase. Feeding a design brief into an LLM and asking for 20 solutions - including ones that feel unreasonable - is a fast way to break out of first-idea thinking. AI does not have taste or strategic awareness, but it does not run out of ideas the way humans do after a long workshop.

**Content and microcopy** is another area where AI earns its place. Generating first drafts of error messages, button labels, onboarding copy, and empty states is now a reasonable starting point. Refining them for tone, accuracy, and brand voice still takes a human. But the blank-page problem largely goes away.

**Prototyping speed** is improving. Tools like Figma AI, Galileo, and others can generate rough layouts from prompts, resize components, and produce variants automatically. These are not finished designs - they are starting points. But they compress the time between "I have an idea" and "I have something I can put in front of a user."

For a practical rundown of what is worth using today, our guide to [AI tools for UX designers](/blog/ai-tools-for-ux-designers/) covers the current landscape with honest assessments of where each tool earns its place.

None of this is magic, and none of it removes the need for good UX thinking. What it does is compress the time on tasks that were previously just slow. That matters, because it frees up time for the work that is harder to automate - the conversations with real users, the problem reframing, the strategic decisions about what to build at all.

For a grounding in the research skills that remain irreplaceable, see [what UX research actually looks like in practice](/blog/ux-research-agile-development/).

## Designing AI-powered products

This is where the real design challenge lives, and it is newer territory.

More and more products now include generative text, conversational interfaces, predictive features, or AI-driven personalisation. Designing these experiences well is a specific skill set - and most of the existing UX playbook does not cover it adequately.

**Conversational and generative interfaces** do not behave like traditional UIs. Users cannot see a menu of options; they have to know what to ask for. The interface has no fixed state - outputs vary, and users need to develop a mental model of a system that does not always behave consistently. Designing for this means thinking carefully about discoverability, prompt guidance, and how to help users get useful results without requiring them to become prompt engineers.

**Designing for trust** is now a core UX problem. When a product surfaces a recommendation, generates a summary, or makes a prediction, users need to be able to calibrate how much to trust it. That means showing your working - where did this come from, how confident is the system, what is the basis for this output. Opacity breeds either blind trust or blanket scepticism, neither of which serves users well.

**Transparency and explainability** are not just ethical nice-to-haves. They are functional design requirements. A user who does not understand why they were shown something, or why the system behaved in a particular way, cannot make good decisions about whether to act on it. Designing explanations that are accurate without being overwhelming is genuinely hard.

**Error states and failure modes** in AI systems are different from conventional software errors. An AI component does not return a 404 or crash cleanly - it produces output that may be subtly wrong, overconfident, or simply unhelpful. Designing for this means being honest with users when the system is uncertain, giving them ways to correct or override outputs, and avoiding interfaces that make it easy to accept bad outputs without scrutiny.

**User control** is the thread running through all of this. Good AI UX gives users meaningful agency over what the system does and does not do. That might mean easy opt-outs, persistent preferences, the ability to see and edit what the system knows about them, or simply clear ways to undo AI-generated actions. Control is not a feature - it is a design principle.

These patterns are still being worked out across the industry. There is no settled canon yet, which is both a challenge and an opportunity for designers entering the field now.

## What AI does not replace

It is worth being direct about this, because the discourse swings between hype and panic and neither is useful. For a grounded take on the displacement question, see our dedicated post on [whether AI will replace UX designers](/blog/will-ai-replace-ux-designers/).

**Research with real people** is not replaceable. AI can analyse existing data, but it cannot have a conversation with a frustrated user and notice the thing they are not saying. It cannot observe someone struggle with a task and understand what that struggle reveals about their mental model. Generative AI produces outputs based on patterns in training data - it cannot tell you what your specific users, in your specific context, actually need.

**Problem framing** is the most valuable UX skill and the hardest to automate. Before you design anything, you need to identify the right problem to solve. That requires talking to people, understanding context, challenging assumptions, and often convincing stakeholders that the problem they think they have is not the one that needs solving. No prompt does this for you.

**Design judgement** - knowing when something is good enough, when to push back on a brief, when an interaction pattern is technically correct but experientially wrong - develops through practice and cannot be generated. AI tools can produce outputs; they cannot evaluate whether an output is right for a given situation.

**Ethical reasoning** is not a feature that can be added later. Designers working on AI-powered products are now in a position where the decisions they make about what to surface, when, and how have real consequences for real people. That responsibility requires human judgement.

## How designers should adapt

The practical answer is this: use AI to compress the time on tasks that used to be slow, and reinvest that time in the skills that matter more as AI gets better.

Use AI for first drafts, not final outputs. Treat AI-generated research synthesis as a starting point, not a conclusion. Stay curious about new tools, but evaluate them against the quality of work they produce, not the sophistication of the demo.

Double down on research with real people, because that is where the insight gap will open up between designers who take shortcuts and designers who do not. Double down on communication and facilitation, because the ability to involve stakeholders, run good workshops, and present findings clearly becomes more valuable as the "making" part of the job gets faster. Double down on problem framing, because the organisations that use AI well will be the ones that start with the right questions.

If you are learning UX now, or considering a career change into the field, the AI moment is not a reason to hesitate - it is a reason to develop a broader skill set. Designers who understand both how to use AI tools and how to design AI-powered experiences are increasingly in demand, and that gap is not going to close quickly.

To understand what the full UX design skill set looks like, [what is UX design](/blog/what-is-ux-design/) covers the foundations. The [full course catalogue](/courses/) shows how these skills are taught in a structured programme.

## The skills that matter now

The headline skills for UX designers in 2026 are not fundamentally different from what they have always been - they are just more important:

- **User research** - the ability to learn from real people, not just from data
- **Problem framing** - identifying the right question before committing to an answer
- **Systems thinking** - understanding how a design decision affects the broader experience
- **Communication** - presenting findings, building alignment, and advocating for users
- **Ethical reasoning** - recognising when a design decision creates harm or erodes trust

To these, add the capability to evaluate and use AI tools critically, and to design AI-powered experiences with transparency and user control at their core.

None of this is simple. Uncertainty is genuine - the tools are developing faster than the best practices, and some of what looks settled now will look different in two years. The designers who will handle that well are the ones with strong fundamentals, not the ones who learned the fastest prompt.

---

The UX Academy (myuxacademy.com) [Beginner UX (AI) Design course](/courses/beginner-ux-design/) is now open. It covers AI tools in the UX workflow and designing AI-powered product experiences - the two areas this post has explored. The next cohort starts <CohortDate />. Reserve your place from £99 (refundable deposit), with the balance of £1,401 due before the course begins.

If you want to see how we teach before committing, the [free UX/UI masterclass](/masterclass/free-ux-ui-masterclass/) is a live session covering what the field actually looks like and whether a career in UX is the right move for you.