Better charts from simple questions

Stephen Turbek 9 June 2009

Selecting the wrong chart, like bad chart design, can obscure the data. Here is a simple model pick the right chart for your needs.

First, let’s ask a few questions to make sure we are going in the right direction.

Is a human making the chart?

If a person is creating a chart, they can decide the most appropriate format, and more importantly, highlight the interesting data. Charts generated by automatic systems must be conservatively designed, as their output is unknown. Programmers love Pie charts because the size won’t change and muck up the layout.

Who is the audience?

Knowing the audience is essential for a successful communication through visuals. Assuming the viewer understands the context (e.g. remembering how many widgets we shipped each month last year) or including data the viewed is assumed to understand is a common source of confusion. Provide gentle reminders. When designing for a specialized audience, consistency with standards (for example, complex stock charts) is generally better for communication than a radical improvement.

Are you trying to illustrate a point or analyze data?

Charts are used for several reasons; confusing them leads to bad design. Chart design that works for analysis is often wrong for presentation and vice versa. Charts in a presentation are often meant not to analyze data, but simply to illustrate a point. This is the only time it is OK to use a pie chart (See below for tips on how to make them work).

Do you even need a chart? A chart implicitly asks the audience to analyze the numbers. Often, though, you simply want to tell the number, as below

source: presentation zen

What is being decided?

Analysis charts are tools to help make a decision. “For information purposes only” usually means the designer doesn’t understand the problem. A chart designer should understand the business better than the person who will be reading the chart. Each element on a dashboard, for example, should be the answer to a clearly articulated question, with defined metrics leading to specific actions. Ideally, the business needs should be so well understood that the dashboard should answer a series of yes/no questions, such as “Are our sales on target?” or “Do I need to hire more sales people?”, rather than merely reporting the sales total and expecting the user to recall and compare this amount to an undefined series of others. Essentially, a dashboard should answer the question “Do I need to do something?”

Boring charts are usually the result of not having something significant to say.

What is the context of the chart?

Numbers are only interesting in comparison with other numbers. Knowing the context of the data (what the viewer wants to use it for) makes it easier to pick the right chart. Even the best chart design cannot fix an undigested data dump. Making a chart is easy; the hard part is asking the right question.

If I told you that our company shipped 50,000 widgets, it matters:

If it were this year or this month

If it last year’s ship rates were 10,000 or 100,000 widgets

If our competitor’s ship rates were 10,000 or 100,000 widgets

One good approach is to start by writing the question this chart is supposed to answer. The real question is not “How many widgets did we sell last month?” but “Is our new sales plan worth the investment?” As charts are there to help make comparisons, ask:

Am I comparing [something] against time, other things, or its contents?

To compare against time, use a line chart

A line chart emphasized the continuum of a measurement over time, whereas a series of bars focus on the individual measurements. Time should always be shown horizontally from left to right. Use a step line chart, as angled lines suggest more data than actually exists.

This is equally important with multiples as we want to highlight the relative changes, not the individual values.

To compare items, use a horizontal bar chart

Bar charts emphasize discreteness, that the items have little influence over each other. A line chart, by comparison, emphasizes the connection.

Horizontal bar charts are the most visually effective chart.

-You don’t need a “legend” or call out lines, as pie charts do.

-Text labels fit nicely into the design, saving space to make the chart larger (vertical bars rarely fit text well).

-They can be more easily read and compared to each other. The eye “tracks” (compares items) vertically more easily than horizontally.

To compare contents over time, use a stacked area chart

Stacked area charts emphasize the contents of each measurement and de-emphasize the individual values and the numbers themselves.

To compare the contents of a single item, use a horizontal bar chart

Comparing contents of an item is in fact, simply comparing the components to each other, something our old friend the horizontal bar chart is good at.

The allure of the pie chart remains strong. It makes sense to people to show “parts of a hole” as a pie chart. Programmers also like it because the overall size of the chart does not change, making designing a screen simpler.

But Pie charts are very poor at helping the viewer compare amounts. For example: In the example above right, how different are items 2 & 5? Depending on data labels to explain the chart raises the question of why the chart is there at all. That said, pie charts have their uses, see below for ways to make pie charts work.

