Definitions. UX — user experience — is the process of understanding and solving specific problems, often discrete digital interface solutions; it looks at the digital touchpoints. Service Design is the understanding of how services are created, delivered and experienced by customers, noting specific problems in an experience journey that need to be improved; it looks at the holistic experience of all online and offline interactions. The course draws the relationship as nesting: several UX problems sit inside one service, and the service sits inside the customer's overall perception of the brand, which is CX.

Why they matter. Good UX increases usability, reduces errors because they are considered early and solved for, generates revenue by helping businesses meet their goals, and meets real customer needs. Service design matters because a well-designed screen cannot rescue a service that fails around it — Harris Interactive found 86% would pay more for a better service experience, and the course's coffee-shop example makes the point that when two shops sell identical coffee at an identical price, service design is the reason a customer chooses one.

Examples from my own experience. In my group project on university group-assignment coordination, designing a clear scheduling screen was a UX concern — layout, hierarchy, whether the primary action was obvious. Making sure a confirmed meeting actually flowed through to notifications, task ownership and the way the team then worked together was a Service Design concern. When we tested only the screen, we found people could book a meeting easily and still had no idea who owned the work afterwards — a UX success sitting inside a service failure.

Why this matters commercially. Both are needed because they answer different questions. UX answers "can they do this?"; service design answers "does this whole thing work?" Investing only in the first produces a polished interface on top of a process that still frustrates people, which is the pattern behind the four challenges the course names — lack of differentiation, reliance on old systems and processes, disconnect between customer and business, and inability to innovate.

What I would consider. First, where the problem came from — a business investment in an initiative, or complaints heard in day-to-day life. Second, the current state: what the existing experience is like, how it would perform in a heuristics analysis, what the legacy products or services are, and where the gaps are. Third, competitors: what key players are doing, what industry best practice looks like, and what has been working well or not.

Then what sources I can rely on: business stakeholders — product owners, subject matter experts, and front stage and back stage employees; customers and end users, where I need to decide who I am designing for, whether I need a mix of participants, and whether different groups need separate sessions; and existing data analytics such as web traffic, call centre traffic, social media interactions and publicly available statistics.

Practically I would consider preparation — setting up the activity space, doing a practice run and testing the tech, physically (room, printing, whiteboard, markers, post-its) or digitally (Teams, Zoom, FigJam, Miro) — and roles, because everyone has one: meeting organizer, facilitator, note taker, time keeper, tech set up. Finally ethics: consent captured before the research, personally identifiable information stored securely, and being upfront and transparent about how insights will be used.

Two activities. (1) A 1-hour semi-structured user interview, chosen because the problem is not yet clear and I need to understand behaviour and motivation rather than measure it. (2) A co-design workshop with a mix of customers and frontline staff, chosen because it surfaces the current state and builds stakeholder buy-in in the same session.

Two artefacts. (1) A discussion guide — five timed sections over 60 minutes: introduction and warm-up, participant context, current state, exploring the ideal experience, and thank you and close. It exists so the session has a natural flow and is comparable across participants. (2) A participant recruitment brief / screener stating who I need, the behaviours they must already have, quotas across the mix, and an explicit exclusion — because who I exclude shapes what I can conclude.

The distinction. Quantitative data is anything that can be represented as a number; qualitative data is anything that can't. Their purposes differ too: quantitative research measures and assesses, confirms, justifies and validates, and closes down the inquiry; qualitative research explores, investigates, understands and expands the focus of the inquiry.

Quantitative examples. Direct success and indirect success rates on a task; overall task success rate; time to complete; the number of clicks needed; an ease-of-use rating out of 5; a confidence rating out of 5; click paths and heat maps showing where attention went.

Qualitative examples. What participants liked, what they did not like, and what they would suggest; overall impressions; and the observed and inferred responses a moderator records — for example *user pauses on screen* as an observation, and *user appears confused* as an inference.

