Radha R would like to thank Derick Jose, chief architect with the business intelligence practice at MindTree Consulting, for contributing this month’s column.


In today’s world where people are inundated with more data than they can process, dashboard design plays a very important role as it is the central conduit through which information flows to the decision-maker.


If we do not present the right metrics in the right form at the right time, the business users can end up making the wrong decisions, impacting the business process.



Let’s consider some of the questions faced while designing a dashboard:


  • Am I measuring the right key performance indicators (KPIs)? What are the domain specific metrics that are best practices to measure the health of a business process?
  • How actionable is the information I am presenting on the dashboard?
  • Where did I draw the data for the dashboard from? How hygienic is the quality of the dashboard data?
  • Does your dashboard show context to the information? Is the source of information tagged to the dashboard? Can the end user find out when the dashboard information was last refreshed and when the next cycle of refresh is going to be (daily, weekly, monthly)?
  • Are the right analytical constructs used to synthesize insights?
  • Are the insights disseminated to points of action, empowering people to act on them? Do they know all the action options?
  • How actionable are these insights that are disseminated? Are they synthesized?
  • Does your dashboard “action enable” the consumer of the information? For example, can they invoke the mail utility from within the portal dashboard to send a mail request or trigger a transaction to reset the reorder point in a supply chain scenario?
  • Does your dashboard give the provision of adding end user comments to the information presented?
  • Can your dashboard guide a new user through a prescribed path to do analysis in addition to exposing them to cubes to explore data at will?

All of these are critical elements to be addressed as a part of the dashboard strategy.


Benchmark Key Performance Indicators with Industry Standards


The following section distills some of the dashboard related findings I have experienced while executing customer projects.



Many customers, at some point in time, want to know if the metrics they are measuring are the right metrics to monitor. Many at times customers have found that the metrics they are tracking are not the right ones to track. Doing a gap assessment with industry benchmarks aligns you with industry best practices.


For example, a leading glass manufacturer wanted to audit the metrics, which they currently use to monitor the health of their sales, finance, manufacturing and sourcing process. An “as is” map of all the KPIs and the business processes they monitor across sales, manufacturing, finance and sourcing was done. These metrics were then benchmarked against the SCOR supply chain metrics framework. SCOR is a business process reference model created by an industry consortium. The resulting gaps in KPIs were isolated and a strategy was outlined to capture and source those metrics. The SCOR metrics framework broadly covers three areas:


  • KPIs related to business process in sourcing of raw materials,
  • KPIs related to manufacturing and
  • KPIs related to distribution processes.

Wrap the Dashboard Metrics with Contextual Metadata


Often when a report or a visual dashboard/scorecard is presented to the business users, many questions remain unanswered. The following are some examples:


  • Where did you source this data from?
  • While loading the data warehouse what percentage of the data got rejected/encountered data quality problems?
  • Is the dashboard presenting “fresh” information or “stale” information?
  • When was the data warehouse last refreshed?
  • When is it going to be refreshed next?
  • Were any high value transactions that would skew the overall trends rejected as a part of the loading process?

As a part of MindTree’s reusable business intelligence (BI)components (RUBIC) framework for quality enhanced and accelerated BI implementations, there are multiple good practice contextual metadata elements to consider:


  • Which are the sources of the data? This question helps understand if it is the authoritative source.
  • Who owns this data? The answer helps determine data quality.
  • When was it last refreshed? This question highlights actionability of the information.
  • When is it going to be refreshed next? This helps understand the latency of information.
  • What percentage of data got rejected? This helps understand if there are “does not feel right” data skews.


Validate the Dashboard Design by a Usability Specialist


In most dashboard environments, the dashboard is designed by a tool specialist without giving consideration to usability principles. Even though it’s a well engineered data warehouse that can perform well, many business users do not use the dashboard as it is perceived as not being user friendly leading to poor adoption of the infrastructure and change management issues. Upfront validation of the dashboard design by a usability specialist can mitigate this risk.


For example, a leading auto manufacturer in the U.S. wanted to present a supplier dashboard to about 2000 suppliers. One of the factors driving adoption of the dashboard by the suppliers was its flexibility and user friendliness. The client invested in a packaged BI solution whose default screens where not very friendly. This was clearly identified as a risk by the client. In order to mitigate this risk, the team recruited an experienced designer whose inputs were factored. The final dashboard was engineered, keeping in mind user friendliness and usability, leading to higher adoption by the suppliers.


Prioritize and Rank Alerts/Exceptions Streamed To the Dashboard


Because there are tons of raw data, it is important to have a mechanism by which important exceptions/behaviors are proactively pushed to the information consumers. A business rule can be codified, which detects the alert pattern of interest. It can be coded into a program, using database-stored procedures, which can crawl through the fact tables and detect patterns that need immediate attention of the business user. This way information finds the business user as opposed to the business user polling the fact tables for the occurrence of critical patterns.


For example, in a retail scenario, if a store is continuously inflecting downward in sales for the third time in six months, then this is a pattern of interest to store managers.


In a supplier spend data warehouse application, if multiple payments are made to the same supplier and the average value of the transaction exceeds 30 percent of the last six months moving average, then this is an interesting alert to probe further from a fraud perspective.


Enrich Dashboard with Business Users Comments


When the same dashboard information is presented to multiple business users, a small text box can be provided that can capture the comments from an end user perspective. This can often be tagged to the dashboard and put the information in context, adding a lot of perspective to the structured KPIs being rendered.



Present Information in Three Different Levels


Information can be presented in three layers depending upon the granularity of the information: the visual dashboard level, the static report level and the self service cube level. When a user navigates the dashboard, a simple set of 8 to 12 KPIs can be presented to the business users, which would give a sense of what is going well and what is not. For example, in a retail context, a store manager who wants to understand which categories of products are experiencing stock outs and which categories are slow moving can use a simple static report. If a store manager wants to drill further, he can invoke a cube that has both promotion spends and store sales so he can validate the effect of promotions on sales.


Pick the Right Visual Construct Using Dashboard Design Principles


In presenting information in a dashboard, some information is presented best with bar charts, some with time series line graph and, when presenting correlations, a scatter plot is useful. Sometimes merely rendering it as simple tables is effective. Once the dashboard design principles are explicitly documented, all the developers working on the front end can adhere to the same principles while rendering the reports and dashboard.


Provide for Guided Analytics


In a typical organization, business users can come at various levels of analytical maturity and the capability of the dashboard can be used to guide the “average” business user in order to access the same navigational path as that of an analytically savvy business user.


Consider a data warehousing consulting exercise done by MindTree for a glass manufacturer. The head of sales mentioned that he had a team of close to 200 sales people in the field, some of whom were extremely savvy with respect to data analysis while the others were more or less average. The requirement of the sales head was to codify a “guided analytics” scenario that would help the average sales person doing analysis on the path that an experienced analyst would traverse.



In the long run, with the excesses of raw data overflowing all around us, the competitive advantage shifts to those with ordered actionable information. It is no longer important just to process vast amounts of raw data by increasing the throughput of data warehouse infrastructures. Power shifts to those who can explain what is worth knowing and why. Thoughtful dashboard design is one of the essential components to achieve this final state.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access