We are huge admirers of Stephen Few, a world leader in the field of data visualisation. we were delighted when we, at last, managed to attend one of his workshops.
Although I have read his books and am conversant with his brilliant design philosophies, it was a great experience to (re)learn all about visualisations from the master himself. He makes the techniques and fundamentals sound so simple, yet I know from experience they can be so difficult to implement in practice.
I have designed some good but also, in all honesty, some atrocious visualisations and dashboards over the years. When I started, I approached these visualisations as a ‘thing to be done’. In other words, I always treated them as an end product. For instance, a requirement for creating a dashboard would have a starting point as a dashboard. All I considered was what the dashboard would look like, and I would then set about creating the same (the results of this approach fall into the ‘atrocious’ category). As I garnered experience, I realised my best work was produced when I started relating to visualisation as a journey, sometimes short and, admittedly, sometimes painful.
This does not mean the end product is not important but rather that it should not be the starting point. Creating simple and powerful visualisations requires a thought process that won’t be effective if it is reverse engineered in this way. Once I realised this, I was better able to serve the business community, as I explain below (note: the scope of this article is limited to serving the business users, dashboards and ad hoc queries). To get the best out of you and/or your team for effective visualisations, there are some key steps that I believe should be followed:
(The Why) Identify the Objective:
Although this is a golden rule for any requirement management process, it is often ignored for visualisations. The designers (or developers, depending on the assignment) have a tendency to jump to tables and charts as soon as soon as they are handed the requirement. But the key to simplicity is to understand why the business requires any visualisation without visualising it ourselves in the first place. Asking this question may return some surprising answers – it’s not always that easy for the business users. Incidentally, the one caveat is “Never ask the business what visualisations they want” – because in doing so the ‘why’ is liable to become irrelevant.
(The Who) Identify the Audience:
“Why worry about the audience when we can create some funky visualisations with the latest set of tools!” – well, because if the user community has not been well analysed, you will get almost zero usage of the dashboard. The business might be sold on the great visualisations that the tool spits out, but when it comes to effective usage, nothing beats simplicity and relevance. And this can only be achieved if you understand the user community properly. This understanding also enables you to set up any user-training that may be required. For instance, in a financial company that I worked with where there was a requirement for a dashboard, the users were obviously all too familiar with excel (and not surprisingly used it even with their existing dashboards). With some relevant training and communication, we provided a compelling storyline (including drilling across, drilling down etc.) and some visualisations not easily available on excel that enabled the users to gain insight from the dashboards directly.
(The How) Make the Journey:
The best way to start this journey is by brainstorming with the team (if you have one) or alternatively by building simple wireframes and getting feedback from the relevant people. This iterative approach is a critical part of the visualisation journey. I do understand that we are often limited (or overburdened with choice) by the visualisation tools we use, and possibly even the skill sets for visualisations. However, the journey is a lot about understanding what the business wants (and note, sometimes that requires helping them identify that in the first place) . The aim should always be to make the visualisations simple and intuitive; this is the biggest challenge by far – I am frequently surprised by the number of iterations we go through to produce the (seemingly) simplest of tables and charts.
Once finalised, it goes into the usual build and test phase and possibly through more iterations when the users touch and feel them. And be aware that you may wow the business with your funky visualisations at the beginning but in the long run, there is no better satisfaction than the business gaining insights from the visualisations you have created. This response is the hallmark of a true visualisation expert.