INFS3700 Exam Sprint Guidethe condensed version · 12 revision areas, answer skeletons, 2 mock exams
No section matches that search term. Try a shorter word, or clear the search.
Sprint guide · Section A

The exam on one page

Everything on this page comes from 10 UX & SD in Industry — Lecture Slides T2 2026, the lecturer's own revision deck. It is the only authoritative statement of scope and format that exists. If anything elsewhere in your notes contradicts this page, this page wins.

FactWhat the slides say
Duration15 minutes reading time + 2 hours writing
Total100 marks
Question 125 marks — sub-parts of 10 + 15
Question 220 marks — sub-parts of 8 + 12
Question 355 marks — sub-parts of 10 + 5 + 10 + 15 + 15
ConditionsOn campus, Inspera with Safe Exam Browser. No notes. Physical student ID, laptop + charger, smartphone for MFA, a pen
Marking criteriaNone released. The deck says "We will not provide marking criteria"
FeedbackSummative only — no qualitative feedback, no exam mark on Moodle
Source: Week 10 Lecture, slides 14–23. The mark split is slide 23.

The four named formats

Formats explicitly named

  • Theoretical questions — define and explain a concept
  • Case study questions — apply concepts to a supplied scenario
  • Drawing out artefacts — produce a diagram, not prose
  • "Always use examples to support your points!!!" — the deck's own punctuation, said twice

What the slides do not say

  • Which question covers which topic.
  • Which sub-parts are written and which are drawn.
  • How marks are distributed inside a sub-part.
  • How long an answer should be.

Plan around the mark values, which are published, rather than around a predicted topic, which is not.

What the Week 10 recordings add that the slides do not say transcript-derived

  • Two sub-parts are hand-drawn, and both are inside Question 3. "two out of these 12345 questions are drawing questions, uh, for the question three." So two of Q3's five sub-parts require a hand-drawn artefact and cannot be answered with prose alone. On the paper supplied, the lecturer's wording was tentative — "I think each one of you will be given 4 pieces of paper" — so expect four sheets rather than count on it.
  • You draw on paper, photograph it and upload it — "draw you can draw it. / Uh piece of paper. / Take photo, upload that." The drawing is a sub-question inside the case study, not a separate question.
  • The two hours includes all of that — "two hours including answering the questions drawing and uploading that."
  • Theoretical questions may be scenario-framed — "imagine if you were something something or this business… and you would use framework, principles, um, we taught in this course, uh, to answer that question." The case study is "a problem space looking thing".
  • Bring a pencil as well as a pen. The slide prefers a pen; the tutor prefers a pencil because you can erase, then concluded "Pen or penciling doesn't really matter that much… make sure that you can make your drawing clear to us". Legibility in the photo is the actual requirement.

Lecture transcript clarification — lecture transcript\wk10.txt, SPEAKER 0 (lecturer). Tutor explanation — WEEK10\tut transcript raw.txt, [22:55]–[23:09], [27:53]–[29:40], [29:51]–[30:08]. These are spoken clarifications, not printed slide content; the Week 10 slides remain authoritative on everything they do state.

12 exam-relevant revision areas — and where each one is taught

Eleven areas are explicitly listed on Week 10 slide 12. Quantitative and qualitative data is included as an additional revision area because Week 10 slide 30 revises it directly and Practice Question 3 explicitly examines it. Note also that slide 12 prints "Workshop / interview planning" as a single combined entry, which this guide keeps as one area (02).
#Topic (the deck's own wording)GroupPrimary source
01Participant criteriaAssignment tasksW2 s67; W7 s26–27, s35; assignment briefs
02Workshop / interview planningAssignment tasksW2 s41–57, s64–69; W10 s8–9
03Synthesis & analysisAssignment tasksW3 s14–33, s55–67; W10 s27
04WireframesAssignment tasksW5 s7–33
05UX TestingAssignment tasksW7 s6–51
06Heuristics evaluationP&P tasksW1 s30–40; W10 s25–26
07Research methodsP&P tasksW2 s17–39; W10 s6–7
08Design principlesP&P tasksW4 s8–32; W10 s28–29
09StoryboardsP&P tasksW4 s43–50; W7 s10
10Service design 5PsP&P tasksW8 s38–44
11Service blueprintP&P tasksW9 lecture deck (40 slides); W9 tut prep
12Quantitative & qualitative dataResearch data & metricsW2 s20–39; W7 s42–43; W5 s47–49; W10 s30
Areas 01–11 are the eleven entries printed on Week 10 slide 12 under "Assignment tasks" and "P&P tasks" — counting "Workshop / interview planning" as the single combined entry the slide prints. Area 12 is not on slide 12; it is included because slide 30 is a full revision slide headed "Week 2, 7 Research data and metrics", and Week 10's own Practice Question 3 asks directly about quantitative versus qualitative data.

What is not examinable

Excluded topics explicitly excluded

  • Personas
  • Journey maps
  • Design patterns & design systems
  • Service design capabilities

Excluded formats explicitly excluded

  • Mid- to high-fidelity sketching — you will not be asked to produce one
  • Calculations — no arithmetic is required
  • Referencing — no citation format is required
Source: Week 10 Lecture, slide 13 — "What won't be in the exam".

Two traps in the exclusion list

  • Excluded ≠ unmentionable. You may still name a persona or a journey map as a step in a process — the Week 3 method map itself does. What is excluded is being asked to build one, or building an answer whose substance is one.
  • You still need to know what mid- and high-fidelity mean. That is the argument for choosing low fidelity. What is excluded is drawing them, not defining them.
Sprint guide · Section B

The whole course as one process

Every one of the twelve revision areas sits somewhere on this line. If a case-study question drops you in the middle of a project, this map tells you which topic you are being asked about — and what came before and after it, which is usually what an "explain why" sub-part is reaching for.

Define scope Discover Define Develop Deliver Project brief 07 Research methods 01 Participant criteria 02 Workshop / interview plan 03 Synthesis Insights · HMW Prioritisation 08 Design principles · 06 Heuristics 09 Storyboards → 04 Wireframes 10 5Ps → 11 Service blueprint 05 UX Testing Hypothesis 12 Data & metrics Iterate The sentence that runs the whole way along: observation → theme → insight → problem / HMW → concept → hypothesis → result → decision. Every "so what?" in this course sits on one of those arrows.
Original diagram, built for this guide. The four phase names and the Iterate loop are the course's own Double Diamond wording (Week 10, slide 11); the topic numbers are this guide's, matching the sections below. Which topics sit in which phase follows the week each is taught in.

Using the map in the exam

  • Locate the question on the line first. "You have just run five interviews and have 60 sticky notes" is a Define question — topic 03 — no matter what else the stem mentions.
  • The answer to "why" usually sits with the neighbours. Why write participant criteria? Because the research method (left) demands a specific kind of person, and the synthesis (right) is worthless if the wrong people were in the room.
  • A "what would you do next" sub-part is asking you to move one step right. After wireframes comes a hypothesis and a test, not more wireframes.
Topic 01 · Assignment tasks

Participant criteria

DefinitionThe written rules that decide who is eligible to take part in a piece of research — and who is not — set down before recruiting begins. The course frames them as "Rules for recruiting": Who · What · How · Where · When.
PurposeTo make the sample defensible. Criteria are what let you say the people you spoke to could actually answer the research question, and what let a reader judge how far your findings generalise.
WhenAfter the research question and method are set, before anyone is approached. This order is the whole point — criteria written afterwards only describe whoever happened to turn up.

Steps

  1. Who — the population, plus the behavioural qualifier that makes them relevant ("has renewed a policy online in the last 12 months"), not just a demographic.
  2. What — how many, and any quota (gender profile, age profile, experience level).
  3. How — the recruitment channel, and what it does to the sample.
  4. Where — in person, remote, or on a specific platform.
  5. When — timing, and how long you need with each person.
  6. Exclusions — who is deliberately kept out, and why.
  7. Limitations — what this sample cannot tell you.

One example you can use

Group 5's own workshop. Participants were named first and the criteria written afterwards. The tutor flagged it twice, and the group's own audit concedes the criteria were "not clearly addressed". student example

Use it as a failure with a lesson: because the criteria came second, the group could not say what the eight participants represented, so every later insight carried an unstated limitation. Naming that in an answer is more honest, and more useful, than inventing a clean success.

The one mistake to avoid

Writing a demographic and stopping. "Aged 18–25, university students" is not a criterion — it does not say what those people must have done. Add the behavioural qualifier and the exclusion, and the criterion becomes usable.

Answer skeleton

Participant criteria are [definition] → for this problem the research question is [X], which can only be answered by people who [behavioural qualifier] → Who / What / How / Where / When, one line each → exclusions: [who is out, and why] → limitation: [what this sample cannot show] → example: [your project, and what went right or wrong].

