Guidelines for developing data visualisations on the web

Visualising data on the web is an elaborate task in an age where devices are multifarious, inclusive design is the responsible thing to do, and the multitude of tools and resources can become perplexing. This post describes the challenges that our team faced when working on a data visualisation project that needed to meet criteria such as: usable, responsive, visually compelling, interactive, compatible across browsers and operating systems, and very importantly, accessible. Based on our experiences, we have formulated a set of guidelines for developing data visualisations on the web.

Start with user needs

Firstly, identify the users to help shape the right solution. This means knowing the target audience and the devices they might interact with the data visualisations on. Our user-base is largely non-technical and in managerial roles, so the charts needed to communicate relevant and meaningful statistics, as well as include digestible written content. Statistically complex and heavily annotated system monitoring visualisations were clearly off the charts. The visualisations also needed to be supported on mobile, tablet, and desktop devices, and across a variety of operating systems and browsers.

Explore what’s out there

Second, doing some light experimentation with a handful of visualisation libraries can help narrow down implementation choices. It was certainly an exciting discovery to find the number of libraries that can produce beautiful interactive and responsive charts out-of-the-box with minimal effort. However, there was an interesting dilemma due to a dichotomy between using a library that offers a high level of control but comes with a high development effort, (eg D3.js), and a more constrained library that ships with pre-built and customisable charts (eg Chart.js, Highcharts) that allows faster development. We opted for the latter; I will describe why next.

Narrow down your explorations

Most libraries with pre-built charts are responsive, interactive, and cross-browser compatible, so these criteria can easily be ticked. One of the more defining implementation factors was the customisability of the charting library. For instance, we needed to adjust the charts to: apply branding styles, produce a specific range of visualisation types, apply custom annotations, and choose a library that was compatible with our software stack and data formats. If these can be achieved by customising pre-built charts, then the solution is clear-cut. But what narrowed down our choice even more was whether the library included out-of-the-box accessibility support, which leads nicely to the next guideline.

Inclusive design means accessible charts

Consider web accessibility and support for assistive technology. This is a legal, and therefore essential, requirement in our case. We typically follow the accessibility guidelines as defined by WCAG 2.1 (at the time of writing this post). For instance, we added screen-reader support, use of colour with consideration to visual impairments, and keyboard-only input functionality, among others.

Do the hard work to make it simple

Next, present the data in a clear and consistent way that’s right for the target audience. For example, we had multiple charts on a single page and therefore needed to include clear visual separation. We ensured that descriptive content surrounding the charts, labels on the charts, and the use of colour were consistent. Fortunately, the charting library we used included useful features such as annotations, toggle for data sets, and chart animations. Annotations helped us provide supporting content to data, for instance, we added a hover-over (and clickable) tooltip for each data point in our charts. This helps interrogate each data point in more detail, especially those that stand out amongst others. In addition, we included data set toggles (eg on a line chart) to help filter the data, and a modern aesthetic by using animations.

Build, measure, learn

Finally, test the charts with the right user base and iterate. We gathered feedback from the mock-up stage through to the functional prototype stage. This enabled us to gather useful feedback from the target audience and refine the charts so that the data visualisations were useful to the right people. When it comes to releasing, the charts do not need to be perfect. Creating releases early and often ensures that a wider range of target users are exposed to it sooner, and can provide useful feedback to iterate into the next releases.

To sum up

The above guidelines enabled us to develop a useful, usable, and compelling user experience. Although these are grounded within our project, we believe that the guidelines, as well as the challenges that we faced, can be generalised to other projects. Getting from start to finish can be challenging, but by building a good understanding of users, experimenting with existing technologies, adopting an iterative design and development process, and keeping things clear and simple, will certainly make life easier.