Think, for a moment, about the dashboard in the vehicle you drive. Whether your vehicle is a 1973 AMC Gremlin, a yacht, or a Boeing 747, the characteristics are the same. They all provide:
- Instant, visual indications of the most important operational parameters of the vehicle.
- Visual and/or audible indications of abnormal conditions.
- Controls for certain important functions.
- Indications that are arranged to be seen all at once.
A good deal of thought goes into the design of vehicle dashboards, and they have evolved over the years. At one time, automobile dashboards were festooned with numerous gauges and dials to show oil pressure, coolant temperature, alternator voltage, and other measurements. But automotive engineers came to realize that most drivers don’t need to know about these parameters unless there is something wrong, and having a sea of indications is not necessarily helpful in normal driving. Eventually, most of these gauges were replaced with “idiot lights” that illuminated only when something was abnormal.
Expanding the Dashboard Concept
Recently, the dashboard concept has been expanded to other aspects of life as well. The advent of the graphical computer user interface in general, and web browsers in particular, has enabled developers to construct “dashboards” for just about everything, from company finances to factory operations to hospital intensive-care units to your in-home entertainment.
But making a dashboard can be trickier than you might think, and if you get it wrong, you run the risk of providing information that is at best irrelevant and at worst misleading or even dangerous.
How do developers go about building a dashboard? Here are five important steps:
- Determine the key metrics to be shown. This is the hardest part. Clients may ask for a long list of metrics they want to include on their dashboards. But if you put too many things on the dashboard, most of them will end up being ignored, or the truly important items will be lost in all the noise. So encourage the client to limit dashboard items to a handful – a good number is usually around six or fewer.
- Decide how to display the metrics. Dashboards are intended to be visual, and different metrics are most effectively displayed in different ways. For example, if you have two measures that are being compared, a bar chart is often best. Single measures can be represented with a graphical “gauge.” For some measures, the exact number is less important than the range it falls in—in this case, a simple “traffic light” (red/yellow/green) may be best.
- Determine what controls to include. Web dashboards are generally more about information display than providing buttons and knobs, but in certain applications a client might want to take action on the basis of the displayed information, such as turning equipment on or off. As with the metrics to display, it’s best to limit the number of controls to include.
- Find the data. The data you need to calculate a given metric may not exist in a single convenient location. You may need to combine data from different systems, databases, tables, spreadsheets, flat files, or data warehouses. Some data sources may be updated in real time, and others may be updated only periodically. Some data might not exist at all, in which case you will need to ask the client some hard questions about how, exactly, you are going to calculate that metric.
- Prototype, demonstrate, update, repeat. Repeated cycles of prototyping, demos, and feedback from the client are essential to getting it right. Even then, the client may ask for tweaks after going live with it for a time.
Dashboards have become an important management tool in all aspects of business. It takes careful consideration and skill to do it right, but the reward for a client is a better handle on what’s going on with their business.