Source: Week 2 Lecture, slide 67 ("Rules for recruiting") and the screener on the same slide; Week 7 Lecture, slides 26–27; Group Assignment brief, p5. Sample size: W7 s35, "Magic of 5 users" — 5 users ≈ 85% of problems, attributed on the slide to Jeff Sauro of MeasuringU, not to Nielsen.
Topic 02 · Assignment tasks

Workshop & interview planning

DefinitionA workshop is a structured, facilitated session that gets a group to produce something together. An interview is a one-to-one conversation run from a written protocol. Both are planned artefacts in this course: what you are examined on is the plan, not the charisma.
PurposeWorkshop: generate and converge on ideas with the people who hold the knowledge, and get buy-in in the same session. Interview: understand why an individual behaves as they do, in their own words.
WhenDiscover, and again at Define when you need a group to prioritise. An interview usually precedes a workshop — you need material to work with.

Steps — workshop

  1. Beginning — welcome and warm-up, icebreaker, project context, introduction to the process.
  2. Middle — the activities, mixing group and individual work.
  3. End — reflections and discussion, then feedback.
  4. Choose activities from the 4Cs: Collect · Choose · Create · Commit — the course's own list of 40 numbered activities.
  5. All four Cs sit inside the first diamond only — Collect and Choose under Discover, Create and Commit under Define. The lecturer said so explicitly while marking a past student submission wrong: "they are sitting literally only within this double diamond, the first diamond… that's not accurate". A workshop is research, not design. transcript-derived Lecture transcript clarification — lecture transcript\wk4.txt.
  6. Assign the roles: meeting organiser, facilitator, note taker, time keeper, tech set-up.

Steps — interview

The protocol must contain seven things (W2 s47, labelled a. to g.):

  1. A heading
  2. Instructions to the interviewer (opening statements)
  3. The key research questions to be asked
  4. Probes to follow key questions
  5. Transition messages for the interviewer
  6. Space for recording the interviewer's comments
  7. Space in which the researcher records reflective notes

Question types to use

What questions · Why questions · summing-up questions · and no question at all — the slide's note is that silence is golden.

Question types to avoid

Leading questions · hypothetical questions · design questions (asking the participant to do your job for you).

The one mistake to avoid

Merging the two Beginning / Middle / End structures. The course prints one for workshops (W2 s55) and a different one for interviews (W2 s69), with different steps. Use whichever the question asks for, and do not blend them.

Answer skeleton

State the objective the session must achieve → who is in the room and why (topic 01) → the agenda in Beginning / Middle / End with a time against each block → name the specific 4Cs activities and say what each one produces → the roles → how you will capture the output → one line on the risk you designed against (dominant voices, silence, running over).

Source: Week 2 Lecture, slides 41–47, 52–57, 64–69; the 4Cs activity list is W2 s10, repeated verbatim at W3 s8; Week 10 Lecture, slides 8–9 ("Preparing for research"); Group Assignment brief, p4. The 4Cs slide numbers two items "4" and none "5" — reproduce it or renumber silently, but do not treat the numbering as a fact about the framework.
Topic 03 · Assignment tasks

Synthesis & analysis

DefinitionThe work of turning raw research into something decidable. The course names three sensemaking steps and one test for a finished insight: it must be IRA — Interesting, Relevant, Actionable.
PurposeTo get from "here is everything we heard" to "here is the problem worth solving", with the reasoning visible so someone else can disagree with it.
WhenDefine — between fieldwork and any design work. Nothing downstream is safe until this is done.

Steps

  1. Observations — what was actually said or done, one per note.
  2. Affinity mapping — group by what the notes have in common, then name each cluster after the experience, not the solution.
  3. Themes — the named clusters.
  4. Insights — a theme that passes IRA: Interesting (it changed your view), Relevant, Actionable.
  5. Problem framing — turn the insight into a problem statement.
  6. How Might We — reopen the problem as an opportunity.
  7. Prioritise — Impact × Importance (W3 s64) or Impact × Effort (W3 s65).

One example you can use

Group 5's clustering. Sixteen-odd observations were grouped and the clusters were named after the experience — "can't tell if anyone has started" — rather than after a proposed fix. student example

The contrast is the group's second HMW, "How might we give group members one trusted view…", which embeds the solution in the question. Quote both and you have demonstrated the distinction rather than asserted it.

The one mistake to avoid

Writing an HMW that already contains the answer. W3 s61 is the only slide in the course that contrasts poor / good / better HMW wording directly — a poor one names the solution, a better one names the outcome and leaves the method open.

Answer skeleton

Name the three sensemaking steps → describe the affinity method and the naming rule → give the IRA test in full → show one worked chain: observation → theme → insight → problem statement → HMW using the case's own evidence → prioritise with a named matrix and say what each axis means → state which item you would take forward and why.

Source: Week 3 Lecture, slides 14–33 and 55–67; Week 10 Lecture, slide 27. Prioritisation: W3 s64 Impact × Importance (Impact = customer benefit, Importance = business benefit, scored 1–5) and W3 s65 Impact × Effort (High/Low = Start Here · Do Next · Proceed Carefully · Avoid). These are two different matrices — say which one you are using.
Topic 04 · Assignment tasks

Wireframes

DefinitionW5 s21, verbatim: "A wireframe is a stripped-down visual map without any graphic treatment." W5 s19 adds that it communicates the content and layout of each page and acts as a blueprint for designers and developers.
PurposeTo settle structure — hierarchy, functionality, layout, interaction options — before anyone argues about colour. W5 s22: "Your wireframe should match your level of thinking and what you're trying to communicate."
WhenDevelop, once you have a concept worth making concrete. In the exam it is low fidelity only — mid and high fidelity are explicitly excluded from what you produce.

Steps — drawing one under exam conditions

  1. Name the screen and say where in the flow it sits.
  2. Block out the regions — top to bottom, biggest first.
  3. One primary action, visually dominant.
  4. Placeholders only: images marked with an X, text as lines or scribbles (W5 s29). No real copy.
  5. Show the navigation and mark the current state.
  6. Annotate two or three decisions with the evidence behind them.
  7. If more than one screen: draw the arrow from the element that was tapped — that is what makes it a wireflow.

The six things a wireframe communicates (W5 s20)

  1. Design concept or intent
  2. Hierarchy of elements on a page
  3. Functionality
  4. Relative proportions of elements
  5. Page layout
  6. Interaction options

This doubles as an annotation checklist: if your drawing does not carry all six, add them.

The one mistake to avoid

Drawing something pretty. Detail costs you time and buys you nothing — and the deck's own comparison (W5 s26) says only a prototype is Interactive and User-testing ready. A labelled, annotated block sketch answers the question; a shaded UI does not.

Answer skeleton

Define wireframe → say which fidelity you are producing and why (quote s22) → draw it, labelled → annotate three decisions, each as "[element] because [evidence from the case]" → name what the wireframe does not tell you, and what you would do next to find out (a hypothesis and a test — topic 05).

Source: Week 5 Lecture, slides 7–33; the sketch / wireframe / prototype comparison is slide 26; the wireflow example is slide 15. Note the deck's internal conflict on fidelity: s19 says "medium to high", s8 and s26 say low / mid / high. Treat s8 and s26 as the general rule.
Topic 05 · Assignment tasks

UX Testing

DefinitionPutting a design in front of real users to find out whether it works. The course separates concept testing (early — is this idea worth building?) from usability testing (later — can people actually use it?), and moderated from unmoderated.
PurposeTo replace an opinion with evidence. Every test in this course exists to answer a hypothesis you wrote down first.
WhenDeliver — and again after each iteration. Concept testing sits earlier, at the point where ideas are still cheap to kill.

Steps — the course's four (W7)

  1. Plan — determine research objectives and hypotheses, plan your approach.
  2. Prepare — recruit and schedule participants, prepare the discussion guide.
  3. Moderate — facilitate the session, build rapport, set the scene, listen.
  4. Outcomes — capture and synthesise your findings, share findings.

Moderating has its own 8 Rules (W7 s37), beginning Be Curious and Listen More Than You Talk.

The hypothesis recipe — learn it verbatim

We believe that [issue, problem or obstacle]
So if we [change this variable]
We will see [predict the outcome]

A good hypothesis is testable, specific, falsifiable and tied to a measure. If you cannot say what result would prove you wrong, it is not a hypothesis.

One example you can use

The individual-assignment test plan: a hypothesis, a task-based scenario, and a threshold ("at least 4 of 5"). student example Say plainly that the course publishes no threshold conventions — the number was the student's own judgement. Stating that is stronger than pretending it came from the slides.

Sample size, with the right attribution

