Saviant’s Dashboard design framework

Our solution – Saviant’s dashboard design framework

Saviant’s Dashboard Design Framework (image 1) addresses these issues through a 5-step process. The arrow in the framework which cuts across these 5 steps is to highlight that this framework is a part of a whole BI Platform Project and there are steps in the project prior to as well as after dashboard creation.

This framework helps requirement elicitation teams and business teams to fundamentally re-evaluate the situation and come up with meaningful dashboards.

Now, let us look at how the framework actually works through a simple Sales Report example. For simplicity, the following terminology is used.

Report: A report is a combination of multiple dashboards where navigation between those dashboards is possible.

Dashboard: A dashboard is a standalone page and is a combination of charts. A dashboard will usually have 6 to 8 charts and will be presented in a single screen.

For better understanding of the above definitions, please refer to the sample report here, which has 3 dashboard pages.

Note: This technical terminology differs from platform to platform, however, we are using the above definitions for the purpose of understanding this framework.

Step 1: Defining report structure

Health of a function or for that matter even a KPI can seldom be covered in a few charts. “How is my Sales doing?” needs a multidimensional view. This creates a need to structure the report in such a way that it is concise yet relevant. Structure refers to a view of all dashboards within a particular report with the navigation paths. Usually a top-down approach works in this case. This means that one can begin with an overview dashboard and then allow on-demand unwrapping of facts.

This way, the landing dashboard page will show just the right amount information that is needed to understand the red flags, at the same time, help in maintaining a clutter free experience. If it is necessary to drill-down on a certain focus area, a separate dashboard page can be linked to facilitate seamless navigation.

Image 2 illustrates how a Sales Report which involves categories, brands and customers may be structured. The report will have 7 dashboard pages.

Step 2: Creating a storyline of the individual dashboard page

Establishing a structure is a good start, especially from a scoping perspective, however, much more information is required to make this report a reality. This is where Step 2 is critical. A curated set of questions enables thought provoking discussion with respect to the expectations from each dashboard page. This type of documentation eliminates understanding gaps and helps bring absolute clarity on the requirement.

As mentioned earlier, these questions have to be answered for every dashboard page and not for the whole report. A sample dashboard expectation write-up for “Sales Overview” is presented in image 3.

Step 3: Sketching a visual map of each dashboard

The next step is about visualization of requirements. The analyst team may have this responsibility in most cases. This is a creativity exercise and multiple factors drive the quality of output:

1. Understanding the business context
2. Understanding of the information in Step 2 (Dashboard expectations)
3. Know-how of the BI platform to spot tasks that may not be technically feasible
4. Strong knowledge base of similar projects
5. Secondary research skills
6. Knowledge of best practices

In addition, it is important to validate whether the potential dashboard is addressing the questions documented in the expectations write-up. This version will need a few iterations and is primarily for analyst team to work on. This may not be useful for presentation to the business team. Image 4 shows a possible sketch of “Sales Overview” dashboard considered in our example journey.

Step 4: Wireframing: Designing a formal version of the sketch

This is the magic step where everything comes together to present a visual representation of the potential dashboard. The intention is to have a version as close as possible to the final output. More importantly, this is a view of the output without spending any effort to actually build it.

At this point, it is a good idea to present this to the business team and seek an approval before moving ahead with the development. There is definitely a scope for revision and additional inputs, however, the good thing is that it will only take a few hours and not days.

Such an excellent visual view can be developed via multiple methods:

1. Maintain a library of visuals in the company knowledge base and use powerpoint to bring them together.
2. Use insert chart functionality in powerpoint/excel.
3. Use a wireframing tool (e.g., Figma) with a subscription (e.g., numerro.io).

At Saviant, there is not only a library of visuals but code, layout and validation libraries too. All such libraries along with multiple frameworks and accelerators help in building high quality BI Platforms at speed.

A possible Wireframe for our “Sales Overview” dashboard is shown in Image 5.

Step 5: Building the actual dashboard

When Steps 1 to 4 are followed with intent and rigor, Step 5 becomes the easiest part of the framework. This step is about building the dashboard and more importantly validating whether the right numbers are getting showcased. No executive will entertain a stunning dashboard with wrong data.

Additional details will be required for this step which the implementation team may ask for. Some of which are given below:

1. Aggregation logic – When to use sum and when to use average (e.g., in our example, YTD Sales will need SUM however, Service Level will need AVERAGE)
2. Calculation logic – How is New Item sales calculated (e.g., New Item sales is sales of those items that have been launched in the last 6 months)
3. Actual data for comparison with Dashboard data
4. Clarity whether a Mobile Version of the dashboard is required for on the go access
5. Other details regarding access control, deployment mechanism, refresh schedule, etc. which are specific to the use case.