The most reliable way to get user feedback for your app is to watch people use it, and to do so at three points: before it is designed, while it is being built and after it goes live. Asking people what they think comes a distant second. People are polite, they forget the details, and they describe what they would like instead of what they do.
If the app is an internal business system or a customer portal, you have an advantage that the makers of consumer apps lack. You know exactly who your users are, and you can sit beside them.
Before you build: watch the work as it is done now
The first feedback worth having is about the current way of working, whether that is a spreadsheet, an old system or a paper form. Spend an hour with each kind of user while they do the job, and note:
- the steps they take, in order;
- anything they copy from one place and type into another;
- the notes stuck to the monitor and the private spreadsheet kept on the side;
- the moments they have to ask a colleague.
Ask “show me the last time that went wrong”, not “what would you like”. The first question produces facts. The second produces a wish list.
Include the newest member of staff and the most reluctant one. The first still remembers what was hard to learn, and the second will tell you what everyone else has stopped noticing.
For a customer portal the equivalent is to read what customers already send you. The calls and emails your staff answer every day, asking where an order is or for a copy of an invoice, are a ready-made list of what a customer portal should do.
Write up what you find as tasks, and group the people into types of user. Our article on how to use personas covers that step.
While it is being built: test with five people
A usability test is simple. Give a real user a realistic task and something to try it on, then watch without helping. The thing they try it on can be a clickable prototype or an early working version, a distinction explained in wireframe, mock-up and prototype.
You do not need many people. Jakob Nielsen of the Nielsen Norman Group, in his article “Why You Only Need to Test with 5 Users”, argued that five users reveal most of the usability problems and that the budget is better spent on several small rounds than on one large study. He adds a qualification that matters for business systems: where there are distinct groups of users, such as dispatchers and engineers, test a few people from each.
A few rules make the difference between a useful session and a wasted one.
- Set a real task. “A customer has rung to move Thursday’s visit to Friday morning. Please do that.” Not “have a look round and tell us what you think”.
- Stay quiet. Do not explain, prompt or defend the design. If you have to explain a screen, the screen has failed, and that is the finding.
- Ask them to think aloud. What people expected to happen is as useful as what they did.
- Record what they did. Where they hesitated, what they clicked first, where they gave up. Opinions about colours can wait.
- Have a developer or designer watch. Seeing a user struggle persuades in a way a written report does not.
Clear the obvious faults before each round. A tester who meets a crash will report the crash and nothing else.
After the session, fix what you found and test again with different people. The second round shows whether the fix worked and uncovers the problems the first ones were hiding. If your supplier shows you working software at intervals during the build, those are the natural moments for a round.
After launch: make reporting a problem effortless
Staff will tell each other about a problem long before they tell you. The aim after launch is to make telling you take ten seconds.
A feedback link on every screen. A short box for a comment, sent with the details nobody should have to type: which screen, which user, the time, the browser or device. It has to arrive somewhere a named person reads it.
Someone on the floor. In the first week, have a person who knows the system sit with the teams using it. Most of what they hear would never have been written down.
The support log. Record every question and fault, and sort them by cause. The same question asked three times is a design problem, not a training problem.
A short survey, used sparingly. The System Usability Scale, devised by John Brooke in 1986, is ten standard statements that produce a score out of 100. Its value lies in repetition: ask the same ten after launch and again six months later, and you can see whether changes have helped. Add one open question, such as “what slows you down most?”.
The people who talk to customers. For a portal, account managers and customer service staff hear the complaints first. Ask them regularly. If the app is published in the public app stores, read the written reviews as well as the star rating.
What the system can tell you without asking
People report what annoys them. They seldom report what they have quietly stopped using. Usage data fills that gap:
- which screens and features are used, and which never are;
- where people abandon a form part-way through;
- how long a common task takes from start to finish;
- searches that return nothing;
- error messages, counted by screen.
Session recording tools go further and replay what a user did on screen. Microsoft Clarity, for instance, records sessions and produces heatmaps of where people click, and Microsoft offers it free of charge.
Treat this with care. Usage data and recordings are personal data, recording how staff use a system is a form of monitoring, and a recording may capture customer details shown on the screen. Tell people what is collected and why, mask sensitive fields, and on a customer-facing site check the rules on cookies and consent. Take advice on your data protection obligations before switching any of it on.
Turning feedback into changes
Feedback that leads nowhere soon stops arriving. Give it a process, and keep the process light.
- Put everything in one list with one owner, whatever the source.
- Sort each item as a fault, a usability problem or a request for something new. They are paid for differently. A fault is put right, a usability problem is an improvement, and a new feature is a change to the scope that should be quoted.
- Rank by how often it happens and what it costs each time. A small irritation met two hundred times a day outranks a serious one met twice a year.
- Look for the problem behind the request. “Add an export to Excel” usually means a report is missing. Building what was asked for is sometimes right, and understanding why it was asked for is always worth the time.
- Tell people what changed because of what they said. A line in a team meeting is enough. Nothing does more to keep feedback coming.
Set aside time and budget for this before launch. The first month of real use always produces a list, and a support arrangement that includes small changes means the list gets dealt with while people still remember raising it.
If you have a system in use today, you can start this week without building anything. Choose its most used screen, watch three people work with it for ten minutes each, and write down every hesitation. You will finish with a short list of changes and a good idea of how much feedback you have been missing.