Protocol design
A written protocol for a group you actually belong to, tested for a week and reported on honestly.
Due: 23 April 2027 · Weight: 35%
The brief#
Design a small set of shared norms for a group you belong to, run it for a week, and report what actually happened.
Use your diagnosis, or a fresh friction point, from a share house, a project team, a studio or a lab group: somewhere the group’s coexistence currently runs on assumption rather than agreement. Write a short protocol: who does what, when, and what happens when someone doesn’t. Then get the group to actually try it for at least five days.
This is the week the workplace material earns its keep: a protocol that only works when everyone already likes each other is not a protocol, it’s a description of a group that got lucky. Design for the version of the group that includes someone you’d rather not be rostered with, and that still gets the task done.
What you submit#
- the protocol itself, written so someone outside the group could run it
- a test log: what happened each day, including where it broke down. The log template works here too; a protocol that “worked perfectly” with no friction reported reads as untested, not successful
- a short reflection on what you’d change before running it again
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.
- submitted by the deadline, as a protocol document plus a test log
- the protocol addresses a specific, named friction point in a real group
- the test log covers at least five days of actual use, not a single trial
- the work is yours, with any assistance declared
How it is marked
| Criterion | Weight |
|---|---|
| The protocol is practical enough for the group to actually run | 30% |
| Evidence it was genuinely tested, not just written | 40% |
| Honest reflection on what worked and what didn't | 30% |
What separates the grades
Where the mark actually lands within a band is a judgement call; this is what tells the bands apart.
| Band | What it looks like |
|---|---|
| HD | The protocol names who does what down to the specific friction point it targets, the test log shows real breakdowns and how they were handled as they happened, and the reflection changes something concrete for next time. |
| D | The protocol is workable and genuinely tested across the full run, and the reflection is honest, but the changes proposed are minor rather than addressing the friction point that motivated the protocol in the first place. |
| C | The protocol addresses the friction point in principle, but a reader outside the group would need it explained to actually run it; the log covers the required days but reads thin on what actually happened. |
| P | A protocol exists and a log was kept, but the log reads like a diary rather than a test, no clear evidence the protocol was actually put into practice, or the reflection just says "it worked." |