Howdy!

In this post I’ll cover the basics of how to properly design a reporting dashboard.

Wait… what is a ‘reporting dashboard’?

Right… well… a reporting dashboard is a dashboard that visualizes data analytics. 

It’s important to emphasize this because the term ‘dashboard’ is very often used to describe various UI interfaces, some in which you can also perform actions or configure stuff. We’re not going to discuss such types of dashboards in this post.

So – in our case we’re focusing on a dashboard which mainly visualizes data, and the main actions you can take are setting up the filters… and that’s it.

 

Why do we need a reporting dashboard?

I guess you know the answer to this, but just to make sure everyone is on the same page here I’ll state the obvious:

A reporting dashboard is the only place where the business data and performance can be graphically visualized in a human ‘readable’ form.

Your alternative is to go directly to the database and run queries there, get the results as a table or spreadsheet and analyze it from there. Even if you were a geeky nerd who is fine with this approach – it certainly won’t work for your customers.

Hence – if your company consists of more than 5 people – then you probably need some reporting dashboards already.

 

Wait – is it for me or for my customers?

The short answer is ‘both’.

The longer answer is that while both you and your customers may need some reporting dashboards they will probably won’t look the same.

Meaning – there are different reporting dashboards aimed for different stakeholders.

Even within your company – your engineering team may build their own dashboards for monitoring the performance of their infrastructure, while you’ll have some reporting dashboards showing the business KPIs.

Your customers, however, may need a new set of reporting dashboards showing them their desired performance related to the product you sold them.

For example – if you are selling to your customers a tasks-management system, then a reporting dashboard for your customers may visualize how many tasks were completed within a given period of time, what’s the status of the various projects, etc…

 

Who is building these dashboards and using what tools?

Oh… now it’s getting interesting.

Internal reporting

There are several data visualization platforms out there, where Tableau and Looker being the market leaders at this time of writing. From my experience – engineers love to use Grafana (I guess due to its simplicity and API support).

Those are great visualization platforms for the internal stakeholders or your company. I wouldn’t recommend providing access to your customers to dashboards built by these tools, because their visualization is not great in terms of ‘eye candy’ and it may also cause you some issues with the software licenses of these products.

External reporting

Not all types of business and products require providing a reporting dashboard to customers. For example – if you are in B2C then most likely there is no need for a reporting dashboard for external stakeholders.

If your business does need to provide a reporting dashboard to customers then usually it will be designed by a UX/UI designer and developed by your engineering force (mainly front end developers). This way, it’d be possible to integrate the reporting dashboards as part of the overall dashboard or portal that the customer can access to (e.g. – the customer will navigate to a ‘reporting’ section in the bigger dashboard).

 

Ok.. but who builds it?

Well — if it’s an internal reporting dashboard then usually the data analyst in your company will build it for you. With a lack of one — there is the alternative of using analytics platforms such as Mixpanel, Amplitude, Flurry or the similars. With this approach — you’ll need to define to your developers what type of analytical events to embed in their code. These events will be sent to aforementioned platforms and then you will be able to (relatively) easily build your own dashboard using their user interface.

 

As for customer facing reporting dashboards – you’ll need a front-end development force, and it’s a bigger project that you will need to manage as any other product of yours. Meaning – running a full discovery process with your customers, understanding what data they would like to see in such a dashboard, then working with a UX and UI designer to design it and then handing it over to the development team.

If your company is big – this project might even belong in a different department, and you’ll just be a collaborator.

 

I need to spec-out a reporting dashboard – how should I approach it?

Again – if there is no dedicated department that will do it for you – then you should treat it as a full product that needs to go through all product phases, starting with discovery. The discovery process will be totally different for internal stakeholders and for customers.

Designing a reporting dashboard for internal stakeholders

The request to build a reporting dashboard for internal stakeholders usually comes from one of two sources – the business team (including the executive team) OR you…

At the end of the day – the company needs to know how it’s doing with its business goals and OKRs.

During the discovery phase you’ll need to inquire all relevant stakeholders what this dashboard must contain. On top of that you’ll need to make sure to add all main KPIs to the list, even if they weren’t requested explicitly.

The outline of a reporting dashboard

Now that you know the KPIs that need to be shown, I will outline for you my favorite approach for designing such a dashboard (content-wise). This outline catered to any case I came across in my career so far.

