Feedback for developers: 5 essentials

One of the primary reasons why feedback fails to be acted on is because it is not specific enough. Feedback for Developers should be clear and concise, and it should identify the issue at hand without the need for back-and-forth communication.

Creating feedback using visual medium (think annotated screenshots, video and even full session replays) is the easiest way to avoid unclear feedback that developers find difficult to interpret or replicate to achieve what the user experienced. If your Developer can’t recreate the bug, the user feedback is going to be met with a ‘cannot recreate. Ticket closed’ response. That’s only going to lead to the bug remaining and resurfacing later down the line taking more developer time away from producing product improvements. Visual feedback gives developers the exact picture of what element is out of whack, or what steps were taken to experience the bug without guesswork, leading to faster remediation times and less frustrated developer teams.

Another reason why feedback fails to be acted on is because it is not timely. Surveys, user groups and email based feedback is often delivered at a time when users aren’t hands-on with the product. Creating opportunities for individuals and teams to submit feedback directly at the time of interaction with your application or website increases the relevancy of feedback as well as its clarity. Helping developers triage bugs and improving the quality of feature request oriented feedback.

The volume of feedback for Developers to action is also likely to increase when users are provided an intuitive means to deliver feedback quickly as the ‘A-HA’ moment strikes or the code error rears its head. By categorizing and prioritizing this increased feedback, it’s extra validation for developers that their feature build is going to find that perfect market fit that drives adoption and utilization. 

Feedback for Developers also needs to be consistent in order for it to be effective. If an individual receives conflicting feedback from different sources, software teams and developers will likely become confused about what they are supposed to do creating back-and-forth communication that adds to the length of development cycles, or worse still, feature builds will be out of sync with what users actually want.

This is especially impactful for teams using a Waterfall Deployment methodology where stages need to be finalized prior to moving forward. Utilizing a single feedback collection source, like a feedback portal to capture and prioritize creates a consistency in format and capability, especially paired with the visual elements raised in point 1.

Developers don’t need the kitchen sink thrown at them when it comes to new requests for features and fixes. Categorize feedback into groups, stake rank the most common requests or bug fixes and deliver the feedback that matters to the people that need it. Not all developers need to know about the UI feedback, not all developers need the bug fixes.

Delivery of curated user feedback keeps it relevant, and relevancy creates action. In order to filter it, developers or Product Managers leading the user feedback initiative should first categorize the feedback into its respective groups, think UI, bugs, integrations, feature requests etc. and stack rank suggestions within each category. Taking the most supported ideas or the most commonly reported bugs helps align which feedback should make it to the roadmap and into the next sprint, and which can be left for a later time.

This categorization and stack ranking can be powered by users directly if software teams provide a portal for users not only to submit their ideas, but also view other suggestions from fellow users, and essentially like or upvote suggestions for features they’d like to see also. Doing this allows teams to take maximum advantage of users and save time combing through multiple disjointed pieces of feedback. 

Another advantage is users LOVE IT! Seeing what user generated suggestions are rising, helps inform the community of your potential roadmap and makes them feel invested in your product.

If you’re a Developer in an organization, you have your existing toolset and workflows already established. User feedback needs to be delivered to these locations without developers having to go to a secondary platform or tool or inbox, spreadsheet or however you’ve done it in the past. Because you’ve followed our helpful steps in points 1-4, your user feedback will be clear, consistent and ranked.

Now it’s time to put the highest priority feedback at the fingertips of your developer team to work on. That may be pushing user feedback into their Jira board, or Asana, Basecamp or whatever, but ensure it gets there. Moving this into production workflows doesn’t need to be any extra effort for those in charge of handling the user feedback either. Modern tooling should allow you to integrate into the common tools you’re using. If they don’t, consider moving to one that does to streamline the feedback process and make your life simpler. At least submit your own user feedback and ask for it.