In roughly two months, we designed and built a feasible solution that would seed the growth of one of the most powerful web-based data visualization tools out there.


As the core of design at DataPad, I was responsible for initial research, design principles, early concepts, interaction details, and visual design.


I aimed to maintain a balance between flexibility in expressing data (i.e. "expressiveness") and ease of use for both beginners and experts. Our longer vision sought to empower anyone to explore data at the speed of thought.


Charting Solution
The basic interactions for creating a simple chart. I designed the chart to include both drag and drop as well as type-ahead interactions.
One of our final cuts (deployed) of DataPad's charting UI. Our front-end ninja, Arne Bech, and I worked closely together to iterate on interaction details. The end result came very close to the original designs.

Before my time

Before I put my hands into the product, the team had a rough prototype built — a "pipeline to the backend" as I recall our CEO, Wes, humbly describing it.

Very early charting UI concept (sans design).
Side by Side Comparison.
Another early prototype. This was a step forward, but still not explicit enough. It was hard to predict how data would be mapped onto a chart.

Light Research Into Existing Charting Tools

I started the process with some academic reading, exploration of existing charting tools, and discussions about what's best for DataPad. The most important overarching finding was this:

Many existing visualization tools focus too much on helping users decide what the data should look like versus helping them explore answers to their business or research questions.

As business and research questions become more complex, it becomes more important for tools to automatically make the basic decisions (e.g. what colors should I use to represent different countries? or should I use a line chart or a bar chart?). Of the existing visualization tools I looked at, only a handful came close to addressing this kind of problem: Tableau, Lumira, Platfora, and Microstrategy. In the end, we borrowed from Tableau's visualization principles, but remained consistent with both DataPad's visual design language and existing charting engine.

Initial Concepts

After initial review of existing tools in the market, I began exploring rough concepts through sketching and visual mocks.

Early mock. I'd removed some elements and simplified others to see how it would compare to the early prototype. Here, chart types are represented by icons, the chart canvas background is white for greater contrast, and the dropdown to select a dataset is removed. I moved on from this to explore more drastic interaction design differences from our initial prototype.
The Pivot Table Concept borrowed visualization principles from Tableau. This was a strong candidate for design since it's explicit, predictable, and flexible, but proved too ambitious for our development timeline.
Pivot Table Heatmap. This variation on the pivot table shows a different layout and a heatmap showing amount of contribution across cities.
Tooltips for Chart Types. Early sketches exploring the concept of chart type tooltips to explain when to use each type and what's needed (e.g. one dimension and one measure) to generate each type. While the team felt this was useful, it unfortunately did not find a place in our development timeline.
A close mock-up to the final. Aside from visual details — mainly the floating X and Y inputs — this was a close iteration to the final design. I decided to move filters to the sidebar to place more emphasis on the chart and to allow better alignment filters when they are added.

Sketching Microinteractions

As the product progressed, we discovered new needs like letting users specify whether a token was a dimension (independent variable) or a measure (dependent variable).

Microinteraction sketches of the token menu. These sketches of the "token menu" explore ways to allow the user to set a token to either a dimension or a measure.
About to Drop a "Token".
Tabbed Token Menu. This type of menu was chosen over alternatives to emphasize the two very different options of dimension versus measure.
Setting Limit in Submenu
Changed from a Dimension to Measure

Charting a Path to Success

Design had set out to build the foundation for a web-based charting tool expressive enough to visualize data in different ways and explicit enough that results were predictable for both beginner and expert users. While we did not have the opportunity to conduct extensive testing on the tool, the informal sessions we did have with users gave us some insight to how we should have progressed. Some users tried to create certain visualizations that were not yet feasible. To design around these limitations, tooltips for existing and "coming soon" chart types might have helped. Online support or a feature request would help keep track of what types users might need (we used Intercom for this).

The main issues with DataPad's charting tool were associated with its unpredictability. Our charting engine was making some assumptions about how to best represent plotted data. While we were well on our way to making better assumptions and forming a more consistent framework for how data gets plotted, we did not manage to get there in the final cut. If design had continued, one key improvement would have included a tooltip wizard for each chart type (not unlike Tableau's) to guide users in making better visualization decisions.