The best tool is the one people actually use
Software that nobody wants to use is a wasted investment, even when it works perfectly.
It is the most common cause of failure for internal projects: the tool does what it is supposed to do, but requires too many steps, is unclear, and people go back to the Excel spreadsheet they used before. At that point, the project has cost money and achieved nothing.
Designing the user experience means understanding how people actually work today, designing how they will work tomorrow, and testing it before development. Fixing a prototype takes hours. Fixing software that has already been built takes weeks.
What you get
- Less training required, because the tool is self-explanatory.
- Fewer operational errors, because the interface makes mistakes harder to make.
- Less resistance to change, because people are involved in the design process rather than informed at the end.
How we work, in four steps
- Observation: we talk to the people who will use the tool and observe how they work today. We do not ask what they would like; we ask them to show us the last time they performed that task. The difference between the stated process and the actual one is almost always significant.
- Structure: organization of information and workflows, with the main user journeys defined. A flawed architecture cannot be compensated for by the interface.
- Prototype: a navigable but undeveloped version that people can click through and make mistakes with, without consequences.
- Testing: real people attempt to complete real tasks using the prototype. We observe where they get stuck and make corrections before writing code.
What we measure during testing
How many people complete the task without help, how long it takes, where they stop, and what they say while doing it. These are concrete observations of real behavior, not opinions about visual design collected in a meeting.
A small number of participants is enough to uncover most serious usability problems: you do not need a statistically significant sample, you need to observe the right people performing the right tasks.
Accessibility, including internal tools
Full keyboard navigation, adequate contrast, screen reader compatibility, and sufficiently large click targets. These principles apply to internal tools just as much as to public websites: a colleague who cannot use the business management system is a business problem before it is a compliance issue.
Designing interfaces for automation
When a tool proposes an automated action, the interface must show three things: what it proposes, why it proposes it, and how to correct it. This is what makes automation acceptable to the people who work with it every day.
Correction must be designed as a primary workflow, not as an exception hidden in a menu: it is the flow on which trust is built, and the data it generates is what allows the system to improve over time.