Trauma-informed Software Patterns: Safety Under Stress
“Trauma-informed” here is not a UI aesthetic — it’s a safety property: in high stress, people have less time, less attention, and less tolerance for surprises. Protective software should reduce cognitive load, minimize exposure, and fail safely.
Patterns (practical, testable)
1) Make the essential path obvious
One “do the thing” action, predictable placement, works offline. Avoid hidden states and ambiguous toggles.
2) Reduce disclosure by default
Show only what’s needed for the current task. Minimize previews, exports, and “helpful” sharing prompts.
3) Prefer reversible actions
Undo, restore windows, and “safe trash” beat permanent deletes. Treat reversibility as a requirement, not a feature.
4) Choose stable, plain-language labels
Stress kills recall. Use consistent naming and avoid jargon when it matters. Don’t rename core concepts casually.
5) Support “stop using it” safely
Clear exit paths: export, delete, or freeze. Reversibility and local authority should extend to leaving.
6) Degrade deliberately
When storage/CPU/battery are scarce, reduce features without breaking the essential workflow.
Where this connects in Protective Computing
- Exposure Minimization: collect and reveal less, by default.
- Reversibility: make error recovery a first-class behavior.
- Degraded Functionality: define safe behavior under constraint.
- Essential Utility: keep the “must work” path simple and durable.
- Coercion Resistance: plan for pressure, not just accidents.