Designing software for operators, not tourists
The person who will use your tool 40 hours a week is not the person who will demo it. Design for the operator — the demo can take care of itself.
Software aimed at operations teams often gets designed for the buyer: the executive, the partner in a boardroom, the person in the demo. They need to be impressed quickly. They\u2019ll use the product twice a year.
The operator, meanwhile, will touch your tool every hour of every working day. They will learn it better than you ever will. They will find the edges. They will route around anything that slows them down.
Design for the operator. The demo will take care of itself.
What operators need
Speed of recognition, not speed of first impression. An operator doesn\u2019t need an onboarding carousel. They need the thing they\u2019re looking for to be in the same place tomorrow.
Dense information done well. A table with 20 columns is fine. A table with 20 columns and 5 of them unlabelled abbreviations is not.
Keyboard-first. If it can\u2019t be done without a mouse, a good operator will write a script to work around you.
Unambiguous state. “Processing…” is not a state. “Awaiting customer approval since 3 Apr, 9:42am” is.
Undo. Everything destructive should be reversible for long enough to realise you shouldn\u2019t have done it.
What operators don\u2019t need
- Confetti animations.
- AI-generated motivational copy.
- Tours. (The operator has already used it more than you have.)
- “Fun” error messages.
- Dashboards that are secretly a sales pitch for an upsell module.
A small test
Before shipping an operations screen, watch a real user do their most common task three times in silence. Note every moment they slow down, pause, or squint. Fix those \u2014 before adding new features.
You\u2019ll ship fewer features. You\u2019ll keep clients longer.
We write more about this inside Dynamis Labs, which exists partly because operator-centric design only improves through deliberate practice.