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-cen- tric”) 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.
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 data 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
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 an 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 dashboards.