Creating a Plane Sailing Data Visualisation Design Process
An outline of our collaborative data visualisation design process
Here at EmpathyBroker, all of us have plenty of ideas and opinions on how our data visualisations should look, work and feel. When we first started working on new visualisation projects, we noticed that having input from so many opinions during the early design process often made the direction of project fuzzy, sometimes with no clear end in sight. To avoid this, and many other classic pitfalls in software development, we started to create an iterative design and development process to collaboratively build our data visualisations.
The first, and arguably most important, part of the process is to fully define and check that all requirements and the definition of “done” are clear. To achieve this, we have created a data visualisation checklist. This is quite similar to a pre-flight checklist in aviation, which his “a list of tasks that should be performed by pilots and aircrew prior to takeoff. Its purpose is to improve flight safety by ensuring that no important tasks are forgotten.” (source: Wikipedia).
In our case, the “pilots” of a data visualisation project commonly are:
- Stakeholder (holds the vision, signs off the work)
- UX/Visual designer (creates the visual and interaction design)
- Data Visualisation Engineer (drives the information design and implementation) ← me
We go through the pre-flight checklist together as a team and ensure that all the items have been ticked off, making sure the work ahead is clearly defined and safe to kick off with everyone understanding and feeling comfortable with the direction. If one or more items on the checklist are left unticked, then the vague requirements and lack of clear definition could make the project’s outcome uncertain. To avoid these pitfalls, we always perform our pre-flight checklist before taking off with the project.
This is what our checklist looks like in a nutshell:
Why?
1. Purpose ….. CLEAR
2. Insight ….. CLEAR
3. Action ….. CLEAR
Who?
1. Audience ….. DEFINED
2. Roles ….. ASSIGNED
Where?
1. Platform ….. SET
2. Device Type(s) ….. SET
What?
1. Metrics ….. SET & AVAILABILITY CHECKED
2. Dimensions ….. SET & AVAILABILITY CHECKED
3. Filters ….. SET & AVAILABILITY CHECKED
4. Date Range ….. SET & AVAILABILITY CHECKED
5. Data and API Limitations ….. CHECKED
How?
1. Potential Charting Methods ….. INVESTIGATED
Once every item on the checklist has been reviewed and ticked off, the project is clear for takeoff.
The data visualisation project is then kicked off (or put “in-flight” if you will), with the following three checkpoints to pass:
- Sketch (done by data vis engineer)
- Mock-up (done by ux designer)
- Build (done by data vis engineer / FE engineer)
The outcome of each of these steps will be discussed and reviewed by all those involved until the stakeholder is happy to sign off the work on each step. Only then, when we´re sure the project is still on course, will it move on to the next checkpoint. Below is an illustration of what the entire process looks like, all the way from checklist to safe landing:
While airborne, we have to ensure that the project is moving in the correct direction.
For the “pilots” to steer and land the project successfully, they have to be constantly aware of the project’s direction. Many agile software development practises exist to ensure that this is the case and I won’t go into too much detail here. Small iterations and regular check-ins with all those involved in the project are crucial to ensure the project doesn’t drift off course too much and to be able to make any course correction early.
One key element I would like to point out, and one that has become very useful for us during the project’s lifecycle is documentation. Each idea, concept, sketch, mockup and screenshot as well as the initial checklist is documented in our internal wiki for everyone to access, review and comment.
Each visualisation project has its own wiki page, where it’s possible to see what the current and previous versions/iterations of each of the project’s steps look like.
This not only makes the process transparent to the whole company but also means it’s possible to retrospectively follow the course the project took. In the worst case scenario, this can also serve as a kind of a flight recorder if the project crashes, helping with the analysis of why a project didn’t succeed and as a postmortem documentation.
Of course, this process is not set in stone and we continue to evolve it with every bump we encounter. And although it might not be perfect yet, it is already helping us steer our data visualisation projects safely to their destinations, even when the projects encounter turbulence.
