The Instrument Cluster You'd Trust
The capstone — design a complete alert vocabulary for a vehicle of your choosing, and defend it as a system rather than a pile of good ideas
Due: 14 May 2027 · Weight: 50%
The brief#
Design a complete, coherent alert vocabulary for a vehicle that does not yet have one — and defend it as a system a driver could learn to trust.
Choose your own vehicle and context: a small EV, a motorcycle, a delivery van, a low-speed autonomous shuttle, whatever gives you a real set of constraints to design against. The scope should be realistic for the semester that produced it — twelve to twenty alerts, covering the full range from routine status through to the ones that mean stop the vehicle now, is a reasonable target. Twice that is not more impressive; it is usually a sign the scope wasn’t chosen carefully.
Every earlier assessment asked you to work on one alert, or one dashboard that already existed. This one asks you to build the whole vocabulary from nothing, which means the interesting decisions are the ones between alerts: how loud is loud enough for the worst case without being oppressive for the routine one, which alerts share a channel and which need their own, and what happens when two things go wrong at once. A vocabulary is not a list of words; it’s the relationships between them.
What you submit#
- a short statement of the vehicle, its driver, and the operating context (100–200 words) — enough to judge fit, not a design-fiction short story
- the full alert vocabulary: every alert, its trigger, its channel(s), and its place in the system’s overall urgency hierarchy, presented so a reader can see the whole system at a glance (a table, a diagram, or both)
- a written defence (1,000–1,500 words) that argues for the system as a whole and directly addresses at least one failure mode — what happens when this system is wrong, and why the design still holds up
- this is a capstone: it should draw visibly on material from across the semester, not just the weeks nearest the vehicle type you picked
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.
- the vehicle and its operating context are stated precisely enough that a reader can judge whether the design fits it
- the full alert vocabulary is specified — what triggers each alert, what channel(s) it uses, and how it relates in urgency to every other alert in the system
- the submission argues for the system as a whole, addressing at least one likely failure mode (a false alarm, an overloaded driver, a channel that fails) and how the design handles it
How it is marked
Judged as a whole system, not as a checklist of channels covered. A strong submission demonstrates command of gauges, lights, icons, colour, sound, text, and — where the chosen vehicle warrants it — HUD or driver-assistance alerts, and argues for the vocabulary as a coherent whole rather than defending each choice in isolation. A submission that is excellent on individual alerts but incoherent between them will not score as highly as one that is merely good throughout but consistent.