Column: User Assistance

Tables get a bad rap—especially in the Web world where, once upon a time, Web developers misused them for HTML layout. But tables are still very useful for the purpose for which they were originally intended—a way to show relationships among discrete data points. From a user assistance perspective, we deal with tables in two contexts:

1. user assistance—Tables can present information or instructions in our documentation.
2. user interfaces—Tables can display information within a user interface itself.

In this column, I’ll review some of the basic principles of good table design from an information developer’s perspective, then discuss their visual design and interactivity. These principles and my examples provide the bare essentials of table design. When designing tables, a key information design objective is keeping them simple, so if you start needing more than this column provides, you might be making things unnecessarily complicated for your users. Read More

The explosion of information that analysts and executives must consume, as well as the increasing variety of sources from which that information comes, has boosted the popularity of information dashboards. Modeled after the dashboard of a car or airplane—which informs its operator about the status and operation of the vehicle they’re controlling at a glance—dashboard user interfaces provide a great deal of useful information to users at a glance. Typically, the role of an information dashboard is to quickly inform users and, thus, enable them to take immediate action.

For example, a sales executive might use a dashboard to compare current sales levels to plan or levels at the same time last year, as well as to see the current volume of orders in the sales pipeline—that is, orders his salespeople are working on, but have not yet closed. Using that same dashboard, he could compare that information across the various sales regions and respond quickly if indicators showed a potential problem brewing in a particular region or a general slow-down across the enterprise. Read More

A recent Alertbox by Jakob Nielsen, “Thinking Aloud: The #1 Usability Tool,” reinforced the usefulness of the thinking-aloud protocol as a great usability testing approach. I couldn’t agree more. But there is a big difference between someone’s thinking out loud about a task they are doing and someone’s voicing their opinion about a design. The first is very valuable; the second is so-so at best and dangerous at worst.

Here is the kind of data you want to get from a user who is thinking aloud:

• “I want to do…”
• “I’m looking at the UI, and I think it does…”
• ‘Hmm, that’s not what I expected; I thought it was going to…”
• “That took longer than I expected.”

In short, you want to learn how a user sees her task and how she is making sense of a user interface in terms of that task. Read More