Linked In Profile of Cecilia Huster

Part 4. Data visualization

Top-Down Design Process

Whatever it takes to break up the text and avoid a solid wall is helpful. It's not true that nobody reads on the web, but most people don't read web pages the way they read books. On the web users scan first. It takes effort to read text, so users try to figure out if your text is worth it before committing. So you need to make the important tidbits stand out by putting them in a bulleted list, linking them or adding a GIF that brings home your message. 

  • Headlines and subheadings that tell the story
  • Left-aligned text with ragged right margin
  • At least 14px font size and accessible contrast to the background
  • Concise and simple language
  • Underlined text links that make sense out of context
  • Bulleted lists
  • Pull quotes
  • Inverted pyramid writing
  • Sidebars

By now it's pretty well known what makes for compelling text content:

STATIC TEXT

Tomes have been written about data visualization. My guiding principle is the Luke Wroblewski quote "Obvious always wins." Just as with text, most users want information with as little effort as possible. They're not visiting web sites because they want to admire the designer's skills. So let's look at some pros and cons for common visualizations.

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. 

Gauge with call-out for the most important number

Pie chart with legend

Donut graph with call-out for the most important number

PIE CHARTS, DONUTS & GAUGES

Circular or semi-circular graphs are OK to give the user a general idea of some data. Most users can tell how many different categories something is made up of. 

If there are only 2-3 categories they may be able to compare the slices. But for comparing numbers, bar charts are much better. 


Circular and semi-circular graphs 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.


Circles are 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. 


Semi-circles are a lot easier to design with and around. They also lend themselves to larger renderings, making them easier to read. 

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. 

Standard Know/Feel/Do matrix in Excel

USER JOURNEYS

One task = one page

One of the first things I was taught when I started designing was that each page should correspond to a task. I still think it's a good starting point, but there are many exceptions to this rule. Here are a two:


One page = many tasks

When people use your app all day long, they would much rather do many different tasks in a row. Having to wait for a page to load between each task eats into their productivity. 


An example of this could be a customer record in a CRM. The person working on the record will often need to change several values or launch several wizards from the record. It would be annoying if the user had to wait for a complete page refresh for each changed value. 


One task = many pages

When the objective is to train people, it can help if each task is subdivided. That way your users really understand what they're doing. Once they've shown that they get it, all the subtasks can be grouped into a complete task. Later on when the user has mastered the whole task, they can perform multiple tasks at once, e.g. as macros. 


Lessons learned in gamification

In gaming the learning process is formally addressed as part of onboarding. It's also used in gamified non-game contexts. 


As an aside, I've taken a course in gamification of enterprise software and I'd love to put it into practice. There's so much more to gamification than leaderboards and cute badges. Millions of people spend many hours each day in enterprise software. That means that gamification and consumerification opens up many opportunities to improve users' quality of life. 

When I first draw up the sitemap or user flow, I keep my options regarding pages and states open. I tell stakeholders that the boxes are topics or tasks and that I will define pages and states as we go along. If the development team thinks that the pages and states have been determined, they will often define them in the code as well. Then when scope and requirements change, they lead to expensive code changes. Part of the Agile methodology is to embrace change, so it's important to communicate clearly about what has been decided, and what's still on the table. 


I also tell everybody that I'm showing them the flow as a basis for discussion. At this point everything is up for grabs, particularly if we can come up with solutions that move us closer to business or user goals. None of my deliverables are "my babies." If I advocate a specific solution, it's because it's better for the user, and by extension, better for the business. 

PAGES AND STATES

SINGLE COLUMN
This is the layout we went with in the end. While it means most of the content is below the fold, it has other advantages:


  • Big, bold shapes and plenty of whitespace limit cognitive overload 
  • Once the user stars to scroll, all the information is discoverable
  • It's easy to surface the most important information with a clear information hierarchy
  • Easy to design responsively

HORIZONTAL TABS
I'm not a big fan of tabs. They often hide important content. It's only when the content in the default tab really is much more important than the other tabs, that I seriously suggest it.  

Staggered thirds layout

FOUR-LEAF CLOVER
This layout feels kind of static and dated, but it is one way of getting most of the information above the fold. Today I would probably have gone for a layout of staggered thirds instead.

In my notes from the time, I was concerned about information overwhelm. Staggered thirds wouldn't help with that.

Layouts differ depending on a number of factors. Here are some examples.


App usage
  • How often is it used? 
  • In what physical, geographical or social context? 
  • How serious is it if the user makes a mistake?


Devices features and limitations
  • Viewport changes, e.g. orientation, pinch and zoom 
  • Location data
  • Bio data for one or several users
  • Recently visited sites, accessed documents or keyword searches


Intended audience
  • What do they know about the subject matter? 
  • How comfortable are they with the device?
  • Do they need to be reminded or motivated to use the app? 

SEVERAL LAYOUTS
I usually explore several different layouts before I decide on one. Here's an example from the Investment Scorecard.

LAYOUT


 If there is no existing polic to lean on, I start with research. This time it's quantitative:

  • What viewport size is the most common in the target audience?
  • What size is the second, third etc most common?
  • Are there traps here, e.g. low mobile usage because the site is unusable in that form factor?


Given the data, the product manager, engineering lead and I come to a decision about the number and placement of breakpoints. I would argue that in most cases fewer breakpoints are better. More important than the number of breakpoints, is that the user is in charge of how they see your content. That means not disabling pinch and zoom, accessibility selections, orientation locks etc. 


Responsive design process

I then start designing for the most common form factor. I agree with the engineering lead on if I should sketch the layouts for different sizes as I go along, or leave it till the end. 


My designs tend to have a strong information hierarchy, so often what the developers have done just needs to be refined. That's best done together. If any documentation of the decisions is needed, we take screenshots as we go along. 


For responsiveness the design decisions boil down to:

  • Which design elements float up as the viewport gets wider?
  • Which elements get banished to the bottom when it gets smaller?
  • Font size, margin and line length adjustments to ensure readability
  • Image cropping so that the salient part is visible at all sizes
  • Are there elements that are less important that we can remove completely at smaller sizes?
  • Conversely are there extra elements that only show up in larger viewports? 

Seeing that I just brought up responsive design, let's tackle non-desktop form factors next.


Responsive design

Responsive designs are relatively simple. In many cases, Product, UX and Engineering make a decision about breakpoints that apply to all projects. This decision is revisited a couple of times per year. There may also be ad-hoc additions if a new form factor surges onto the market, e.g. the recent iPhone X with its "interesting" notch at the top.  

NON-DESKTOP LAYOUTS

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