Question 6 of 14: Persona-Based Design in the UCD Lifecycle

Question 6: Persona-Based Design in the UCD Lifecycle (10 marks)

Question text not reproduced: the examination questions are © Engineers and Geoscientists BC. Open the official past paper (linked at the top of this page) to read the question, then follow the worked solution below.

Part A — pros and cons of persona-based design. Pros: personas turn an abstract, statistical description of "the users" into a concrete, memorable individual the whole team can design and argue for/against, which improves communication and keeps design decisions grounded in specific needs rather than the designer's own assumptions; they help surface and reconcile conflicting requirements across distinct user types (a hospital pharmacist building a library differs sharply from a nurse only ever selecting from it) by making the differences explicit; and they persist as a shared reference across a long project, reducing the risk that "the user" quietly drifts to mean "whoever is in the room." Cons: a persona built on weak or biased research (assumptions rather than real data) can be actively misleading, giving false confidence to a fictional profile that does not represent real users; personas can oversimplify a genuinely diverse user population into a small number of stereotypes, causing edge-case or minority user needs to be designed out; and they require real upfront investment (user research, validation, maintenance as understanding evolves) that a time-pressured project may be tempted to skip, producing personas invented from opinion rather than evidence.

Part B — building and placing personas. A persona is put together by (1) gathering data on real users through interviews, observation and surveys of actual or representative pharmacists and nurses across different hospital units; (2) identifying patterns/clusters in that data — groups of users who share goals, behaviours, pain points and technical proficiency; (3) synthesising each cluster into a single fictional but specific individual with a name, role, goals, frustrations, and relevant context (e.g. "Denise, senior ICU pharmacist, updates the ICU drug library twice a year, comfortable with Windows software but has limited time and zero tolerance for ambiguous confirmation dialogs"); and (4) validating and documenting the persona so the whole team uses the same reference. Within the UCD lifecycle, personas are best created during the early "understand users/context of use" and requirements-gathering stage, right after the initial user research is analysed and before design concepts are generated, so that the research findings are captured in a form the design stage can actually use. They are then used throughout design and evaluation — to generate and prioritise design alternatives ("would Denise be able to find this in under 10 seconds?"), to write task scenarios for prototyping and usability testing, and to sanity-check design decisions and trade-offs at every subsequent iteration.