Product design is all about tradeoffs—and when we designed I Done This 2.0, we had a lot to consider. We added new functionality, like blockers. But we also noticed a few patterns in our user behavior data that we weren’t quite sure what to do with.
We find, for example, that a higher volume of short entries helps people feel great about their work, and it’s more interesting for their co-workers to read. Does that mean we should encourage this behavior, and cap entries after a certain number of characters?
Ultimately, we set our default in I Done This 2.0 to shorter entries, but we added an optional button to allow longer entries. We don’t want to fall down the rabbit-hole of offering too many configuration options—but we also don’t want to lose customers who find our product useful. When it comes to exact entry length, we’re passing the baton to those who know their team’s needs best—team leaders.
You must always Prioritize Product Development via Matrices. Our goal is to help teams communicate asynchronously, and we’ll always be tinkering with the best ways to achieve that.
But this probes at a bigger question. Your product has a mission. And you have to make lots of small, iterative decisions to stay on track. How do you balance competing factors like behavioral data and customer requests for the product?
It’s (mostly) about your data
Keeping your product development user-centric is key. If it’s not user-centric, it’s like your team is driving without a map. The fact is, you need to listen to your customers. The surefire way to make sure your results will be accurate is to see what users actually do.
Data measures what users do in your product, and for how long. It’s a quantitative sign that you’re (hopefully) on the right track.
Credit: Createful.com
There are a number of ways to access your users’ behavioral data. Tools like Amplitude give you detailed analytics on how customers use your product, and FullStory actually lets you record and replay user sessions. These tools are life-saving when it comes to understanding user behavior.
But even if you’re armed with great tools, you still can’t take your data at face value.
What does your data really mean?
You always need context for your numbers, and that requires working backwards. It’s great to ask yourself questions like:
- How many steps does it take a user to accomplish a task? Can we reduce that number going forward?
- How do our most reliable customers use our product? Can we make that path easier to follow for others?
- How do customers that churn use the product? What are they missing?
Above all, use data—and the context around it—to learn what your customers could be getting out of your product. You can even use it to ground your conversations with customers, since you’ll have a clear picture of how they use your product.
The customer (data) is almost always right
Looking for patterns in customer feedback can point you towards things that need to be changed. But are your data and customer feedback truly equal?
Behavioral data ≠ customer feedback
The reality is, customer feedback alone is just one part of the “user-centric development” equation. When customers give feedback, things inevitably get lost in translation. As you figure out where to go next with your product, behavioral data is salient—especially since self-reported claims are often subjective.
To quote Jakob Nielson:
Watch what people actually do.
Do not believe what people say they do.
Definitely don’t believe what people predict they may do in the future.
You can’t only react to those who cry the loudest. Sometimes, we find ourselves reacting to the noisiest customers from our support pages and social media. We constantly need to balance those requests with the rest of our customers’ needs.
Feedback is your lifeline in product design
That’s not to say you should ignore feedback from customers. After all, you’re building the product for their use!
Feedback is most effective when it correlates with your data. A user’s data may indicate one thing, but that customer’s feedback offers an explanation for it—like if they were trying to test a new feature and couldn’t do it successfully. For example, on I Done This: maybe someone logged their goals as “dones,” because they didn’t realize it was possible to log “goals.”
You can do this by engaging customers after different milestones—for example, the first time they import a CSV or invite a team member. The experience will be fresh in their minds and it’s a good time to ask for feedback via email or in-app surveys. Users may not know what they specifically want, but you can compare your data with your customer requests, and see where they’re consistent.
Look for places where your data and customer feedback overlap. Finding those trends will help you highlight what needs to be fixed, sooner.
Solve the right product design problems problems
Customers will surprise you, and they’ll highlight great things about your product that you might not have anticipated. Zero in on those as you keep developing your product.
Assuming your product functions impeccably, your users’ behavioral data should guide your product development—and show you what not to scrap—especially when it’s supported by what your most loyal customers want.
Ultimately, you need to understand what your users want from your product. It’s not just about focusing on a specific feature that your analytics shows people are using. It’s about making sure your team has all the information they need to make good decisions.