Design
Turn standards into flows that ask for consent, show people how to escalate, and use words they can act on.
-
See who the design asks to adapt
The design stance behind this work: what a system demands of people, who carries those demands, and whether they can make it change.
-
Model the burden of one flow
Score a real user journey for time spent, number of steps, and whether there is a way out. Use the result as a design brief.
-
Put a checkpoint where the harm happens
Design the checkpoints that pause, slow, or escalate a flow when your rule is wrong, and put them where the people it decides about can reach them.
-
Write copy people can act on
Use phrases a person can send, file, or read out to challenge a decision, without needing to know this framework.
What to run, satisfy, and read
The diagnostics that show risk in this role's work, the standards that apply to it, and the reading behind them.
Diagnostics
Reading
- Ethotechnical design — The design stance: the institution should adapt before it asks people to.
- Language people can use — The questions people send about a decision. The screen should answer them.
- Check each flow: can a person challenge the decision, get an answer by a date, and leave without losing their place?
- Put the challenge route on the screen where the decision appears, not in a help page.
- Count what the flow asks of people, in minutes and steps, before it ships.
Other roles
If that was not you
- Engineering — You build or operate the system that makes the decision.
- Policy and compliance — You write the rules the system has to satisfy, or prove to a regulator that it does.
- Audit and assurance — You verify someone else's claims from the evidence their system emits.
- Operations — You run the appeals, the incident response, or the queues where the system's errors land.
- Research — You study these systems and publish about them.
- Executive — You decide whether to deploy, and you carry the liability when it goes wrong.