In my work as a decision science oriented software developer, I often explain to my clients that what they really want is a big green button that, when pressed, gives them the answer to the question they are currently wrestling with—a Magic 8-Ball that dispenses specific, data-driven advice.
The challenge is, how close I can get them to that.
I often find myself frustrated by how data is presented to users. There’s an unholy obsession with visual components such as charts and grids. And it’s a conspiracy between the clients and the software developers.
Clients often ask for specific types of user interface components—often based on what they have seen in other applications (such as the system being replaced). Charts are a fairly common request. They look good, convey a lot of data and, after all, a picture is worth a thousand words.
Software developers like charts, as they are off-the-shelf components that add a splash of color to an otherwise bland screen. You get a lot of (often frivolous) functionality for very little effort.
The only problem is that a chart is actually an analysis tool. You use it to visualize the complex data and draw conclusions. However, what clients really need are those conclusions. And why are they having to tease them out of a chart when they have surplus computing power at their finger tips?
Charts are everywhere. They are so ubiquitous that we don’t stop to think about whether they are actually adding any value. Next time you see a chart, pause and try to work out what it’s telling you.
I see charts all the time in the Economist (for example), and the conclusions that the chart is supporting are stated in the accompanying text. Deriving them from the chart is usually a non-trivial experience—even for someone who works with data and already has the answer (from the text). It’s not rocket science, but it’s time that I don’t need to waste when I can just be told the answer.
Whenever I see a chart in a proposed user interface design I immediately ask what conclusion needs to be drawn from the chart. Growth in the last quarter? Just show me the number. Shifts in demographics? Tease out the salient points for me.
In most cases, the presence of a chart is a product of lazy thinking. We have some data. Data is hard to analyze. Let’s just throw it at the screen and move the problem downstream to the user.
This just isn’t good enough. Everyone knows knowledge workers are drowning under a deluge of data. Reformatting it just isn’t acceptable. We need to mine it for insight. Summarize it so that busy users get the answers they need with minimal effort.
This isn’t to say that charts are always bad. But, the abuse of them is widespread. I’d say that in the majority of cases more could be done to assist the user. Remember, that most users are not going to be professional data scientists, so handing them raw data and asking them to make sense of it is a dangerous proposition.
Of course, tools like R have many charting options. In that case, it makes perfect sense. R is a tool for data analysts and so are charts. It’s when we take those charts and hand then off to general business users that sanity leaves us.
Charts aren’t the only user interface component that is widely abused. The amount of times I’ve seen a web grid employed as a feeble search tool…
So, whenever you come across a proposal to use a user interface component that throws a lot of data onto the screen, think—can you do better?
If you are interested in the issues raised in this article, you may like to review the following Learning Tree courses