7-Step Process to Build a Dashboard (2024)

One of the most effective and straightforward ways to convert data into an asset is to make it accessible to your business in an easily consumable manner through a dashboard. Never overlook the power of simplicity - dashboards with the right amount of information, at the right hands, at the right time can empower organisations in unimaginable ways. When used correctly, dashboards can help make an informed decision allowing you to see what you are doing right, where you need to improve and what the trends are. However, more often than not, majority of the dashboards meet a dead-end - i.e. users don't feel a personal connection to the end product either because the information isn't meaningful, is difficult to use/navigate or even to find.

Broadly, there are three basic types of dashboards - operational (real-time data related to daily operations), analytical (interactive and trends - influence future decision making), strategical (tracking KPIs and strategic objectives). Does not matter which type of dashboard you are trying to build - you can ensure that they don't meet a similar fate. This article will look into how to make your dashboards personal and how to avoid dead-ends simply by following some steps to design and build great dashboards.

The 7 Step Process

1. Requirement gathering

This is the most important step of the process - asking your users and stakeholder the right questions and gathering accurate requirements. It will set a solid foundation for your build and will deeply influence your next steps as well. There are a number of things you may want to consider at this step:

• Understand the type of request: Is it a one-off data extract/analysis or a visualisation project that requires a periodic refresh? Not all requests need to end up being a dashboard. If an ad-hoc request/need can be satisfied using a simple Excel table - then choose that route by all means.
• Who is your intended user base/audience? Find out who is going to use your dashboard. What are the problems the users are trying to solve or what are the potential hypothesis would they like to test using the dashboard? Tailoring your dashboard depending on the user type will make it more personable. E.g. a sales representative will need detailed data about his/her area with multiple drill-downs and the ability to cut and slice using a number of dimensions. Whereas, an executive may want to see only the most important Key Performance Indicators (KPI) to flag immediate needs and pain points.

• Which platform(s) should the dashboard be accessible through? We usually build dashboards that are desktop compatible and rarely think about other modes of consumption. But in fact, a lot of consumption happens via mobiles and tablets as well. Think about who your users are what their preferences are e.g. C-Suite executives, who are usually time-poor, may want to see daily KPI reports on their smartphones.
• What would your users like to see? This is the most important part of this stage where you ask the users the right questions to understand what they want to see. Are there any particular KPIs or metrics they are interested in? Do they want to see any trends or growth/decline in certain metrics? What are the questions or problems your users are trying to solve through the dashboard?
• What views would your users like to see? Ask your users what they would like to see on the first page, which sections require a drill-down, and how the data should be broken down and filtered.
• How frequently should the dashboard be refreshed? Do they want to see the dashboard refreshed annually, monthly, weekly, daily or real-time? Does this frequency match with the underlying data update frequency?
• Discuss what the data sources can be used: Ask your stakeholders what data sources can be potentially used to build the dashboard they are after. Come up with a quick list of the potential core, peripheral and external datasets, their data custodians and location.
• Talk about the deadlines: It is always good to discuss what the timelines during this step. Set in stone when your stakeholders would like to see the first version (e.g. MVP or Just-in-time design), the iterations and the final version.

2. Ideation

Once you have gathered the requirements, it is time to put more thought into what the final product will look like. At this step, you not only think about the technicalities but also a come up with a solid work plan. It is a good idea to break your project into manageable chunks making it easier to delegate tasks and then synthesize everything into one single product. Few things you may look into at this stage are:

• Wireframing - come up with mockups of how you think the end product will look like. Discuss with your team which charts to use, where they will be located, what your pages will look like, what your headline metrics and titles should be, where you will place logos and icons etc. This may need a couple of brainstorming sessions with your team, users and other stakeholders. Sometimes, your potential users may not even know what they want. In such situations, you come up with a mockup first and then solicit their feedback. You can create your mockup by simply using a pen and paper, PowerPoint or online drawing tools like LucidChart.

Pen and paper example

PowerPoint example

• Technical requirement: Think and document in detail the technical requirements of the dashboard. Include things such as KPI calculations, data assumptions/inclusion/exclusions, data sources (core, peripheral and external), and the automation process.
• Storyboarding: Now that we have an idea of what the end product looks like come up with few key questions your users may want the dashboard to answer and see if those can be answered. E.g. which store had the highest sale growth this quarter when compared to the same time last year
• Project management: This is the best time to think about how you would manage the project, what the tasks and steps are, who will do what, what the work plan is, and of course the timelines.

Don't forget to get the wireframe and technical requirements endorsed by your stakeholders

3. Extract, Transform & Load Your Data

