Skip to Content

Xcelsius Dashboards – Do it yourself!

How you go about gathering the requirements from Business to build Dashboards?

How you engage your users during the development stage of Dashboard project?


These are very important questions, because we know that a good Dashboard is not defined by how many different data interfaces it is able to read data from e.g. XML, WSDL etc. but is defined by how a dashboard is able to engage a user and help a user to see the bigger picture.


A great dashboard is one which empowers a user to make an intelligent and actionable decision. “Empowerment” I believe is the key here and a user should feel empowered as a direct result of using a dashboard and also while being involved during the development phase of a dashboard.


In a quest to outline good dashboard design checklist, I came across a very good article by Zach Geminani on what he refers to as “Information Experience“. In the article he discusses four objectives which can be applied in general to any dashboard initiative or a project.


Below is the outline of the checklist to meet the objectives of “Information Experience”.




The outline above is a great starting point and it helped me to try a brainstorming and requirement gathering process a year back.


The basic objective was to engage the business user to go through the process as if they are developing the dashboards themselves. This helps, as business user, to adhere to guidelines and to think through the relevance of specific information. The process also ensures that once a dashboard is created and deployed, its adoption is immediate.


I am sure, the process might not be a perfect one, so it is important for me to share it and see if it can be done in a better way.


Below is the presentation, which discusses the process involved.



You can download the Dashboard Components and Template from locations below.


Dashboard Components:

Dashboard Template:


You must be Logged on to comment or reply to a post.
  • Why just add a maximum of 4 components?
    Maybe, I misunderstood that point.

    IMHO dashboards should offer rich information, and not be sparse. “Small multiples” for example support multi-variant analysis. Another great chart types are the “bullet charts” (see Stephen Few) combined with “sparklines” (see Prof. Edward R. Tufte), because of the rich information they offer (high data density).
    KPIs should be enriched with context, for example, time series, or same period this year versus same period last year or versus KPI of competitors.
    KPIs that belong together should be shown together at a gölance, meaning on the same screen, e.g. Profit Margin in %, Profit Margin in $ (or Revenue in $) and customer satisfaction, etc.

    Visualizations one should stay away from, because they offer only sparse information or are just poor viszualizations:
    – Gauges (sparse information)
    – Pie Charts (poor visualization: the human eye cannot very exactly compare angles or areas)
    – Dual-y axis charts (poor visualization: often it is not clear which KPI/measure belongs to which y-axis)
    – Stacked charts (poor visualization as the different segments cannot be compared easily, but for the bottom segment and the total)

    Stephen Few has written a recent article:

    • Thanks Andreas for sharing very valuable points!

      Adding the 4 components was only specific to my project i.e. to begin with something simple and at later time explore the possibility of combining 2-3 dashboards into one dashboard.

      The process or presentation is not a for experienced team of developers to brainstorm among themselves as they have to apply principles you mentioned above.

      It primarily is to engage the Business user who is not aware of detailed aspects of Information consumption. And of course, the process is supposed to supervised by experienced Information Team member.