Decompose one real waiting system into the mechanisms actually shaping it — interface, environment, queue structure, priority, and value — instead of describing the experience of using it as one undifferentiated whole.
- Waiting Field Notes15% · due Week 4
- Queue Case Study20% · due Week 9
- Waiting Experiment25% · due Week 10
- Waiting Audit40% · due Week 12
Due: 19 April 2027 · Weight: 20%
The brief#
Take everything Weeks 5 to 9 taught about how a waiting system is built — its interface, its environment, its queue structure, its priority rules, and its value exchanges — and use it to decompose one real system into the mechanisms actually operating in it, rather than describing the experience of using it as one undifferentiated whole.
Choose one real waiting system and determine, for each of interface, environment, queue structure, priority redistribution, and value/attribute exchange, whether it is present, absent, ambiguous, or cannot be determined from what you can access. Where a mechanism is present, say specifically what it does, in this course’s own vocabulary for that mechanism — not in the language of a general customer-experience description. Finding a mechanism genuinely absent is a legitimate, valued result here, not a gap in your analysis.
Choosing a system#
Any real-world waiting system with sufficient publicly observable or documentable features to analyse its waiting mechanisms will do: a café or retail queue with a posted or ticketed order, a delivery or shipping checkout with more than one speed or cost option, a call centre or online support queue with a stated priority category, a transit system with boarding groups, or something similar. You may reuse or extend a system you already mapped for Week 7, 8, or 9 — deepening one system’s analysis across mechanisms is worth more here than starting over on a new one.
Carrying forward this course’s existing observation rules: no medical, emergency, clinical, or triage setting. Don’t identify, name, or photograph any real person. Observation must be non-interfering, drawn only from publicly observable or documentable features — signage, published terms, a website’s stated options, your own non-identifying notes on how a queue actually behaved. Don’t interview staff or customers; nothing in this course’s existing rules extends that permission to this assessment.
Choosing your system: choose your system with the later Waiting Audit in mind: the Audit will normally revisit this same system using the course’s complete ten-mechanism toolkit. Your system does not need to exhibit all ten mechanisms, but it should provide enough observable or documentable features for meaningful whole-system analysis later in the course.
The five mechanisms#
You don’t need five equal-length sections. Structure the analysis however the system itself makes sense, but address all five mechanisms somewhere, with an explicit finding for each:
- Interface (Week 5): does the system communicate anything about the wait itself — a countdown, a position indicator, a percent-done signal — and if so, what does it actually show, versus what it merely implies?
- Environment (Week 6): does the physical or digital space shape the wait on its own, independent of the queue or the interface — seating, layout, sound, visual design?
- Queue structure (Week 7): what rule governs order, and could you actually verify it from where you stood or from what’s published?
- Priority redistribution (Week 8): does one class of person get served sooner than another, on a stated criterion? A separate faster service tier is not automatically priority redistribution. Priority requires an ordering relationship in which one class is served sooner relative to another class in the same service/ordering system. Identify what ordering relationship actually exists before applying the Week 8 label — if the faster and slower options share no queue or order position, that is not priority, whatever else it might be.
- Value/attribute exchange (Week 9): does the system trade time against money, flexibility, certainty, or another attribute, explicitly? Classify this half of the system as value/attribute exchange, priority redistribution, both, or cannot determine from published information or evidence, using the same test Week 9 taught: does it change what’s received, or does it change who’s served first? Implicit value is a practitioner proposition from Maister, not an observable finding established by this case study. You may discuss perceived value as a possible interpretation only where relevant, but must not present it as an observed mechanism or empirical finding about users.
A single feature can implicate more than one mechanism. Say exactly which, rather than filing it under whichever label is most convenient.
What you submit#
Findings for all five mechanisms, each with its evidence and its present/absent/ambiguous/cannot-determine call, structured however suits your system. Close with a required synthesis: which mechanisms interacted with each other, which were fully independent, where the available evidence was insufficient to say, and how you kept the classifications distinct rather than letting them blend into one description of “the experience.”
End with a limitations section naming what this analysis can’t establish: the limits of what you could observe or document, the time window you observed it in, the impossibility of inferring anyone’s psychology from what you saw, the absence of any controlled comparison, and the fact that one system observed once is not evidence about that type of system in general.
Course readings — Harrison, Amento, Kuznetsov and Bell; Myers; Pruyn and Smidts; Larson; Rafaeli, Barron and Haber; Raz, Avi-Itzhak and Levy; Maister; Dietl, Voigt and Kuhn — are analytical lenses for interpreting what you observe, not evidence that your chosen system produces the same effects those studies measured in their own contexts.
Aim for roughly 1,200 to 1,800 words, or an equivalent mix of text and evidence — screenshots and photographs of signage or published terms don’t count toward that limit.
What you must not claim#
Without evidence for it, don’t claim what anyone felt, satisfaction, fairness, efficiency, willingness to pay, why the organisation designed the system that way, causality, or general customer or user behaviour. “Cannot determine from available evidence” is a legitimate, successful finding wherever it’s honest — not a failure to find something.
How this is marked#
Marking rewards analytical accuracy, not the number of mechanisms found. A system that genuinely exhibits only two or three of the five mechanisms can receive full marks if the analysis correctly establishes the others as absent or undeterminable, with evidence for that call. A submission that strains to manufacture a mechanism that isn’t there will score worse than one that states its absence plainly.
Afterwards#
This is the last piece of work before the course turns from analysis to intervention. The Waiting Experiment and the Waiting Audit both depend on the same discipline this case study tests: separating what a system does from how it might feel, and naming plainly what the evidence in front of you can’t establish.
The spec
The brief poses the problem and leaves room for a response. The spec is the fixed part: what a marker checks. Some lines can be checked mechanically; the rest call for judgement.
- you have chosen one real-world waiting system with sufficient publicly observable or documentable features to analyse its waiting mechanisms, and it is not a medical, emergency, clinical, or triage setting
- you have not identified, named, or photographed any real person, and all observation is non-interfering and drawn only from publicly observable or documentable features, not from interviewing staff or customers
- you have given a finding — present, absent, ambiguous, or cannot determine — for each of interface, environment, queue structure, priority redistribution, and value/attribute exchange
- for every mechanism you find present, you have described specifically what it does using that mechanism's own course vocabulary, not a generic description of the experience
- you have not treated implicit value as an observed mechanism or an empirical finding about users; any discussion of perceived value is marked as interpretation, not as something the case study established
- for the priority finding, you have identified the actual ordering relationship between classes (or its absence) before applying the label, rather than treating any separate faster tier as automatically priority
- you have classified the system as one of value/attribute exchange, priority redistribution, both, or cannot determine from published information or evidence, and justified the choice from what you found
- you have closed with a synthesis stating which mechanisms interacted, which were independent, where the evidence was insufficient, and how you kept the classifications distinct rather than blended
- you have included a limitations section covering observation and documentation limits, the time window you observed, the impossibility of inferring anyone's psychology, the absence of a controlled comparison, and the inability to generalise from one system
- you have not claimed what anyone felt, satisfaction, fairness, efficiency, willingness to pay, the organisation's motive, causality, or general customer or user behaviour without evidence for it
- the submission is approximately 1,200 to 1,800 words, or an equivalent combination of text and evidence — images or screenshots don't count toward that limit
How it is marked
| Criterion | Weight |
|---|---|
| Accuracy of mechanism identification | 35% |
| Quality of the distinctions drawn between mechanisms | 30% |
| Honesty and specificity of limitations and uncertainty | 15% |
| Clarity and use of the course's own vocabulary | 20% |