in

W

Lead Product Designer

Cecilia Huster

Part 4. Data visualization

Top down design process

Tomes have been written about data visualization. My guiding principle is the Luke Wroblewski quote "Obvious always wins." Most users want information with as little effort as possible. Rarely are they visiting web sites because they want to admire our graphic design skills. So let's look at how we can satisfy our users' need for different types of information, while limiting cognitive load. 

DATA VISUALIZATIONS

Tables

Tables are great for audiences that are used to them, e.g. financial advisors. They also shine as supporting information for graphs. In that role they can deepen trust by demonstrating that the organization has done its homework. 


The general public, on the other hand, is going to feel challenged by tables that contain more than about a dozen data points. People with short educations and certain learning disabilities may simply skip over any tables they come across. That means that a table rarely should be used as the only way of conveying information. 

Bar graphs

Bar graphs are one of the most common data visualizations because they're easy to create and to understand. Bar graphs are suitable for data that can be divided into discrete units, e.g. different years. 

Some users will want to drill down into the detail. For those a supporting table can be useful.


Bar graphs can be stacked, to show what they're made up of. In that case, allowing users to select which sources to include, helps comprehension and makes users feel in control. The illustration is an example of that. 

Pie charts and donuts

I'm not a big fan of pie charts and donut charts. If I just want to give the user a general idea of how many different categories something is made up of, pie charts work well. It's easy to see that all the slices make up 100% of the pie. But that's pretty much the only thing they have going for them. 

It's hard to compare the relative sizes of slices in pie charts. Donuts are even worse. For comparing numbers, bar charts are much better. 


Both donuts and pies usually require a legend. Users then have to go back and forth between the legend and the slices to figure out what the colors mean.


 They're also just awkward shapes to design with. As much as I like round things, designing for screens means designing in boxes. Circles create awkward dead space in the corners. 

Still to come

  • Line graphs
  • Combinations of line graphs and bars
  • Area graphs
  • Scatter graphs
  • Bubble graphs
  • Grouped bar graphs


Make responsive. 

Since I moved to the Bay Area in 2008, I've mostly worked on transactional sites and apps. Often the interactions and data visualizations have been very complex. That's something I enjoy.


My goal when designing is usually that the user shouldn't have to focus on the interface. It should just do what they expect. There's absolutely room for positive surprises, but we all have better things to do than figuring out where to tap to make things go. 


The purple thumbnail leads you to a deceptively simple user journey that I created back in the waning days of the waterfall era. 

The purpose with this user flow was to give the team an overview of how the seller and buyer flows work together. 


It starts out in a checkout flow that's detailed elsewhere. If we think the seller might be up to no good, we apply a hold to the transaction, as soon as the funds from the buyer come in. We also send an email to the potentially dodgy seller, telling them to ship the item that the buyer just paid for. The email is new, as you can tell from its pink color. It includes a link to a modified page (blue) where the seller can add tracking information to show good faith.


If the seller adds the tracking information, we send it on to the buyer. The email to the buyer contains a link to a page on which the buyer can tell us that they got the item. If they do that, we release the hold and the buyer receives payment for the item. 


Note that I'm not trying to map out all possible flows. In fact, I'm omitting more than I'm including. It's important to keep user flows simple and uncluttered. Keeping things simple and uncluttered is always a good idea. Even more so for user flows, an abstraction that  can be pretty difficult to understand for people who aren't used to them. 


The wavy lines indicate that this is the flow as it appears to the users. It's not what happens behind the scenes. I leave the technical documentation to engineers and other technical staff, so I have time to design stuff.


On the other hand, I always create a flow. On the rare occassions in the past when I've tried to get by without one, there were always complications. Even if it's one page with two states, I jot it down as a flow. It's a very rare project indeed that stays that simple. 

USER JOURNEYS

LEGEND

As usual I included a legend. I usually weave in the legend as elements of the flow come up. E.g. the green page at the bottom is a manual step.  


Clever stakeholders will see what I'm trying to achieve by looking at the legend. That's usually a good thing.

There were several things I wanted to highlight with this documentation:


  1. Customer-facing elements, in this case an automatic email. We needed to inventory them and decide who was going to write and design these. 
  2. Manual and offline parts of the advisor's workflow. These tend to be very expensive. Making them visible helps us to minimize them.
  3. Hand-off points between different apps. Advisors had to deal with a bewildering number of apps, all with different designs and interaction conventions. Again, making the hand-off points visible helped us minimize them.

  4. Decision points and other "glue." The trainer for the advisors was going to be on the call. She needed to know how to train the advisors in using the tool. 


This flow represents the experience of a financial advisor receiving an incoming call from a client. 

INCOMING CALL FLOW FOR ADVISORS