Managing & Implementing Feedback (Tool / System / Process)

Anyone who's been responsible for a tool, a system, or a process has had to deal with 'user' feedback along the way. I touched on People being the center of any initiative in my previous article (link), and dealing with their feedback ss probably one of the most challenging aspects of being the lead on a program or initiative.

Why?

Well, most likely the loudest feedback you get will be negative and it's easy to get disheartened, disregard it, or react too quickly before you analyze and understand it. The happy folks are usually a lot quieter. Maybe they'll respond to a survey or drop a kind note, but more often they simply get on with their work! So how do you sort through the feedback and understand what to action, what not to, and what to prioritize first?

My framework for this can largely be summarized into the following key steps:

1) Make you analyze and fully understand the 'why' behind the comment.

2) Understand the 'how' to address the comment that serves the overall goal of the initiative and addresses the 'why' of the commenter.

3) Implement 'right'. Timeliness is important, but more important is actually solving the issue.

4) Communicate what was done!

Let's dive into each of these in a bit more detail.

Analyzing and Understanding the 'Why'

Every piece of feedback has its own story as every 'user' has their own unique background and experiences that color their opinion and how they utilize what you've provided them. It's important to engage with them and understand their perspective on things and why they have commented as they did!

For example: Recently we introduced some new functionality in a tool which replaced a mega-Excel sheet which had a multitude of columns. For quick visibility of all the data and recognizing a wide variety of screen sizes and resolutions, the digital document was set to use a responsive font and column sizing so that the end-user didn't have to scroll at all. For most users this was no problem and appreciated, but for a small subset of users, it was a disaster and user feedback was simple 'I won't use the tool, I can't read it'. Physically they could not read the text and since it was 'responsive' it did not react to zoom as a normal document would. The fix? More on that below.

Other times, the request might stem from something as simple as missing training or misunderstanding what something does. Maybe a little helping hand is all that person needs, but first you have to understand 'why' they're having that comment in the first place!

To summarize... get to the bottom of why someone made the comment BEFORE you leap to making a change!

Getting to 'How' to Address the Feedback

Remember our user from the previous section who couldn't read the text in the system? After some back and forth, the fix was to implement a 'zoom' functionality that resized the fonts, set them so they'd be able to be further zoomed with the browser settings, and could be reset back to the all-in-one view on demand. Result? Happy users on both ends as folks who didn't need to do the extra clicks were happy and those who needed a little larger font were able to get that. Even better would have been to implement a preference for this, but the time to implement that vs implementing a button was dramatic! Better to get a fix in place quickly vs dragging it out, especially if the fix gets them using the tool again when they'd dropped it before.

Depending on the situation, rapid iterations and feedback loops with the individual (tested against others mind you!) helps making sure that the 'how' of implementation is actually going to solve it. Don't take the feedback and go into a dark room and dream up something without testing it with the affected people. If you do that, you run a higher change of missing the mark and further disenchanting your users.

Other times, the request might not be something that should be implemented. People might misunderstand what to do, have missed training, or simply like how they do it better. Situations like this require thoughtful conversations with the individual to get to the root of it and might drive changes to your Organizational Change Management program if it's a case of internal resistance to something new or they might be as simple as lending a helping hand showing how to do something!

Implement 'Right'

Quick implementation is important, but it's also a double-edged sword. Do it too quickly and you risk missing things or having to spend more time to fix it again. Do it too slowly or over analyze the problem and it's likely to fester.

For example: Conflicting information was provided by a client between their verbal, written, and system-wise extracts. The team scrambled for a 'quick fix' thinking they understood the problem, but this resulted in generating thousands of items that later needed to be modified for a 'full fix' after it was really understood. In the time between the identification of the problem and the 'full fix' not only was technical debt incurred in terms of configuration and code that needed to be unraveled, but communications with the project team using the tool became challenged due to multiple course corrections. In this case, it's essential to step back to the 'why' and 'how' of the above and take a little extra time to make sure it's implemented 'right'!

While failing fast or rapid iteration has it's place, the methodology needs be carefully used so that people don't go through change fatigue or get frustrated by something not fully working each time they use it.

To me, the way to balance speed and the 'right' fix is clear and open communication between parties involved. Make sure the problem is understood to a point of 'good enough' for the commenting party and that the proposed solution will actually fix the problem AND fit within the overall program objectives. From that point, move quickly, but make sure that expectations are set with the commenting party on how long it'll take to implement. Don't overpromise and underdeliver! Be open, people will generally be much more collaborative when they know you're working to fix their problem, even if it ends up taking a little longer than originally desired.

Communicate

So you've heard the feedback, had your conversations and understood 'why', figured out 'how' you'll address it, got it implemented - now what?

Release notes (if software) or functional updates (such as procedures) are useful to communicate and reinforce initiative mission points and also that feedback was received and incorporate.

Don't forget this last step to communicate that we got your feedback, heard you, and have turned out changes (or not)! It's an important closure on the cycle.

Wrap Up

Hopefully this article helps you navigate the muddy waters of user feedback! I'm curious to hear your thoughts? Am I off base or have you got some good suggestions of your own? Look forward to hearing in the comments.