W7 s35, "Magic of 5 users": 3 → 65%, 4 → 75%, 5 → 85%, 6 → 90%, 8 → 95%, 12 → 99%, from a 31% per-user error probability. The slide attributes this to Jeff Sauro of MeasuringU. Do not write "Nielsen says test five users".

The one mistake to avoid

Writing tasks as instructions. "Click the renew button" tells the participant the answer. "Your policy expires next week — do what you would normally do" tests whether they can find it. Task wording is half the validity of the test.

Answer skeleton

Which kind of test, and why that one here → the hypothesis in the three-clause form → participants and sample size, with the criteria from topic 01 → two or three task scenarios in the user's language → what you will measure (topic 12) → how you will know the hypothesis was wrong → one line on a bias you have designed against.

Source: Week 7 Lecture, slides 6–51; concept-testing artefacts are s10; the 8 Rules are s37; sample size is s35; metrics are s42–43. Individual Assignment brief, p4. Week 7 names four biases without defining them — name them, do not invent definitions.
Topic 06 · P&P tasks

Heuristics evaluation

DefinitionAn expert walk-through of an interface against a fixed set of usability rules. This course uses its own set of five, printed under the heading "Combining 5 heuristics for INFS3700".
PurposeTo find usability problems without users — fast, cheap, and early enough to fix things before testing.
WhenDiscover (current-state analysis of an existing product) and again before a usability test, so the test is not spent on problems you could have found yourself.
#HeuristicAuthor band on the slide
01Software should be forthcomingAlan Cooper — "Software should be polite"
02Software should be self-confident
03Visibility of system statusJakob Nielsen — Usability Heuristics
04Match between system & real world
05Don't waste my time!Steve Krug
Source: Week 1 Lecture, slide 35 — three authors, not one. Writing "Nielsen's five heuristics" contradicts the slide.

Steps — the five-part finding

  1. Name the heuristic it breaches.
  2. The evidence — what you actually observed on the screen.
  3. The user consequence — what this does to the person.
  4. The business consequence — what it costs the organisation.
  5. A specific recommendation — not "improve the UX".

One example you can use

A file upload with no progress indicator breaches 03 Visibility of system status: the user cannot tell whether it is working, so they click again, which duplicates the upload and generates support contacts. Recommendation: a determinate progress bar with a byte count and a cancel action. One sentence per step and the finding is complete.

The one mistake to avoid

Listing the five heuristics and stopping. What the question asks for is applying one to specific evidence. One fully worked finding beats five named heuristics with nothing attached.

Answer skeleton

Define heuristic evaluation and say when it is used → list the five with their author bands → pick two or three that the case actually breaches → run each through the five-part finding → close with which you would fix first and why (impact, not effort).

Source: Week 1 Lecture, slides 30–40; Week 10 Lecture, slides 25–26, which restate all five positively and then negatively, with a "we found that / so what" column. Week 10's negative version leaves the "so what" column empty — that is the exercise.
Topic 07 · P&P tasks

Research methods

DefinitionThe techniques used to gather evidence about users. The course splits them into qualitative (why people behave as they do) and quantitative (how many, how often, how much), and maps both onto the Double Diamond.
PurposeTo choose a method that can actually answer the question you have — and to say why the alternatives cannot.
WhenQualitative into Discover and Develop; quantitative into Define and Deliver. That mapping is the course's own (W2).

Steps — choosing a method

  1. State the research question. If it starts with "why", you need qualitative; "how many" needs quantitative.
  2. Place the problem on Risk × Problem Clarity: low clarity + high risk = Research Heavy; high clarity + low risk = Ship it and Measure.
  3. Pick the method that produces the evidence you named.
  4. Say what it cannot tell you.
  5. Triangulate — pair it with a second method that covers that gap.

One example you can use

Problem Space 2, done properly: an online survey to size how widespread the coordination problem is across the cohort, then semi-structured interviews with a subset to explain the pattern the survey found. Survey gives scale and cannot give reasons; interviews give reasons and cannot give scale. Naming that trade-off is the answer.

The one mistake to avoid

Naming a method without naming its output. "I would do interviews" is not an answer; "I would run six semi-structured interviews producing a discussion guide, transcripts and participant snapshots" is. Every method in the course has named artefacts — use them.

Answer skeleton

Define qualitative and quantitative and give each one's purpose → state the research question this case actually has → choose one of each and say what evidence it produces → say what each cannot answer → triangulate: how the two together close the gap → one line on the participants those methods require.

Source: Week 2 Lecture, slides 17–39; Week 10 Lecture, slides 6–7 ("How do we even start" and "What sources can we rely on"). Week 10's source list — business stakeholders, customers and end users, existing data analytics — is a ready-made answer to "where would you look first".
Topic 08 · P&P tasks

Design principles

DefinitionThe five rules this course uses to judge whether an interface behaves the way people expect. Printed as 5 Design Principles on the Week 4 deck.
PurposeTo give a shared, testable language for why a design works — usable both to critique an existing product and to justify one you have drawn.
WhenDevelop, while designing; and in evaluation, alongside the heuristics. Week 10 restates them in the same "we found that / so what" form as the heuristics.
#PrincipleEveryday object you can cite
1Perceivable and predictableA measuring cup whose markings you read from above while pouring
2Consistent and conventionalScissors — the same shape everywhere, so nobody needs instructions
3Use natural affordancesA kettle handle that shows where the hand goes
4Provide feedbackA volume knob with detents you can feel and hear
5Provide constraintsAn AA battery compartment shaped so the cell only fits one way
Source: Week 4 Lecture, slides 8–32; the five names are verbatim. The everyday objects are the ones photographed for the Week 4 P&P task student example — they are yours to reuse, which means you are not competing with the lecturer's own examples.

Steps — applying one

  1. Name the principle.
  2. Point at the specific element in the case.
  3. Say what the user expects, and what the design does instead.
  4. Give the consequence.
  5. Give the change, and say which principle the change now satisfies.

One example you can use

The Week 4 car-insurance form: the rejected version lists Year, Make, First Name, Last Name, Model, Phone Number, Address in one undifferentiated column; the approved version chunks the same fields under Personal Information and Vehicle Information. Same fields, same count — only the grouping changed. That is perceivable and predictable in one image.

The one mistake to avoid

Writing about affordances vs signifiers. The word "signifier" appears nowhere in the Week 4 deck. On viewing patterns, be precise rather than avoidant: the deck prints only "Two Viewing Patterns", but the lecturer names the F pattern aloud in the Week 4 recording, so that term is safe. The second pattern's name is not recoverable from the recording — describe it instead of calling it a Z-pattern. Using outside vocabulary here makes a correct answer inconsistent with the source.

Answer skeleton

List all five by name → choose the two or three the case breaches → for each: element → expectation → what happens instead → consequence → fix → close by naming the principle a competing design choice would have traded away.

Source: Week 4 Lecture, slides 8–32; Week 10 Lecture, slides 28–29. The course's five-part good-error-message structure — say what happened, say why, provide reassurance, give a way out, help them fix it — is the model for how specific a recommendation should be.
Topic 09 · P&P tasks

Storyboards

DefinitionW4 s43, verbatim: "Storyboards are used to convey social or functional messages through entertainment and engagement in a visual format" — physical or digital. They show, in a linear and sequential fashion, how a customer may interact with your experience.
PurposeTo make an idea human — to show a person, in a situation, with a problem, and what changes for them. It answers "why would anyone want this?", which a wireframe cannot.
WhenIdeate, at the start of Develop — before any screen exists. Also a concept-testing artefact: W7 s10 lists storyboards alongside wireframes, early prototypes and service blueprints.

Steps — the three acts

  1. Beginning = Problem. Establish the actor, the context and the trigger, then show the pain point.
  2. Middle = Objective, Goal, Action. The user acts; the intervention or touchpoint appears.
  3. End = Outcome. What changed for them, and what it means beyond this moment.
  4. Caption every frame — the drawing carries the scene, the caption carries the meaning.
  5. Mark the emotion in each frame.

The eight elements (W4 s45)

Characters · Speech bubbles · Devices · Signs · Arrows · Office furniture · Transportation elements · Backgrounds. And the three principles for great storyboards (W4 s46): Stay Authentic · Keep it Simple · Highlight Emotion.

One example you can use

The course's own Heartline narrative (W4 s47): Tom, Susan and a check-in reminder. It is a complete three-act story with a named actor, a trigger, a touchpoint and an emotional outcome — quote its shape rather than its details, and it will carry any scenario.

Where it differs from its neighbours

A storyboard shows one person's experience over time. A wireframe shows one screen's structure. A service blueprint shows what the organisation does to make that experience possible. If a question mentions emotion or context outside the screen, it wants a storyboard.

The one mistake to avoid

Drawing six pictures of an interface. That is a wireflow with worse drawing. A storyboard must contain a person, a place and a feeling — if you can remove the human and it still makes sense, it is not a storyboard.

