A dashboard, not to be confused with the term Balanced Scorecard, is “an easy to read, often single page, real-time user interface, showing a graphical presentation of the current status (snapshot) and historical trends of an organization’s or computer appliances key performance indicators to enable instantaneous and informed decisions to be made at a glance.” (quote from: Peter McFadden)
For Business Intelligence purposes it is implemented in Management Information Systems in order to show significant, often aggregated, information on a computer screen to enable individuals to be decision makers. This gets done by offering a reliable data basis for daily work and it has to be ensured that it doesn’t confuse or mislead by being wrongly designed. Unfortunately this is not part of the intention vendors have. They often try to impress by stressing graphical highlights, as branch expert Stephen Few stated: “An effective dashboard is the product not of cute gauges, meters, and traffic lights, but rather of informed design: more science than art, more simplicity than dazzle. It is, above all else, about communication.”
To achieve all this intents by automatically reporting, it is required to transform data out of the sources into information in order to enable the user to take the next step in the commonly known knowledge pyramid which means using humanous skill to make that into knowledge.
Very often a dashboard is one possibe last stage on the „long way of data“, as it can be seen from a technical point of view. At first data is transfered into the company’s data warehouse, then divided into several data marts and then analyzed according to pre-defined OLAP procedures and to present the most important key performance indicators. A dashboard usually fits a single screen so it is enormously important to consider the actual size of its elements in particular, in which frequency it is refreshed and updated, the characteristics of the users (e.g. appointed tech-professionals or a group of white collar workers) and afterwards use all this knowledge to design whole in the best way possible.
The one basic and elementary question, that always has to be asked, is: What is the best way to create the ‚perfect‘ dashboard starting at the very beginning? To start that requirements analysis it has to be defined what the final goal for that dashboard is, what type of knowledge should result out of this analysis.
When coming to design it has to be distinguished between two two kinds of data which can be presented: quantitive (like aggregated numbers and figures which can be measured and compared with each other) and non-quantitive data (for example individual names or subjects). Since an user also is a human individual, there is a need to ensure that he isn’t overwhelmed with information by highlighting the most important information visually. The general creed should be ‚Keep it short and simple‘ by varying KPI charts in size, using meaningful chart types and remove all already-known, redundant ‚non-data‘ pixels and visual application gimmicks.
To sum it up it can be summarized into „emphasise the purpose of communication and keep it as simple as only possible, no matter how tempting the opportunity of graphical gimmicks is“.