Many companies use information dashboards to monitor and manage business performance. A dashboard may be narrowly focused on detailed metrics within a single department or could provide a broad view of the performance of an entire company. The ability of a dashboard to solve such a wide range of business problems is a key strength but can make the design and development process challenging due to technical complexity and scope creep. When embarking on a dashboard project, a structured, iterative approach is recommended to ensure business needs are clearly understood and development efforts effectively meet these business goals. There are six key success factors that have proven to be valuable during multiple dashboard development projects:
1. Clearly Understand Business Needs
To be successful, a dashboard must solve real business problems, so it is important to separate “nice to have” requirements from business-critical needs. Start by creating a simple list of dashboard features using the classic user story format to identify the “who”, “what” and “why” of each capability. This approach ensures that we know who will use a feature, what the feature does and why it is important to the business.
Prioritization of these requirements or stories is a critical next step allowing work to commence on the highest value features that can be delivered in the initial phase or sprint. Often projects can get bogged down at this early stage by attempting to document every possible requirement and this should be avoided by breaking the task into multiple phases, so our understanding of requirements is expanded and refined as the project progresses.
2. Strive for Simple and Elegant Dashboard Views
Dashboard design can be viewed as a blend of art and science. This can make the design process challenging as decisions on what should or should not be included can appear somewhat arbitrary and often subject to individual taste. What initially appears to be a good design might include only a small proportion of critical business metrics. Conversely, a dashboard that includes all the critical data needed to understand how a business is performing but lacks color or graphics might be bland and uninspiring.
There is a tendency to create dashboard views that look impressive, have a “wow” factor, or “pop” attracting admiration from passing users. While this attention might make us feel good, the real test of a dashboard is its ability to display business information in a clean, simple and intuitive way. Avoid selecting a chart or visualization because it looks cool or adding graphics that draw attention away from the data, consuming valuable real estate with no tangible benefit. Through the dashboard design process, continually ask if each element adds real value and displays information as simply and cleanly as possible.
3. Model Data to Simplify Ongoing Maintenance & Enhancement
A data model is the foundation of every dashboard and care should be taken to create a design that both meets functional goals and can be supported and enhanced as the business changes. As data is sourced and transformed, there are many potential pitfalls than can increase complexity and make ongoing support and enhancement expensive and time consuming. The model should allow data to be stored cleanly and consistently with a level of detail or grain that supports all the metrics that are needed. Common hazards to avoid include aggregating at too high a level and mixing data of different grains in the same fact table.
Some dashboard tools require data to be heavily denormalized or flattened, creating a blend of fact and dimension tables that can introduce complexity and inefficiencies. If your chosen tool can support a relational data model, then this is often preferable as data can be more efficiently stored, refreshed, expanded and enhanced. In environments with many business metrics, a metric table can often help control complexity and allow many different types of metrics to be efficiently stored. New metrics can be introduced quickly and easily using this approach with minimal changes to the underlying database, data model and even dashboard views.
4. Release Early and Often
Agile software development techniques are not appropriate for every IT project, but it is almost essential to avoid waterfall methods in dashboard projects. Dashboards are often one-off initiatives that address a unique business problem, making it next to impossible to develop a long-range detailed project plan. Instead, follow an Agile project technique like Scrum that supports rapid development in small “chunks”, allowing early testing of key design concepts and frequent feedback from sponsors and users.
Although early dashboard releases will often be based on small sample datasets with just a few key metrics, user feedback can still be incredibly valuable, clearing misconceptions, validating assumptions and highlighting potential problems, including data quality issues. A functioning dashboard should be released at the end of each sprint every one to four weeks depending on project complexity and team size.
5. Data Sourcing & Transformation
The process of sourcing and transforming data can be very complex and there are multiple points at which this work can be performed. Data is most often stored in relational databases or file systems and the process of extracting and preparing data can be performed in the source database, data warehouse, data lake or data mart. This typically is achieved through a series of SQL scripts to source, organize and load data into fresh tables for consumption by the dashboard tool. Metrics can also be calculated in SQL and stored in the database which reduces the load on the dashboard tool and provides a degree of governance and standardization over the calculation methods. Some of the latest dashboard products include “data-prep” tools that simplify and automate data sourcing and transformation tasks, offering the potential to accelerate the development process. Leveraging these tools can also simplify development and maintenance as transformation logic is written through advanced user interfaces that avoid locking transformation logic deep in code. Care should be taken, especially with large datasets, as these advanced tools can hog system resources and significantly slow the data refresh process.
Calculation logic using traditional approaches is essentially “locked” deep in code and changes can require the help of highly skilled programmers that may not understand the business. Essential updates or additions to the dashboard will often require code changes which can be complex and time consuming. An alternative approach is to leverage data “prep” tools that simplify and automate the process of extracting and transforming data, and pre-calculating metrics. These tools provide a more business-friendly interface that can accelerate both the initial build and ongoing maintenance and updates. Dashboard tools also allow some degree of data transformation and metric calculation in real time which provides additional flexibility, in some cases with a minimal performance hit. Often, it makes sense to use a blended approach, combining database and SQL transformations with data prep tools to load the refresh the dashboard and then perform real-time metric calculations on this foundation.
6. Promote User Adoption
A dashboard can only add value if people use it, which makes user adoption a critical element in every project. If a new dashboard just regurgitates metrics available in existing reports, it may not be compelling enough for users to change behavior. This can be a real challenge as most of a product manager’s current job may involve data extraction and manipulation rather than managing products. Someone that has built a career as a spreadsheet “jockey” may not welcome a fancy dashboard that eliminates most of this work.
Techniques to address this challenge include eliminating old reports, but this is not easy if these are created by the users themselves. Partnering with an executive sponsor that holds the organization accountable for dashboard performance metrics is one technique that can be effective. Another technique is to work closely with a small group of “super-users” that have the respect and trust of many across the organization to evangelize and support user adoption.
Engaging broadly with the user base early in the design and development process helps ensure that all key requirements and potential roadblocks are understood and accounted for. Giving users credit for key dashboard features makes them feel invested in the final product and far more likely to use and support the tool so this is highly recommended. Trust in the numbers is the ultimate test and is the downfall of many dashboard projects. Can users trust that the numbers are accurate and up to date? People will almost always fall back to old, tried and true manual reports, even though the numbers may be far from accurate.
Conclusion
Information dashboards are one proven way to unlock the value of business data. By following these tips, it is hoped that your dashboard projects will be more successful through enhanced design, development, and user adoption.
