Skip to content
Writing
How we build

Designing for the person at the counter, not the person who signs

The buyer wants visibility, control and reporting. The user wants to finish the task in front of them and deal with the next person in the queue. These are not the same product, and when a vendor optimises for the buyer, the user quietly keeps a parallel register.

2 min readOadbox

Watch the work before designing for it

We do not start from requirements documents. We start by standing at the counter for a day — the fee desk, the nurses' station, the weighbridge, the collection round — and watching what actually happens, including the workarounds nobody would mention in a meeting.

The workarounds are the most valuable thing there. Each one is a place where the existing process failed and a human patched it, which tells you exactly what the software has to absorb.

Optimise the common case ruthlessly

In most operational screens, one path accounts for the overwhelming majority of use. That path should be reachable without thought, without a mouse where possible, and without the interface asking questions it could answer itself.

  • Count the interactions in the common case, and treat the count as a budget.
  • Put the rare case behind one extra step rather than slowing the common one.
  • Default everything that can be defaulted, and show what was defaulted.
  • Never make the user tell the system something it already knows.

Make errors recoverable rather than preventing them

Confirmation dialogues are usually a substitute for an undo that was too hard to build. They train people to click through, and then fail at the moment they were meant for.

Where an action is genuinely destructive, the better design is a reversal that leaves a trail. Where it is not, get out of the way.

The buyer still gets what they wanted

None of this is at the buyer's expense. Visibility and control depend entirely on data being entered, and data gets entered when entering it is the fastest way to finish the job.

The reporting a management team wants is a downstream benefit of a counter that adopted the software. It is never achieved by adding fields the counter has no reason to fill.

Product teamDesignAdoption

Written by the Oadbox team. Something here not match how it works in your business? We would genuinely like to hear it — connect@oadbox.com.

Eleven products, already running. One of them probably fits how you work.

See it on your own data rather than in a slide deck — thirty minutes with someone from the product team.