Engaging the Public about Pipeline Incidents
Introduction
Pipeline Incidents was a design project I worked on with the Interactions Lab in Calgary for the Canada Energy Regulator, formally known as the National Energy Board (NEB). The goal of the project was to create an approachable, comprehensive, and accessible application regarding pipeline incident data that would engage the general public.
I was a part of the design team as a visual designer, user experience designer, and a data analyst. My contributions to this project are creating sketches, refined mockups, and digital prototypes; user testing; crafting an accessible colour palette; drafting the design document for developer handoff. The project can be viewed online on the Canada Energy Regulator’s website.
Project Details
Role Visual Designer, Experience Designer, Data Analyst
For Canada Energy Regulator
Date April 2017 – Oct 2017
Type Data Visualization, Desktop and Mobile App, Client-Based
Role
For
Date
Type
URL
Visual Designer, Experience Designer, Data Analyst
Canada Energy Regulator
April 2017 – Oct 2017
Data Visualization, Desktop and Mobile App, Client-Based
Problem
How do we make energy data engaging, accessible, transparent, and understandable?
Canada Energy Regulator has launched an open data initiative to make its data more accessible, transparent, and understandable. Even though Canada Energy Regulator puts up yearly data about the pipelines on their website, there’s a lack of public engagement. The reasons for this lack of engagement are as followed:
1.
No one knows where to find this data.
2.
Hard to comprehend the stories the data has to tell.
3.
A sense of expertise is required to understand the spreadsheets.
This project tackles the problem: How do we get people to engage with data visualizations and understand the wealth of stories energy data holds?
Data Cleaning and Understanding
Spreadsheets are unfriendly and hard to understand the trends of the data.
It’s no wonder that there was a lack of engagement with the pipeline data the Canada Energy Regulator provided. They were all arranged in visually unappealing spreadsheets. People with no previous data science knowledge would be disinterested in staring at rows and columns to attempt to understand the data.
Before designing the visualization, we first needed to understand the data and the underlying trends. This activity would help the team create a visualization that complemented the stories the data had to share. The spreadsheets provided on the CER’s website needed massive data cleaning before the team to make sense of the data. We used Data Wrangler to clean up the data and Tableau for insights and trends.
User Personas
Designing for the general public.
When considering what data visualizations we could craft, we needed to understand the target audience for the project. There were four user personas developed from the data gathered from CER; the General Public, Environmentalists, Data Analysts, and CER Employees. Each persona had its own needs and desires. Since the goal of the project is to engage the public to learn more about Canada’s pipelines, the team decided that the General Public persona was the main focus.
By understanding that we would be designing for the General Public, we acknowledge the varying experiences each person would have with the data visualization. Some might be more familiar with interactive visualizations, and some might not be. Our design needed to take into account these varying experiences and design our interactions in such a way that would encompass a large population of users.
We made some assumptions about the goals the General Public would have, as shown in the image above. Whatever their goal was for approaching Pipeline Incidents, we wanted to make their journey through the data exploration as engaging and accessible as possible.
Sketching and Refinement
Plotting data on a map helped people better relate to the data.
When evaluating the team’s sketches of how we could represent the data, many used maps to visualize the location of incidents. Maps helped make sense of where potential trends were and revealed where major pipelines where. From this, it was clear early on that a map of Canada would help people relate better to the data.
Version 1
Once we settled to use a map to represent most of the data, we refined the idea more and focused on adding real data into the refined sketch. This process allowed us to see whether or not the visualization fit the data or not. Version 1 of Pipeline Incidents had the map of Canada as the main focus of the visualization. To the left of the map was a timeline that represented the data of when incidents occurred.
From our refinement, we quickly realized that it was hard for people to compare the details of pipeline incidents. For this design, a person needed to remember the details of one incident to compare it with their newly selected incident. This back and forth would create too much cognitive strain on the general public, which would increase the probability of people dropping off after a few minutes. The design needed to be changed to allow people to compare incident details to one another seamlessly. Of course, this was another assumption the team had regarding the general public’s needs. This assumption would be evaluated during one of our user testing rounds, which is found later in this case study.
Version 2
Using colourful columns to represent data chunks allowed for a better overview of the data.
Considering that the problem for version 1 was the inability to compare between incidents, the team thought about using a parallel coordinate plot visualization to represent the data. A parallel coordinate plot visualization has columns representing data categories, chunks in each column to denote different data sections, and lines between each chunk to allow for detailed comparisons. This design would allow a better overview of the pipeline incidents data while supporting a sense of curiosity and engagement that version 1 had.
By using colour to denote different data categories, the person can quickly recognize pipeline incidents’ details. Using different line thickness and opacity helped people focus on the specific incident in question. Since we discovered that people are better able to relate to data when displayed on a map, version 2 still had a map feature.
Colour Palette
Designing an accessible colour palette to represent 13 distinct data categories was a fun and challenging puzzle.
We decided to use colour to represent different data categories so that the data would be visually engaging. The use of colour would also help people quickly differentiate between multiple data groups, increasing their data literacy. It was important that each section of data, in addition to the different data categories, was visually distinct from each other. Therefore, the colours could not be reused to represent other data. I understand that this creates situations where the visualization would feel visually busy and overwhelming. However, it is essential that the data be preserved and easily identifiable between the data sections and categories.
Since this was a government-funded project, and our target audience was the general public, the colour palette needed to be inclusive to all. To better understand colour deficiencies, I read research papers and interviewed people with colour blindness about their experiences to gain more understanding, perspective, and empathy. As I designed the colour palettes, I utilized tools, such as colorbrewer, chroma.js and colour blindness simulators. In the end, I was able to come up with an algorithm to generate 13 primary colours and 26 transitional colours. The colour palette ensures that people can see the distinct change in hue, saturation, and brightness.
However, just assigning the colours to the data categories was not enough. Depending on what the data category was, and what colour I assigned, the visualization would have negative connotations. For example, the data category, Company, could not be red or green because it would imply a sense of negative or positive statement towards that company. I had to be mindful when assigning the colours. I presented the colour decisions to Canada Energy Board to ensure no underlying political statements were being made.
Testing
With such a novel data visualization, it was crucial to test with people to understand their experiences early on.
Paper Prototypes
Early on in the design process, we needed feedback from people. We had to evaluate our assumptions we were making for the users. Thus, we created paper prototypes to assess the user’s goals as they came across the initial visualization screen. We gathered people around the lab who had varying experiences with data visualizations to test the interactions.
People with no existing knowledge of pipeline incidents were not interested in a single particular incident.
The round of testing with paper prototypes revealed many insights about the user experience of the visualization. We learned that the general public, who have little to no existing knowledge of pipeline incidents, would not be interested in a single particular incident. This revelation went against our previous assumption regarding the general public’s goals of comparing multiple pipeline incidents. The current design of Pipeline Incidents created difficulties for the testers who just wanted to explore a broad set of pipeline incidents. Since our design focused on delivering information on single incidents, we overlooked the experience of exploring incidents as a whole.
Furthermore, the design of pinning an incident became cluttered and cumbersome. People struggled to understand the importance of pinning an incident. They did not consider it as one of their goals while exploring the data. Those that did pin an incident found it awkward because the incident had no sense of space, and the pinned information would be floating in space. Below is an image of a pinned incident, after re-evaluation, it’s clear how awkward it looks.
These findings lead us to redesign incident selection. We created an area on the left of the workspace that would display a list of incidents whenever a person was to interact with sections of categories or incident lines themselves. This redesign introduces people to the incident list, allowing them to become familiar with it as they interact with the data. Thus, when they decide to pin an item, they understand where the pinned incident would stay, rather than be surprised with a randomly floating window of data.
Digital Prototypes
Evaluating micro-interactions through digital prototypes uncovered awkward behaviours.
From the results of the paper prototypes, we redesigned the incidents list. We created a digital prototype for both user testing and developer handoff. As we started testing the digital prototype with ourselves and a few people, we noticed more jarring interactions. At first, the starred incidents were at the top of the list. As a person starred an incident, the top list would grow, which would push down the list of incidents. This interaction created a jumping effect that was undesirable. Below is a gif displaying this awkward behaviour.
Our solution for this jumping effect was to move the starred list of incidents down to the bottom of the incident list. This way, the list of starred incidents can dynamically grow without hindering the person’s current view of the list. The gif below demonstrates the new interaction.
Solution
An approachable interactive visualization that engages people to interact with the data in a more accessible manner, increasing the opportunity for understanding.
Pipeline Incidents is a parallel coordinates visualization that engagingly displays pipeline incident data. It serves as a tool to bring the data close and personal to the general public. By creating an interactive product, the general public can directly manipulate the data, thus forming their understanding and position on the matter.
Pipeline Incidents was designed through multiple rounds of data understanding, sketching and refinement, prototyping, and quick user testing before handing the details off to development. In between each stage, we presented our process to the client, Canada Energy Regulator, for stakeholder feedback and approval.
Key Takeaways and Reflections
Pipeline Incidents was a great project that taught me how to work with a team of other designers; clients with great perspective, style, and vision; and an outsourced team of developers. From this project, I was able to experience a full iterative design process. I learnt a lot about designing for accessibility, political connotations regarding colour usage, inclusive design, and fulfill design and data requirements.
This project showed the value of testing often and early. The different types of prototype fidelity allowed a wealth of user insights. Due to this experience, I’m a strong advocate for taking the time to test features, ideas, layouts, and designs with others as much as possible.
One thing I wish we had more of during this project is more user research. During the design process, the team would make assumptions about our users that might have been unfounded. Without time for research, we were unable to support or disprove those assumptions. We carried the design with those assumptions in mind.
For future work, I would love to run studies with the general public to gather their experiences using the live product. Are people engaged with the data visualization? Do people understand the data more as compared to just looking at a line graph or a spreadsheet? These studies would truly help evaluate whether or not the design of Pipeline Incidents solves people’s issues with understanding energy data.
If you would like to chat more on what I learned throughout this process, connect with me through email at [email protected].