The ultimate goal of a custom digital dashboard is to assist the user in making informed and timely decisions for improving business performance. But the digital dashboard space is filled with a wide variety of players, including an abundance of business analysts and software developers. It is the view of Dundas Consulting that business people don't always understand the technical requirements of dashboard creation - and developers sometimes misunderstand the business needs. There seems to be few entities who can bridge the gap between the two camps.
The following discussion provides a step-by-step summary of how a dashboard develops from a fuzzy idea into an actual, usable business tool. From visualization techniques to sound technical implementation to the end-user experience, the dashboard created must represent the data correctly while satisfying the user's individual processes and needs. Although every project will have its own idiosyncrasies, here are the five common steps we usually take:
Step One: Business Requirements
To start, you need to understand the business metrics you want to see. There's no point in talking about your dashboard's cool tooltips or fancy hover-overs until you identify the kind of core data you want represented. Think about the tale you want your dashboard to tell. This story should be clear and concise, but flexible enough to be told many different ways.
Less figuratively, metrics should be immediately visible and understandable; they should be easy to manipulate via the interface in order to get the view of the data you need. The first thing we do is try to get an understanding of the client's business and identify the current business processes by working with their analysts or end users. This information establishes a foundation for creating the right dashboard for that particular client by identifying the key metrics affecting the performance of the company.
Step Two: Understanding The Underlying Data
Next, a look at how this group of metrics maps to the actual raw data is needed. It's common to find more than one database in a business and we often see disparate data stores with no unified data warehouse for analysis. A good understanding of database technologies is helpful and it's always preferential to work with a client's database team, as they usually know their data better than we do!
Frequently, we recommend the client consolidate their databases into one centralized storage location for the reasons of performance and maintainability. These options are usually presented:
- One, replication or batch jobs to grab only the necessary raw data for the metrics and place it into a centralized database; and
- Two, for real-time data, use web services or any other network data-transfer methodologies to pull data directly from the databases.
In the end, either the client's or our database team will then provide a data access API. This data access layer will simplify and streamline the pulling of data from the consolidated data source generated for the application.
On a side note, it should be stated here that we've recommended many clients go with stored procedures - or concepts of stored procedures - whenever possible. This separates the application from the data sources in a maintainable manner, e.g., there are no database query strings in the application code. While there are times when it makes sense to mix the business logic into the stored procedure, most of our projects usually handle the business logic from the application side. (Business logic refers to the functional algorithms that manipulate data into a consumable form for the U.I.) With all this in mind, we're now ready to get on with the dashboard.