Answer skeleton

Define storyboard (quote s43) → give the three acts → name the actor and their trigger from the case → six frames, captioned, with emotion marked → say which frame carries the intervention → close with what you would learn by concept-testing it, and with whom.

Source: Week 4 Lecture, slides 43–50 — the whole of the course's storyboard teaching, and the primary source for this topic. Week 7 Lecture, slide 10 is the supporting application. The Week 5 deck contains no storyboard material; its section 05.5 is "Storytelling in/for design", which is about presenting research to an audience.
Topic 10 · P&P tasks

Service Design 5Ps

DefinitionThe five dimensions the course uses to describe a whole service: People · Processes · Places · Products · Performance.
PurposeTo stop an analysis collapsing into "the app". A service fails through staff, steps, venues and measures as often as through interfaces, and the 5Ps force you to look at all of them.
WhenAt the start of any service-level analysis — and immediately before a blueprint, which is the 5Ps arranged in time.
PWhat it coversThe diagnostic question revision device
PeopleCustomers, frontline staff, back-office staff, partnersWho has to do something for this to work?
ProcessesThe steps, rules and handovers that deliver the serviceWhat has to happen, in what order, and who hands over to whom?
PlacesPhysical and digital environments where the service happensWhere does the customer actually stand or click?
ProductsThe tangible things and systems used or receivedWhat do they touch, carry away, or log into?
PerformanceHow the service is measured and how well it doesHow would anyone know this got better?
Source: Week 8 Lecture, slides 38–44 — the five names and their definitions are the course's. The diagnostic questions column is this guide's own revision device, not a course framework.

One example you can use

A GP clinic. People: patient, receptionist, GP, pathology courier. Processes: booking → check-in → consult → referral → results. Places: the waiting room and the booking app. Products: the Medicare card, the script, the SMS reminder. Performance: wait time, did-not-attend rate, whether the patient understood the next step. Five sentences and the whole service is on the page.

The trap in the same deck

W8 s35 also prints a list of five items — but it is a set of project brief headings, and the slide never calls it "the 5Ps". The 5Ps are on s39. Reproducing s35 as the 5Ps is the single easiest way to get this topic wrong.

The one mistake to avoid

Applying the 5Ps to a whole industry instead of one service. The tutor: "we don't use this analysis for the whole industry or sector because there's no point… Usually we use that for specific [services] that we want to improve." At sector level the five answers stop discriminating. If the case names a sector, narrow it in your first sentence. transcript-derived

The other mistake: treating Performance as an afterthought. It is the P that makes the other four accountable — and it is where a "how would you evaluate this" sub-part is answered.

Answer skeleton

Name all five → one sentence of definition each → apply each to the case in one sentence → identify which P the case's failure actually sits in → say what you would change there → note what a blueprint would add that the 5Ps alone cannot show (topic 11).

Source: Week 8 Lecture, slides 38–44. The Week 8/9 tutorial case study is the course's own worked application — one case study serves both weeks, framed with the 5Ps in Week 8 and blueprinted in Week 9.
Topic 11 · P&P tasks

Service blueprint

DefinitionAn operational diagram that maps what the customer does against everything the organisation does to make it possible, laid out in time. Originally proposed by Lynn Shostack (1984) and evolving since — the contribution was treating service delivery, traditionally seen as intangible, as something that could be documented and designed.
PurposeThree, in the deck's own words: to visualise · to align · to prototype. It exposes where the customer's experience breaks because of something invisible to them.
WhenDiscover/Define for a current state blueprint (align on what exists, find breakdowns); Develop/Deliver for a future state one (communicate change, plan touchpoints, build roadmaps).

The five components — top to bottom

  1. Physical evidence / touchpoints
  2. Customer actions
  3. — line of interaction —
  4. Frontstage actions (what the customer can see)
  5. — line of visibility —
  6. Backstage actions
  7. — line of internal interaction —
  8. Support processes

Steps — the course's six (W9 s18)

  1. Prepare supplies
  2. Gather partners
  3. Take a first pass
  4. Fill in
  5. Direct attention
  6. Share it

How many lines?

All three lines are course terminology. The Week 9 lecture deck names line of interaction, line of visibility and line of internal interaction on slides 7, 8 and 23. Some templates in the same deck (s34–35) draw only two — that is a presentation variation inside the course's own material, not a sign that the third line comes from outside. Draw three and label them, or draw two to match the template; either is defensible. What is not defensible is drawing an unlabelled line.

One example you can use

The deck's own restaurant blueprint. Its most useful detail: the server prepares the table before the customer arrives. Backstage work is plotted at the moment it starts, not when the customer notices it — that is what makes the vertical column a service moment.

Two rules the tutor corrected in class

  • One touchpoint per service moment — do not stack three into one column.
  • Name who performs every staff action — "confirms booking" is not an action until someone owns it.

The one mistake to avoid

Drawing a journey map with extra rows. A blueprint's lanes are defined by who acts and whether the customer can see it — not by stages of feeling. If nothing in your diagram crosses the line of visibility, you have not drawn a blueprint.

Answer skeleton

Define blueprint and name Shostack → current or future state, and why that one → draw it: stages across the top, five lanes down, lines labelled → fill one full service moment top to bottom → point at one breakdown the diagram exposes → say what you would change and which lane the change lands in.

Source: Week 9 Lecture (40 slides) — the primary source: definition and Shostack origin (s9), the three lines (s7, s8, s23), lane definitions (s16–18), structure and service moments (s17), the six-step build (s18), the worked restaurant example and blank template (s34–35). Supporting: Week 9 tutorial preparation for the P&P task's five-component wording, and the Week 9 tutorial recordings for the tutor's live corrections.
Topic 12 · Research data & metrics

Quantitative & qualitative data

DefinitionQuantitative feedback counts and rates things: direct/indirect success, ratings and scales, time to complete. Qualitative feedback is what people say: what they liked, what they did not, what they would suggest.
PurposeQuantitative tells you that something is wrong and how widespread it is; qualitative tells you why. Neither is a finding on its own.
WhenEvery time a result comes back. Week 10 slide 30 is a whole revision slide on how to read one.

The two conclusions the course allows

  • "Our experience has been validated" — high success rate due to…, high confidence rating due to…, customers liked X, Y, Z and therefore…
  • "Iterate to improve the experience" — low success rate due to…, low confidence rating due to…, customers found X, Y, Z confusing and therefore…

Note the due to and the therefore. The slide's own sentence structure forces the "so what".

Which vocabulary comes from where

  • Direct success · Indirect success · Failure · Confidence rating — W5 s48 and W10 s30. Not in the Week 7 deck at all.
  • Success rate · Time spent before completing · Number of clicks · Ease of use · User satisfaction — W7 s42.
  • "Task completion rate" and "time to complete" are paraphrases — Week 7 never uses those phrases.

Safe approach: use the Week 10 slide-30 vocabulary and give the Week 7 equivalent alongside it.

One example you can use

The course's NRMA industry example: 86.7% direct success, a 4.8/5 confidence rating, and 45% of users misreading one element. The weak reading is "86.7%, so it's good". The strong reading pairs the success rate with the heat map showing an alternative click target and with open feedback — diagnosis first, then a decision to validate or iterate.

Steps — reading a result

  1. State the number, with its measure.
  2. Pair it with a qualitative source.
  3. Diagnose: what would explain both?
  4. Decide: validate, or iterate.
  5. Say what you would measure next to check.

The one mistake to avoid

Naming a collection method as if it were a data type. The tutor corrected exactly this on this exact practice question: "i know interview is a method for qualitative research but it doesn't mean that… some of them can be measurable and counted… it's not a type data." And separately: "Open ended means only that they can add [their own answer]… even close ended also can be [quantitative]… they can be both." Name the data, not the instrument, and do not equate question format with data type. transcript-derived

The other mistake: reporting a number as a conclusion. Calculations are explicitly excluded from this exam — you are never asked to compute anything, so focus on interpreting the data and explaining its implications. A number with no "so what" is an unfinished sentence.

Answer skeleton

Define both types with their purposes → give two or three examples of each, using the right deck's vocabulary → say how you would collect each (method, participants, instrument) → take one supplied figure and read it properly: number → qualitative pair → diagnosis → decision → next measure.

Source: Week 10 Lecture, slide 30 (the summary and the two interpretation structures); Week 2 Lecture, slides 20, 25, 36, 39 (definitions); Week 7 Lecture, slides 42–43 (the metrics list); Week 5 Lecture, slides 47–49 (the worked industry example that supplies direct/indirect success and confidence rating).
Sprint guide · Section C

Artefact drawing sheets

"Drawing out artefacts" is one of the four formats named on Week 10 slide 13. Three artefacts in this course are drawable and examinable: a low-fidelity wireframe, a storyboard and a service blueprint. Each sheet below is the empty frame plus the labels that must appear on it. Print this section and draw on it until the structure is automatic.