To compare the contents of several items, use a stacked horizontal bar chart

Stacked bar charts are one of the most useful charts for analyzing complex contents of multiple items. If the number of items or contents gets above 10, consider breaking it into multiple analyses.

How to use pie charts

Graphic designers know to disdain the pie chart. They are rightly afraid that the result will look like this:

Source: http://brandon.ikevin.net/costume/

This pie chart does not help the reader compare the items and analyze the context.

-It is difficult to compare slices in a pie chart.

-Too many items make it unreadable.

The bar chart is a better for analysis, but pie charts are great communicators of simple messages, which is often what people want them for. They can be ok, as long as you control the data and the display

source: apple computer

Some tips

Tell the story in the title

A caption is worth a thousand pictures. Presentations documents are distributed outside of a presentation, which loses much of the context. Better than a title is the one-phrase summary that a person should walk away with. In the above example, the caption could read “iPods Market Share Continues to Increase”.

Resist the urge to zoom into the action Show charts with axes that go to 0. A common mistake in stock charts, this over-emphasizes changes. Sometimes I wonder if this is intentional, perhaps making for more “exciting” visuals.

Highlight the main figure and diminish the others with color.

Don't display more than six items in a pie chart. If you have more items, you should be using a bar chart.

To make a point obvious, compare only 2 values. Collapsing the many “long tail” (1% - 10%) values into an “others” category reduces visual noise. You can even collapse the majority into an “other” in comparison to the highlighted value, as shown below.

source: apple computer

You want your chart to look as much like Pac-man as possible.

via http://www.boingboing.net/2006/11/02/hilarious-piechartvi.html

Specialty charts

Stock Charts

Different audiences require different charts. New investors expect a stock chart to reflect numbers they understand, for example, a stock price. They can be confused when the Y axis is logarithmic (a better measurement of change, used by more sophisticated investors), and make incorrect assumptions as to how much the stock is going up or down.

The default view of a chart should reflect the audience. Google finance has a simpler chart, aimed at a general audience. A professional trader will want (and take the time to learn about) the additional information.

Source: google finance

Source: http://stockcharts.com/

To compare items over 2 measurements, use a Scatter plot

Scatter plot charts show items measured across two dimensions making connections visible.

Here is a (not beautiful) chart that clearly highlights an abnormal result in the upper right (in this case a player who was cheating in a poker tournament). The chart compares how often the person bet (Y Axis) to how often they won (X Axis).

Source: http://simplecomplexity.net/2008/02/29/catching-an-online-poker-cheater-with-data-mining/

Note that scatter plots are more sophisticated, so annotation and highlighting of interesting data is very important. The above chart clearly needs well labeled axes, the red dot made more visible, and a title.

To compare items over 3 measurements, use a Bubble plot

A bubble diagram is a scatter plot with a 3^rd dimension of data shown as the size of the bubble. Though beloved in the sciences and finance, it does require some explanation to the average audience.

The New York Times stock performance chart. Source: http://www.nytimes.com/pages/business/index.html

Do not use Radar charts. These are sometimes recommended for cyclical data sets, such as months per year. Use overlayed line charts instead.

Source www.perceptualedge.com/blog/?p=118

I’d like to thank Vlad Jenkins & John Daschbach for inspiring design ideas.

How to make personas useful (and it’s not stock photos)

Advancing Advanced Search

Advanced search is the ugly child of interface design -always included, but never loved. Websites have come to depend on their search engines as the volume of content has increased. Yet advanced search functionality has not significantly developed in years. Poor matches and overwhelming search results remain a problem for users. Perhaps the standard search pattern deserves a new look. A progressive disclosure approach can enable users to use precision advanced search techniques to refine their searches and pinpoint the desired results.



Fig. 1: A typical separation of standard and advanced search (Yahoo!). The design discourages use of advanced search.

In the quest to make web sites more usable, we settled on a pattern of a clean, minimal search box with a link to an advanced search page. Jakob Nielsen recommended, “use an intimidating name like ‘advanced search’ to scare off novice users from getting into the page and hurting themselves.”(1) This model has been successful. Search rivals hierarchical website navigation on many sites and is the primary means of navigation on enormous sites such as Ebay and Amazon. Advanced search, however, has not fared so well, with only a small percentage of users using it.

