Feedback: How to Ask For It, Evaluate It, and Use It
By: Joshua Smith
Tags: Data Visualization, Design, Feedback, Critique

Asking: Describing your goals for better feedback

I’ll often see a viz posted on Twitter with a short plug/description and then the quick note: “feedback appreciated”. After several perspective pieces on the appropriate time and place for feedback, the community has more commonly adopted a mentality of signaling whether or not they want feedback. However, this simple notation fails to give the evaluator any guidance on how to give feedback.

For example, let’s take the commonly-criticized choice of red and green colors. Assume I’ve chosen to use them in a viz because my audience is in retail, red and green are commonly accepted indicators (and often so culturally ingrained, e.g. “We’re in the red”, that users absolutely demand them). If I post this viz with red and green colors, and ask for feedback, I will most certainly get some feedback that I shouldn’t use those colors because of accessibility issues.

But, as I stated above, I chose the colors for a specific reason. There are plenty of ways to use red and green that get around accessibility issues, such as tweaking the saturation and luminosity so that the colors are still distinguishable for red-green color vision deficiencies. But, without providing my evaluators more context, I’m putting the onus on them to reverse-engineer my goals.

But what if I had asked the community, “Hey — my users are demanding I use red and green to indicate good and bad, and those colors carry an organizational cultural meaning that is immediately recognizable to users, and the culture will be difficult to change. What do you recommend?”

The additional context helps my evaluators solve the right problems. By giving them some insight into my design strategy, they can provide feedback that gets me to my end goal.

We can find some well-structured asks for feedback in the Data Visualization Society’s Slack channel devoted to feedback channel, #share-critique. There’s a common form used to ask for feedback, which you can see Chris Love (Tableau Zen Master) using below:

Notice how much context is provided here. While this doesn’t capture Chris’ entire design strategy here, these are really key elements: the goals and the audience start to describe the experience he wants his piece to create. Add in the ask for specific feedback, and what stage he is in the project, and you’ve got a much better starting point for more refined feedback.

While I really love this format because it’s short and simple, I think there are some additional elements we can provide when asking for feedback that can further refine the feedback we get, and even draw out new ideas from our evaluators. There are three things that can help you describe your design strategy to potential evaluators:

Describe your target audience. If you’re looking for a broad audience, you might need to work from a lower-level data literacy. However, if it’s a chart for the American Statistical Association, your users are going to be much more familiar with a variety of visualization techniques and advanced methodology. This information can help evaluators refine their thoughts to fit your users. Describe the experience you’re hoping to create. What do you want people to feel when they engage with your viz? Is this a topic that you want to stir excitement? Is it a morose topic that should generate compassion? Or perhaps you want to create a sense of outrage over an injustice. The emotive reaction to our work is an important, but under-considered, aspect of data visualization. Describe the key takeaways — the “story”, if that’s the term you prefer. What do you want them to learn? Should this drive some action on the part of the users? What opposing views are you competing against? What should your users remember when they recall your visualization?

While these three items don’t completely describe your design strategy, it offers a great starting point. This information allows evaluators to ensure their recommendations drive toward your goals, rather than generic best practices.

However, even if we provide this information, we shouldn’t blindly apply feedback (even from DataViz celebrities); we need to evaluate the evaluation.