How I would collect the quantitative data. An online survey using closed and Likert questions to measure how common a problem is at scale, scripted so that general questions come first, questions are chunked logically, wording is simple and specific to the audience, and only one thing is asked at a time. For task-level numbers, remote unmoderated testing through a tool such as Maze, which records completion, click paths and time without a moderator present. Existing web analytics where the product is already live.

How I would collect the qualitative data. One-to-one semi-structured interviews, using What, Why and summing-up questions and deliberate silence, and avoiding leading, hypothetical and design questions. Moderated think-aloud usability sessions where I brief the participant that we are testing the designs and not them, and ask them to narrate what they expect to happen. Contextual inquiry where the physical setting matters, observing with as little interference as possible. Consent is collected in every case, as industry standard practice.

Why both. Survey data can show what problems are common, but interviews can explain why those problems happen. Combining sources is triangulation — a form of cross-checking that increases the validity and reliability of the results, because weaknesses in one data source are compensated for by the strengths of another.

The five, with their sources. The course combines three authors' sets. From Alan Cooper ("Software should be polite"): 01 Software should be forthcoming and 02 Software should be self-confident. From Jakob Nielsen's usability heuristics: 03 Visibility of system status and 04 Match between system & real world. From Steve Krug: 05 Don't waste my time! The framing on the slide is that by combining different sets of heuristics we can readily assess any experience.

Evidence for 03, visibility of system status. This heuristic means the system keeps users informed and sets expectations through clear, appropriate and timely feedback. I would look for progress indicators that name the current step ("Syncing 5 of 21"), explicit success and error states, saved-versus-unsaved indicators, and whether the interface changes immediately when an action is submitted. A violation looks like a screen that goes inert after a submit with no spinner and no message, because the user then cannot distinguish processing from failure.

Evidence for 04, match between system and real world. This means the system speaks the users' language, using words, phrases and concepts familiar to them rather than system-oriented terms, and uses icons based on everyday objects. I would look for internal jargon or database terms surfacing in labels, raw error codes shown to end users, and menu structures that mirror the organisation chart rather than the user's task. The remedy the course gives is a card sort with real people — an open sort to see how users group and name things, then a closed round to validate.

The 5Ps are used to map out the territory of a reimagined service and to get a sense of the boundaries of the ecosystem. They sit within the Discover stage of the Double Diamond and help set the trajectory of research.

People — "it's about everyone's experience; your teams, your customers, and your partners." It splits into customers & users, employees (Front of House and Back of House) and partners. In a GP clinic: the patient is the user, though the service user who books may be a parent; the receptionist is Front of House; the practice manager and billing staff are Back of House; the pathology lab and pharmacy are partners.

Processes — "to understand the workflows, routines and workarounds to 'get the job done'", split into Operations and Systems. In the clinic: triage rules for urgent symptoms and the recall process for abnormal results are operations; the online booking platform and the medical record system are systems.

Places — "physical and digital environments where services are created, delivered and experienced", split into Touchpoints, Workspaces and In between. Touchpoints: the booking page, reception desk, waiting room, consult room. Workspaces: whether reception can actually see the waiting room. In between: the patient travelling to the clinic, and the gap between the consultation and results arriving.

Products — "the tangible objects and collateral used to inform or deliver the service", split into Digital, Analog and Spatial. Digital: the SMS reminder and e-script. Analog: the new-patient history form and printed referral. Spatial: clinic signage and the wait-time screen.

Performance — "measures of success, such as KPIs, for the business and its customers, which drive the quality of the service provided." It is the least tangible and sits across all of the other four. For the clinic: no-show rate and appointments per day for the business, waiting time for the patient — and, importantly, the course notes performance "doesn't have to be measured in numbers, it can be measured by emotions or how valuable it is to a person", so whether the patient felt listened to is also a performance measure.

A service blueprint is "an operational tool that visualizes the components of a service in enough detail to analyze, implement, and maintain it". It is laid out as components against stages: time runs left to right across experience stages, and the components run down as swim lanes. Each vertical column is a service moment — everything happening at that instant, frontstage and backstage.