There are generally four parts to each reporting dashboard:

1. The filters section
2. The main metrics
3. The trends of the main metrics
4. Custom tables

 

The filters section

On the top of the dashboard there needs to be a filters section. The must have filter is a time filter. The challenge here is to understand how long back you are going to allow setting up the time filter (6 months? One year? 5 years?). The bigger period a filter is set the more data that needs to be processed – and processing will cost money and will affect the response time. 

The second decision regarding the time filter is what should be the default value of the filter (Last 30 days? Last week?).

 

Once you’re done with the time filter, there are probably other filters that make sense for your business. Usually they will be used to filter out customers from the display (such as a name filter or an industry filter). But again – it can be practically anything that is relevant to your type of business.

Whatever filter you decide to support – don’t forget to define the default value for each.

 

The main metrics

The next section is what I call the ‘main metrics’. It shows all relevant KPIs as a standalone figure. For example – a metric showing the total number of customers, the CTR or the gross revenue. 

Some of the metrics are subject to the filters section. Hence, if the time filter is set to the last 30 days and the rest of the filters are filtering out some of your customers – then some of the main metrics need to adhere to these filters. For example – if only 5 customers made it through the filters – then the gross revenue metric should show the revenue generated in the last 30 days and only for these 5 customers.

However, the ‘total number of customers’ may not adhere to such filters, and still show the total number of customers as of now and across your whole business. It really is a question of what makes sense for your dashboard.

 

The trends of the main metrics

This section is all about plotting the main metrics over time in some type of graph, where the time filter dictates the period.

For example – the total number of customers will be plotted over the given time period, so we can see how it’s growing (or decreasing…) over time.

Some metrics will require some adjustments to be properly plotted over time, and you also need to consider the screen real estate. After all – you don’t want to overflow the display with too many graphs. Therefore, consider plotting related metrics (metrics which are measured with the same units) on the same graph. For instance – gross and net revenue can be plotted together on the same graph.

 

Custom tables

This is where your discovery process will deliver most of its impact. In this part of the reporting dashboard you’ll display data tables or other graphs which were requested by the various internal stakeholders, and required for them in order to manage their daily work.

For example – a table showing data about the new customers who are still onboarding.

 

Important notes

1. If you are running into too many ‘custom visualizations’ then consider designing a dedicated reporting dashboard for each internal stakeholder group (sales, product, executive team, etc..). That’s perfectly fine and quite common.
2. If data takes too much time to load – work with your data analyst to optimize the queries and play with the defaults. Also consider moving some visualizations to other tabs/dashboards. If it doesn’t help – then maybe the data strategy of your company is not great, and you’ll need to work with the engineering time to revisit what data set holds what.
3. It’s a good practice to design dashboards that track the performance of features you release. The only consideration here is the importance of the feature and the availability of the data analysis team. Ideally you’d want this for most of your features, but you may need to compromise and for some of your features ask for ad-hoc data when needed (due to lack of availability of the analysts team).

 

Designing a customer facing reporting dashboard

To be honest – it works pretty much the same, but with some important restrictions/considerations:

1. It’s totally unpredictable when the customers will use the dashboard and how often. Therefore, restrict the filters to a resolution that can’t ‘hurt’ you in terms of costs and performance. For example – consider limiting how far back they can set the time filter (is 6 months good enough?)
2. Clearly there is a major implicit filter which is set in advance for each customer dashboard – and that’s the filter that makes sure that only the data of this specific customer is being shown for each of the customers. It requires proper data segregation on your backend.
3. Some of the metrics are irrelevant for the customers. For example – total number of customers or gross revenue. On the other hand – there are customer-facing metrics that need to be shown. Usually it’s about the value delivered by your product for the customer. For example – ‘leads generated’. These metrics should come up if you do a proper discovery process with your customers.
4. Less is more. Focus on the metrics that make sense for your customers and show the value of your product. If you are unsure if a specific metric/graph needs to be included – don’t include it, and wait for the customers to specifically ask for it. Recall – each visualization that you are adding will make your servers work more and cost more.

 

That’s it for today.

If you found this post/series useful – please let me know in the comments. If you think others can benefit from it – feel free to share it with them.

 

Thank you, and until next time 🙂