Great Technology Starts With the People Who Use It.

01We ask to watch before we ask what is needed

A requirements workshop produces a description of the work. Sitting beside somebody for an afternoon produces the work itself — and the two are never the same document. The description is tidy. The work has a second screen open, a personal spreadsheet doing the part the system cannot, a colleague who gets a message whenever a particular case appears, and a step everyone performs that nobody can explain the origin of.

None of that is in the specification, and all of it decides whether what we build gets used. So we ask to watch first. Not to catch anyone out — the workarounds are usually the most intelligent thing happening in the process — but because they are a map of exactly where the existing system stopped being useful.

02Complexity is not the same as difficulty

The processes we are handed are genuinely complex. They carry exceptions accumulated over decades, regulation that cannot be simplified away and edge cases that exist because something once went badly wrong. Pretending otherwise is how a redesign fails in its second month.

But complexity belongs to the system, not to the person. Our job is to hold the complexity behind the interface and hand the user a decision they can actually make: this one, now, with these three facts and a way back if it turns out to be wrong. That is an engineering problem long before it is a visual one — it decides the data model, the state machine, the API and what the system is even allowed to do on its own.

Nobody has ever asked us for a beautiful screen. They ask for their Tuesday afternoon back.

03Design for the worst day, not the demo

Demonstrations are performed on a good day, with clean data, one case at a time and an audience that wants it to work. Real use is the opposite: the queue is long, the input is wrong, two systems disagree and the person has eleven minutes before a meeting.

So the questions we design against are the ugly ones. What does this look like when the model is unsure? Where does the work go when it cannot be completed? How does somebody hand a case to a colleague mid-way? What does the screen say when the answer is 'we do not know' — because a system that never admits that is a system people learn to distrust all at once, on the day it is confidently wrong.

• 01Every automated decision shows what it was based on.
• 02Every uncertain decision has a human route, and that route is fast.
• 03Nothing important happens without a way to undo it.
• 04The unhappy path is designed, not discovered in production.

04Adoption is a requirement, and we write it down as one

A system that is technically correct and unused has failed. We treat that as a defect rather than a training issue, which changes what gets built: the pilot group includes the sceptic as well as the enthusiast, the first release covers a whole task rather than half of several, and success is measured by whether people stop keeping the old spreadsheet — not by log-in counts.

It also changes who is in the team. Designers, business analysts and engineers work the same problem at the same time rather than in sequence, because the moment where the workflow gets simple is usually a moment where a data model has to change, and that conversation cannot happen after the architecture is fixed.