The five components are: Physical evidence (touchpoints) — the medium of exchange between the customer and the service, from confirmation emails and SMS to signage, uniforms and paperwork; Customer actions — the physical or mental actions the customer performs; Frontstage actions — staff actions the customer can see; Backstage actions — staff actions taken for this customer out of sight; and Support processes — the tools and systems necessary to support the staff and the service moment.

Three lines cut across the lanes. The line of interaction marks what customers can and cannot directly interact with. The line of visibility is the division between frontstage and backstage — "the elements you choose to show to your customer (and when) can have a profound impact on the experience". The line of internal interaction separates backstage actions from support processes. Note that the lecturer's own template draws only the first two, so a two-line blueprint is equally acceptable.

Why the line of visibility matters. It is the mechanism that makes the blueprint useful. A customer's experience is shaped by work they never see, so plotting that work below the line lets you trace a visible failure back to an invisible cause. For example, a patient reports at reception; the receptionist flags them as arrived; that flag changes a status on the doctor's screen inside the consulting room. The customer sees none of it, but if that step does not happen they wait indefinitely. That single arrow crosses both lines and is exactly what a blueprint exists to expose.

Purpose. A current-state blueprint is used at the beginning of a project to capture the experience as it is presently delivered — it aligns teams on the current state, captures existing operational knowledge, and identifies service breakdowns and pain points. A future-state blueprint is used toward the end of the design process to communicate change, plan touchpoints, capture operational needs and develop roadmaps — and once the experience is built, it helps future teams maintain it, "just as an architectural blueprint helps a building engineer maintain a building".

The three differ across fidelity, cost, interactivity and what they represent. A sketch is low fidelity, very quick, free, minimal in detail, static, not user-testing ready, and represents ideas. A wireframe can be low, mid or high fidelity, is quick and inexpensive, minimal in detail, static, also not user-testing ready, and represents screens. A prototype is high fidelity, less quick, inexpensive, "appropriately refined" in detail, interactive, user-testing ready, and represents flows and function.

When to use each. A simple block sketch — placeholders for images marked with an X, text as lines or scribbles, not drawn to scale — is best used in the divergent phase when you have several concepts to share, and while doing information architecture research. Its purpose is to "communicate concepts, not specifics". A wireframe is used as divergent options begin to converge, for more formal reviews with stakeholders, and with engineers to confirm functionality. A prototype is used to simulate an interactive digital experience, to test with users during any phase of the design cycle, and to mitigate the risk of releasing bad solutions to the market.

The discriminator that matters. Only the prototype is interactive and user-testing ready, so if the research question is about navigation or where a workflow breaks, a wireframe cannot answer it. Conversely, if the question is about concept understanding, categorisation or naming, a wireframe is sufficient and much cheaper. The governing rule the course gives is that "your wireframe should match your level of thinking and what you're trying to communicate."

All three are visual artefacts, but each is a picture of something different.

A storyboard is a picture of a person's situation over time. It is linear and sequential and visually communicates how a customer may interact with an experience or service. It runs in three acts — Beginning is the Problem, Middle is the Objective / Goal / Action, End is the Outcome — and it uses characters, speech bubbles, devices, signs, arrows and backgrounds to carry context and emotion. It shows why the design matters to someone. It does not show layout, and it shows nothing of what the organisation does invisibly.

A wireframe is a picture of a screen — "a stripped-down visual map without any graphic treatment". It communicates design intent, hierarchy of elements, functionality, relative proportions, page layout and interaction options. Joined into a wireflow it shows the screens needed to get from A to B on the happy path. It shows nothing about emotion, context outside the screen, or backstage systems.

A service blueprint is a picture of the whole service, visible and invisible — "an operational tool that visualizes the components of a service in enough detail to analyze, implement, and maintain it". Experience stages run across as time unfolds, and five lanes run down: physical evidence, customer actions, frontstage actions, backstage actions and support processes, divided by the line of interaction, the line of visibility and the line of internal interaction. It shows what must happen inside the organisation for the customer's experience to work. It shows nothing of screen layout and does not carry an individual's narrative emotion.