Three rules that apply to all three drawings

  1. Label everything. A tutor corrected all four Week 9 groups on labelling. An unlabelled diagram cannot be read back, which means it cannot be marked.
  2. Annotate two or three decisions with the reason. The drawing shows what; the annotation shows why. The reasoning is the part a written answer would have carried.
  3. Draw the structure first, contents second. If you run out of time, a complete, correctly-labelled skeleton reads far better than one beautifully finished corner.

Sheet 1 · Low-fidelity wireframe

screen name + where you are system status region ONE primary action list — mark the flagged item images = X · text = lines (W5 s29) nav — mark the current state Annotate — element, then the evidence behind it 1 ……… because ……… 2 ……… because ……… 3 ……… because ……… 4 what this wireframe does NOT tell me: 5 the hypothesis I would test next: → Second screen? Draw the arrow FROM the element that was tapped. That is what turns two wireframes into a wireflow (W5 s15). Cover all six of W5 s20: concept, hierarchy, functionality, proportion, layout, interaction options.
Blank drawing sheet, built for this guide. The region names follow the annotated wireframe in the full guide's Chapter 11; the placeholder convention (images marked X, text as lines) and the six communicated things are Week 5 Lecture, slides 29 and 20.

Sheet 2 · Storyboard

BEGINNING = Problem MIDDLE = Objective · Goal · Action END = Outcome 1 · actor, contextand trigger 2 · the painpoint 3 · what the userdoes 4 · the interventionor touchpoint 5 · the outcomefor them 6 · what it meansbeyond this captioncaptioncaption captioncaptioncaption emotion: ☺ / ☹emotion: ☺ / ☹emotion: ☺ / ☹ emotion: ☺ / ☹emotion: ☺ / ☹emotion: ☺ / ☹ Eight elements to draw from (W4 s45): characters · speech bubbles · devices · signs · arrows · office furniture · transportation elements · backgrounds. Three principles (W4 s46): Stay Authentic · Keep it Simple · Highlight Emotion.
Blank six-frame sheet, built for this guide. The three-act structure, the eight elements and the three principles are Week 4 Lecture, slides 43–46. The six-frame division is this guide's structure — the course's own template is unlabelled, so the frame count is a revision device, not a course rule.

Sheet 3 · Service blueprint

CUSTOMER: ……………………………… SCENARIO: ……………………………… ☐ current state ☐ future state stage 1stage 2stage 3stage 4 one service moment — read top to bottom 1 · Physical evidence / touchpoints 2 · Customer actions 3 · Frontstage actions 4 · Backstage actions 5 · Support processes line of interaction line of visibility line of internal interaction
Blank blueprint sheet, built for this guide. The five components, the three lines and the service-moment column follow the Week 9 Lecture — components and structure at slides 16–18, the three lines at slides 7, 8 and 23, the blank template at slides 34–35. The third line is drawn dashed here only to mark that some templates in the deck omit it; it is course terminology either way.

Which artefact does the question want?

If the stem is about…Draw…Because it is the only one that shows…
A person's situation, feelings, context outside the screenStoryboarda human being over time
A screen, its layout, or moving between screensWireframe / wireflowstructure, hierarchy and interaction
A whole service, staff, handovers, something invisible failingService blueprintwhat the organisation does below the line of visibility
What you would do next, and with whomwrite, don't drawa research plan, interview guide or workshop plan
Sprint guide · Section D

Answer skeletons by mark value

Read this before using anything on this page. Guide inference — not stated by the lecturer. The course publishes the mark values and nothing else: "We will not provide marking criteria" (Week 10, slide 15). Every structure, time and component count below is this guide's proposal, derived from what the Week 10 practice questions actually ask for. They are scaffolding for practice, not a rubric. If a question's own wording asks for something different, follow the question.

The paper has exactly five mark values: 5, 8, 10, 12 and 15. Each one buys a different amount of structure. The times assume 2 hours for 100 marks — about 1.2 minutes per mark — with a few minutes held back at the end.

MarksTimeShapeWhat has to be in it
5≈ 6 minOne paragraphDefinition → one application to the case → one example. No headings, no preamble. If it is a "name the X" question, name exactly the number asked and stop.
8≈ 10 minParagraph + listDefinition → purpose → 3–4 named components or steps → one worked example. This is the shortest answer where a short list earns its space.
10≈ 12 min3 blocksDefinition and purpose → application, with the case's own evidence quoted → example + "so what". Roughly a third of the words in each block.
12≈ 14 min4 blocksThe 10-mark shape plus a comparison or a limitation — what you did not choose and why, or what this approach cannot tell you.
15≈ 18 min5 blocksDefinition → framework named in full → applied to the case point by point → example with a consequence → recommendation with a way of checking it worked. A 15-mark answer that ends without a recommendation has stopped early.

The five skeletons, written out

5 marks — the one-paragraph answer
  1. Sentence 1 — the direct answer. Answer the question in its own words before you explain anything.
  2. Sentence 2 — the definition, in the course's terms.
  3. Sentence 3 — the application: "In this case that means…"
  4. Sentence 4 — an example, one clause of context and then the point.

Worked shape. "A confidence rating is a self-reported measure of how sure a participant was that they completed the task correctly. It is quantitative but subjective, which is why the course pairs it with success rate rather than using it alone. In this case the 4.8/5 rating alongside an 86.7% success rate says most people succeeded and believed they had. In my own testing a high rating with a low success rate was the signal that the task wording was misleading them."

8 marks — definition, components, example
  1. Definition — one or two sentences, course wording.
  2. Purpose — what it is for, and when in the process it happens.
  3. The named components — 3–5 of them, each with a half-sentence gloss. Use the course's own list; if the course numbers them, keep the numbers.
  4. One example, with what it showed.

The trap at 8 marks is spending six of them on the definition. Definition and purpose together should be about a quarter of the answer.

10 marks — the standard applied answer
  1. Block 1 — Define and situate. What it is, what it is for, where it sits in the process.
  2. Block 2 — Apply. Take the case's own evidence — a quote, a metric, a described failure — and run the concept over it. Name the evidence you are using.
  3. Block 3 — Example and consequence. Your own example, then the "so what": what changed, or what would have changed.

If the command verb is compare, split block 2 into two halves with a stated basis of comparison, and give block 3 to the difference that matters.

12 marks — applied, plus what you rejected
  1. Define and situate.
  2. Apply to the case with named evidence.
  3. The alternative you did not take, and the specific reason — cost, time, what it cannot show, who it excludes. This is the block that separates 12 from 10.
  4. Example and consequence.

Any of the course's paired frameworks gives you block 3 for free: qualitative vs quantitative, moderated vs unmoderated, concept vs usability testing, Impact × Importance vs Impact × Effort, low vs mid fidelity, current vs future state.

15 marks — the full answer, ending in a recommendation
  1. Define and situate — brief. Two or three sentences.
  2. Name the framework in full. All five heuristics, all five principles, all five Ps, all five blueprint components, the three sensemaking steps — whichever applies. Naming the whole framework costs little space and gives the rest of the answer something to work through.
  3. Apply it point by point to the case. Not every point needs a paragraph; the ones the case actually breaches do.
  4. Example with a consequence. Yours, with what it showed.
  5. Recommendation + verification. The specific change, and how you would know it worked — a measure, a test, a hypothesis. Close the loop.

A drawn artefact may appear in one of Question 3's sub-parts, but the transcript does not identify which mark values those sub-parts carry — so do not assume it will be a 15. Where drawing is required, use the artefact as the main application block and put the reasoning into its labels and annotations.

Bullets or prose? The tutor answered this directly transcript-derived

A student asked whether paragraphs or bullet points were expected. The tutor: "usually like essay ties [essay types] were probably not expected that much, right? Um sometimes the bull reports [bullet points] might make things clearer, so you're welcome to do so… I wouldn't say like the way you write it, it's more like remark [we mark] based on the points like uh the criteria right if you actually touch these points that you should touch then it should be good so you could put that in long sentence could be a shorter sentence, it it's fine. Both ways. But just like make sure I touch the key points."

Use whichever is clearer for the question. Structure and coverage matter more than prose polish. Note the boundary: this is a tutor describing how he approaches marking; the Week 10 slide still states that no marking criteria will be provided to students, so treat it as guidance on how to present an answer, not as a published rubric. Tutor explanation — WEEK10\tut transcript raw.txt, [31:42]–[32:19]; speaker unlabelled, identified as the tutor from context.

Command verbs — what each one changes

