Track 09 · Systems & unit costLesson 11 of 11
The screen the operator uses all day
Design the queue and the decision card, then measure time to decision.
- The FDE path · Stage 4 of 6
- 35 min read
- 75 min hands-on
- Pro
What you'll be able to do
01- Run a contextual inquiry with operators and turn what you see into requirements for a queue and a decision card.
- Design a triage queue ordered by risk and time left, and a decision card that shows the proposal, why, the evidence with its source and age, and one-key actions.
- Capture every override as labelled data, with a reason that says whether the model, the data or a missing rule was wrong.
- Design the stale, empty, error and refusal states, and meet the WCAG 2.2 AA basics for a keyboard-first tool.
- Measure the surface (time to decision, acceptance, overrides by reason, 7-day rework, adoption by operator) and say what each number tells you to fix.
Before you start
- Agents where people already work: where the agent appears. This lesson is the screen itself.
- The operational model: objects, links and actions: the card's evidence is object properties with provenance, and its buttons are actions.
- Approval gates and bounded autonomy: the decision card is where a gate meets a person.
- Shadowing the work as it's really done: the observation habits contextual inquiry builds on.
- Some HTML and JavaScript. The worked example is one Python file with its page inside it.
Starting here? On the core path this lesson closes stage 4. Two ideas used below: an action is the only way the system changes anything, with checks, approvals and an audit record (The operational model: objects, links and actions); an override is a person changing or refusing what the agent proposed.
The short version
An agent's proposals become work through a queue and a decision card. The queue decides what an operator sees next; the card decides whether they can judge a proposal in thirty seconds or need five minutes in three other systems. Build them from watching operators work, not from a dashboard template. The card shows the proposal, a one-line reason, the evidence with its source and age, and what the agent already did, with one key per action. Every override carries a reason code, because those reasons are the cheapest labelled data you will get and they tell you whether to fix the model, the data or the rules. Then measure the screen like a product: time to decision, acceptance, overrides by reason, rework within seven days, and who has stopped using it.
- Design from the operator's unit of work, observed on site, not from the agent's output format.
- Evidence beats confidence. Show the values and their sources; "0.87" helps nobody decide.
- No reject without a reason. A reason code turns each override into a label someone can act on.
- High acceptance can be bad news. Fast approvals with rising rework mean the screen invites rubber-stamping.
- Keyboard first and accessible from day one: the people who use it most need it fastest.
Pro lesson
The rest of this lesson is in Pro.
The mental model, worked example, field note, failure table, exercise and self-check, with the voice tutor.
Pro opens this stage
Stage 4 · Agents that act safely- 7 lessons, with the voice tutor
- Lab · Find the intake agent's failed writes, graded here
Also in Pro
- Every stage and specialisation, in full
- Every lab and every role project
- Halden weeks 2–10, on your record
- Every drill, live in the playground
- All solutions, plus the server judge
- Lab Assistant and every Teach with AI