“What feature should we build next?”
It’s a common question from product owners, and it’s not always easy to answer. The feature backlog is a mile long — which one will give you the most bang for the buck? Which one do customers want the most?
There’s many ways to measure customer demand for a planned feature: user surveys, public voting, support feedback, social media. But all these approaches have a common shortcoming: they rely on users telling you what they want, rather than showing.
And the cardinal rule of user feedback:
It’s tempting to rely on tools like surveys to gauge customer interest. It’s simple, direct, and obvious: just ask them what they want.
But users aren’t always consciously aware of what they want or able to clearly articulate what that is. As the apocryphal Henry Ford supposedly said:
“If I asked people what they wanted, they would have said a faster horse.”
Economists refer to this phenomenon as “stated vs. revealed preferences”. It’s the idea that captures contradictory behavior, like when someone says they want to lose a few pounds, but goes back for a second helping of dessert. Their stated preference (to lose weight) is contradicted by their true, revealed preference (to eat dessert).
So revealed preferences help show us the customer’s true intent, but how do we figure out what that is? Since we can’t simply ask, we need to be creative.
Let’s say you are building a CRM SaaS product that helps salespeople track leads and close opportunities. You’ve heard some requests from customers to include an in-app dialer that lets salespeople place phone calls directly from the app. How can we know if these requests are stated or true preferences?
Use pressure indicating UI.
What is a pressure indicator? It’s a UI element that helps capture user preference by allowing users to reveal it with intentional action. The simplest example might be something like this:
The key is what happens when the user clicks on the “Call Frank” button: we fire off an analytics tracking event, and show a modal like this:
Note that we didn’t build the full, complex feature of an in-app dialer. All we did here is add a button and a modal — a trivial effort by comparison.
The goal here is to sort out whether the in-app dialer is a feature that users actually want vs. what they think they want. By providing an avenue for users to express intent through their actions rather than their words, we can be far more confident that the results reflect reality.
Why are these called “pressure indicators”? Because the level of activity you see on something like the “Call Frank” button gives you a sense of the force of user preference behind it. If you add that button and are overwhelmed with users attempting to use it, it’s a strong indicator that lots of users are bumping into that particular boundary of your product’s feature set.
In the above example, we captured the intent of the user to use the in-app dialer feature. This is a huge improvement over simply asking users if they want it — but we can do even better.
In that example, all we captured was binary intent: yes, they tried to use the feature, or no, they didn’t.
With a subtle tweak of the modal, we can capture more:
By offering to notify users when the feature is ready, you get two important benefits:
Capturing revealed preferences is tricky, because users must think that they have a chance to use the feature — otherwise, you end up capturing stated preferences instead.
The risk here is user frustration — in our example above, if a user planned to call Frank through the app after seeing the button, they might get frustrated if they attempt to place the call via the apparent in-app dialer. Instead they are greeted with our modal and have to fumble to find the phone number and manually dial.
There is no simple rule for this, but in general, try to keep a few things in mind:
Pressure indicating UI is all about approaching product design from an intentional, focused perspective. By understanding users’ true preferences, we can build the product they need that makes their lives better, with fewer false starts for our teams.
Want to chat more about how to add pressure indicating UI to your app, or product design in general? Feel free to reach out on Twitter!