Why most people don’t use advanced search

Despite its name, advanced search has not advanced very far. There is great power to conquer the overwhelming number of search results, but the current standard presents barriers to users. Specifically,

• The link is often small, vague, and does not describe benefits to the user
• Advanced search pages typically have confusing page design for the few who make it there.
• There is generally poor search revision functionality: Once a search is performed, the “advancedness” is lost. For example, the Google advanced search delivers the standard search results page. You have to get the query right the first time; there is no opportunity to adjust your query.

Fig. 2: Google’s advanced search is still complicated.

Who does use advanced search?

Tim Bray wrote, “The people who do use Advanced Search are your most fanatical users, the professional librarians, spooks, and private investigators.”(2) As in many situations, segmenting a population makes it harder to see whether the needs of a subgroup are shared by the majority. Current design is based on the idea that there are two separate audiences with distinct needs. The reality is that there are overlapping needs that are limited by the search pattern.

The essential problem of search — too many irrelevant results — has not gone away.

A typical user has to make a choice between doing a search and clicking a link to do a search. In other words, do you want it now, or want to go somewhere else to look? The immediacy of the search text field and the complexity of advanced search means that users will try the text search first.

Perhaps the old framing is wrong. Rather than being a matter of geeks versus normal people, the question should be whether users see a benefit to advanced search on starting. Unfortunately, there is typically no way to use advanced search at the point users realize they need it — when they haven’t found what they were looking for and have too many search results. They have “missed the exit” to advanced search. Users don’t want to lose the investment in their search; they need a way to use additional techniques to work with what they have. A new model of search can help with this problem.

Other approaches to search

Let’s take a quick look at other search innovations from the last decade. Web data has matured and become more structured. Taxonomies and tagging are now common. There are new opportunities to deal with search results overload by filtering, as long as it is clear and easy for the audience. Despite the truism that users will not go past the first page of search results, they will use obvious tools to refine their searches.

Searching by defined parameters is natural in some circumstances (for example, airline ticket searching) but the majority of sites are not sufficiently data-driven to have an interface designed around the data.

Fig. 3: travelocity.com Flight searches, in a sense, only use advanced search.

Tags can improve search results by better describing what someone is seeking.

Fig. 4: amazon.com’s approach to tagging a product

Faceted searching, or returning browsing categories in the search results (as eBay does) can be effective at prompting the user to select a single category.

Fig. 5: ebay.com’s faceted search

Filtering search results

Amazon and Kayak offer filters to enable users to reduce many results to a few. This can be very effective, but there are obvious constraints due to the limited space available for each filter. Only the first few filters are visible when the page loads.

Fig. 6: Filtering on amazon.com and Kayak

Another approach: Progressive disclosure of functionality

One solution to the essential problems of advanced search discoverability and complexity is to progressively disclose (3) the functionality to the user. Instead of a single, complicated page, break it into understandable units and give each to the user when they ask for it.

In this example, show the ways the user could filter the results (e.g., “Brand” or “Price”) in a highlighted banner above the search results.

Fig. 7: Filters highlighted in a banner (it doesn’t have to be green, it just has to stand out!)

When the user clicks a link, display the filter with enough space to clearly articulate how to use it. Don’t cram it in; the user asked for it. In contrast to the left-hand column filters in the examples above, which are naturally space-constrained, this method can hold many more types of filters and doesn’t show functionality they didn’t request.

Fig. 8: When the user clicks "price" above, give the module enough space to be readable.

Let’s look at an example scenario.



1. The user performs a text search normally.

Fig. 9: Searching for a DVD player using the simple search box

2. On the search results page, show options to filter the search in a prominent location above the results. Communicate the value of filtering. Order them by popularity, using size and font weight to highlight others. If there are many options, consider hiding rarely used options under an expandable section.

Fig. 10: A search results page, with options to filter.

3. When the user clicks an option, display a page module for that search parameter without reloading the page. The user should be able to change the parameters at any time to receive an updated search. If possible, show the number of results for each parameter, so the user can see how exclusive it is, and identify which parameter maybe giving them 0 results.



