Someone on the team drops a screenshot into the chat with a grimacing emoji. A one star review, posted last night. It names the new booking screen you shipped two weeks ago. Confusing, slow, whoever designed this has never used a phone. You read it four times before lunch, and each time it stings a little more.
Public criticism of your work feels different from a comment in a code review. It is written by a stranger, in anger, where anyone can see it, and you cannot reply as yourself. It is easy to either dismiss it completely or let it ruin your week. Neither helps.
Start by separating the tone from the content. Angry reviews are often written in the moment of frustration, and the insult is rarely the useful part. Underneath it there is usually a specific event. Here, someone found the screen confusing and slow. That is worth taking seriously, even if the last sentence is not.
Then look at one review as one data point, not a verdict. Read the other recent reviews and the support tickets. Check your analytics for that screen. How many people start a booking and give up? Has that number changed since the release? One loud voice can point at a real problem, or at one person's bad afternoon. The numbers help you tell which.
If you can, try to reproduce what they describe. Use an older phone, a slow connection, a larger text size. Many complaints about slowness or confusion come from conditions the team never tested.
Do not reply defensively, and in most companies you should not reply at all unless replying is your job. Pass it to whoever handles store responses, with a note about what you found. A calm public answer that says what is being fixed can win a user back.
And remember that most satisfied people never write anything. Reviews lean towards the frustrated. Treat this one as a free bug report from someone who cared enough to complain, take what is useful from it, and let the rest go.
– Asael Shinder
Top comments (0)