Software can be improved with user-centred design by working through a short cycle: watch people do the real work, change the parts that slow them down or cause mistakes, and test each change with the same people before and after it is built. It does not need a rewrite or a design department. For a business system the results show up as less training, fewer errors and fewer spreadsheets kept on the side.
What user-centred design means
User-centred design means designing a system round the people who use it and the tasks they carry out, involving them throughout, and checking the design against what happens in real use. The international standard on the subject, ISO 9241-210, calls it human-centred design and describes it as a repeating set of activities: understand the context in which the system is used, set out what users require, produce designs, and evaluate those designs against the requirements.
It is not the same as making software attractive. Appearance is one part of the picture, and our article on the difference between UI and UX design explains where it fits.
The GOV.UK Service Manual, which sets out how government services should be designed, defines user needs as “the needs that a user has of a service, and which that service must satisfy for the user to get the right outcome for them”. For an internal system the outcome is the job done correctly, at the first attempt, without help.
Internal software tends to be the most neglected in this respect. Customers who dislike a website go elsewhere and the sales figures show it. Staff who dislike the stock system have to use it anyway, so the cost stays hidden in slower work and quiet workarounds.
Signs that a system does not fit its users
- People keep their own spreadsheets or paper notes alongside the system. Our page on replacing spreadsheets describes where that leads.
- New starters need weeks before they can be left alone with it, and there are instruction sheets taped to monitors.
- The same mistakes are corrected month after month: the wrong customer selected, a date in the wrong field.
- The same questions keep reaching whoever supports it.
- One routine task means visiting many screens, or typing the same information twice.
- People enter the minimum the system will accept and no more.
- Customers telephone when they could have used the portal.
Most of these leave a trail in records you already hold. The Service Manual’s advice is to begin by reviewing existing evidence, and it gives analytics, search logs and call centre data as examples. In a business that means support requests, correction entries and usage figures for the portal.
Find out what users need
Watch people work. Half an hour sitting beside someone while they do their normal job reveals more than a meeting about the system. Note what they copy from one screen to another, what they write on paper, what they look up elsewhere and where they wait.
Ask about particular occasions. “Tell me about the last time this went wrong” produces better information than “what would you like the system to do”. People are poor at specifying features and good at describing what happened to them.
Treat second-hand accounts with care. A manager’s description of a process is often the official version, and what happens at the desk may differ. The Service Manual puts it firmly: “Treat any opinions or suggestions that do not come from users as assumptions that have to be proven by doing research.”
Write each need down in the user’s own terms. The Service Manual suggests the form “I need to… so that…”. For example: “I need to see which orders are waiting for stock, so that I do not promise a delivery date we cannot meet.” A need written this way can be tested later, and it does not prejudge how the screen should look.
Notice that users differ. Someone who enters orders all day wants speed and keyboard shortcuts. Someone who approves expenses once a month wants to be led through it. Describing these groups is the job of personas, covered in how to use personas.
Improve the system you already have
None of this requires a replacement. An established system can be improved a screen at a time, as part of ordinary software maintenance. These are the changes that most often repay the effort in business software.
- Put the commonest task first. If most visits to the system are to do one thing, that thing should be on the opening screen.
- Remove steps. Fill in sensible defaults, remember the last choice, and do not ask for information the system already holds.
- Replace free text with choices wherever the answers are known, so that entries are consistent and can be reported on.
- Check entries as they are made. An error message should appear beside the field, in plain words, and say what to do about it.
- Use the users’ vocabulary. Labels should be the words people say aloud, which are rarely the names of columns in the database.
- Show what is waiting. A list of “items that need my attention” saves each person from hunting for their work.
- Make search forgiving. People look things up by what they happen to know: part of a name, a postcode, an order number.
- Guard against costly slips. Ask for confirmation before anything is deleted or sent, and offer a way to undo it.
Accessibility belongs on this list. Text that can be enlarged, good contrast and screens that work from the keyboard help everyone, and the Web Content Accessibility Guidelines (WCAG) 2.2 are the usual standard to work to. Public sector bodies have specific accessibility regulations to meet, and employers have duties towards disabled staff under equality law. Take advice on what applies to you.
Decide the order of work by how often a task is done. Saving twenty seconds on something done two hundred times a day is worth more than redesigning a report that is run once a year.
Older systems are no exception. When one is being moved to a newer platform, the move is a chance to redesign the worst screens. Copying them across as they stand wastes it. That choice is part of any legacy software modernisation.
Test before and after
Before a change is built, mock it up and try it on the people who will use it. The Service Manual describes moderated usability testing as watching “participants try to complete specific tasks”, and advises the person running the session to “stay quiet” and mostly watch and listen. A handful of people is enough for each round. A mock-up can be made without specialist tools, as described in how to prototype an app without design skills.
After the change goes live, measure what you measured at the start: the time a task takes, the number of corrections, the number of support requests, the share of customers using the portal without ringing. Without the earlier figure you will have opinions about whether the change worked and no evidence.
Give users a standing way to report difficulties, such as a named person or a link on every screen, and let them see that reports lead to changes. People stop reporting problems when nothing comes of it.
Where to start
Choose the single task that is done most often in your most used system. Sit beside one person for thirty minutes while they do it. Count the screens they visit, the things they type more than once and the things they look up somewhere else. That count is your first list of improvements. Take it to whoever maintains the system and ask what the top three would cost to fix.