Contrary to first impression, an “executive dashboard” is not found in a CIO’s car. Rather, an executive dashboard, also known as a manager dashboard, executive cockpit, or digital cockpit, is a child of what in the 1980s was referred to as the Executive Information System (EIS). These systems, and their web-based progeny, all have the same goal: bringing critical information to decision makers and improving the performance of a business.
Who uses them and why?
An executive dashboard (referred to as “dashboard” for the rest of this article) is an intranet for a select group of users. These users tend to be executives—VPs and above, the people who are the main decision-makers in the company.
However, not all new dashboards are for executives and their ilk. As organizations push to become more nimble (and hence more competitive), dashboards are now being developed for managers of all stripes. When developing a dashboard, don’t be surprised if you hear phrases such as: “Every employee a CFO.” These reflect a realization by companies that faster decision-making helps them succeed. This means giving managers the ability to make decisions on their own. Companies are finding it’s much better to allow a manager to make an immediate decision in response to a market opportunity than to force him to wait for the CFO, or some other executive, to be alerted to the opportunity and then make a decision.
A dashboard supports a manager or executive by doing three things:
These types of questions require the ability to explore a series of KPIs. Also, they require drilling down into figures based on time or region, or selecting and comparing variables. In this case, it is important that the information is presented in a way that helps the executive or manager come to a conclusion about the issue they’re confronting, and construct a rationale to support the decision they make.
The backbone of the dashboard
The heart of any dashboard is
the KPI. KPIs can measure all sorts of things, such as:
These measures can be financial or operational, but at the very least they should say
something important to the user about the business. KPIs are most often presented in tables, charts,
and graphs. Different executives and managers will need different KPIs to support their views of
The data for each KPI has to come from
somewhere. For each KPI it is important to know:
The source data will often be kept in a variety of places. Some of these will be operational systems, such as SAP or PeopleSoft, and some will be data warehouses. It is important for information architects to understand where the data is coming from, and how it is getting into the dashboard. Data accessibility will have an impact on how the dashboard is designed.
During the requirements-gathering phase of the project, executives and managers will voice the need for different KPIs. Also, based on their level within the organization, some information may have to be protected from some users. Information architects should have a clear understanding of these limitations to ensure that the right data is delivered to the right people.
Users will also want to customize the dashboard. The dashboard’s interface should also allow users to pick which KPIs they see first, as well as set their own alert levels. Users’ interests may change over time, and alert levels can change depending on the business environment. Pre-set alert levels should be programmed into the dashboard, if these are known, but unless the business requirements state otherwise, users should be allowed to change these to suit their situations.
Finally, the more robust portal servers will allow integration of other business systems into the dashboard, such as email, news feeds, and so on. These should be included, if possible, since they will only increase the value of the dashboard and the likelihood that the user will, in fact, use it.
Since not everyone is interested in the same set of KPIs, and since the structure of the company may require that some information is screened from particular users, a good portal server will be required, or a server platform that can provide similar functionality. If the company already has portal software, then it would be wise to take advantage of this.
Dashboard projects can sometimes move a bit slower than other projects because the target audience—executives, mostly—are harder to schedule time with. If the dashboard is for senior executives (the CEO, for example), then it will be very unlikely you will be able to interview your users (with the likelihood decreasing as the size of the company increases). Usually, at this point, the client will appoint someone to identify the needs of the senior executives, and he or she should be able to provide you with most of the information you need.
However, there are some other things you can do to help make the dashboard as useful as possible:
Understanding the technology
A large part of ensuring the success of a dashboard project will be getting the technology right. As an IA, you will probably not be expected to manage this part of the project, but it will be critical that you understand the possibilities and limitations of technology. The following are some things to keep in mind.
There are many companies that provide systems and software for the BI space, and they all offer a variety of features. Some of the players currently develop systems to manage business information, such as SAP, PeopleSoft, and Siebel. Others develop data warehouses and analytic tools such as data-mining tools. Some of the players here are Oracle, Hyperion, Cognos, and Business Objects. This is by no means a complete list, and each vendor offers a different set of capabilities. Most have some sort of dashboard offering that is tied into their own system.
However, the information needed to create an effective dashboard rarely lives in just one system or database. Most organizations use a variety of these systems and may even have a few home-grown solutions as well, including Excel spreadsheets. On a recent project, the client captured much of their financial information in Hyperion Essbase, operational information in SAP, and sales information in Siebel.
Moreover, many of these systems are not known for their ease of use. Often they present too much—or too little—data, and sometimes they are not customizable by the user. The graphs themselves may be confusing.
Understanding exactly what information the executive or manager needs, and why they need it, will help you make a decision on how current the data needs to be on the dashboard. Sometimes data that is a little older may even be better, since the executive or manager will have more faith in its reliability.
Once charting software is chosen, you might perform a test to help clarify its limitations. Design one chart or graph, and then try to generate that using the charting software. You may find that you can’t make the font as small as you would like, or that other design elements cannot be represented as you intend. It’s better to find this out sooner rather than later.
Another thing to keep in mind is that not all reporting software generates charts on the fly. Especially if charting is a part of a BI system, be sure you understand how often charts are generated, as some BI charting applications generate charts on a daily basis, rather than on demand.
You should keep in mind that dashboard projects often come about because of frustration with existing systems. Often, the current BI systems have not been stitched together in a meaningful way (there are too many of them, or they are not integrated), or the systems are less than useful because the information is presented in a way that is not immediately comprehensible or useful.
For an information architect (at least for me) this is the most exciting challenge: Organizing data in a way that is meaningful for the user, as opposed to reflecting how the systems collect and manage data. It is the essential Tufte challenge: how to take massive amounts of data and clearly tell the story inherent within it.
Tables, charts, and graphs
When using reporting software, be wary of options that look great, but don’t tell the story you’d like to communicate. For example, 3-D options may look nice, but they add a lot of excess “chartjunk” and detract from the story you’re trying to tell. For the busy executive, quick comprehension outweighs a pretty picture every time.
The user must be able to compare the data to either the past or the projected future. Incorporating past data will help give the executive or manager perspective on current data. Incorporating projections will help the user see where they are headed if the current state remains unchanged. Almost every KPI should have some time element incorporated into it for these reasons.
Scope refers to the ability to drill down into data, or roll up data. For example, if an executive is experiencing extreme growth for his or her business unit, they will want to know who or what is responsible. Giving them the ability to drill down in data based on geography, or sub-group, or some other variable, will help provide them with answers to their critical questions.
The ability to navigate along these dimensions will improve the value of the dashboard immeasurably.
The steps one follows to build an executive dashboard are not too different, if at all, from the steps one would follow to build a “normal” website (if there is such a thing). However, the target audience, and the types of information being presented, place demands on the project which are different from the average web project. It may also require the Information Architect to spend more time worrying about technology than he or she is used to.
But, putting these issues aside, designing an executive dashboard presents an almost pure data-design challenge-one of the few an IA can find in the web world. It gives the IA an opportunity to understand specific questions, and then try to answer those questions using data presented in tables, charts, and graphs. As an IA who also considers himself an information designer, this is a wonderful opportunity indeed.Articles
About Alex Kirtland
Alex Kirtland is a Senior Information Architect and Experience Lead and is currently working as a freelance consultant. He has worked with a variety of companies and organizations, including Kodak, Verizon, Avaya, Western Union, and the Federal Reserve Bank of New York. He has experience with a diverse set of project types, from executive dashboards to metadata strategies to recipe finders. Most recently he has helped the Rodale Press redesign their online magazines, including MensHealth.com. If you want to learn more about him please visit his website www.alexkirtland.com.
Kirtland, A., "Executive Dashboards", DSSResources.COM, 01/20/2006.
Alex Kirtland provided permission to archive this article at DSSResources.COM on December 5, 2005 and he received permission from boxesandarrows.com where it was initially published. This article was originally published 11/24/2003 at URL http://www.boxesandarrows.com/view/executive_dashboards. This article was posted at DSSResources.COM on January 20, 2006.