As a developer, there are few things better than putting the final touches on an extremely functional and insightful dashboard for a stakeholder. You’ve checked all the filters are working and apply to the right worksheets, the color scheme effectively highlights points of attention, and your font choice and sizes are all appropriate. While the work has been rewarding, it can also be quite strenuous.
But luckily you are now seeing the light at the end of the tunnel. Often optimism is high walking into the final rough draft review. Maybe there are a couple critiques of a color choice, a request to arrange one dashboard element in a different location, and some follow up questions on moving to production. But then it happens…
“Your metrics aren’t matching this other report… Why are we using MTD instead of QTD… when we scale this to the business they won’t understand the current acronyms.”
This certainly isn’t the outcome your team is hoping for, especially as the developer. But it’s also a challenge we’ve all faced at least once. Here are some tips to help avoid being caught in a similar situation:
Ask the Five W's
Who: Who is going to be using this dashboard? Are the end users the company CEO or a supply chain analyst? Can your stakeholders properly interpret a scatter plot? The answers to these questions should most certainly impact your design and messaging of your dashboard.
What:Â What are the key requirements needed in the end product. Are there certain metrics, chart types, trends, or analyses that are necessary? Gathering a very detailed list of requirements can give you a solid starting point to build out a more in depth analysis. Always try and clarify any issues or questions regarding requirements as early as possible.
When:Â When is this end product needed by and when will it be used? Always set expectations for how long development should take. If a project looks too good to be true in terms or turnaround time, it probably is. There will be issues that arise so make sure to set realistic expectations.
Where:Â Where will this dashboard be viewed? The end user may have a computer in front of them all day or they may be a area sales manager and will need to have all the views available in a mobile format. Another where item is time zone. If your stakeholders are in different time zones make sure that the data source refreshes coincide with all users.
Why: I saved the best for last. Always ask yourself why this product is being created. There may be very similar products already available within your organization that you can leverage. In terms of design, understanding the end goal of the dashboard may be the single most important variable to consider.
Create Multiple Views
When designing dashboards for stakeholders it is preferably to have multiple ideas going at one time. I try and create three separate views when presenting to stakeholders for a number of reasons:
- Giving your stakeholders options helps them understand the capabilities of what you’re building. It enables them to narrow down what they want to see in the final product so your likelihood of avoiding my theoretical scenario above decreases.
- Building unique views allows you to get all of your creative ideas down on paper. This not only gives your stakeholders a better idea of desired end product, but it enables you as the developer to choose the best elements you’ve included to create a superior end product.
- Do not put all of your eggs in one basket. If you spend a lot of time pursuing one idea that does not pan out you may feel like you failed. Instead, if you already have multiple ideas working if feels more like you are pursuing a different idea instead of associating a change of direction with a negative connotation.
Clear and Consistent Communication
This is a broad concept so I want to break this down into applicable categories:
Stakeholders:Â Ultimately whatever you are producing will be used by your stakeholders, so it only makes sense that you bring them into the loop early and often. Waiting until a late iteration of a dashboard to get stakeholder feedback can be very detrimental to the development process. Keeping that channel of communication open can help avoiding the bombshell “this isn’t what we envisioned” moment.
Business Analyst: If you are working with a business analyst, laying the groundwork for a healthy working relationship includes communicating beyond the point of certainty on a consistent basis. Clarify abbreviations, acronyms, field names, calculation methods, and anything else that could cause a potential mix up down the road
Data Back End: A dashboard is only as good as the data behind it. Make sure that you know when your data sources refresh and if there is any maintenance being performed on certain databases. Having your data source shut down for maintenance 10 minutes before a key presentation is a situation you want to avoid.
Delivery Method
I touched on this a little earlier in my necessary questions section but I think it needs a little more discussion. There are several ways to deliver Tableau dashboards to end users, but you must make sure your method is optimal for your circumstances. This topic is extremely important as it will ultimately influence the design of your end product.
Email direct link to Tableau Server: This method is perhaps the most efficient, but it also might be the most costly. This method requires all viewers to have some sort of license to view Server, but if you do go this route it is able to be automated on Tableau Server using the “Subscription” or “Alerts” feature. Also, if you are emailing links, users may not be inclined to click on the link. I know it’s just one more step, but it may result in less usage.
Email screenshot: Although this method defeats a lot of the purpose of Tableau being an interactive tool, this will ensure than anyone opening this email will at least see the data being disseminated. If you go this route, you will need to customize the view (if there is customization) for each viewer before you send the email as opposed to a direct link where you are able to customize a view based on viewer.
Email Powerpoint: The newest version of Tableau allows users to export dashboards to Powerpoint, which presents another way you can send dashboards to stakeholders. Powerpoint can be a familiar face to many users, so while you lose valuable interaction with your dashboards, you gain a trusted medium.
Tableau Public: this only works when the data you are working with is public. If anyone can see your data, this is a cheap way to host your visualizations.
I hope this was helpful advice for avoiding some common pitfalls and ultimately delivering your end product in a more timely and impactful manner.
