This is a story of a customer psychology analysis. It led me to choose less precise language in a product UI, and achieve better user experience.
It started when my dev partners found an internal API limitation in a web app we own. This API limitation was causing a data visualization dashboard feature to throw error when the user’s query results have more than 300 data entries.
It would be very expensive to lift that API limitation, so as the PM I needed to investigate whether this bug is worth fixing. Site telemetry data gave me some answer: I predicted that less than 0.01% of users could run into this issue, on a very infrequent basis. So I decided to not fix it. Instead, we will display an error message explaining the situation to customers.
Stripping away some details, I designed the error message to be: “If you have more than 300 data entries, this dashboard may not work. If so, please report issue to us.”
Seeing this, one of my dev partners asked me during design review: “Ellery, why would you use the phrase ‘may not work‘ instead of ‘will not work‘? Given the known API limitation, isn’t it more accurate that way?”
I explained my reasoning, an analysis of customer psychology: this design was made with a hypothesis that customers will hardly ever run into this issue, but if it’s causing customers problem more frequently than we thought, we should know that. The easiest way to know is to have customers to report problem to us (building extra telemetry to track this error would also be expensive).
Saying ‘this may not work’ motivates customers to report issues, because it sounds like we will fix them (and that’s true). Saying ‘this will not work’ makes users think it is pointless to report issues anyway, since it is already a won’t-fix.
In this scenario, even though ‘may not work’ is less precise than ‘will not work’, I believe it creates closer customer-product relationship and promotes better user experience in the long run.