It was late 2022.
I had just transitioned from a BI Solution Architect role (it took a while to understand what this role actually meant, but essentially it was tech sales for a Data Visualization tool. Think Tableau, PowerBI, Sigma competitor). I had transitioned from that role to a Data Analyst role.
One of the biggest, unexpected shocks that I got in the Data Analyst role was this: ”I couldn’t wrap my head around the concept of building a dashboard that would not eventually get used.
You see, as a Solution Architect/Tech Sales guy for a dashboard creation tool. Every dashboard we created was utilized in one way or the other. We created customized dashboards for product demonstrations to prospective buyers (the dashboard was sure to be used for the presentation). We also created dashboards for proof of concepts with the prospective buyers data to see how well our tool integrated with their internal tools and how well it handled the use cases they needed data visualization for (e.g. internal data analysis, embedding a product of their own etc.)
It was rare that a dashboard would be created to aid Sales efforts and it would not be utilized (except the prospect was a no show for the Sales Call).
So, you can imagine the total shock and horror when as a freshly minted Data Analyst, someone reaches out to the team and says: “ Hey, we need to be able to see how much product we have across all our locations in a single unified view”. And without hesitation, I jumped right into it. Wrote the SQL query, verified the correctness of the data, created an interactive Tableau dashboard for the user to lookup what they needed. Said Dashboard was presented, requester remarked “Oh this is wonderful”. And then crickets…..
Weeks later, when looking at the dashboard metrics, it stopped being accessed a few days after the initial delivery.
At so many organizations, dashboards are created which end up in the sea of lost souls, never again to be used or resurrected, never again to see the light of day ( ok this is getting a bit dramatic, but you get the point).
How can this lack of adoption and lack of repeat usage be addressed?
After all, organizations pay a lot for Data Visualization software (e.g. for Tableau Pricing is 75USD per Creator, 45USD per Explorer and 15 USD per Creator - all prices per month). The organization I worked for had 10K plus employees.
Not sure what enterprise pricing would cost, but going by this user based model, you are looking at minimum $180,000 per year if all employees needed view-only access. If this much money is being spent on a software, and it is not being used frequently, money is being left on the table.
This doesn’t include the opportunity cost i.e. when done right, proper data analysis and visualization can uncover insights which would save your organization millions of dollars (I have seen this done in excel and in tools like Tableau). So, to rephrase the question above, how can organizations stop leaving money on the table?
Fast forward to Mid 2024.
Another dashboard project is at the tail end of being wrapped up. The requester is very appreciative, he brings on members of his team to take a look at the dashboard. The members of the team who do not have access already request access to the data visualization tool so they can begin using said dashboard. The requester expresses his intention to socialize the dashboard to his superiors in the future.
Someone from an adjacent team starts using the dashboard prototype in one of his external meetings, he assigns a direct report to begin using the dashboard to verify the data. The direct report reaches out because he found some discrepancies on the data being displayed, and it was promptly corrected.
An external consultant reaches out to get a walkthrough of the dashboard as it might be applicable to the work he is currently doing for the organization etc.
What brought about this massive jump in adoption, interest and repeat usage?
These series of posts walks through two fundamental changes in the dashboard build process that made these happen.
In the past, dashboard creation projects would go like this:
Discovery > Data Collection/Preparation > Build Dashboard > Present Dashboard > Implement Feedback > Rinse/Repeat
For this particular dashboard project, after Discovery (asking questions to further explore the end user request), prototyping was done before any additional legwork went into the dashboard build.
Discovery > Collaborative Prototyping > Data Collection/Preparation > Build Dashboard > Present Dashboard > Implement Feedback > Rinse/Repeat
For Definition of Terms:
What is meant by Collaborative visual prototyping is this:
A visual prototype of the dashboard is created (the tool you use should be dependent on the tech savviness of your stakeholders/end users). Initially Figma was used, it was seeming too complex for the end users, eventually PowerPoint was settled upon.
The tool you use for this is the secondary issue here (it could be power point, it could be Figma, it could be a paper sketch). The primary focus should be translating a written document to a visual prototype before building begins.
The primary concept here was borrowed from Product thinking. It was the idea of creating a visual prototype and getting feedback on that prototype before actual development work begins.
The idea is this, it is easier to modify the prototype, make changes upfront, rather than getting feedback after time and effort has been invested in building the final solution. Making changes at that point will be more costly and time consuming.
The prototype can easily be changed and modified. A fully built solution however might take more time.
This prototype is created in collaboration with the end users/requester of the dashboard (hence the “collaborative”).
Get as much feedback as possible on the prototype, every visual, every dashboard screen etc. Until the end user(s)/ stakeholder(s) are satisfied with the prototype. Once there is agreement on the visual prototype, and the stakeholders agree (this is what is needed) then the build process can begin.
A caveat to this. This is more upfront work. There were more meetings at the start of the initiative than the typical process. However, it saves a lot of time and infinite scope creep down the line.
The visual prototype defines the output very clearly: in a language (graphical and visual language) much more than a written document would.
The next post will discuss the 2nd fundamental change that ensured this dashboard did not end up in the abyss.
In the meantime, for future dashboard projects. Consider a visual prototype, share the prototype with the audience, get feedback on the prototype. Iterate on this until there is an agreed upon prototype, and then let the build begin. At this point, the “Definition of Done” (what it looks like when the project is finished is clearly defined, and there would be a more pleasant experience for everyone.
The second fundamental change would be shared in part 2 of this article.
In the meantime. Have a productive day ✌🏿
Next Post: How to Make Dashboards People Actually Use 2