Visualization Creation Experience
Customers had to export their data from our software into tools like Tableau to create visualizations. We needed to enable users to easily create visualizations within our software. We also needed unique visualizations to draw users away from the tools they were familiar with.
-
Role
I was design lead for both the visualization creation experience and new visualizations.
-
Team
Designers: Chris Burt, Maxwell Brejak, Nancy Xu
Developers: Baz Ramadhan, Jérémie Boudin -
Date
Ideation: 2019
Finals: 2020
The Problem:
Making charts in our software took serious expertise.
Users loved our tables and workbooks, but barely used our charts and dashboards. Business intelligence software, like Qlik or Tableau, provided data visualizations that were easy to create and easy to share. We didn't. So our users were exporting their data into those instead.
We needed a better visualization creation experience. Not only would this make things simpler for users, but it would put a spotlight on our product's value. After all, it only made sense for execs to think their dashboards were also crunching the numbers.
We also needed something to draw users away from the business intelligence tools they were familiar with. Unique visualizations, tailored to supply chain, that more generic business intelligence applications didn't offer.
Come for the new visualizations, stay for the new and improved visualization creation experience. A win for us, and for our users!
Unless we could provide new solutions, users would never switch tools. The current tools they used were optimized for easy visualization creation. Not to mention the companies producing them were bigger than we were. Just designing a better visualization creation experience wasn't an option. We needed a differentiator.
So we reached out to our field personnel and customer contacts. We asked them what tough supply chain problems they were currently struggling to solve. We narrowed down to just the issues they were struggling to build dashboards for. And we asked them why.
Across all our respondents, the same 2 issues came up again and again:
There were so many stages of production from raw materials to finished goods that identifying which components were slowing down manufacturing was incredibly challenging.
Tracking total inventory was easy, but there were so many individual orders that showing what inventory was allocated to which order just couldn’t be done using standard charts.
We had our problems. Next we needed to dig much deeper before finding our solutions.
Discovery:
We needed to learn what problems other visualization tools couldn’t solve.
Digging deeper, we learned that we weren’t the first ones to tackle these problems. We discovered that our support team had unofficial tools to help customers troubleshoot their sourcing and scheduling:
Support had made a prototype network diagram to visualize production hierarchies.
Support often used MS Powerpoint to draw scheduling timelines for customers.
Research:
Once we asked for more details, it became clear this wouldn’t be easy.
Users needed to consume huge amounts of data.
Manufacturing involves an enormous number of moving parts. In order to troubleshoot production processes, users needed to be able to see a summary of everything - and be able to zoom in effortlessly on anything.
If key metrics weren't immediately clear, nothing would work.
Users needed to be able to quickly and easily consume a wide breadth of KPIs. Despite the sheer quantity of data involved, performance of anything and everything needed to be constantly visible and presented as clearly as possible.
Timing was way more important than we thought.
Scheduling manufacturing is like conducting an orchestra. Whenever something went wrong, users needed to be able to see each and moving piece arrayed over time. Summaries weren't enough. They needed timing details for everything.
In early network designs, my focus was on balancing wealth of data with usability.
Exploration and iteration led to a network diagram with a more refined, yet flexible look.
In early timeline designs, I focused on creating scalable components and patterns.
I created a lane system for the timeline to maximize data density and consistency.
Meanwhile...
The team was working on a mobile-inspired chart creation UI.
We figured that our old charting creation was complicated in large part because our data model was complicated. So the challenge became exposing that data model in a way that was easy to understand.
To address this, we put all the controls for creating the chart on the chart canvas itself. We tried to keep everything as amodal as possible, and leaned on Natural UI techniques from mobile design in an attempt to simplify.
We landed on designs with settings and options right next to the chart elements they were related to.
Chart legend as option bar.
Early prototype testing indicated that users liked the idea of the main chart controls being part of the presentation, and found it intuitive to use. So we leaned into that style of presentation, showing more and more information in the legend chips, and built all the chart options into pop-up menus that appeared on clicking a chip.
Unfortunately, all of our testing had been done before building the Network and Timeline Visualizations. These were much more complex than standard charts like bar graphs, line charts, combo charts, and similar.
When we tested this approach using these more complex charts, it didn’t end well.
Testing:
It turned out one of our key assumptions was wrong.
While both the timeline and network visualizations were performing fantastically in user tests, our chart creation UI wasn't.
We thought that the biggest challenge was presenting our complex data model in an intuitive way, but navigating the data model turned out to be something our users were relatively good at. The issue with our old chart creation experience wasn't the data model, it was the inconsistency. The creation of every chart was different. Users couldn't learn the interface once and then make anything. Each time they wanted to make a new type of chart, they had to learn all over again. So we scrapped the NUI-inspired design, and started again, keeping the following insights in mind:
Navigation needed a serious overhaul.
Decentralizing was a mistake. Rather than placing controls near what they affected, gathering all the controls together and organizing them was the path to success. So long NUI, a good old GUI control panel was what we needed.
Organizing the data was the real challenge.
Users knew their data, but there was still a lot of it. We needed to make it easy for them to choose the right data for each chart. We also needed to make it easy for them to track what data was already used, and for what.
Users needed requirements to be really clear.
A line chart needs an x-axis and a y-axis. Simple. But what about a network visualization? Clearly communicating requirements became more important the more complex the chart.
Consistency mattered more than anything.
Despite how much individual visualizations might vary, creating them needed to always be the same. Users didn't need to learn how to use each chart - they already knew that - they just needed to learn our chart creation tool. And ideally only once.
So we set out to correct our mistakes. Here’s what we came out with:
In the end we went with a classic side-panel - standardized and scalable. It let users see all the data they’d piped into the chart in one place, clearly communicated required vs optional fields, & stayed consistent.
I designed the timeline entirely myself, and focused on density that remained easy to read at a glance. I went through several iterations, making the chart denser and denser every time.
I was particularly proud of the tapering trick I came up with for the events that spanned time periods. It meant they could overlap within the same line while remaining clearly distinguishable.
Showing production processes in a network could present hierarchical data even more densely than a table, which really excited our customers. They were building solutions based around the network visualization before we even released it.
To ensure it was up to the task, I designed encodings for a lot of data. Symbols, colors, indicators, line thickness, swim-lanes, and more. I also included gestures tailored to moving from the big picture to the small details, and back again. I learned a lot about how to make data as digestible as possible.
Conclusion:
In the end, we pulled it off, and learned a lot along the way.
The new visualizations were both big hits, and the final chart creation experience went over well with users. For configuring complex charts, success rates rose from 33% to over 80% - and for configuring simple charts, the new experience performed equally as well as the old one.
If there was key lesson I learned from this project, it was to never underestimate users. Our users knew their business and had so much domain knowledge. We tried to simplify the experience for them, but we were simplifying what seemed hard to us, not what was actually hard for them. It took both learning and listening on our part to understand where the users needed help. After a good dose of humility, doing both got a lot easier. Now, I carry that humility with me to every new project.