Sooner or later someone says it: "The tool is slow." It is the most common complaint about internal software and one of the hardest to act on. Slow compared with what? Always, or since Tuesday? For everyone, or only for the person who sits next to the printer?
Without answers, the complaint goes to the developer, who cannot reproduce it and replies "works for me". The staff member concludes nobody listens. This article gives a short routine that turns a vague complaint into something a person can fix.
Step one: ask four questions
Before measuring anything, ask the person who complained. It takes two minutes.
- What exactly were you doing? "Opening the order list", not "using the tool".
- How long did it take, roughly? Three seconds and thirty seconds are different problems.
- When did you notice it? Always, since a certain day, or at certain times such as Monday morning.
- Where were you? Office, home, a branch, on a phone. Which device and which connection.
Write the answers into the same place where you collect other support questions. One complaint with answers is worth ten without.
Step two: measure three things
You do not need monitoring software. A phone stopwatch and a colleague are enough for a first look.
1. How long does the action take? Repeat the exact action three times and write down the times. One slow attempt can be bad luck; three show a pattern.
2. Is it slow for everyone? Ask a colleague to do the same action at the same time, ideally from another place. If only one person is slow, look at their device or connection. If everyone is slow, look at the tool or the server.
3. Is it slow every time? Try again in the morning, at noon and late in the afternoon. Slowness that appears only at busy hours points to load. Slowness that appears only after a big import or a month end points to the amount of data.
The result is one line: "Opening the order list takes about 12 seconds, for two of two people, in the morning and in the afternoon." That is something a developer can work with.
Step three: find the likely place
Most slowness comes from four places. The measurements above usually show which.
- The screen. The page tries to show too much at once, for example thousands of rows in one list. Typical sign: slow for everyone, grows over time as data grows. Typical fix: show a page at a time and add search and filters.
- The data. A search or report has to look through a large amount of data without a suitable index, or a report calculates everything on demand. Typical sign: one specific action is slow, always. The MDN performance overview and the web.dev guide to Core Web Vitals describe how teams measure what users feel; your developer will know the details.
- The network. Slow only from certain places, or only on a phone, or only when many people are online. Typical fix: reduce what is sent, or fix the connection in that location.
- The device. An old computer, a browser with many tabs or extensions, a nearly full disk. Typical sign: slow for one person, everywhere in the tool and in other websites too.
You do not have to be certain. A good guess narrows where to look first.
What "fast enough" means
Without a target, improvement never ends. Research on how people experience waiting has long suggested that around one second is where users still feel in flow, and around ten seconds is where attention starts to wander; the Nielsen Norman Group summary of response time limits explains these limits. Use them as a guide, not a rule.
Then decide per task. Opening the daily list used fifty times a day should take a couple of seconds. A monthly report that takes a minute may be perfectly acceptable if the screen tells people it is working. Write the target next to the task: "Order list opens in under 3 seconds with up to 5,000 orders."
Who fixes what
Slow tools stay slow when everyone assumes someone else owns the problem. Agree this once.
| Cause | Who looks at it |
|---|---|
| Screen or data | The developer or supplier of the tool |
| Network or location | Whoever looks after the office network or the internet provider |
| Device | Whoever looks after laptops and phones |
| Unclear | The tool owner, who asks the others in that order |
Name one person who receives all "slow" reports and checks that the four questions are answered. That person is not expected to fix anything, only to route it and report back. If you already have a way of showing errors to staff and routing the technical detail, use the same route.
Tell people what happened
When the cause is found, tell the person who complained, even if the answer is "it is your old laptop" or "we will fix it next month". An unanswered complaint is the reason staff stop reporting and start working around the tool.
Common mistakes
- Starting to optimise without a measurement. Time is spent on the wrong place.
- Testing only on the developer's fast machine and good connection. Staff do not work there.
- Treating one slow moment as a trend. Repeat before you conclude.
- No target. Nobody can say when the work is done.
- No owner. The complaint circulates and nothing changes.
A first step
Next time someone says the tool is slow, do not forward the message. Ask the four questions, time the action three times, ask one colleague to try it, and write the one-line result. Send that line to whoever should fix it.
Sources
- MDN Web Docs, Web performance
- web.dev, Web Vitals
- Nielsen Norman Group, Response Times: The 3 Important Limits
- This article is a planning aid. The examples and numbers in the examples are illustrative. No client results are claimed.