Every designer's first instinct is to design for themselves, because you are the user you understand best and the only one available at all hours. User-centred design is the discipline of not doing that. It is a set of habits for staying honest about who you are actually solving a problem for, and it is probably the most transferable thing this course will teach you.
Where A2.1 introduced the methods, B1.1 is about running them on purpose. You plan an inquiry, choose the right method for the question you actually have, and turn the mess of what people told you into personae, usability objectives and task analyses you can design against. This is the closest thing in the syllabus to a walkthrough of your IA, so treat these as tools you will use rather than terms you will describe. One warning worth giving early: research that only confirms what you had already decided to build is not research, and examiners can tell.
Students must be able toConstruct a plan for a UCD process based on research questions that engage with user-Centred research methods.
User-Centred design (UCD) is a design process that builds every decision around the real needs, behaviours and limits of the people who will use the product, not around the designer's assumptions.
Before you can research your users, you need a plan. A UCD research plan is a short written document that answers three questions: What do I need to find out? How will I find it out? What will I do with the findings?
Your plan begins with research questions: specific things you don't yet know about your users. Good research questions are about people's problems, habits and motivations. Weak research questions ask about product features. Compare:
Weak: "What features should the app have?"
Better: "What step in the current checkout process causes users to abandon their cart?"
Once you have your questions, choose methods that can actually answer them (more on methods in 1.1.2). Then decide how many participants you need and how you will record what they tell you. Finally, set a timeline you can realistically meet.
7-Step UCD Research Plan
- Define the design context: Who is the product for? What problem does it address?
- Identify your target user group(s): Who experiences this problem most acutely?
- Write 3–5 specific research questions: Focus on behaviour, frustration and motivation.
- Choose 2–3 research methods: Match each method to the questions it can answer best.
- Plan your sample: How many participants? How will you recruit them?
- Decide how you will record and organise data: Notes, recordings, observation logs?
- Set a timeline: When will research be complete? When will you start designing?
Each product below presents a different kind of design challenge. Read the context, then study how the inquiry strategy would be structured differently in each case. Notice how the choice of research methods follows directly from the nature of the users and the decisions that need to be made.
- Observe the lift lobby during class transitions to map actual usage patterns
- Interview students with mobility needs and staff who use it daily with equipment
- Survey the broader community on signage clarity and door timing
- Conduct task analysis of the full journey for a wheelchair user, from ground floor to classroom
- Analyse existing usage data to identify where users hesitate or drop off
- Run separate unstructured interviews with power users and casual users.
- A/B test two navigation prototypes with a live subset of real users
- Hold a focus group with content creators, who have the highest stake in how navigation changes affect reach
- Conduct field research at gyms, running events and recreational sports clubs
- Run structured taste-testing sessions with Likert scales on sweetness, aftertaste and colour preference
- Interview recreational athletes about when, where and why they select a sports drink.
- Use a focus group to test packaging and branding concepts against competitor products on a shelf mock-up
- Observe professionals using drills on active construction sites.
- Conduct structured interviews with tradespeople and DIY users separately, using the same questions to expose divergent priorities
- Apply task analysis to the bit-changing process, which preliminary research suggests is a shared pain point
- Ergonomic assessment: measure grip force range, one-handed operation and balance point across percentile hand sizes
Students must be able toApply a variety of user-centred research methods (field research, user observation, interviews, questionnaires and focus groups) and analyse data to establish users' characteristics, behaviours, and the wants and needs of the target population defined by their demographics.
Different research methods collect different kinds of information. The choice of method should be driven by your research questions, not by what is easiest to set up.
Field research: Observe users in their real environment (a kitchen, a bus, a hospital). Reveals the gap between what users say they do and what they actually do. Prone to the observer effect: people may behave differently when they know they're being watched.
User observation: Watch a participant perform a specific task. Can be in a lab or real setting. Good for spotting hesitation, workarounds and errors that users wouldn't think to mention.
Interviews: A structured interview uses the same fixed questions for every participant, making results easy to compare. An unstructured interview follows the conversation wherever it leads, uncovering unexpected insights but producing harder-to-analyse data. Most real research uses a semi-structured format.
Questionnaires: Reach many people quickly. A Likert scale (typically 1–5, from Strongly Disagree to Strongly Agree) turns attitudes into numbers, giving you quantitative data. The scale is named after the American social psychologist Rensis Likert, who developed it in 1932 to measure attitudes and opinions. Always include a few open-ended questions alongside the Likert items, because those capture the qualitative data that explains the numbers.
Focus groups: A small group, usually no more than 8 to 12 people, discusses a topic together under a facilitator. Useful for exploring social attitudes and generating ideas, and particularly useful early in a project. Risk: one dominant voice can skew the group's responses, and a group that small may not surface every usability issue.
The facilitator is doing real work throughout, not just listening. Their duties are to introduce the topic, keep the discussion moving when it stalls, make sure every participant gets a chance to speak, and steer the conversation back on topic without shutting down the interaction between participants.
The method of extremes designs for the ends of the user population rather than the average. Instead of asking what the typical user can do, you ask what the largest and the smallest user need, then design so that both are accommodated. The mean is used alongside these two limits.
The convention is to apply each extreme where it does the most good. Doorways, ladders, step heights and escape hatches are sized on the 95th percentile of males, because clearance has to work for the largest user. The force required to operate a control button is set by the 5th percentile of females, because if the weakest user can press it, everyone can. Together these choices accommodate the largest possible number of people.
By its nature, this approach still excludes anyone falling beyond the extremes that were chosen. That is why designing for extreme users often means prioritising people with disabilities, whose needs sit outside the able-bodied range entirely. Doing so reliably produces better designs for everyone, and it is the point where the method of extremes shades into universal design, which aims for products usable by all people without adaptation.
The observer effect describes how people change their behaviour simply because they know they are being watched. A worker who normally rushes through a safety check may suddenly follow every step correctly while a researcher is present, then revert to old habits once the researcher leaves. This makes field research and observation harder to interpret than they first appear: the data collected is a mixture of normal behaviour and watched behaviour, and separating the two is rarely straightforward.
This connects to the research planning covered in A2.1 User-centred Research Methods: a strong research plan anticipates the observer effect in advance rather than discovering it after the data has already been collected.
- Extend the session: behaviour often normalises after the first 10–15 minutes of being watched, once the novelty of being observed fades.
- Use passive data sources: app analytics, sensor logs and CCTV-style observation avoid the participant being aware of the observation at all.
- Triangulate: compare what was observed against a separate questionnaire or interview to check whether the two sources agree.
| Method | Best for finding… | Main weakness |
|---|---|---|
| Field research | What users actually do (not what they say) | Time-consuming; observer effect |
| User observation | Specific errors, hesitation points, workarounds | Artificial setting may not reflect real use |
| Structured interview | Consistent, comparable answers across many people | Rigid questions miss unexpected issues |
| Unstructured interview | Deep, unexpected insights | Hard to analyse; small sample only |
| Questionnaire / Likert | Quantitative satisfaction or attitude scores | Doesn't explain why |
| Focus group | Group opinions, social dynamics, idea generation | One dominant voice can skew results |
A single project typically combines 2–3 methods. Field research or observation uncovers what problems exist; interviews and questionnaires explain why and how many people are affected.
Press the button to receive a field research assignment. Each assignment gives you a specific real-world setting, something to observe, and instructions for data to collect. Treat it as a genuine brief.
Type your focus group topic, then generate facilitator questions. Your topic is inserted into each question automatically. Press "New set" to get a different selection of six questions.
Answer the five usability questions as if you are a typical user. Then click "Get survey results" to see how 1,000 "simulated" respondents responded to the same questions.
Students must be able toCreate a primary persona or personae based on user-centred research to aid design development.
A persona is a fictional but research-based character who represents a real user group. You build one from patterns found in your research, not from your own imagination or assumptions about users.
There are three types:
Primary persona: The main user the design is built for. If your design does not fully satisfy this person, it fails. You design for one primary persona first; everything else is secondary.
Secondary persona: An additional user with needs beyond the primary. Satisfy them if you can, but never at the cost of the primary persona's experience.
Anti-persona: A representation of someone who would misuse the product in ways that harm real users or the business (Nielsen Norman Group). Designing with them in mind reveals security gaps, safety issues and abuse routes that would otherwise be discovered too late.
Anti-personae are not only about hostile users. Three real examples show the range:
- McDonald's uses anti-personae in marketing, so that its advertising does not target or mislead vegan customers who have no interest in buying a hamburger.
- Trainline, a train booking site, knows that many visitors only want to plan a journey and will never buy a ticket. The site is built to give those non-purchasers a good experience anyway.
- Systems designers use anti-personae to model attackers, building defences against data breaches, identity theft and denial-of-service attacks before launch.
Use cases: A use case is a written description of how a user will interact with a product, told from the user's point of view. Where a persona tells you who and a scenario tells you when and where, a use case walks through the interaction itself, step by step. That is what makes it useful for judging usability as the user actually experiences it.
What makes a good persona? Specific frustrations (not vague ones), realistic limits and habits, a concrete use scenario. A persona who "loves technology and is very organised" tells you nothing useful. A persona who "uses her phone one-handed while holding her coffee, drops it twice a week, and gives up on apps that require more than two taps to find what she needs" guides real design decisions.
Interview questions that build good personas
Don't ask "What features do you want?" Ask about problems, habits and frustrations instead.
- "What is the most frustrating thing about the current way of doing this task?"
- "How do you currently solve this problem?"
- "What would make this task faster or easier for you?"
- "When was the last time you gave up on a product like this? Why?"
- "What do you usually do first when you open this type of app?"
Common persona-building mistakes
| Mistake | Why it fails |
|---|---|
| Designing for "everyone" | "Everyone" is not a user group. No product fits all people. |
| Inventing needs without research | You will design for your own imagination, not real users. |
| Making the persona too perfect | Real users have frustrations, limits and bad habits. |
| Skipping the secondary persona | You miss easy improvements that serve more people. |
Work through this after your interviews, using what real users told you rather than what you imagine about them. Every field should trace back to something you heard or observed.
Answer a series of guided questions about your primary user, each one explained as you go, then lay the result out on a printable A4 sheet. Switch between five templates, add a photo if you have one, and download it as a PNG for your IA. →
Students must be able toExplain and apply five usability objectives (learnability, efficiency, memorability, errors and satisfaction) in order to evaluate a product.
Jakob Nielsen's five usability objectives (often called the "Five E's") give you a structured framework for evaluating any product from the user's perspective.
The objectives are not independent. A product that scores well on Efficiency but poorly on Error tolerance may actually frustrate expert users when they recover from mistakes. Always evaluate all five together.
Measuring usability (the SUS):
The System Usability Scale (SUS), developed by John Brooke in 1986, is a standardised 10-question Likert survey that produces a score from 0–100. Its questions deliberately alternate: good usability scores high on the odd-numbered questions and low on the even-numbered ones, which stops respondents from simply ticking down one column. The raw answers are then converted into the final score. The industry average is around 68. Below 50 indicates serious problems, and above 85 is excellent. Any score below 68 is a signal to investigate which of the five objectives is being violated.
Poka-yoke and the Errors objective:
Poka-yoke (Japanese: "mistake-proofing") is a design strategy that targets the Errors objective directly. It was developed by a Toyota engineer in the 1960s. The key idea is that instead of warning users after they make a mistake, the design makes the mistake impossible or corrects it automatically.
- Battery compartments shaped so a cell physically will not fit the wrong way round.
- Child-proof medication caps that need a push and a twist at the same time, a combination young children struggle to produce.
- Fuel nozzles distinguished by colour coding and by physical size, so diesel cannot be put into a petrol car.
- Microwave doors that cut power the instant they open, and prevent operation while open.
- Surgical checklists that count every sponge and instrument back out of the patient after an operation.
- Limit switches on machinery, which stop a moving part before it travels past its intended limit and collides with something else.
- USB-C plugs that work in either orientation, removing the failure entirely rather than warning about it.
You will also see the Five E's written as: Effective, Efficient, Engaging, Error tolerant, Easy to learn. Most of these line up with the IB terms above. Easy to learn is Learnability, Efficient is Efficiency, Engaging is Satisfaction, and Error tolerant is Errors. The two lists are not identical, though. The IB list includes Memorability, which the E's version leaves out, while the E's version adds Effective (does the product actually do its job?), which the IB list treats as a given. Use the IB five in an exam answer.
Each card below shows one of the Five E's in action. For each example, ask yourself: how would you measure whether this product succeeds on this objective? What would a failure look like?
Students must be able toApply task analysis techniques to break down a process into steps and identify the critical points for design improvement.
Task analysis is the process of breaking down a user's overall goal into a hierarchy of smaller, observable steps.
There are two main approaches, and they answer different questions:
- Hierarchical Task Analysis (HTA) maps the structure of a task, breaking a high-level goal into sub-goals, operations and plans until you have a tree of actions a user can actually perform. This is the approach used throughout this section.
- Cognitive Task Analysis (CTA) maps the thinking behind the task: the knowledge, judgement and skill a user needs to perform it well. It is used to improve training and interfaces, where the difficulty is mental rather than physical.
The two are often used together, because a complete picture of a task needs both its structure and the thinking it demands. Task analysis is also iterative, so expect to revisit it as the design develops.
Users rarely know exactly what makes a process frustrating. They just stop using the product. By mapping every micro-step, you find precisely where users hesitate, make errors, or give up entirely.
How to conduct a basic HTA:
1. Start with the user's overall goal (e.g., "Pay for an online order").
2. Break it into 4–7 main stages.
3. Break each stage into sub-steps: go until the steps are actions a user can actually perform.
4. Flag each step where users might: (a) hesitate, (b) make an error, or (c) abandon.
Cognitive load is the amount of mental effort required at any given step. When a step asks users to hold too many things in mind at once, cognitive load spikes, leading to errors and abandonment. The fix is usually one of three things: split the step into smaller pieces, add a visual cue, or reduce the number of choices.
Worked example: Mobile shopping app checkout
| Stage | Sub-steps | ⚠ Flag |
|---|---|---|
| 1. Open cart | Tap cart icon → review items → adjust quantities | |
| 2. Enter details | Confirm shipping address → choose delivery speed | |
| 3. Payment | Select payment method → if not logged in: manually type card number, expiry, CVV → system prompts: "Create an account before continuing" | ⚠ High cognitive load. Users must stop, decide, and often abandon. |
| 4. Confirm | Review order summary → tap "Place Order" |
Design change identified: Move account creation to after order confirmation. Add a "Save my info for next time?" toggle as the final optional step. This removes an interruption mid-task, reducing abandonment at the highest-friction point.
Enter your user's goal, build the hierarchy of steps, flag the friction points, then generate a visual HTA map you can rearrange and export. Try it →
Ten questions covering all five learning objectives. Select one answer per question, then click "Check all answers" to see your score and the explanations.
Show example answer
Easy to learn (Learnability):
The interface should require minimal instruction to get started. For example, the watch could have only two physical buttons: one to cycle through functions (steps, heart rate, time) and one to confirm. A short narrated audio tutorial that plays the first time the watch turns on guides the user without requiring them to read a manual, reducing frustration for users unfamiliar with complex technology.
Error tolerant (Errors):
The design should prevent or forgive common mistakes. For example, if the user accidentally touches the screen with a shaky hand, the watch could require a 1-second long press to change any setting rather than responding to brief contact. Additionally, if the user forgets to stop a workout session, the watch could auto-detect 5 minutes of inactivity and display: "Did you finish exercising?", preventing inaccurate data recording without requiring any user action.
Show example answer
A designer would conduct task analysis by breaking the checkout process into a hierarchy of sub-tasks:
- Open cart
- Review items
- Select shipping address
- Choose shipping speed
- Enter payment information
- Confirm order
Pain point discovered: Users frequently abandon checkout after realising they must manually re-enter credit card details because they are not logged in, and a "Create account" screen appears after entering their email address but before payment, interrupting the task mid-flow and increasing cognitive load at the highest-friction point.
Design change: Add a guest checkout option that processes payment without requiring account creation. Reposition the account creation prompt to after the order is confirmed, with a simple "Save my info for next time?" toggle. This removes the mid-task interruption and reduces the steps between intent and completion.
Show example answer
Scenario: A team is designing an AI-assisted moderation dashboard for a large social media platform. Human moderators use the dashboard to review flagged posts for hate speech, bullying and misinformation.
Primary persona (Elena, 34, professional content moderator):
Goals: Quickly and accurately review flagged posts; minimise false removals; maintain personal wellbeing by avoiding repeated exposure to graphic content.
Needs: Clear visual indicators of violation type, batch processing tools, keyboard shortcuts, automatic blurring of graphic images.
Anti-persona ("Bad Actor" Ben):
Represents a malicious user or coordinated group who submits mass false reports to overwhelm moderators, or posts borderline content designed to confuse the AI filter. He is not a moderator; he is someone who exploits the system.
How the anti-persona prevents misuse: By designing with Ben in mind, the team can add safeguards: rate-limiting reports from a single account per hour; requiring a verified account before submitting reports; flagging accounts that repeatedly submit false reports for human review. These safeguards protect Elena from being flooded with junk reports, and protect legitimate users from coordinated false-flagging campaigns.
Show example answer
| Method | Advantage in this context | Disadvantage in this context |
|---|---|---|
| Field research | Observes real behaviour: watching students collaborate in a library or dorm reveals workarounds, distractions and silent frustrations (e.g., one student retyping instead of using comments) that users would never mention in an interview. | Time-consuming and unpredictable: group projects happen irregularly, and the observer's presence may change behaviour (observer effect: students may appear more productive than normal). |
| Structured interview | Produces consistent, comparable data across many students. Identical questions ("On a scale of 1–5, how easy is it to recover a deleted file?") allow statistical comparison between year groups or between tools. | Misses unconscious issues: students may say "collaboration is easy" while field research would show them spending 10 minutes per session figuring out who edited what. Structured questions cannot uncover what users don't think to mention. |
Recommended approach: Conduct structured interviews first to identify broad satisfaction patterns, then use targeted field observation with a small group to uncover the specific usability problems that interviews missed.
Show example answer
Research question 1: "At what specific point during the docking process do users fail to properly lock the scooter, and what physical or cognitive factors contribute to that failure?"
Method: User observation at an existing kiosk, watching 8–10 real users return a scooter.
Justification: Users are unlikely to be aware of or articulate the precise moment of failure in an interview. Observation at the actual kiosk captures the physical interaction in context (including hesitation, incorrect grip and missed feedback cues) that a questionnaire would miss.
Research question 2: "How satisfied are users with the current touchscreen interface, and which specific steps feel most confusing?"
Method: A short questionnaire with a 5-question Likert scale (satisfaction rating per screen) plus two open-ended follow-up questions.
Justification: A questionnaire can be distributed digitally to a large number of users quickly (e.g., via QR code at the kiosk), producing quantitative satisfaction scores that can be compared across different kiosk locations. The open-ended questions capture qualitative context that the Likert scores alone cannot provide.
Linking Questions
- To what extent does UCD rely on a strong foundation of ergonomics? (A1.1)
- How important is a good understanding of user-centred research methods to ensure effective UCD? (A2.1)
- To what extent can the UCD process be influenced by the quality of modelling and prototyping of potential design solutions? (B2.2)
- To what extent should a UCD process focus on ensuring inclusive design? (C1.2)
- What influence can product analysis and evaluation have on the effectiveness of UCD? (C3.1)