10 · Principles
Principles for Designing Complex Systems
The ten rules I work from when the system is bigger than the screen.
By John Wright-Nyingifa · Distilled from 7 years of designing infrastructure products.
Start with the system, not the screen.
Model the actors, dependencies, and state transitions first. Screens are projections of system truth.
Design for understanding, not decoration.
The UI's job is to reduce ambiguity. Beauty supports clarity, but never replaces it.
Let the system's architecture shape the UX.
If execution, verification, and settlement are distinct, the UX must reflect that. Don't compress layered reality into a single "confirmed."
Reveal complexity only when it is useful.
Default to simple phases and outcomes. Offer deeper detail only when it changes a decision.
Model failure before modeling success.
Success paths are easy. Trust is earned in degraded states.
Everything is a state transition. Show it.
Replace spinners with phase-based statuses. Make prerequisites visible (waiting on DA, prover, sequencer, settlement).
Logs should read like stories, not error piles.
"What I tried → what happened → what's true now → what's next." Keep raw traces behind an expand.
Trust comes from predictability, not opacity.
Users tolerate slowness. Users do not tolerate uncertainty disguised as progress.
Make people feel in control, even when they're not executing.
Offer policy controls and clear boundaries. Always provide a safe exit: pause, cancel, claim, retry.
Complexity isn't the enemy. Ambiguity is.
It's okay that the system is complicated. It's not okay that the user can't tell what is true.
Practical Checks
Use during design reviews:
→ Can a user name the current phase in one sentence?
→ Can a user predict the next phase?
→ If something fails, is there a stable end state?
→ Do we separate "included," "verified," and "finalized"?
→ Do we expose assumptions and guarantees clearly?