VerbWhat the answer must doWhat leaves the answer incomplete
DefineState it in the course's terms, then bound it — what it is not.A definition with no boundary.
ExplainGive the mechanism: how it works, why it produces that effect.Describing what it is instead of how it works.
CompareState the basis of comparison first, then both sides on that basis, then which matters here.Two descriptions side by side with no basis and no verdict.
EvaluateApply a named standard, judge against it, and commit to a position.Listing pros and cons without deciding.
RecommendOne specific change, the reason from the evidence, and how you would check it worked."Improve the UX" — a sentence that could be written without reading the case.
DrawProduce the artefact, labelled, with two or three annotated decisions.Writing a description of a diagram instead of drawing one.
Apply / UseThe framework is assumed known — spend the words on the case, not the theory.Re-teaching the framework and running out of time.
Guide inference — not stated by the lecturer. No official rubric exists. This table is derived from what the three Week 10 practice questions actually ask for and from the phrasing of the assignment briefs.

Two sentence patterns worth memorising

  • "We found that… so what?" — the course's own two-column structure, used on six separate Week 10 and Week 5 slides. Never write a finding without its consequence.
  • "We believe that… so if we… we will see…" — the hypothesis recipe. It works as an answer structure anywhere you are asked to justify a change.
Sprint guide · Section E

Mock exam 1

These are not past papers. They were written for this guide, they were not written or seen by the course staff, and no marking criteria exist for this exam. The only thing they copy from the course is the published mark structure on Week 10, slide 23: 25 (10 + 15), 20 (8 + 12), 55 (10 + 5 + 10 + 15 + 15). The topics are drawn from this guide's twelve revision areas — eleven of which are printed on slide 12 — but which topics actually appear in your exam is not knowable from any source in this folder.

How to sit it

  • 15 minutes reading, 2 hours writing. Closed book. Do it in one sitting.
  • During reading time, identify the mark value, command verb and relevant case evidence for each sub-part. Record or annotate anything only where the examination interface or invigilator explicitly permits it. Rehearse it that way — in the real exam, whether you may write during reading time depends on the rules in force on the day.
  • Do not open the answer plans until you have finished. They are collapsed for exactly that reason.
  • Q3 has a drawn sub-part. Use paper, and label it as if a stranger had to read it.

Question 1 25

(a) Define exploratory research and explain what it is for. Name two research activities and two artefacts it produces, and give an example from your own experience. 10

(b) You have been asked to plan the exploratory research for a university's enrolment service. Set out your participant criteria and explain how you would recruit against them. Justify your sample size, and state two limitations of the sample you would end up with. 15

Answer plan — Question 1

1(a) — 10 marks, three blocks.

  • Define + situate. Exploratory research is what you do before you know what the problem is — it sits in Discover on the Double Diamond and its output is understanding, not a decision. Contrast it in one clause with evaluative research, which tests something that already exists.
  • Two activities, two artefacts — the question specifies a count, so label them so they are countable at a glance. Activities: semi-structured interviews; a workshop (the 4Cs Collect stage). Artefacts: a discussion guide and transcripts / participant snapshots from the interviews; clustered outputs from the workshop. Say for each what it lets you do next.
  • Example + so what. Your own project: what you set out to learn, which activity produced it, and one thing you learned that you had not expected — the surprise is the evidence that it was genuinely exploratory.

1(b) — 15 marks, five blocks. This is the full-length shape from Section D.

  • Situate. Criteria come after the research question and before recruitment. Say what the research question is for enrolment — e.g. "why do continuing students leave enrolment until the final week?"
  • The framework in full: Who · What · How · Where · When (W2 s67), plus exclusions and limitations.
  • Apply each one. Who: continuing undergraduates who have enrolled at least once, plus a second segment of first-years who have not — the behavioural qualifier, not just "students". What: numbers and quota across the two segments. How: the channel, and what it biases toward. Where: on campus vs remote. When: during the enrolment window, not after it, or they will be reconstructing from memory.
  • Sample size, attributed. For a usability test of the enrolment interface, Magic of 5 — 5 users ≈ 85% of problems — attributed on W7 s35 to Jeff Sauro of MeasuringU. For exploratory interviews, say instead that you recruit until you stop hearing new themes, and that the course gives no fixed number for this.
  • Two limitations, stated plainly. E.g. recruiting through a student portal reaches only students who already log in, so the people most likely to be locked out are the ones you will miss; and a single-campus sample cannot speak for distance students. Say what each limitation would stop you claiming.
  • Example. The workshop where criteria were written after recruitment — and what that cost. A failure with a lesson answers this better than a clean success.

Question 2 20

(a) Name the five heuristics used in INFS3700 and state who each is attributed to. 8

(b) A food-delivery app shows a spinning icon with no text after a user places an order, and the order confirmation arrives by email up to ten minutes later. Evaluate this against the heuristics. Identify two breaches, and for each give the evidence, the user consequence, the business consequence and a specific recommendation. 12

Answer plan — Question 2

2(a) — 8 marks. A list question with an attribution requirement. Give all five, grouped by their author bands exactly as W1 s35 prints them:

  • Alan Cooper — "Software should be polite": 01 Software should be forthcoming, 02 Software should be self-confident
  • Jakob Nielsen — Usability Heuristics: 03 Visibility of system status, 04 Match between system & real world
  • Steve Krug: 05 Don't waste my time!

Add one sentence that the set is titled "Combining 5 heuristics for INFS3700" and is therefore this course's own combination, not any single author's list. That sentence is what turns a recall answer into a correct one.

2(b) — 12 marks. Two breaches × the five-part finding, then the comparison block.

  • Breach 1 — 03 Visibility of system status. Evidence: a spinner with no text, and no state change for up to ten minutes. User consequence: the user cannot tell whether the order was placed, so they re-order or abandon. Business consequence: duplicate orders, refunds, support contacts. Recommendation: replace the spinner with a named state and a time estimate — "Order received · restaurant confirming · usually under 2 minutes" — and push the confirmation in-app, not only by email.
  • Breach 2 — 01 Software should be forthcoming, or 05 Don't waste my time. Forthcoming: the system knows the order status and does not volunteer it. Don't waste my time: the user has to leave the app and check email to learn something the app already knows. Either is defensible — pick one, and say why that one rather than the other.
  • The 12-mark extra block: which of the two you would fix first, and on what basis. Impact on the user, not effort for the team — and say how you would know it worked (a drop in duplicate orders, or a direct-success measure on "confirm my order was placed").

Question 3 — case study 55

Case. A metropolitan public library has launched a "reserve and collect" service. A member reserves a book in the app, the app says "available at your branch", and they travel in to collect it. Complaints have risen sharply.

Research so far has found:

  • 72% of reservations are collected successfully within the 5-day hold window.
  • Members rate their confidence that the book will be there at 2.9 / 5.
  • A member interview: "It said available. I drove twenty minutes. They said it was still on the returns trolley — could be tomorrow, could be Thursday."
  • Branch staff report that returned books sit unshelved for up to two days at peak, and that the app's "available" flag is set when a book is checked in, not when it is shelved and located.
  • A staff member: "We can see it's been returned. We can't see where it physically is."

(a) Using the 5Ps of service design, analyse this service. Identify which P the failure actually sits in, and justify that choice. 10

(b) Write one How Might We statement for the problem, and explain what makes it a good one. 5

(c) Interpret the quantitative and qualitative evidence above. What do the two together tell you that neither tells you alone? 10

(d) Draw a service blueprint for the reserve-and-collect journey. Label all lanes and lines, and annotate the point at which the service breaks. 15

(e) Recommend one change. Write a hypothesis for it, describe how you would test it, and state how you would know it had worked. 15

Answer plan — Question 3

3(a) — 10 marks. Name all five, apply each in one sentence, then commit.

  • People: member, branch staff, the returns/shelving team. Processes: reserve → check-in → shelve → locate → hold → collect. Places: the app and the branch collection point. Products: the app, the hold shelf, the book itself. Performance: the 72% collection rate and the 2.9/5 confidence rating.
  • Commit: the failure is in Processes — specifically the handover between check-in and shelving. It presents as a Products failure (the app lies) but the app is faithfully reporting the only event the process actually records. Saying that, and saying why it is not a Products failure, is the analysis.

3(b) — 5 marks. One paragraph. State the HMW, then say what makes it good.

  • "How might we give members an accurate picture of whether a reserved book can actually be collected today?"
  • Good because it names the outcome (an accurate picture, today) and not the solution. It leaves open whether the fix is a new status, a delayed flag, a staff scan or a changed promise. Contrast with a poor version — "How might we add a shelving-status barcode scan to the app?" — which has already chosen the answer, and cite W3 s61 as the slide that draws this distinction.

