My coworker Kelly shared a fantastic lesson recently:
Tell me the problem, not how you think I should fix it.
This is really much harder than it seems at first glance. While talking with users, I often end up with all sorts of suggestions about how we could improve our products. Add a feature, change the layout, remove a roadblock, etc. Even if a user didn’t make the suggestion explicitly, I sometimes come away from an interaction thinking, If only we did this instead of that …
It’s really easy to think you know the solution to your problem. If I had a penny for every time I told a developer or designer, “Our users want X,” or “We could resolve the issue by doing Y,” well, you know. But the fix you come up with might not be the best fix for everyone using the product, or even the best fix to help you reach your own goal — and pushing for minute fixes can also mean missing out on fixes you can make to the bigger picture.
Slowly, I am learning to recognize that instinct to come up with a fix and refocus on identifying the problem. Here are some things I ask myself to help with that:
- What assumptions did we make when designing the product about how it was going to be used, and what assumptions is this user making about how the product should work? Where do those assumptions clash?
- What was the user’s goal, and where did the product fail to help them meet that goal?
- What patterns or trends have I seen recently in the problems our users are telling us about (or the fixes they are asking for) that might indicate a bigger breakdown?
With those questions in mind, I can engage the people who use our products in conversations about the problems they are encountering, and communicate those problems to the people who create our products. And I’m happy to brainstorm and offer suggestions when it’s helpful, but unless I start by communicating the problem, we are all missing an important step along the way to the solution.