Put simply: the storyboard answers "why would anyone want this?"; the wireframe answers "what does it look like and how does it work?"; the blueprint answers "what has to happen behind the scenes for this to be possible?"

Concept testing happens at earlier stages of the design and aims to refine and remove ideas quickly to focus on key ideas only. Its purposes are to evaluate the MVP and value proposition, prevent bad ideas progressing, and refine good ideas. It is structured around hypothesis-driven learning, participant snapshots, and scenarios with task-oriented instructions, and can be run on wireframes, early prototypes, storyboards or service blueprints.

Usability testing is a more rigorous form of evaluative testing that happens closer to the completion of development, before release. It uncovers problems in the design, discovers opportunities to improve it, and teaches you about user behaviour and preferences. Its core elements are the facilitator, the tasks and the participant, and it allows experiences to be measured and compared across industries or over time.

When each. Concept testing is right when you are deciding whether to build something — you have three storyboarded ideas and want to kill two before investing in either. Usability testing is right when you have decided what to build and need to know whether people can actually complete the task, and how long it takes them.

Where I would start. Before recruiting anyone I would do a current-state analysis — what is the existing timetabling experience like, how does the official system perform against the five heuristics, what are the legacy tools, and where are the gaps — and a competitor analysis, which here means the unofficial third-party tools students have adopted. The fact that students built and chose workarounds is itself evidence about where the official system fails, and it is free to gather.

How much research is warranted. Using the Risk × Problem Clarity matrix: problem clarity is moderate (we know students struggle, but not why they abandon the official tool) and risk is high (a timetable error costs a student a term). That puts this toward Research Heavy, which justifies primary research rather than shipping and measuring.

Sources. Business stakeholders: the product owner for the student system, subject matter experts in timetabling, and front stage staff such as student-centre advisors who field the complaints. Customers and end users: students. Existing analytics: web traffic on the timetabling pages, and call-centre or help-desk volumes during enrolment week — both of which tell me where the process leaks before I ask anyone anything.

Method 1 — an online survey (quantitative). Chosen to measure the scale of the problem: how many tools students use, how often clashes occur, how long the process takes, and how satisfied they are. Justified because I need to know which pain points are common rather than merely vivid, and a survey is the only method here that reaches enough students to say so. I would keep it short, chunk questions logically, avoid double-barrelled and leading wording, and use a mix of closed and Likert items.

Method 2 — semi-structured 1:1 interviews (qualitative). Chosen to explain why: asking students to walk me through the last timetable they built, what they tried, where they got stuck, and why they moved to an unofficial tool. Justified because the survey cannot recover reasoning or workaround behaviour. I would use What and Why questions and summing-up questions, avoid leading, hypothetical and design questions, and use silence deliberately.

Participant criteria. Who: currently enrolled students who have built a timetable in the last two terms. The mix must span the groups whose constraints differ — first-year undergraduates, postgraduates, students with part-time jobs, and students with long commutes, because each faces a different version of the problem. Exclusion: students who have never built their own timetable, since they cannot speak to the task. I would state that recruitment through university channels is a convenience sample and that findings are directional.

Artefacts I would produce. A research plan stating the problem, the objective, the approach and why, the sample and why, and the key research questions; a discussion guide with timed sections; and a participant recruitment brief with quotas and the exclusion.

How I would know when to stop. When new interviews stop producing new insights — the course's own signal that discovery has come to an end for now — and when I can triangulate the same finding across the survey, the interviews and the analytics.

People. Customers & users — the patient, who may not be the person the medicine is for. Front of House — the counter pharmacist and assistants. Back of House — the dispensing pharmacist and stock staff. Partners — the prescribing GP, the e-script service, wholesalers.

Processes. Operations — script verification, checking for interactions, the rules governing which medicines require a pharmacist conversation. Systems — the dispensing system, the e-script token service, the point-of-sale terminal.

Places. Touchpoints — the counter, the waiting area, the collection point, the pharmacy app if one exists. Workspaces — whether the dispensing bench is visible from the queue, which changes how the wait feels. In between — the customer leaving to shop elsewhere and returning, which is currently unsupported.