3(c) — 10 marks. Three blocks: what each says, what neither says, what both say together.

  • Quantitative alone: 72% collected, confidence 2.9/5. Those two disagree — a 72% success rate with a 2.9 confidence means members succeed more often than they expect to. That gap is the finding.
  • Qualitative alone: the member quote gives the mechanism (a false "available"), the staff quote gives the cause (check-in ≠ located). Neither tells you how widespread it is.
  • Together: the failure is not frequent enough to be an outage but is unpredictable, and unpredictability is what destroys confidence. Diagnose, then decide — this is an iterate, not a validate. Use the Week 10 slide-30 vocabulary (low confidence rating due to…, customers found X confusing and therefore…) and note that the course excludes calculations, so no arithmetic is expected here.

3(d) — 15 marks. Draw it. Stages across the top: reserve · notified · travel · collect. Lanes down: physical evidence, customer actions, frontstage, backstage, support processes. Lines labelled.

  • Physical evidence: app screen, "available" notification, hold shelf, the book.
  • Customer: reserves → receives notification → travels → asks at desk.
  • Frontstage: desk staff search the hold shelf, then the trolley.
  • Backstage: book checked in; book waits on returns trolley; book shelved.
  • Support: the catalogue system that flips the flag on check-in.
  • The annotation that completes the answer: say where the failure starts, not just where it becomes visible. The failure begins in the support process, when check-in is treated as equivalent to confirmed shelf availability. That premature status then propagates outward — across the line of internal interaction into backstage, where the book is still physically on the returns trolley and contradicts the record; through the backstage-to-frontstage handoff, where desk staff search a hold shelf the system says is stocked; and across the line of visibility into the customer-visible app notification, which is where the member finally encounters it.
  • Be precise about what the line of visibility does. It separates activity the customer can see from activity they cannot. It marks where the bad status becomes visible; it is not what caused it. An answer that says "the failure is at the line of visibility" has described the symptom. Mark both points on the diagram — origin and surfacing — and label which is which. Apply the two rules the tutor corrected in class: one touchpoint per service moment, and name who performs every staff action.

3(e) — 15 marks. One change, a hypothesis, a test, a measure.

  • Change: split the status — the flag flips to "Returned — being processed" at check-in and to "Ready to collect" only when the item is scanned onto the hold shelf. Notification fires on the second event, not the first.
  • Hypothesis: We believe that members lose trust because "available" is set before the book is collectable. So if we notify only on shelf-scan and show a distinct in-process state, we will see confidence rise and wasted trips fall.
  • Test: concept-test the two-state notification with members using a low-fidelity wireframe (a storyboard would do the same job if you want to show the wasted journey), then a moderated usability test on the task "find out whether you can pick up your book today". Participants: members who have reserved in the last month — the behavioural qualifier from topic 01. Five users, attributed to Sauro's Magic of 5.
  • How you would know: confidence rating moves off 2.9; direct success on the "can I collect today" task; and the operational measure — collections attempted before the item was shelved. Say which of these you would consider decisive, and say what result would prove you wrong.
Sprint guide · Section F

Mock exam 2

Same structure, different topics. Mock 1 leans on service design and data; this one leans on synthesis, design principles, wireframes, storyboards and testing. Between them the two papers touch all twelve revision areas. The same warning applies: not a past paper, not seen by course staff, no marking criteria exist. Only the mark structure is the course's.

Question 1 25

(a) Compare qualitative and quantitative research. State the basis of your comparison, give examples of each, and explain how you would collect both. 10

(b) Explain the process of turning raw research into a problem worth solving. Name the steps, define an insight, and show one worked chain from a single observation through to a How Might We statement. 15

Answer plan — Question 1

1(a) — 10 marks. The verb is compare, so state the basis first.

  • Basis: what kind of question each can answer. Qualitative answers why and how; quantitative answers how many, how often, how much. Say this in one sentence before anything else — a comparison with no stated basis is the classic way to miss what this verb is asking for.
  • Where each sits: the course maps qualitative into Discover and Develop, quantitative into Define and Deliver (W2).
  • Examples with their outputs. Qualitative: semi-structured interviews → discussion guide, transcripts, participant snapshots; contextual observation → observed vs inferred behaviour. Quantitative: an online survey → distributions and segment sizes; usability metrics → direct/indirect success, ratings and scales, time to complete.
  • How you would collect both — the question asks this explicitly, so answer it explicitly: recruit against criteria, run the survey first to size the problem, then interview a subset to explain the pattern. Name this as triangulation and say what it buys you.
  • Close with the verdict a comparison needs: neither is sufficient; the pairing is what makes a finding defensible.

1(b) — 15 marks. Full-length shape.

  • Situate. This is Define — between fieldwork and any design work.
  • The framework in full. The three sensemaking steps, then: observations → affinity mapping → themes → insights → problem statement → How Might We → prioritisation.
  • Define insight properly. W3 s16: insights are groupings of observations that bubble up into a clear theme that is IRA — Interesting, Relevant, Actionable. Give all three tests, and give the s17 gloss on Interesting: how did the user's perspective change yours?
  • The worked chain — one line each, using a real example. Observation: "I checked the group chat four times before the meeting to see if anyone had started." Theme: effort spent checking, not doing. Insight: members cannot see progress without asking, so they substitute checking for working — interesting (it reframes the problem from motivation to visibility), relevant, actionable. Problem statement: team members have no shared view of progress and fall back on interruption. HMW: "How might we let a team member see what has moved without asking anyone?"
  • Prioritisation + naming rule. Name one matrix and define its axes — Impact × Importance (W3 s64, customer benefit × business benefit, 1–5) or Impact × Effort (W3 s65, Start Here / Do Next / Proceed Carefully / Avoid). And state the affinity naming rule: clusters are named after the experience, not the proposed fix.

Question 2 20

(a) Define a storyboard and explain what it communicates that a wireframe cannot. 8

(b) A council wants residents to report street faults — potholes, broken lights — from their phones. Draw a storyboard for a resident reporting a fault, and annotate what each frame is doing. 12

Answer plan — Question 2

2(a) — 8 marks. Definition, purpose, components, contrast.

  • Definition, quoting W4 s43: storyboards convey social or functional messages through entertainment and engagement in a visual format — showing, in a linear and sequential fashion, how a customer may interact with your experience.
  • Purpose: it answers "why would anyone want this?" A storyboard carries a person, a situation and an emotion.
  • Components: the three acts, and two or three of the eight elements (characters, speech bubbles, devices, signs, arrows…).
  • The contrast the question asks for: a wireframe shows one screen's structure — layout, hierarchy, functionality, interaction options. It cannot show context outside the screen, emotion, or the trigger that made someone open the app at all. Name what each artefact does not show; that is the core comparison the question requires.

2(b) — 12 marks. Draw six frames, three acts, captioned, emotion marked.

  • Frame 1 — actor, context, trigger. A named resident walking home in the dark past a dead streetlight. Emotion: uneasy.
  • Frame 2 — the pain point. They have reported it before by phone, waited on hold, and never heard back. Emotion: resigned. This frame is what makes it a storyboard rather than a wireflow.
  • Frame 3 — the user action. Phone out, photo taken on the spot.
  • Frame 4 — the intervention / touchpoint. The app captures the location automatically and shows a reference number. Emotion: relief.
  • Frame 5 — the outcome. A notification: "crew scheduled Thursday". Emotion: trust.
  • Frame 6 — what it means beyond this. They report the next fault without hesitating — and tell a neighbour.
  • Annotations: against frame 2, note that the pain is the silence, not the pothole; against frame 4, note that automatic location removes the step most likely to make someone abandon; against frame 5, that the outcome is a closed loop, which is what turns one report into a reporting habit. Apply the three principles by name — Stay Authentic · Keep it Simple · Highlight Emotion.

Question 3 — case study 55

Case. A community sports club has replaced paper sign-ups with an app for its weekly volunteer roster — canteen, scoring, first aid. Volunteer numbers have fallen since launch.

Research so far has found:

  • Direct success on the task "sign up for a shift next Saturday" is 54%; a further 21% completed it indirectly, after backtracking.
  • Average time on that task is 3m 40s. On the old paper sheet it took seconds.
  • A volunteer: "There are three lists that look the same. I don't know which one is this week until I've opened all three."
  • Another: "I signed up. I think. It didn't say anything, so I signed up again."
  • A club administrator: "Half the duplicates are the same person twice."
  • Older volunteers report giving up and texting the administrator instead.

(a) Evaluate the app against the five design principles. Identify the two most damaging breaches and justify why those two. 10

(b) Write a hypothesis for the change you would make, using the course's structure. 5

(c) Interpret the metrics above. What does the gap between direct and indirect success tell you, and what would you need to know that these figures cannot tell you? 10

(d) Draw a low-fidelity wireframe for the redesigned shift sign-up screen, plus the screen that follows it. Annotate three decisions with the evidence behind each. 15

(e) Plan the usability test for your redesign: participants and criteria, tasks, what you would measure, and two things that could bias the result. 15

Answer plan — Question 3

