Personas and Requirements Pitfalls
Personas
A persona is a fictional but realistic profile representing a class of users, built from user research data — not guesswork. A well-constructed persona typically includes:
- A name and a representative photo or sketch.
- Goals — what they are trying to achieve.
- Frustrations — what currently gets in their way.
- Technical proficiency and domain expertise.
- A representative quote that captures their attitude.
- Relevant demographic or contextual details (age, role, environment).
Why Personas Matter
- Focus: they keep the design team concentrated on real user needs rather than an imagined “average user” or — worse — the designer themselves as the implicit model.
- Conflict resolution: when the team disagrees about a design decision, the question becomes “would this persona actually do this?” rather than a battle of personal preferences.
- Communication: they convey user research findings concisely to stakeholders who were not present during the research.
Exam Trap: Generic Personas
“John, 25, likes technology” is not a persona — it is a demographic blob.
A good persona is specific to the app’s domain and includes a concrete pain point that the design addresses. For a career-guidance app, “Emma, 22, a final-year languages student who feels overwhelmed by the number of career options and does not know where to start — she wants structured, step-by-step guidance, not a search engine” is a useful persona. “Student, 22, wants a job” is not.
Three Common Pitfalls in Requirements Gathering
1. Users Cannot Always Articulate Their Own Needs
Especially for tacit, habitual, or automatic behaviour — a user may genuinely not know why they do something a certain way, because they have never thought about it consciously. Asking “what do you need?” is insufficient.
Solution: use observational methods (ethnography, contextual inquiry) rather than relying solely on self-report through interviews or questionnaires. Watch what users do, not just what they say.
2. Stated Preferences Diverge from Actual Behaviour
A classic pattern: someone claims in an interview that they never use a particular feature, but behavioural log data shows they use it daily. Or they claim to find a feature confusing but complete tasks using it efficiently and without error.
Solution: triangulate self-report with behavioural or log data. Never accept stated preference as the sole source of truth; corroborate it with observation or analytics.
3. Requirements Change Over the Project Lifecycle
As understanding deepens — particularly as prototypes are tested with real users — earlier requirements are found to be wrong, incomplete, or based on faulty assumptions. This is normal and expected; it is not a sign of failure.
Solution: adopt an iterative UCD process so requirements can be revisited at each cycle, rather than being frozen upfront (waterfall-style). The whole point of prototyping and evaluation is to discover that requirements need changing before those changes become expensive.
Weak Evidence Does Not Support Strong Claims
A recurring Tripos question type gives a small piece of evidence and a bold claim, and asks you to critique it. The standard checks:
| Check | Example of a violation |
|---|---|
| Sample size | ”2 of 4 people preferred not to use ring-back” → claimed “half of users don’t use ring-back.” A sample of is far too small to generalise to “users” as a population. |
| Self-report vs observation | ”Joan said she walked 10 minutes once to collect a printout” → claimed “significant time is wasted by designers generally.” A single anecdote about one person on one day cannot support a claim about a group. |
| Maths and source credibility | ”8 of 1000 logged hours were spent on helpfiles” → claimed ”< 1% of time.” Here , so the maths checks out and the data source is objective log data across a large sample — this one is well-supported. |
When asked to critique evidence, explicitly check all three: sample size, whether behaviour was observed or self-reported, and whether the quantitative claim follows from the data.
Good Requirements Checklist
- Testable: could you write a test that passes or fails based on this requirement?
- Specific: does it name a concrete capability or constraint, not a vague adjective?
- Grounded: is it tied to a user need or stakeholder analysis, not invented by the designer?
- Prioritised: in a list of requirements, which are essential (Must have) and which are desirable (Should/Could have)?
Expected Learning
- Describe what a persona is, what it contains, and how it is used in the design process.
- Critique a given persona for being too generic or insufficiently domain-specific.
- Name and explain the three common pitfalls in requirements gathering, with solutions for each.
- Critique a given piece of evidence and claim using the three standard checks (sample size, self-report vs observation, quantitative accuracy).
- Understand that requirements are iterative and provisional in UCD — they are refined through each cycle.
Past Paper Questions
Evidence-critique questions appear in: 2023 Q6 (mindfulness app — evaluating interview findings), 2020 Q5 (evaluating quantitative findings). Personas appear in 2024 Q5 (ChatGPT — suggested personas in a sketch). The “weak evidence → strong claim” trap is tested in the Supervision 1 material.