User experience
and interface design
in Boston

Most dashboards start with a list of available data. Every metric the system can produce ends up on the screen: charts, counters, tables, trends. The result looks impressive in a demo and is almost useless in daily work. People open it, scan it, and still cannot tell whether something needs their attention.

A useful dashboard starts with a question. What does this person need to know when they open the screen? Whether sales are on track this week. Which orders are late. Which machines need a service. Each question suggests a small number of measures and a clear way to show them.

Different roles need different views. A manager wants trends and exceptions, while an operator wants the list of things to act on now. A single dashboard trying to serve both usually serves neither. Separate views, sharing the same data, work better.

Comparison gives numbers meaning. A figure on its own is hard to judge. The same figure next to last week, the target or the same period last year tells the reader immediately whether it is good or bad.

Exceptions deserve the most visual weight. Colour, position and size should draw the eye to what is wrong or unusual. If everything is highlighted, nothing stands out, and a calm screen with one red item is more useful than a screen full of green and amber.

Every number should lead somewhere. A reader who sees ten late orders will want to know which ones. Linking each figure to the list or record behind it turns the dashboard into a starting point for work rather than a report to read and close.

Definitions must be visible. Terms such as active customer, late order and conversion each hide a rule. A short explanation on hover or in a side panel prevents arguments about why two reports show different numbers.

Test with real users and real data. A layout that looks balanced with sample data may break when one figure is a hundred times larger than another, or when a list has three items one day and three hundred the next.

Review the dashboard after a few months. Usage data shows which parts people look at and which they ignore. Removing unused widgets makes the rest easier to read.

Mobile views need their own thinking. A dashboard designed for a wide monitor rarely survives on a phone. On a small screen, the most important question should come first, with a single figure and its comparison, and the detailed charts one tap away.

Empty and loading states count too. A dashboard that shows zero everywhere while data loads can cause alarm, so loading should look different from a real zero.

Many products are designed by people who spend all day on screens, for people who do the same. But a large share of real users are different. Older customers, people who use a computer only at work, people using a product in a second language, people who were pushed onto an app because the paper form disappeared. Designing for them is a skill of its own.

Low confidence is not the same as low ability. These users can complete complex tasks. What they lack is familiarity with conventions that designers take for granted: icons without labels, gestures without hints, menus hidden behind three lines. Each unexplained convention is a point where they may stop.

Plain labels help everyone. A button that says Save changes is clearer than a floppy disk icon. A link that says Show all orders is clearer than an arrow. Text costs a little space and saves a lot of hesitation.

One task per screen reduces anxiety. Long forms with many optional sections make people worry they have missed something. Breaking the task into short steps, with a clear sign of progress and a summary before the final action, gives them a sense of control.

Mistakes need a way back. Users with little confidence are often afraid of breaking something or losing data. Clear undo, confirmation before irreversible steps and a visible way to go back reduce that fear.

Size and contrast matter more than fashion. Small grey text on a white background may look elegant, but it fails many users. Larger tap targets, strong contrast and text that respects system font size settings make a product usable for far more people.

Help must be close to the problem. A help centre several clicks away is rarely used. A short explanation next to a difficult field, or a phone number on the screen where people get stuck, is far more effective.

Research with these users directly. Recruit through channels they actually use, such as community groups, libraries and customer service lines, as well as online panels. Watch them use the product in their own setting, on their own device. Their difficulties are often invisible to experienced testers.

Designing for these users usually improves the product for everyone. Clearer labels, fewer steps and forgiving flows help experts too, especially when they are tired or in a hurry.

Language matters beyond labels. Short sentences, common words and instructions written in the order people act help readers of any level. Legal and technical terms should be explained where they appear. Many teams test key screens with a readability checker and with people who read in a second language.