Consumer apps are designed to be picked up in seconds by someone who has never seen them. Business software has a different job. It is used for hours a day, by the same people, to do the same tasks hundreds of times. A receptionist booking appointments, an accounts officer approving invoices, a call centre agent logging tickets, a warehouse clerk receiving stock: for them, a clumsy screen is not a minor irritation. It is extra minutes, errors and frustration, every day.
Good user experience in business software is therefore less about looking modern and more about respecting the user's time and attention. This article sets out what that means in practice, and how to build it into a project.
Design for the expert, support the beginner
Business software has two kinds of user at once: the new starter who needs guidance, and the experienced user who wants speed. Too often, systems are designed only for the first visit.
- Keyboard support. Experienced users of data-entry screens should be able to work without the mouse: tab through fields in a logical order, submit with a key, and use shortcuts for common actions.
- Sensible defaults. Pre-fill today's date, the user's branch and the most common options.
- Remember recent choices. If someone usually works with the same customers, products or locations, put them at the top.
- Help on the screen. Short hints next to unfamiliar fields, rather than a manual nobody reads.
Jakob Nielsen's widely used usability heuristics include "flexibility and efficiency of use", which captures this idea well: let expert users speed up their work while keeping the system usable for novices.
Count the clicks on the tasks that matter
List the five tasks each role performs most often. For each one, count the steps, clicks and screens involved, and the fields that must be filled. Then ask:
- Which steps exist only because of how the software was built, not because the work needs them?
- Which fields could be filled automatically from information the system already has?
- Can the task be done from one screen instead of three?
Saving a few seconds on a task performed a hundred times a day by twenty people adds up quickly. Measure your own tasks rather than relying on general estimates.
In business software, every unnecessary click is paid for by someone, many times a day, for as long as the system is in use.
Show status clearly
Users should never have to wonder whether something worked. Nielsen's first heuristic, "visibility of system status", is especially important in business systems:
- Confirm saved actions clearly, without blocking pop-ups.
- Show where a record stands: draft, submitted, approved, rejected, paid.
- Indicate progress during long operations, such as imports or report generation.
- Show who last changed a record and when.
Prevent errors, then make them easy to fix
Errors in business systems become wrong invoices, wrong stock and wrong decisions. Design to prevent them:
- Validate as people type, with clear messages next to the field, not a list at the top of the form.
- Use pick-lists instead of free text where the values are known.
- Ask for confirmation only for actions that are hard to undo, so confirmations are not ignored by habit.
- Allow corrections, with an audit trail, rather than forcing users to delete and re-enter.
- Write error messages in plain language that say what went wrong and what to do next.
Use the user's language
Screens should use the words people use at work, not the developer's terms. A clinic says "patient" and "visit", a school says "student" and "term", a property manager says "tenant" and "unit". Where staff work more comfortably in Bangla, offer it properly, including for messages, reports and printed documents.
Design tables for real work
Much business software is lists and tables. Make them useful:
- Filters and saved views for the questions people ask every day.
- Sorting and search that work as people expect.
- Columns users can choose, with sensible defaults per role.
- Bulk actions for repetitive work, such as approving several items at once.
- Export when people genuinely need to take data elsewhere.
Readable and accessible
People use business software for long periods, often on ordinary monitors in bright offices. Text must be readable. The Web Content Accessibility Guidelines (WCAG) 2.2 set a minimum contrast ratio of 4.5:1 for normal text and 3:1 for large text at level AA. Use readable font sizes, avoid relying on colour alone to show status, and make sure the system works at the screen sizes your staff actually use.
How to build good UX into a project
- Watch people work. Spend time with users doing their real tasks before designing anything. You will learn more in an afternoon than from a requirements document.
- Prototype the key screens. Test clickable prototypes with real users before development starts. Changing a prototype is cheap.
- Test with real data. Long customer names, many line items and messy addresses reveal problems that neat sample data hides.
- Review in regular demos. Include actual users, not only managers, in every demo.
- Measure after launch. Time key tasks, track errors and ask users what still slows them down.
A quick review checklist
- Can an experienced user complete the most common task without the mouse?
- Are defaults set for the most common values?
- Is it always clear whether an action worked?
- Do error messages explain how to fix the problem?
- Does the screen use the words users use?
- Does text meet contrast guidelines?
- Have real users tested it with real data?
Where RAED fits
We design business software by observing the people who will use it, prototyping key screens with them, and testing with real data before and after launch. We also review existing systems and suggest focused changes that save users time.
Sources
- Nielsen Norman Group, "10 Usability Heuristics for User Interface Design", Jakob Nielsen, first published 24 April 1994, last reviewed 30 January 2024. nngroup.com
- W3C, "Understanding Success Criterion 1.4.3: Contrast (Minimum)", WCAG 2.2. w3.org
