I generally sit in the role of user research, listening to user’s stories and needs. Ideally the product team joins the research activities as they are happening so that they can hear the information first hand instead of playing a game of telephone. Listening directly to users also builds a level of empathy that humanizes them and their the problems.
In turn I take those research findings and advocate for users to help shape a product in a way to solve their (relevant) problems. Sometimes the product team discounts the research findings and recommendations. Either they feel it’s not representative of the larger user base, potentially because they are already dug-in on the direction they want to take the product. This is where things get interesting.
Empathy Building Tip: sit in the role of the user for a product that you use (or want to use) and provide feedback to their team. It’s an enlightening experience.
Recently I reached out to a plugin developer to provide additional feedback on a feature request that was already under discussion. The vibe on the thread so far was the developer was not sold on the need. I jumped in to add my 2-cents.
In the process of the online exchange I think gave the impression that I was an extreme novice on the entire topic from all aspects (when in fact it was one smaller piece I was less confident about). Ultimately I was trying to convey that if you look different types of websites, their needs are different compared to the traditional “blog”. As a result the features that one type of site would need supported in the plugin may be less important to other types of sites. It felt like the developer was advocating for his perspective without really hearing (or asking the questions) about what I was trying to achieve.
In written communications these conversations can be difficult and something gets lost in the translation. My attempts to indicate usage expectations felt like they were discounted until I mentioned that they were based on stats from an existing project, not just something I was making up.
In the end I’m not sure if the developer will take up the feature request. It’s completely possible that the type of website that I was hoping to support with his plugin is outside of the scope of where he wants to take his project, and that’s fine. Just communicate those limitations upfront while avoiding trying to tell your users that they don’t know what they’re doing (or focusing on the wrong thing). Also, communicating those limitations, or maybe call them covered scenarios, saves everyone a lot of time and headaches.