Usability testing when you have no research budget
Five participants and an afternoon will tell you more about your product than a quarter of internal debate.
ZooBieDoo Infotech Engineering TeamRead
Key takeaways
- Design for the second week of use, not the first hour.
- Keyboard operation raises expert throughput and aids accessibility.
- In operational software, the exceptions are the process.
- Existing workarounds are the most reliable requirements source.
Expert users are not new users
Consumer design optimises for first use: minimal density, generous guidance, one action per screen. Operational software is used by trained people hundreds of times a day, and that guidance becomes friction.
Density that looks overwhelming to a visitor is efficient for someone who knows the domain. Design for the second week of use, not the first hour.
Support keyboard operation properly
Expert users prefer the keyboard because it is faster. Full keyboard navigation, sensible tab order and shortcuts for frequent actions materially increase throughput.
This also improves accessibility, which makes it one of the few investments that serves both efficiency and compliance.
Design the exceptions
- What happens when required data is missing?
- How does someone correct a mistake made three steps ago?
- What does the interface show when an external system is unavailable?
- How are partial or ambiguous records handled?
In operational software the exceptions are the process. Systems that model only the happy path get abandoned in favour of spreadsheets, which handle exceptions perfectly well.
Watch the work before designing it
Sit with the people doing the job. You will find workarounds, second screens, printed reference sheets and shared documents that exist because the system does not support something it should.
Those artefacts are the requirements. They are more reliable than any specification produced in a meeting room, because they represent what people actually needed badly enough to build themselves.
Handling scale in the interface
Operational interfaces that work with fifty records often become unusable with fifty thousand, and that transition happens without any code changing.
Design for the volume the system will actually hold: server-side filtering and sorting, pagination or virtualised lists, saved views for common queries, and bulk actions for operations people perform repeatedly.
Ask what the largest realistic dataset looks like and design against it. Testing with sample data an order of magnitude smaller than production is how interfaces ship that nobody can use after a year.
Frequently asked questions
No density should follow expertise and frequency. Occasional users need more guidance; daily users need efficiency. Where both exist, progressive disclosure can serve them.
Good operational design reduces training need but does not remove it. Task-based guidance and in-context help work better than manuals.
Selectively. Familiar patterns lower the learning curve; consumer minimalism applied to high-frequency work usually reduces productivity.