Products. Digital — the e-script token, an SMS "ready for collection". Analog — the printed script, the dispensing label, the medicine information leaflet. Spatial — queue signage, the collection shelf.

Performance. Business — scripts dispensed per hour, walk-away rate. Customer — minutes waiting, and whether they understood how to take the medicine. Non-numeric — whether the customer felt the conversation was private.

What the mapping reveals. The wait is not caused by the counter interaction; it is caused by Processes — verification and dispensing happen only after the customer is physically present — combined with a gap in Places, because nothing supports the "in between" period when the customer could be elsewhere. That points to an intervention on the process, not the counter: accept the script ahead of arrival and notify when it is ready. Critically, the mapping also shows what must not be automated — the pharmacist conversation required for certain medicines is a Front of House action with a clinical purpose, so a redesign should preserve it while removing the wait around it.

Two faults. First, it frames the business's annoyance rather than the user's need — the emails are a symptom of student uncertainty, and "stopping" them could be achieved by removing the email address, which would make the experience worse. Second, the solution is already embedded in the verb "stop", which forecloses the range of possible answers. A good How Might We suggests a solution is possible without suggesting a particular one.

Rewrite: "How might we make students feel confident they have all the information they need to enrol correctly?"

Why the rewrite is better. It states the user's desired outcome — confidence — rather than the organisation's preferred behaviour. It allows a variety of solutions: clearer guidance at the point of enrolment, a status indicator, a peer channel, a proactive message. And it is neither too broad nor too narrow: it gives a clear place to start brainstorming while leaving room to explore. It follows the pattern the course models on its "good" examples, which are consistently phrased as making users feel confident about something.

What is missing — three things the course requires for each C activity: the instructions a participant could actually follow; the questions the facilitator will ask; and the time allocation. "Participants generate ideas" is a restatement of the activity name, not an instruction, and "a list of ideas" is not a specified output format. There is also no statement of what this activity is meant to produce for the next stage.

Rewrite:

