A key component to success is effectively representing your analytic insights. Make sure your graphics present conclusions and suggest actions for users to take.
I'm a fan of data visualizations, but most people are not. I like to experience data like an art lover experiences abstract art. I enjoy staring at artfully drafted data visualizations like Charles Joseph Minard's figurative map of the French army's successive losses during its Russian campaign of 1812 - 1813.
Edward Tufte, Professor Emeritus at Yale University and noted scholar in data visualization, espouses the idea of craftily presenting data in its raw form and letting the audience contemplate its own conclusions. I thought it was a fantastic idea until I tried it on an audience of impatient executives. Data visualizations are for data-minded people -- the rest of the world wants to know what the data means. When drafting the presentation of your analytics, make it clear what your analysis concludes.
It takes more than data to reach your audience
Infographics are more popular than data visualizations because they're easier for most people to understand and appreciate -- a data visualization helps you see data, while an infographic helps you see information. A good infographic tells a story that has a beginning, a middle, and an end. It's the end that interests most people because they don't appreciate the joy of data discovery. They just want to know the point or the conclusion. That's why it's important to have your data artist design your interface more like an infographic and less like a data visualization.
Even a good data representation gets you only halfway to a well-built analytic interface. For instance, about 10 years ago I was working with a group of DBAs on a data solution that used Oracle 10g as the foundation for its technology stack. By version 10, Oracle made great advancements with its cost-based optimizer, which is the engine that determines the best query execution path. What's more impressive was the way Oracle instrumented its cost-based optimizer. With a little secret knowledge that was passed around the DBA community, you could run a special trace on the cost-based optimizer that would give you all the data Oracle used to make its query execution decision. The only problem was, as with most Oracle trace files, you needed an advanced degree in Oracle-ology in order to interpret this data. If Oracle would have extended this functionality a bit further, a wider audience could have embraced it.
Remember the DIKW pyramid when designing analytic interfaces
Even if your target audience is data-friendly, it behooves you to design an interface that addresses some altitude on the DIKW (Data, Information, Knowledge, and Wisdom) pyramid -- in fact, the higher the better. DIKW is typically represented as a pyramid with its four respective levels. In short: data becomes information when you draw meaning through analysis; information becomes knowledge when disparate pieces of information are connected for new insights; and knowledge becomes wisdom when lessons are learned over time. I'm suggesting that your analytic interface cannot plateau at the data level to be effective.
At a minimum think about what information your data is trying to convey. My speedometer just tells me how fast I'm going; however, my tachometer tells me when I'm working my engine too hard (redlining). Using red as the universal color for danger, my tachometer tells me more than my engine's RPMs -- it tells me when my engine is in danger. Carry this concept forward in the design of your analytic solution. If your product detects a heavy correlation between a certain digital behavior and churn, give the customer something more than an R-squared metric. Go a step further and suggest a course of action that might interrupt the churn.
To do this though, you may need knowledge. When you bring together various pieces of information, you garner knowledge about the subject. When I design an analytic loyalty platform for a client, I look at the total customer experience: sales, service, rewards, and anything else that touches the customer. In this way, I know how valuable this customer is to my client. Sure, they may have bought one expensive item, but what else did they buy? How often did they call customer service? Who did they refer you to? What are they saying about you on social media? You won't know this until you turn your information into knowledge. And the better you represent this knowledge to end users, the more valuable your analytic engine will be.
When knowledge intelligently marinates over time it becomes wisdom. When Dell bought Quest Software, it inherited two products that look at the health and performance of a database: Spotlight and Foglight. Spotlight identifies performance problems that are happening in the moment, like a runaway query that's currently bringing down the database. Foglight runs on your database for a period of time to identify more chronic database problems. For me, Foglight has more wisdom than Spotlight and represents a more evolved data solution. If your analytic solution can show and advise its users based on past knowledge, it will accelerate their learning curve. This is the high-bar in analytic interface design.
Most people don't care about data as much as you do, so don't confuse them with an interface that looks like a logic puzzle. Your graphics should represent information, knowledge, or wisdom if possible but not purely data. Make conclusions explicit and suggest actions for your users to take based on the analysis.
When I stare at a Matisse or Kandinsky I develop insights and inspiration, while my wife just gets a headache.