Best Practices for Building Digital Dashboards
3. Best Practices
Best Practices are the guidelines for building digital dashboards that we believe result in a useful dashboard. While you can design a digital dashboard however you wish, the following practices result in a much more useful, efficient, and aesthetically pleasing dashboard. These practices are also extremely useful when starting the design process of a dashboard project.
3.1 Target User
The first and most important practice of building a dashboard is identifying who your target user is. A dashboard aimed at an executive of a company and one aimed at the marketing director are going to be very different. During the entire development process the end user should be kept in mind and the application tailored to this user. The tailoring process may include simple things such as placement of controls or data sources, but it can also include more complicated things such as the flow of the entire dashboard, or viewing secure data through a secure connection.
3.2 Right tool for the right job
A difficult requirement of building a digital dashboard is to decide what type of data visualization to use for different kinds of data. Generally, data should be displayed as follows:
- Geographical data (i.e. Sales by Province in Canada) – Map
- Data over time, ratio data, comparison of linear data – Chart
- Snapshot data, single values (i.e. KPIs) – Gauge
- Multidimensional data - OLAP
- Other data – Diagram
Using this list should make it easy to break down any data into a group and display it with the appropriate data visualization tool. Further to this, making a dashboard dynamic so that the user is free to change the data visualization on demand is also a good practice, as there may be a perspective the user wishes to view that cannot be predicted while developing. Often times there are ways to get dynamic controls without having to code yourself, an example being Dundas Chart for OLAP Services which has a lot of end-user manipulation controls already built-in to the control.
3.3 Correctly Identifying KPIs
A KPI, or Key Performance Indicator, is a quantifiable measurement that reflects the factors which contribute to success within a company. Usually different people within the company or third party consultants agree upon these measurements beforehand, but sometimes these are defined by the dashboard developer. It is imperative that KPIs be chosen correctly, if they are not it can amount to incorrect data leading to bad decisions. Research and time should be devoted to learning the organization or group’s important indicators of success as this could make or break a dashboard.
3.4 Context
Context is an item which in most dashboards is completely forgotten. This is baffling, as without context, KPIs are completely useless. Consider the following two items of data:
Figure 7: Example data with no context
After a quick glance at Figure 7, the following assumptions are made: Nick is doing really well in sales and everyone else is not, and the revenue per sale is pretty high. This, however, may not be the case.
Figure 8: Same data as Figure 7 with context
Figure 8 shows the same data with context. In this case, it is clear from the chart that no employee has hit the sales target this month. As well, it can now be observed from the gauge that the revenue per sale is not within the expected range. Ideally the gauge should be further improved by an explanation as to what the range and marker are, but at the very least marking the gauge gives it sufficient context.
While giving context to data may seem like an obvious step, it is the most omitted practice by developers of dashboards. In most cases, context is left out because the person creating the dashboard has been working with the data so much they know what “good” and “bad” data is. This assumption, however, cannot be applied to the end user as they may draw false conclusions.
3.5 Layout and Clarity
Layout encompasses the design and placement of controls within a dashboard. While this aspect may seem unimportant, the layout can have a huge impact on whether or not users can easily use a dashboard. The layout should be in a logical and fluent order with respect to the specific data that the dashboard is showing. The dashboard should also conform to the 3 and 10 second rules; within 3 seconds the user should have an idea as to the overall performance of the subject, and within 10 seconds the user should have a general idea as to why this performance is being achieved. For example, if a user were to look at a well designed marketing dashboard, within 3 seconds they should know what marketing campaigns the company is currently engaged in and how each is doing, and within 10 seconds know which campaigns are doing best and perhaps have some idea as to why. If the dashboard is too unintuitive to conform to the 3 and 10 second rules then it will not be useful.
3.6 Visual Aesthetics
Visual aesthetics include animation, palettes, 2D and 3D effects, and the general look and feel of the actual controls. This is closely related to the layout of a dashboard but is concerned with the aesthetic appeal of specific items within a dashboard rather than the overall design. While visual aesthetics are important in making a dashboard attractive, developers must be careful that the visuals do not interfere with the usability and efficiency of the digital dashboard.
3.7 Customizability
While great care should be taken in deciding what data is important for the user of a dashboard to see, providing some ability to customize the view is a good practice to follow. This point is especially true in OLAP driven digital dashboards where the data is multidimensional and the only way to formulate a coherent picture of the data is to view it from all angles. As well, giving the user the ability to change their perspective of the data often allows them to see trends or important changes within it that the user may not have been able to see otherwise. Reporting Services is an excellent example of a tool that is devoted to giving the user the ability to modify the underlying data query with little effort, and as such has enjoyed great success in the enterprise market.
4. Build a Dashboard
Before starting on a dashboard there are a few steps that should be considered. First, the platform that is used for the dashboard can have a severe impact on the available functionality. For example, Reporting Services was mentioned above for its ease of end-user customizability with respect to data. While this is true, Reporting Services has limitations when it comes to interaction with controls – something that the .NET platform does not. Thus, if it is of extreme importance that the user can highlight, zoom or select points on a Chart then Reporting Services would not be the right platform to choose. Making this decision before beginning implementation can save a lot of time, effort and headaches that can occur later in the development cycle.
In the same tone as platform choice, data storage choice is also a factor that should be considered before beginning implementation of a dashboard. Sometimes organizations will already be using a format for their data storage and may not be willing to have copies or move the data around. However, if this is not the case then choosing, for example, a standard SQL database or an OLAP database will result in very different data structures designed for very different data sets. Careful consideration should be taken when choosing a data storage format to find one that best fits the data.
When the above decisions have been made and implementation has begun, the last thing to do is to follow the best practices. This point may seem a bit redundant, especially given the topic of this paper, but ignoring any of the practices can have a serious detrimental effect to a dashboard project. If you are unsure of how to proceed when creating your dashboard, or do not have the resources to create one, Dundas Software offers our years of dashboard experience as an available consulting resource should you require it. Our consulting services can greatly speed up the development of a dashboard project as well as clarify any of the practices outlined above, resulting in an efficient and useful digital dashboard.
5. Conclusion
At the beginning of this document it was stated that a digital dashboard is a tool that allows a user to quickly monitor and analyze the performance of an organization or group. To this end, the best practices (Target User, Correctly Identifying KPIs, Context, Layout and Clarity, etc) have been formulated and written. Each practice has been carefully devised and clarified over the years to ensure that a dashboard following the practices will result in far more clarity than a dashboard that does not follow the practices. Readers of the best practices often think them to be obvious, but a quick look around at the numerous dashboards available on the internet shows that very few follow any significant number of the outlined practices, and almost none follow all of them.
The products offered by Dundas Software are all used for data visualization and fall naturally within the realm of digital dashboards. The .NET products, Dundas Chart, Dundas Gauge and Dundas Map are all designed to be flexible and end-user friendly, as well as easy to data-bind in order to make building a dashboard easy for a developer. Dundas Software also offers the same products for Reporting Services, and in addition, Dundas Calendar, as well as currently investing in Share Point and Windows Presentation Foundation for future products. With the wide array of platform support and data visualization tools available from Dundas Software, any dashboard can be built quickly and easily using a product that fits the requirements of the user. These products, combined with the best practices outlined in this document result in an efficient and useful dashboard every time.