3(a) — 10 marks. Name all five, then commit to two.

  • The two: 4 Provide feedback — "It didn't say anything, so I signed up again" is a direct quote of an absent confirmation, and it is producing the duplicate records the administrator reports; and 1 Perceivable and predictable — three visually identical lists mean the volunteer cannot tell which one is this week without opening all three.
  • Justify the choice. These two are the ones with evidence attached in the case and a measurable consequence: duplicates for the first, 3m 40s and a 54% direct success for the second. Note briefly that 2 Consistent and conventional is also arguably breached, and say why you ranked it below the other two — that ranking is the evaluation.
  • Do not write about signifiers or F-patterns. Neither is course vocabulary.

3(b) — 5 marks. One paragraph, the recipe verbatim.

  • We believe that volunteers abandon sign-up because they cannot tell which roster is current and get no confirmation when they commit. So if we show a single dated "this week" roster as the default view and confirm the sign-up inline with the shift name and date, we will see direct success rise, time on task fall, and duplicate sign-ups drop.
  • Add one sentence on why it is a good hypothesis: it is specific, it names the variable being changed, and it predicts a measurable outcome — which means it can be shown to be wrong.

3(c) — 10 marks.

  • The gap is the finding. 54% direct + 21% indirect = 75% eventually succeeded. A high indirect proportion means the task is possible but not discoverable — people find it by backtracking. If the failure were structural, indirect success would be near zero too. The 3m 40s corroborates it: that is the cost of the backtracking, on a task that took seconds on paper.
  • Pair with the qualitative. The two quotes name the mechanism: three identical lists (discovery) and no confirmation (feedback). Diagnosis, then decision — this is an iterate.
  • What the figures cannot tell you. Who stopped volunteering entirely — they are not in the numbers, because they never started the task. Also nothing about the older volunteers who left the app for SMS. The metrics measure people who tried; the drop in volunteer numbers is about people who did not. Say what you would do to reach them, and note that the course's vocabulary for these measures is Week 10 slide 30's (direct/indirect success, confidence rating), with Week 7's success rate as the equivalent.

3(d) — 15 marks. Two screens, low fidelity, labelled, with an arrow from the tapped element.

  • Screen 1 "This Saturday — 12 April": a dated title bar so the current roster is unmistakable; a single list of shifts with role, time and slots remaining; each row showing its own state (open / full / you're on this); one primary action per row. Placeholders only — images as X, text as lines.
  • Screen 2 "You're on — Canteen, Sat 12 April, 9–11am": reached by tapping the row's action. Confirmation stated in words, with an undo, and the roster row now showing your name.
  • Three annotations, each with its evidence: (1) the date in the title — because "I don't know which one is this week until I've opened all three"; (2) the per-row state including "you're on this" — because "I signed up. I think." and because duplicates are appearing in the administrator's data; (3) one primary action per row, visually dominant — because indirect success at 21% shows people are hunting for the commit step.
  • Close by naming what the wireframe does not settle — whether older volunteers can read it, and whether "you're on this" is legible at a glance — and say that is what 3(e) tests.

3(e) — 15 marks. Follow the course's four steps: Plan, Prepare, Moderate, Outcomes.

  • Participants and criteria. Current and lapsed volunteers who have signed up for a shift in the last season — the behavioural qualifier. Include the older-volunteer segment deliberately, since they are the group the case says gave up. Five to six users for the usability test, attributed to Sauro's Magic of 5 (W7 s35) — 5 users ≈ 85% of problems.
  • Tasks, in the user's language, not the interface's. "You've been asked to help at the canteen this Saturday morning — do what you'd normally do to put your name down." Then: "Check whether you're actually on the roster." Never say "tap the sign-up button".
  • Measure: direct and indirect success on each task; time on task; a confidence rating after task 2; and the qualitative three — what they liked, what they did not, what they would suggest. Add the operational check: duplicate sign-ups.
  • Two biases from the course's own list, both of which genuinely fit this scenario. (i) Social desirability bias — you are testing a club's app with the club's own volunteers, who have every reason to be polite about it; ask what they did, not whether they liked it, and take the behaviour over the compliment. (ii) Hawthorne effect — a volunteer who knows they are being watched will persist through a confusing screen far longer than they would alone on a Saturday morning, which would conceal exactly the abandonment this case is about; use unmoderated sessions for the discoverability task, or say plainly that observed persistence is not evidence of usability. Week 7 slide 39 names four biases — Confirmation bias · Social desirability bias · Hawthorne effect · Culture bias — and gives no definitions, so name them and show you understand them through the mitigation rather than inventing a textbook definition.
  • Two further risks, correctly labelled. Moderator influence — a facilitator who nudges or explains contaminates a discoverability test, which is what the 8 Rules guard against: be curious, listen more than you talk, base it in actual behaviour rather than "would you…?". And sampling — recruiting only from the app's active users excludes precisely the volunteers who left, so recruit lapsed volunteers by SMS. Neither of these two is one of the four biases named on slide 39. They are practical testing risks, and worth raising as such — just do not present them as course-named biases.
  • Close the loop. State what result would make you reject the hypothesis — e.g. direct success rises but duplicates do not fall, which would mean the confirmation was still not being read.
Sprint guide · Section G

The last night, and the morning

What to check the night before

Mandatory — from Week 10, slides 16–21

  • Physical UNSW Student ID card. Electronic IDs are not accepted; a physical driver licence or passport also works. It is scanned at the venue.
  • A pen or pencil — there is an ID form to complete.
  • A laptop with the correct SEB version installed, plus its charger. Power is not guaranteed.
  • Your smartphone, for SSO/MFA login.

Advised

  • A mouse. Laptop fully charged. Bring a pen and a pencil — the slide prefers a pen, the tutor prefers a pencil for the drawn artefact because you can erase, and he concluded it "doesn't really matter that much" provided the drawing is clear in the photograph. transcript-derived
  • Correct SEB version as stated in Week 10 (Mac 3.5.4 / Windows 3.10.0); on Windows, uninstall any other version.
  • Re-run the Inspera Student Practice Test the day before.
  • No OS updates in the two days before. If one happens anyway, re-run the practice test.
  • Arrive 15 minutes early, connect to Uniwide, log in via the Inspera site rather than launching SEB directly.
Source: Week 10 Lecture, slides 16–21. This is a no-notes exam; SEB blocks other applications and websites while it runs.

The five things worth re-reading, in this order

#WhatWhy it is first
1Section A — the exam on one pageKnowing what is excluded stops you spending fifteen minutes writing an answer that cannot be marked.
2The five heuristics with their three author bands, and the five design principles by numberTwo closed lists, high recall value, and both are restated on the Week 10 deck itself.
3The hypothesis recipe and the "we found that / so what" pairTwo sentence patterns that work as answer structures anywhere in the paper.
4Section C — the three drawing sheetsStructure under time pressure is muscle memory, not knowledge. Draw each one once from blank.
5Topic 11 — the blueprint lanes and linesThe most structured artefact in the course, and the one where an unlabelled diagram costs the most.
Guide inference — not stated by the lecturer. This ordering is this guide's suggestion, based on which material is closed-list (fast to recall) and which is procedural (needs rehearsal). The course does not publish a revision order.

The five-minute check at the end of the paper

  1. Does every sub-part have at least one example? Week 10 says it twice, with three exclamation marks.
  2. Does every finding have a "so what" — a consequence for the user, and where relevant for the business?
  3. Did I answer the command verb, and give the number asked for when one was specified?
  4. Is every drawing labelled, with two or three annotated decisions?
  5. Have I built any answer's substance on an excluded topic?
  6. Where I used the same example more than once, does each answer make a different point with it?

The three terminology substitutions that most often go wrong

Do not write…Because the course says…Source
"Nielsen's five heuristics"The set is titled "Combining 5 heuristics for INFS3700" and comes from three authors — Cooper (01, 02), Nielsen (03, 04), Krug (05)W1 s35
"Nielsen says test 5 users"The Magic of 5 is attributed on the slide to Jeff Sauro of MeasuringUW7 s35
"affordances vs signifiers"; calling the second viewing pattern "the Z-pattern""Signifier" appears nowhere in the Week 4 deck. The deck prints only "Two Viewing Patterns" — though the lecturer does name the F pattern aloud, so that one is fine; the second name is not recoverableW4 s26; Wk4 recording

Where to go when this page is not enough

Every topic here is a compression of a full chapter in 02_INFS3700_Final_Exam_Revision_EN.html — the complete guide, with the lecturer's verbatim wording, the course screenshots, 22 practice questions and the full source appendix. The Chinese companions are 03 (full) and 06 (this sprint guide). Provenance for every claim is in 01_SOURCE_MAP.md; what is uncertain and why is in 04_ACCURACY_AND_SCOPE_AUDIT.md.