At this stage, you gather your data and transform it into an "export" quality. Does not matter which ETL technique or tool you use - the idea is to construct a table(s) that will act as the backend of your dashboard. A good practice is to have as many calculations and transformation as possible done within the ETL rather than in the BI visualisation tool. If this dashboard needs to be refreshed regularly, do not have any hardcoded values within your script. Few things to think about at this stage is

• Gather your data - collate your core, peripheral and external datasets
• Conduct data pre-processing - there are a number of things you may want to look at this step such as data exploration, quality check, profiling/cleaning, encoding, and feature engineering

Keep in mind: adhere to coding & naming conventions, and add script comments

4. Dashboard build

Once you have the underlying data table ready it is time to build the visualisation as per your endorsed wireframe. At this stage, you have everything you need to start the build - the data table to connect to and you know which charts you need to design.

Few things to keep in mind at this stage are:

• Adhere to your organisation's style guide: If your company has pre-defined style guides, adhere to it by all means. Make sure that the products you build comply with the branding style. If there are no guides to follow, then make one for your team which will enable you to establish your team's identity. Think about the primary and secondary colours, font, icons and logo you would use for your dashboards. As more products are being added to your team’s repertoire, it helps with the branding and the ease-of-use. The more familiar the users are with the layout and colours the more accepting they would be of new products.
• Automated refreshes: If this dashboard requires to be refreshed regularly, then ensure that the end-to-end process is fully automated. No manual interventions or changes are acceptable!

Get your MVP (beta version) out first and iterate as needed

5. Testing and QA

Once you have finished with the build, it is important to do some mandatory quality checks before sharing the dashboard with your users and stakeholders. There are three types of checks/tests you will have to do (courtesy Rahul Madke, Quora):

1. Data Testing: Visualization is the only layer that talks to business users hence if your data is wrong in the dashboards, your business will take wrong decisions. In Data testing, make sure every number shown on your dashboard is correct and matching with your database numbers. You can write queries on your database to verify these numbers. unlike other tools, Tableau won’t provide you with the database queries directly. You will have to write your own queries.
2. Functionality Testing: If you have used features like hierarchy, actions, filters, navigation buttons, etc. you have to test these features before you push the reports on the server.
3. Design & Consistency Check: As the last step we need to check if our dashboard design is matching with the dashboard design shared/approved by the business team and whether it follows the organization level standards of font, size, colour code, etc.

At this stage, you will also need to:

• get your script reviewed
• come up with some formal test plans and document the results
• do a spell check

6. Documentation

At this stage, you will need to come up with these two types of documentations

User related documents (some of these can feature within the dashboard)

• factsheet about the dashboard - what's the purpose of the dashboard, where it can be found and whom to contact in case they have any questions or need further information
• user manual - how to navigate and use the dashboard. I have written a detailed article on how to come up with a detailed Tableau user guide - you can see it here.
• FAQs: Should cover information on terminologies used, how frequently the data is updated etc.
• data caveats & assumptions
• data source information

Technical documents (select only the ones that will add value - smaller projects will not need the whole suite of documents)

• Steps to follow to refresh the dashboard
• issue tracker
• change request
• technical and non-technical requirements
• work plan
• test plan

7. Launch, Adoption & BAU

At this stage, you have everything you need to launch your product and it's time to let your potential users know that the dashboard exists. After the launch, you need to make sure that the dashboard does not meet a dead-end. Have an implementation plan ready which covers the following:

• Are you building your products iteratively? Communicate to users that the dashboard is being built iteratively - let them know what extra features will be available in the next version. Always try and build your products iteratively (agile/kanban) and be ready for continuous improvements. Have a fail-fast mentality and pivot when required.
• Hard versus soft launch - go for a soft launch approach if your organisation is at an early stage of their analytical maturity cycle. Users can find the shift to new data products overwhelming if they are not guided correctly. A soft launch will not only act a cushion but also opens up opportunities for feedback and change.
• Conduct 1:1 sessions or tutorial sessions with your users and gather feedback and gauge their interest in using the product - speak to your users!
• Make sure your users can access user guides, fact sheets and other information pertaining to the dashboard
• Send your users a survey and consolidate their feedback

Track Usage and identify dead-end dashboards

1. Identify dashboards that are becoming less popular is a great way to identify a potential dead-end dashboard.
2. Stocktake which dashboards are most and least popular
3. Are there any dashboards that were popular before but aren’t anymore? Check if these dashboards cover a problem that the business has already solved.
4. Which dashboards are used by only a small section of the intended audience? Low usage might indicate that some users haven’t been trained properly in using the dashboard. It could mean that some users have different questions that the dashboard does not answer.

That's all for now folks.