Last fall I attended a workshop with a group of open-source developers working on security tools. In talking about the challenges they faced in making their tools more usable, I blithely said something along the lines of “It’s important to always listen to your users, and take your cues from them.”
“But how,” replied one developer, “do you know what feature requests are the right ones?”
My first response was confusion. I was talking about user research, so a question about feature requests seemed like a bit of a non-sequitur – especially since lay users are generally more comfortable sharing problems than they are sharing suggestions for improvement (e.g., “configuring the app is hard!” rather than “please reduce the number of steps in the sign-up flow"). The developer then shared that, although his team didn’t have a lot of opportunities to interact directly with their users, they did have a form for submitting feature requests. Moreover, their more tech-savvy users were using the form a lot, to the point of inundating the team. He wanted to know how to prioritize among this deluge.
Listen for the intent underneath the request
While it is important to listen to your users and learn from their message, it’s absolutely critical to hear the intent behind what they say. To use a contrived example, imagine that a user says “You should put a purple pony on your main page. Ponies are really friendly, and I like them, and they would make me smile every time I opened the app!”
While it is important to listen to your users and learn from their message, it’s absolutely critical to hear the intent behind what they say.
While it’s undoubtedly true that this one user would find your app much improved by the addition of a little Twilight Sparkle, that doesn’t mean that actually adding an image of a My Little Pony is going to improve the experience for most of your users. Even if you got the same message from hundreds of people, you should still ask yourself: What underlying need is driving these requests?
In this example, the suggestion itself gives some clues:
- The user says that ponies are friendly. Does the user find the app unfriendly? Is there something about the color scheme, the typography, or the wording used in the app that could be changed to make it more inviting?
- Ponies are lighthearted and energizing. Does the user feel that interacting with the app is burdensome or painful? Are there unvoiced friction points that could be smoothed over to make the app more enjoyable to use?
- The user says they want to smile when they open the app. Although a pony may not be an appealing symbol for all people, is there another non-invasive way to greet the user when the app is launched?
Find deeper answers through research and analysis
Rather than view feature requests as a set of highly-divergent signals, it can help to try and group requests based on the underlying need that they speak to. If you see a lot of heat around your error conditions, consider reviewing the messages displayed in those situations to make sure they make sense to people not on the development team. If you have a lot of requests around your sign-up flow, perhaps it’s time to do some cognitive walkthroughs with real users to identify friction points. If possible, make sure that your feature-request channel offers users the possibility to enter their contact information, as it is often helpful to follow up with them afterward for more context about why they are making the request.
Keep the channels open
More generally, make sure that your team gets opportunities to interact with users that aren’t just through feature requests. Whether it’s a help forum, a user study, a questionnaire on the download page, or some other channel, the more insight you can gain into what and how users think about your product, the better equipped you will be to prioritize user-facing improvements.
If you want to talk through how your open-source security project learns about its users or prioritizes its feature requests, please get in touch!