“The website is slow” sounds like a technical problem. It is also the beginning of a business conversation.
A developer might immediately look at database queries, caching, or server resources. Those may be relevant, but the first useful question is more basic: slow for whom, during which action, and with what consequence?
Translate the complaint into a journey
Ask the person reporting the issue to describe the last time it happened. Were they opening a product page, searching a catalogue, submitting a form, or waiting for an administration screen? Did the page eventually appear, or did the request fail?
A sales team concerned about checkout delays may need a different investigation from an editor waiting for a large media library to load. Both matter, but they affect different users and workflows. A screenshot, approximate time, device type, and steps to reproduce the behavior can help the technical team begin.
Do not ask a client to diagnose the cause. They can explain what they experienced and why it matters; determining the cause is part of the investigation.
Agree on what improvement would mean
“Make it faster” is an understandable request, but it does not tell the team when to stop. Identify a representative action and a way to observe its current behavior. The team might measure a page load, an application response, or the time needed to complete a specific administrative task.
Choose the measure with the client’s concern in mind. A page can return an initial response quickly while an essential interaction remains unusable. A server-side measurement may help find a bottleneck without describing the full experience in a browser. Explain what each measure can and cannot show.
A target should reflect business needs, available evidence, and constraints. Avoid promising a result before the team understands whether the delay comes from the application, a third-party service, the network, the device, or a combination of factors.
Explain options in terms of trade-offs
Suppose an investigation finds that an expensive search runs repeatedly on a PHP application. The options could include changing the query, storing some results temporarily, changing the user interface, or investigating infrastructure. Each has different costs and consequences.
Describe those consequences in language the decision-maker can use. Temporarily storing results may improve response time but require a rule for when information is refreshed. Increasing server capacity may be quick to test but introduce recurring cost. A larger redesign may solve a broader issue while delaying other work.
These are possibilities, not universal fixes. Present the evidence supporting each option and identify what remains uncertain.
Close the loop with the people affected
After a change, compare the same representative action under reasonably comparable conditions. Ask the original users whether the experience has improved. If it has not, share that result and decide what to investigate next.
Good technical communication does not require removing all technical detail. It means connecting the detail to a decision: what users experienced, what the team found, what changed, and what the organization can do next.
Related
the-website-is-slow-a-developers-guide-to-the-first-business-conversation
