Article sourced from Marketing NPV
Written by Tom Gonzalez, Managing Director, BrightPoint Consulting Inc.,
www.brightpointinc.com
Overview
This paper describes an emerging best practice in the design and deployment of data visualization dashboards.
The approach advocated herein is not the only one you can take in building dashboards, but one found to be particularly effective when deploying more than one dashboard to a range of business users with diverse sets of requirements.
Definitions
The word "dashboard" has become so common that it likely means something slightly different to everyone. But there are several clear distinctions to be drawn that merit taking a moment to align on terminology.
For this discussion the term "page view" is used to represent a collection of one more visual charts, controls, or UI (User Interface) elements presented within a single screen. Each page view can have many interactive elements representing specific metrics, user input devices, or a combination of both.
A "dashboard" is most often a collection of more than one of these page views, along with a mechanism to navigate between them. In the Page View that follows titled "Net Promoter Score," you will be able to filter and view data measuring product Customer Satisfaction levels.
To the left of your Page View, select a DMA (Designated Market Area). Then, move to the line chart and select one of the three market segments: Bright Stars, Steady Core or Cherry Pickers. Next, select a timeframe: 2004, 2005, or 2006. As you click through various market segments and timeframes, you will be able to view the Net Promoter Scores of the selected market segment over that given timeframe. Selecting a new DMA allows you to view Net Promoter Scores in various regions, by market segment and timeframe.
Move below to the Product Line by Channel area and select one of the three products listed: Wizard 5000, Flowbie G2, or SuperCard. Note how clicking on a product button causes the needles to move on each of the three Channel gauges. Color coded embedded alert levels on the Channel gauges allow you to quickly assess how close or far away you are from a specific threshold across each of the three Channels, Self-Serve, SMB Var, and Enterprise.
Figure 1. Net Promoter Score Page View
The Scope of the Challenge
Designing an effective UI for a dashboard can seem a deceptively simple task at first, but soon presents challenges sufficient to ensnare even the most deliberate of developers. The fundamental challenge with dashboard visualization is the conflict of having a limited amount of space in which to communicate a lot of information
Ideally dashboards are more than just business scorecards. They should do more than attempt to balance financial success with perceived business processes, in order to generate growth. Dashboards should provide users with the ability to relate and analyze large patterns of information, in order to glean new insights or understand the business condition more fully.
The UI should be designed to support the specific types of business decisions and insights users hope to gain by viewing the dashboard. This clearly requires more than just a basic understanding of the user's intent, lest we end up with a potpourri of gauges, charts, and tables that only superficially describe the health of the business and fail to uncover any meaningful or directed insights. Providing the user with an effective and engaging experience requires the effective use of layout, color, and interactivity in a synchronistic manner. For more reading on the basics of effective dashboard UI design and business requirements gathering Click Here.
But the challenge with dashboards is even bigger yet. Beyond visualization and UI lie a unique set of engineering requirements for summarizing, aggregating, and pre-calculating information computed from large data sets. For instance, showing basic sales figures during a period of time filtered by product SKU would most likely entail gathering source information from some type of ERP transaction system on an order or line-item basis. A company with any significant order volume could easily be referencing millions of transactional records which would need to be summarized across product SKU.
Adding other filtering dimensions like geography, channel, market segment, etc., quickly creates need for some type of back-end data engine to aggregate and pre-calculate this summary information. In most cases these back end data repositories take the form of a data warehouse, with some type of OLAP system to process the data within the warehouse.
Yet for many organizations, the data warehouse will never encompass all the information that needs to be referenced. Or perhaps they may not have sufficient business intelligence systems in place to collect and aggregate the information. In these cases, calculations tend to be performed by the most pervasive analysis tool employed by businesses today - the spreadsheet.
Business analysts collect data from several sources by hand in the form of extract reports, then import it into a spreadsheet and perform manual calculations to prepare reports for consumption by higher level executives. This manual aggregation process occurs at varied intervals depending on the demands of the business and may work in isolation or in conjunction with more automated back end data aggregation.
In both of these scenarios (using a data warehouse/OLAP solution to pre-calculate or manually aggregating and calculating data via spreadsheets) the dashboard designer is faced with the same data structure challenges. The dashboard will need to collect data from several sources at once and present that data in some type of hierarchal format representing different levels of aggregations and calculations. Most dashboards need some way to transform, filter, and drill across hierarchal data structures, making it critically important to engineer a solution which accommodates these structures in a flexible and consistent manner.
When it comes to a development methodology for building dashboards there is no silver bullet solution. However, there are some general principles which have been found to be effective.
Prioritizing Users Over Data
First among these principles is the choice of basic orientation. There are two alternate approaches that can be used when gathering requirements for a dashboard project: the traditional "bottom-up" (aka the "data-centric") approach; or the more contemporary "top-down" (aka "user-centric") approach.
The data-centric approach is employed most often by teams with more of an engineering focus. It concentrates first and foremost on providing flexible ways to access the data available to users.
Beginning with the underlying data models, the bottom-up method envisions the user experience through the lens of the data structures and defines the navigation and access points accordingly. Highly efficient in its multi-level data access, the risk in this approach (and the reason many good dashboard designers avoid it) is that it often compromises the subtle requirements of the users in favor of accommodating the data. This may lead to a poor outcome as success in dashboard design is not necessarily defined by having the most flexible access to the widest possible data sets, but rather by offering users quick access to the data most relevant to their specific business needs.
Figure 2. Data-Centric vs. User-Centric Approach
The user-centric approach, in contrast, begins with the questions of "what do we need to communicate, to whom, and to what degree of depth? Grounded in the requirements of the users, this path ensures that dashboard design follows a more intuition-guided experience to maximize the level of engagement amongst the executive constituents.
While this approach may seem obvious to those with expertise designing UI for web site applications, many engineers more accustomed to working on back office functionality (e.g. database and report design) might not be as familiar. Rest assured that data structures in this approach are no less important, but often need to be bent and molded through filtering and summarizing techniques, which can result in table structures that are inefficient in the classical datamart sense, but optimized for a superior user experience.
Traditionalists often raise concerns about minimizing the importance of sound data management principles, in particular when large volumes of transaction-level data are involved. However, most dashboards are not used as data-mining tools seeking insights at the lowest level of data capture, but rather performance summary systems offering a broad view of things with one or two levels of drill-in capability to answer the most common questions.
The user-centric approach requires a keen understanding of the user's needs, and the ability to design around them. This can be reduced to two fundamental questions:
- What decisions or insights does the user hope to make by interacting with the dashboard?
- What data is needed and how does it need to be presented to answer those questions?
Obviously, this necessitates securing good feedback from the user community, which can sometimes be a challenge onto itself. For more detailed information on how to gather KPI requirements for dashboard projects, please read "Key Performance Indicators and Metrics: Choosing The Right Data to Display In some cases, after gathering user requirements, it becomes clear that key pieces of data needed are not stored in the current data repository. In order to add meaningful insight to the data already available, it becomes necessary to devise a way to incorporate the missing elements. In a bottom up approach, this realization may not have occurred until the dashboard was deployed to the user audience.
Trying to design a datamart or OLAP solution for a dashboard without clear requirements from end-users is a dicey proposition, mostly because users often have a difficult time articulating requirements until they've had an opportunity to tactilely experience the dashboard for themselves by pointing, clicking, dragging, and dropping. Prior to having a chance to "play" with the UI, users struggle with the prospect of validating back end data schemas and data structure requirements as these artifacts are too far removed from the real world use of the dashboard.
Getting At End User Requirements
Gathering requirements for executive and operational dashboard projects requires an interview process which revolves around two simple questions: "What business questions do you need answers to, and once you have those answers what action would you take or what decision would you make?"
Question 1: "What business questions do you need answers to?"
The purpose here is to help the business user define their requirements in a way that identifies the requisite data behind their question. For instance, a VP of sales might have questions such as "Which sales people are my top producers?" or "Are we on target for the month?" In the case of the former, follow up with a couple of qualifying questions like: "Would this measure be based on gross sales? Would you like to see this daily, weekly, or monthly?" Spend enough time with the user discussing the question until the measure, dimension, grain, and target (in the case of a KPI) are clear. The answers will begin to illuminate the true requirements.
Question 2: "Based on the answer to Question 1, what other questions would this raise or what action would you take?"
Understanding the metric or KPI needed to answer the user's initial question, it then becomes important to find out if the user would want to perform further analysis based on that answer, or if they would be able to take action or make their decision. This process of drilling deeper into the question can be analogous to peeling back the layers of an onion; keep going deeper until you have gotten to the core, which in this case is the user's ability to make a decision or take action.
This iterative question process will quickly filter out the metrics and KPIs that could be considered "interesting" from the ones that are truly critical to the user's decision making process.
The KPI Wheel
The interview process is rarely a structured linear conversation. More often, it is an organic free-flowing exchange of ideas and questions. A KPI Wheel allows the interviewer to conduct a naturally flowing conversation with the end-user while remaining focused on the goal of gathering specific requirements.
The KPI Wheel is a tool that can be used to collect all the specific information that will go into defining and visualizing a metric or KPI, including:
- The business question that we are trying to help the user answer.
- Which business users this question would apply to.
- Why the question is important.
- Where data resides to answer this question.
- What further questions this metric or KPI could raise.
- What actions or decisions could be taken with this information
- The specific measure, dimension, grain and target of the metric or KPI.
Figure 3. KPI Wheel
Start Anywhere, but Go Everywhere
The KPI Wheel is designed as a circle because it embodies the concept that you can start anywhere but go everywhere, thus covering all relevant areas. In the course of an interview session, you will want to continually refer to the wheel, to ensure that all areas are filled in as they are discussed. As your conversation flows, you can simply jot down notes in the appropriate section, making sure to follow up with more questions if some areas remain unfilled.
The beauty behind this approach is that a user can start out very high level "I want to see how sales are doing" or at a very low level "I need to see product sales broken down by region, time, and gross margins." In either scenario, you are able to start at whatever point the user feels comfortable and then move around the wheel filling in the needed details.
Throughout your user interview you many end up creating several KPI wheels and referring to many of them as the conversation progresses. At the conclusion of your interview process, a natural order and hierarchy will develop to the metrics and KPI requirements you have collected. The various KPI wheels you have created can serve as building blocks for your initial dashboard page view designs.
Prototype, Prototype, Prototype
The user-centric approach lends itself to a more agile and iterative project life cycle than traditional waterfall development methods. Recognizing the dynamic nature of most businesses today, it is a good idea to approach the dashboard project with the assumption that significant changes and improvements will be made to the solution over time, and the first generation of dashboards will likely not bear much resemblance to the 3rd or 4th.
For this reason, it usually makes good sense to start off with a pilot or prototype project where proportionately more effort has been put into developing a rich and functional UI, with less effort concentrated on the immediate need for back end data structures. Over time as the dashboard matures and requirements are better defined, adoption increases and more focus is placed upon building the back-end of the solution to achieve more stable data modeling and data storage. This is how the user-centric approach winds up avoiding the expense of iterating through multiple data warehouse and ETL design revisions.
In the traditional data-centric approach to datamart design, much of the focus is put on determining which fact and dimension tables are needed to support user querying. Missing a key dimension or fact table can render the datamart useless for certain types of analysis that no one anticipated needing.
By starting small on the back end (spreadsheets and simple databases) and iterating towards a more finalized UI design, there is a higher probability of pinning down the specific data requirements for the back end before it's built. This can result in huge cost savings since the development time to change and modify a UI is normally a small fraction of the cost to design, develop, and transform large volumes of transactional data into a data mart or warehouse.
The other benefit to a "UI first" approach is putting a meaningful analysis tool in the hands of end-users sooner since there are no long development cycles spent fine tuning large volumes of data. Not to suggest that it may not eventually require a sophisticated back-end to support the ultimate dashboard design. Most often, the underlying datamart emerges in step with the users' ability to articulate requirements. But an elaborate back-end is not a prerequisite to a meaningful dashboard solution.
Most dashboard initiatives start small and then grow like wildfire once users start adopting them. Therefore, if you're building more than one dashboard it is important to create a repeatable and flexible framework so each one does not become a unique project onto itself. This is inevitably the case as over time dashboards usually grow from one or two operational views to a company wide solution with dozens or hundreds of interfaces.
Summary
The user-centric approach to dashboard design provides for a solution that is both intuitively-guided and cost-effective. Designing from the user experience backwards maximizes the level of engagement. Users can "play" with the dashboard first in prototype before having to validate any back end data schemas or data structure requirements. Changes to the UI can be made easily, up front as users further define their needs before the dashboard is built, resulting in savings as development time to change and modify a UI is relatively small in comparison to the cost involved to transform large volumes of data into a data mart or warehouse.
Ultimately the "user-centric" approach to establishing requirements for a dashboard project may prove to be more time and cost efficient when you keep in mind that dashboards typically grow from one or two operational views to dozens or hundreds of interfaces.
About the Author
Mr. Gonzalez is the founder and Managing Director of BrightPoint Consulting, Inc. Tom's primary role at BrightPoint is leading the design and development of customized business intelligence solutions that incorporate his visionary approach to software design, resulting in immersive, interactive, and intuitive end-user applications.
For over 20 years Tom has followed his passion in developing innovative and value driven software applications both large and small, with proof-of-concept projects lasting days to multi-million dollar, multi-year development efforts. During his career, working for such notable clients as Apple, Adobe, Business Objects, BP-Arco, Kimberly Clark, Northrop-Grumman, Symantec, as well as many others, Tom has developed a multi-disciplinary approach to developing data-centric applications by uniquely combining his experience in software architecture, data warehousing, data visualization, business process, application development, user-centric design, and visual arts.
Tom graduated with honors from the University of California, San Diego, where he studied a unique combination of Computer Science, Visual Arts, and Economics. He currently resides in Carlsbad, California, with his wife and two sons.
© 2008 MarketingNPV LLC. Used with permission.