Fig. 11: The search results, filtered by price.

4. Enable the user to add several modules, stacked in chronological order as the user builds up a complicated query.

Fig. 12: The search results, filtered by price and rating.

Recommendations

Define an implicit method for Boolean rules (AND and OR rules) based on normal search patterns — do not ask users to compose Boolean queries. A system that has worked for me is this: If a user selects several different search parameters, perform an AND search between them (e.g., Sony AND Portable). If they choose multiple values for the same parameter, perform an OR search (e.g., Sony OR Panasonic). However, if parameters (such as product features) are clearly non-exclusive, perform an AND search (e.g., Portable AND “HD ready”).

Recognize that quick searches, text searches, and advanced searches may be built with different technologies (e.g., direct database searches, a Google box, or a content management system). You may need to work closely with the developers to make a seamless transition between technologies.

If there are many parameters (more than 15), consider reducing complexity by hiding less used ones under a “see more…” link below the displayed options. Clicking it should display all the options without a page refresh. Evaluate your search logs to make sure you are exposing the right ones. Consider rotating the exposed ones to discover potential popular features, as exposed options will naturally get more usage.

Conclusions

At its core, advanced search is an under-utilized tool hampered by its own design. By enabling the user to add specificity as they request it, designs such as the one above avoid the lonely fate of the standard advanced search page. Defusing this complexity and locating it where users will naturally find it will help advanced search be truly advanced.



References

(1) Nielsen, J. (1997). Search and You May Find. Alertbox, July 15, 1997.

(2) Bray, T. (2003). On Search: The Users.

(3) Wikipedia. Progressive Disclosure

What I learned from my failed web 2.0 project

• build an new approach to online surveys
• explore AJAX coding
• Start a company
• try out new interaction models

1. understands what you are working on
   
2. cares

Automatically Create Table of Contents in Visio

• Download Table_of_contents_creator_macro.zip , unzip and save to your My Documents > My Shapes folder
• Open Visio
• Go to Tools > Macros > Security

• Set Security to Medium (to allow Visio to run Macros)

• Close Visio
• Open a Visio Document
• Select a text box that you want to put the table of contents in
• Open the Table_of_contents_creator_macro.vss stencil
• Choose to enable macros
• Select the text box you want the Table of Contents to appear in (or it will create a new box)
  
• Select Tools > Macros > Table_of_contents_creator_macro > Module1 > Table_of_contents_creator
• That’s it!

Labels: table of contents, visio, visual basic

Real Wireframes Get Real Results

“Just because project teams understand the purpose of wireframes, that doesn’t mean everyone will. Similar to listening to someone sing out loud to his iPod: we only hear the singing, while the person hears the whole orchestra.”

How many times have you been asked, “So, is the new website going to be black and white too?” after presenting your wireframes to a client or a usability test subject?

This question is almost a traditional part of being an information architect. Wireframes do not clearly define what they mean to convey, leading to confusion. This is most apparent in wireframe usability tests with users who don’t know anything about the project or process. Fortunately, there are a few simple steps that will make wireframes be understood by anyone. They don’t even have to be much more work. It’s simply a matter of choosing to “get real” from the start.

Real people don’t understand wireframes
Usability tests are done to get early feedback on content and functionality decisions from people outside the project team. These participants, unfortunately, are not sure how to respond to a wireframe. It is not intuitively clear what they should be doing, which site they are looking at (public site, intranet, client site)—it may not even be clear that they are looking at a web page. This lack of information and context adds a bit of cognitive friction to each step in the process. This level of confusion results in less confident answers and fewer opinions.

Wireframe tests usually take place with well-meaning, but unsophisticated users. They generously accede to poking and prodding and answer questions as best they can, despite not exactly understanding what is wanted. This realism gap is due to the lack of definition of what should and should not be looked at. “Look at the field names but not body copy.” “You can look at the forms but not images.” “Comment on the page layout but not design, and, yes, the font size but not font.” It’s no wonder that the layperson is confused.

