(Don't panic don't run away don't toss an innocent bystander in front of the problem.)
This is the kind of problem report that is probably going to end up being a bit angsty. But why is it so scary?
- It's completely subjective. What the reporter sees as "sluggish" might seem "just fine" to you (or someone else).
- There's no clear goal. If it's sluggish (read: too slow), then what's "snappy"? What is fast enough? How do we know we've fixed it?
- Even if you get it fast enough, it's still pretty high risk that there's an environmental factor on the user's end that will make it continue to appear slow. For example, if their internet connection is slow, then it might still appear sluggish, no matter how fast we make our web application.
So, given that we've decided not to panic or throw innocent team mates at the problem, how can we handle these types of problem reports?
- Get more information. Understand what "sluggish" means to the user. Asking them is surprisingly effective.
- Discuss what you did rather than what the user will see. Since we don't get to say it's fixed - the customer does - we should say that it's better or that we've seen improvements.
- Establish open lines of communication. This isn't always possible, of course, but if it is, then it both helps the user engage with you and makes the whole interaction friendlier.
Certain problem reports are scary. But they're handle-able. So don't run away, handle it.