Good business software design starts from an uncomfortable fact: the tool is used by people who did not choose it, on a morning when they are already behind.
Business software design begins with the first screen
Most people will never explore your navigation. They open the tool, look for the thing they came for, and leave. If the first screen answers “what needs me today”, the product becomes part of the routine. If it presents a dashboard that needs interpreting, it becomes a tab that stays closed.
That means the opening view should be a work queue, not a summary. Summaries are for the person reviewing the team. The person doing the work needs to know what to touch next.
Respect what people already know
People arrive with a working mental model of their job. Software that uses their vocabulary and mirrors their sequence is learned in minutes. Software that imposes its own model, however clean, costs them a retraining they did not ask for, and they will route around it.
Borrowing the language of the trade is not a cosmetic decision. It determines whether training takes an afternoon or a quarter.
Speed is a feature people feel
A page that takes three seconds is not slow in the abstract; it is slow forty times a day. Performance is one of the few improvements users notice without being told about it, which is why we treat page weight and response time as product requirements rather than infrastructure details.
Google’s Core Web Vitals are a reasonable public yardstick, and they line up closely with what people report as “this feels fine” versus “this drags”.
Practical rules we hold to
- The most common action is reachable without a decision
- Nothing destructive happens without a way back
- Empty states explain what to do next instead of showing a blank panel
- Errors say what went wrong and what to do, in plain language
- It works on a phone, because a lot of this work does not happen at a desk
- Keyboard users can complete the whole task without reaching for a mouse
Designing for the bad day
Software is easy to design for the calm case and revealing on the difficult one. The interface that matters is the one someone uses while a customer waits on the phone, and that is the version worth prototyping first.
None of this is novel. It is simply what separates software people tolerate from software people rely on.
Read next: We build around the work, not the feature list. Or see talk to our team.