Activity 3 — Create · Idea Storm (#28) · 10 minutes

Instructions: "You have 4 minutes to write as many ideas as you can on separate stickies, working on your own and in silence — one idea per sticky. Do not discuss yet. We will then read them out together."

Questions the facilitator asks: "What would have to be true for that idea to work?" · "Is there an idea here that solves the ownership problem rather than the reminder problem?"

Time: 4 min silent generation, 6 min read-out and clustering.

Expected output: a set of individually authored ideas, clustered, ready for the Commit activity to prioritise on an Effort/Impact scale.

Also worth saying: individual generation before group discussion is deliberate — it reduces anchoring on the first idea spoken, and it addresses the course's own warning about "biases in the group and loud/outspoken members".

Measured against the course's four criteria for a good hypothesis, this fails three of them and arguably all four.

Not specific. "The checkout is confusing" is not a problem drawn from research; it is an impression. A usable "we believe" clause names what people were observed doing or saying.

The change is vague. "Redesign it" is not a variable that can be changed — it is the whole project. The course's own weak example makes exactly this mistake ("if we change the filters"), and its strong example names a specific intervention ("include a mega-menu in our prototype").

Not testable, and non-directional. "A better user experience" cannot be measured. There is no number, no threshold, and no way to tell afterwards whether the prediction held.

Rewrite: "We believe customers abandon the checkout because the total price changes at the final step when the booking fee is added. So if we display the fee-inclusive total on the results list, we will see fewer abandonments at the payment screen and at least 4 of 5 participants correctly state the total they expect to pay before reaching payment." This makes a prediction, names one specific change, and carries a measurable outcome.

Finding 1 — "Enrolment Entity Extract". This violates Match between system & real world, which requires the system to speak the users' language with words, phrases and concepts familiar to them rather than system-oriented terms. "Entity" and "Extract" are database vocabulary. Consequence: students cannot find their class list without asking someone, which converts a self-service task into a support contact and makes the portal feel like it was built for the institution rather than for them. Recommendation: relabel it "My classes", and validate the vocabulary through an open card sort with students followed by a closed round, so the naming is evidenced rather than assumed.

Finding 2 — no confirmation for 15 seconds after submit. This violates Visibility of system status, which requires the system to keep users informed with clear, appropriate and timely feedback. Consequence: the user cannot distinguish processing from failure, so some will submit a second time — creating duplicate enrolments — and others will abandon believing it failed. This is most damaging precisely because it happens at the moment of commitment. Recommendation: disable the button immediately on submit and show a determinate indicator that names the step ("Confirming your enrolment…"), followed by an explicit success or failure state that says what happens next.

Finding 3 — errors as "ERR_0x2201". This violates Match between system & real world again, and it also fails Don't waste my time, which requires giving users the key information they need to complete the task with ease. Consequence: the user is told something went wrong but not what, why, or what to do, so the only available action is to contact support. Recommendation: replace the code with a message that says what happened, why it happened, offers reassurance, gives a way out and helps them fix it — the five-part structure the course models on its "good" error message. Retain the code in a collapsed detail line for support staff, not as the primary message.

Prioritisation. If only one can be fixed this term, fix the missing submit feedback. It is the only one of the three that causes an incorrect outcome — a duplicate enrolment — rather than friction, and it occurs at the highest-value point in the journey.

Not perceivable and predictable. One undifferentiated column mixes personal details with payment details, and there is no visual hierarchy telling the donor what matters. So what: donors must re-read the whole form to locate themselves, and switching mental contexts mid-form is where abandonment happens. Recommendation: chunk the fields under "Your details" and "Your donation", place labels above their inputs, and give the screen one visually dominant primary action.

Does not provide constraints. A free-text amount field accepts anything, including malformed values. So what: errors are only discovered at submit, after the donor has invested effort. Recommendation: offer preset amount buttons with an "other" option, and validate inline at the field rather than at the end of the form. The course explicitly lists "including validations before submitting a form" as a way design prevents issues occurring.

Does not provide feedback. Nothing confirms the donation was received. So what: the donor does not know whether they have given money, which is the single worst moment to leave someone uncertain, and it will generate support contacts and repeat submissions. Recommendation: confirm at both ends — an immediate state change on submit, and an explicit success screen with a receipt reference and what happens next.

Consistent and conventional and natural affordances should also be checked: does the submit button look pressable and behave like buttons elsewhere on the site, and does the form follow the platform conventions donors already know from other payment flows? Following convention here is not laziness — as the course puts it, users prefer a site to work the same way as the other sites they already know.

Priority. Feedback first, because a donor who does not know whether their money went through is a donor who may not return; then constraints, because they prevent the errors rather than reporting them; then the chunking, which improves completion rate but does not cause failure on its own.

• The screen labelled at the top with its name and, if you draw more than one, a number.
• Major regions blocked out — header, status summary, primary action, list, navigation. Boxes and lines only; images as an X, text as lines. Not to scale.
• A system-status element — a progress indicator, a count of tasks needing attention, or both. This is the element most drawings omit and it maps to a named heuristic and a named design principle.
• One visually dominant primary action.
• Navigation shown, with the current item marked.
• One non-happy-path element — a flagged or blocked item, or an empty state.
• Numbered margin annotations with leader lines, each stating a decision and its reason. For example: "3 — the at-risk task is placed first because research found blockers were discovered too late; ordering by urgency rather than by date makes the problem visible without the user searching for it."
• A closing sentence on fidelity: "This is deliberately low fidelity — placeholders rather than content — because at this stage I am testing whether the information hierarchy communicates status, not what it looks like."

The annotated example in Chapter 11 shows exactly this layout with six worked annotations.

Structure first — draw the grid before filling anything in. A scenario line at the top; four or five named experience stages across (Arrival → Registration → Waiting → Vaccination → Observation & departure); five lanes down; the line of interaction under customer actions and the line of visibility under frontstage actions, both labelled. Add the line of internal interaction above support processes if you want the full three-line model.

Then fill in the course's own order: customer actions first — "this will form the backbone of the blueprint" — then work down the rows in each moment, then across. Name the actor in every staff action, and use one touchpoint per service moment.

A complete response should include:

• Physical evidence at volume: street signage, queue barriers, consent form, information leaflet, the vaccine vial and tray, the observation-area chairs and timer, staff uniforms and lanyards, the SMS certificate.
• Back stage actions that are genuinely actions: "checks the patient's immunisation history in the register", "draws up the dose", "records the batch number against the patient".
• Support processes that are genuinely standing capabilities: the immunisation register, cold-chain storage and monitoring, clinical governance and adverse-event protocol, staff training and accreditation, stock ordering.
• At least two arrows crossing a line — e.g. the consent form handed over (crossing the line of interaction), and registration writing to the immunisation register (crossing the line of visibility).
• One or two circled failure points with a sentence each: "the 15-minute observation period has no visible timer, so patients ask staff repeatedly when they can leave — a visibility-of-status gap with a staffing cost."

State whether it is current or future state. One line at the top. It takes only one line, and it is the thing tutors corrected most.

Six frames in three acts. Beginning = Problem: frame 1 establishes a named actor in a real context; frame 2 delivers the trigger and the pain point. Middle = Objective / Goal / Action: frame 3 shows what they currently try; frame 4 introduces the intervention and the touchpoint. End = Outcome: frame 5 shows the immediate result; frame 6 shows what it enables next.

Stick figures are fine. Each frame gets a one-sentence caption in the actor's point of view. Emotion must visibly change across the frames — the low point in frame 2, resolution by frame 5 — because "Highlight Emotion" is one of only three principles the course gives for a great storyboard, alongside "Stay Authentic — focus on real humans in real contexts" and "Keep it Simple — edit, edit, edit".

The trap to avoid: drawing six app screens. That is a wireflow. A storyboard shows the world around the touchpoint — where the person is, what else is going on, and how they feel — which is precisely what a wireframe cannot carry.

What the numbers say. Combined direct and indirect success is 91%, so the task is achievable — this is not a blocking effectiveness failure. But the split matters more than the total: 19% indirect success means nearly one in five participants completed the task by a route we did not design. That is not a success; it means the intended path is not the discoverable one, and the flow is working partly by accident. The 9% failure rate is a genuine blocking problem for a minority.

The confidence rating is the real finding. At 3.1 out of 5 against a 91% success rate, there is a clear gap between what users did and what they believed they had done. Users are completing the task without trusting the outcome. That is characteristically a feedback and system-status problem rather than a navigation one, and the first open comment — "I wasn't sure it had actually saved" — corroborates it directly.

The qualitative data localises both problems. "I found it in the end but not where I looked first" explains the indirect success: the entry point is not where users expect it, which is a match-to-the-real-world or hierarchy issue. "I wasn't sure it had actually saved" explains the low confidence: no clear success state after the action.

Conclusion. Using the course's framing, this experience should be iterated, not validated. Low confidence rating due to the absence of an explicit confirmation after saving; substantial indirect success due to the primary entry point being mislocated relative to where users look; therefore two specific changes are needed.

What I would do next. (1) Add an explicit, persistent success state after the action, naming what was saved — addressing the confidence gap directly. (2) Use the click-path and heat-map data to identify where the 19% actually clicked first, and either move the primary entry point there or raise its salience through contrast and position. (3) Re-test the same scenario with the same measures so the two rounds are comparable, and treat the confidence rating as the primary success criterion this time, since it is the measure that exposed the problem.

One caution. A 9% failure rate deserves qualitative follow-up before redesigning — unmoderated testing tells you that people failed but not why, so I would run a small number of moderated think-aloud sessions on the same task to recover the reason rather than guessing at it.

(a) Exploratory research. I would begin with a current-state analysis — how the reservation and room-booking systems perform against the five heuristics, what legacy systems exist, and where the gaps are — and with existing analytics, because the council already holds two rich secondary sources: desk enquiry volumes (which tell me what staff are repeatedly asked) and booking-system data (which tells me how often double-bookings actually occur, rather than how often they are complained about). That is free evidence and it targets everything that follows.

Activity 1 — semi-structured 1:1 interviews with members, chosen because the complaint "reservations never seem to arrive" is a statement about expectation, not about logistics, and only an interview can recover what members expected to happen and when. Activity 2 — a co-design workshop with front-desk staff, chosen because staff are the front stage employees who see every failure and have already built workarounds; the workshop surfaces the current state and builds buy-in for whatever changes follow.

Artefact 1 — a research plan stating the problem, the objective, the proposed approach and why it suits this context, the sample and the rationale for who is included and excluded, and the key research questions. Artefact 2 — a discussion guide with five timed sections across an hour, weighted toward the current state.

Participant criteria and justification. Who: library members who have reserved an item or booked a study room in the last three months — a behavioural qualifier, not a demographic one, because the task must be recent enough to recall. The mix should span the distinct user groups whose needs differ: students using study rooms, casual borrowers reserving books, and event attendees. I would also run a separate session with front-desk staff, because mixing staff and members in one session suppresses honest criticism of staff. Exclusion: members who only browse in person, since they have not used the systems in question. Limitation: recruiting through the library's own channels reaches engaged members and under-represents people who gave up, so I would state that the sample skews toward continuing users.

(b) Two How Might We statements.

HMW 1: "How might we help members know where their reservation is and when it will be ready, without having to ask at the desk?"

Well framed because it states the member's desired outcome — knowing — rather than the council's desired behaviour of fewer enquiries; it contains no solution, so it could be answered by a notification, a status page, a shelf-location system or a change to how staff communicate; and the "without…" clause names the burden to avoid without prescribing how.

HMW 2: "How might we make members confident that a study room they have booked will actually be available when they arrive?"

Well framed because it targets confidence, which is the real damage caused by double-booking — the loss of trust rather than the single wasted trip; it does not specify a locking mechanism, a check-in system or a policy change, all of which remain open; and it is narrow enough to start brainstorming from while broad enough to allow a non-technical answer.

Failure point chosen: a room can be booked online but there is no mechanism confirming the booking is still live at the time of arrival, so a room released by a no-show is not reallocated and a double-booked room is only discovered in person.

Hypothesis. "We believe members lose trust in study-room bookings because a booking is not confirmed close to the time and no-shows are never released. So if we send a confirmation prompt 30 minutes before the booking that the member must acknowledge, and automatically release unacknowledged rooms after 10 minutes, we will see fewer arrivals at an occupied room and at least 4 of 5 participants correctly state whether their room is confirmed before travelling to the library."

Test scenario. "You have booked study room 2 for 2pm this afternoon to work on an assignment. It is 1:30pm and you are about to leave home. Using the app, find out whether your room is confirmed, and make sure it is still held for you when you arrive." The scenario states goals, sets a realistic context, and names no screen or button.

Three research questions. (1) Task-based: "Show me how you would check whether your room is confirmed." (2) Probe: "What did you expect to happen after you tapped that? Why?" (3) Rating: "On a scale of 1 to 5, how confident are you that the room will be available when you arrive?"

Two measures of usability. (1) Quantitative — task success: the proportion of participants who confirm the booking without assistance, and whether they do so by the intended route or an indirect one. (2) Quantitative — confidence rating: the average out of 5 from question 3, chosen because confidence is the outcome the hypothesis actually predicts; success alone would not tell me whether trust had been restored. Qualitative open feedback would supply the rationale behind both.

How I would decide whether to iterate. If success is high and confidence is high, the design is validated and no action is required. If success is high but confidence is low — the pattern seen in the earlier renewal study — the mechanism works but does not communicate, so I would iterate the feedback and copy rather than the flow itself. If success is low or indirect success is substantial, the entry point is not discoverable and I would iterate the information hierarchy and re-test the same scenario with the same measures so the rounds are comparable. A disproved hypothesis is not a failure; it means taking another approach based on user insights.