Visual affordances, such as color and underlining links are key to using a site, and these cues make a significant difference in a usability test. Users cannot confidently predict how they would use a page if they don’t recognize links or can’t read what the page expects them to. Information architects, however, tend to shy away from these cues because they don’t want to step on designers’ toes. Wireframes, after all, are not designs.

Or are they?

Avoiding “design” elements removes visual cues that users rely on:

• Color, which identifies hyperlinks and focuses the user’s attention on an element of the page
• Branding, which confirms that the user knows where they are
• Recognizable web page elements, such as forms and search fields
• “Content,” such as account numbers or product names, which allows experienced users to focus on how they would really use the page, instead of interpreting “lorem ipsum”

The boundaries of the role of the information architect shouldn’t be more important than clarity.

Originally the term “wireframe” referred to a quickly rendered 3D model showing the model’s structure used while the model maker was working. They were much faster to work with than the full rendering. Interestingly, they are not currently used as modern tools and techniques are fast enough.

Why wireframes?
Information architects construct wireframes instead of designing final pages, in part, because:

1. Wireframes are faster.
2. Information architecture and design phases can happen in parallel.
3. Wireframes force viewers to focus on the content, not the visual design.

Notice anything? All these goals are internally focused on the project-team. Wireframes aren’t created for external audiences.

Figures 1,2: Originally the term “wireframe” referred to a quickly rendered 3D model showing the model’s structure used while the model maker was working. They were much faster to work with than the full rendering. Interestingly, they are not currently used as modern tools and techniques are fast enough.

Wireframes are conceptual models of a page that web design teams have become to interpreting. Each wireframe is surrounded by experience in reading them, knowledge about the project scope, knowledge about how the designer will use the document. Liz Danzico writes about this wireframes becoming project memory in the article “The Devil’s in the Wireframes.”

Just because project teams understand the purpose of wireframes, that doesn’t mean everyone will. Similar to listening to someone sing out loud to his iPod: we only hear the singing, while the person hears the whole orchestra. Likewise, the test subject knows only that “the page isn’t going to look like what they see,” but what they see is all they have to react to.

Wireframe makeover
Here is an example of the simple steps to transform a standard wireframe into a realistic wireframe. In this example, let’s say we are designing a registration process for Verizon.com (no special criticism is intended for the site below).

The site we are designing for Verizon.com:

Here is a standard wireframe:

And here is the same wireframe, made more real. (An additional 10 minutes was required to use the standard header and a library of realistic form elements in Visio or InDesign.)

And here is a version re-using Verizon’s standard buttons and clip art. (Additional time: two minutes.)

Which do you think would be easier for test subjects to understand?

Tips to get real
These tips are best for intranets or sites with defined styleguides, and less useful for graphical or marketing pages where the design is the content of the page.

1. Make a header bar with the company branding. It should look like the site they are used to, showing the company logo.
2. Use color. Hyperlink color is a basic requirement.
3. Put a web browser frame around the image (or at least the first page).
4. Use real form elements, not drawn replicas of them.
5. Create a template or library of real form elements (feel free to share yours in the comments below).
6. Avoid lorem ipsum. Instead, use: “Descriptive text that will explain this product.” to avoid confusion about greeked text.
7. Use accurately sized fonts (this also keeps you honest about what can fit on the page).
8. Use real detail such as products names and data. Especially on transactional tools with expert users, users care about what they are reading and recognize and use data like account numbers. It may not be important to us, but they have expectations that need to be met.

Compare the wireframe to the current site, note any changes in functionality that may trip them up.

The page doesn’t have to be perfect, just enough to give the test subject their bearings. A semi-designed page is easier to understand than a non-designed page. This is not wasted work; these decisions need to be figured out at some point. Consider bringing designers into the process earlier, cooperating on file formats and processes. It might even make their jobs easier.

Are traditional roles limiting projects?
Wireframes are in fact the first design iteration, and this overlap with visual design can be uncomfortable for teams. However, denial is not the way to fix this issue. Good collaborative relationships should make this overlap an opportunity to reduce work, not fight over ownership. Concern that wireframe might be mistaken for a visual design, or worse, be criticized for lacking design, may be holding the entire project back. It is much easier to communicate within the project team than the outside audience.

Improving Web Navigation with the "All-Menu" Nav

Your Interface is your company