So you’ve built an amazing dashboard in Tableau and are ready to share it with your end-users. You imagine them eagerly opening it every day, applying your painstakingly built parameter actions to slice and dice the data, digging in to answer their complex questions and sharing their insights with others. But all your hard work will go to waste if you don’t complete the final crucial step of proper hand-off.
Tableau is certainly user-friendly but it doesn’t mean you can always just throw anyone a dashboard and expect them to make full use of it without at least some guidance. It’s true that in an ideal world your dashboard is so well built that it stands completely on its own. There are many techniques that can and should be used to maximize this. However, the real world is less than ideal.
In the real world…
- You often don’t have the luxury of time or have sufficient expertise to get your dashboard to where you’d like it to be. Nevertheless something needs to be delivered.
- Your users may be new to Tableau or even to interactive dashboards generally. They may be nervous moving away from an old way of doing things or have inflated expectations. Not all organizations, teams and individuals are at a particularly advanced stage of data maturity or self-service adoption.
In these situations, dedicating some effort at a final stage which I’m calling ‘hand-off’ can make a big difference in improving the adoption of Tableau products that are meant to be used on an ongoing basis by a set of consumers or end-users.
What is hand-off?
Hand-off includes everything between the time you’re ready to publish your dashboard to when your end-users are comfortably using your product independently. You have entered a ‘maintenance phase’ where you expect to only be brought in for occasional bugs or improvements.
You can also call it rolling-out, transitioning or promoting to production. Depending on your background and use case, you may be very comfortable with a formal release process or this may be something completely new to you. In either case, there are some distinguishing features of rolling-out Tableau dashboards that are worth noting.
Of course, there are technical aspects of this roll-out, such as publishing your dashboard to a server, setting up proper permissions, scheduling appropriate flows, etc. There is a lot written on these aspects already and much of it is unique to your specific organization’s Tableau set-up. Instead, what I am focusing on in this article is concerned with planning and user communication in order to facilitate take-up.
If I had to narrow it down to three main recommendations, they would be:
- Plan ahead and dedicate time for hand-off
- Hold demo sessions
- Do a dry run or parallel run
Plan ahead and dedicate time for hand-off
The last 100 meters of implementing any product into production is the most underestimated and underappreciated. Do yourself a huge favor and always leave a window of time at the end that is dedicated just for hand-off. Push back against the expectation, which may come from your client or from yourself, that Tableau is just so extremely easy to use that no dedicated hand-off is needed. Make it a necessary stage just like design and development. Until you’ve gone through this process a few times, estimate however long you think it will take and then expect that time to double. Set the expectation early to avoid headaches later on.
Hold demo sessions
Hold a session with your end-users that is dedicated just for walking them through the final dashboard. You can frame it as ‘training’ if you think they may be reticent or need more guidance.
Presenting a dashboard is actually not as easy as it seems because it is all about effective communication and being able to put yourself in your audience’s shoes, which are not the same technical skills you used for building the dashboard itself. You may be very familiar with what you’ve built and with Tableau, but you will lose your audience if you are not clear and structured in your presentation.
At a high level, there are three main components to cover in a demo: (1) Basics and logistics, (2) Tableau features, and (3) Use cases. These don’t have to be sequential parts of the presentation and ideally are blended together. You will likely also want to provide some reference documentation.
Basics and logistics — Cover things like how to access the dashboard in your organization (e.g. login credentials), how to get help (e.g. who to contact for support) and basic info like how often it is updated and what data feeds it. If Tableau is fairly new to your organization, you should take a bit of time to clarify common terms (e.g. workbook, views, marks, etc.) and your particular set-up (e.g. folder structure, permissions, etc.). There is no need to overdo it — they don’t need to become Tableau experts at this stage, but also don’t underestimate them. Many people are eager to learn and use interactive data and BI products. This is an opportunity not just to share your specific dashboard but to promote self-service data analytics in your organization.
Tableau features— If this is the first Tableau dashboard your users will have worked with, don’t take for granted they will know how to interact with it. Applying filters and finding tooltips are straightforward. But consider the following examples of things I’ve found users stumble with.
- Applying multiple layers of filters and struggling removing them or seeing what is filtered. In this case, they need to get comfortable doing things like removing applied filters with the show all button, undoing actions and reverting the workbook.
- Not knowing that they can access underlying data and how to do so. They often forget that a view has to be selected first.
- Interacting with maps. Depending on how you’ve built your map, you’ll want to show how to toggle between panning and selecting, as well as using the reset axes button, as I haven’t found these very intuitive for new users.
There are some existing resources that you can leverage or point your users to, but I have not found any silver bullet. Tableau has some training videos for Viewers on Tableau Online and Server and there is help documentation for Tableau Reader. There is also Tableau’s Consumer learning path. If any of this content is applicable in your situation, you can provide it to your users ahead of time or to supplement your demo. However, because each organization can be very different, you cannot rely on these resources completely.
Use cases — This is the part that your users are most interested in. This is where you show them how they can use the dashboard to explore the data and answer their questions. Don’t make the mistake of thinking you need to systematically explain each chart, filter or feature of your dashboard. That’s boring and your audience will already be looking at that eye-catching map on the other part of your dashboard long before you ever get to it. On the other hand, don’t be too superficial and jump around. Start with an overview (i.e. “This dashboard provides information on….. It has three main sections….On the side are several common filters that can be applied….”). Then, go through a few specific scenarios, mimicking the process they might take to answer a specific question or perform a task. Practice ahead of time the exact sequence of what you want to show in the demo. Sprinkle in information about Tableau features as you go.
The demo session should be at least one hour and sometimes as long as a whole morning or afternoon. You want to give enough time to cover your content and give time for users to explore and ask questions. If you haven’t gotten much input from these users before, be prepared to take notes on feedback. How to get and handle feedback from end-users on reporting products is another interesting topic that warrants its own discussion. For additional presentation advice, see Andy Cotgreave’s article on presenting data remotely which includes tips on things like effectively using mouse pointers and breaking down complex charts slowly.
Do a dry run or parallel run
If you are replacing an existing reporting product, do a parallel run where both the old and new Tableau versions are run in tandem. If your dashboard is updated on a monthly basis, make the parallel run at least one month. Even if you are not replacing something else, run your dashboard for a ‘dry run’ period. During this period, make it clear that the new version is in a draft form where numbers and behavior may not be 100% reliable.
The length and formality of this dry run period totally depends on how critical the precise functioning of your dashboard is. If it is supporting key operational functions in your organization, you may want to go through a few runs and even keep a back-up legacy report running for a few more periods. Your organization may be used to going through formal testing and acceptance stages before a new BI product or changes to an existing product are implemented. A parallel or dry run is a great complement or can even completely substitute a formal test stage.
Even if there aren’t strict operational requirements for your dashboard, a dry run period can help build confidence and improve take-up among end-users. You don’t want to roll something out with lots of fanfare only to disappoint users who encounter an incorrect number or unexpected behavior. Even if you know how minor a specific issue may be and how easy it is to change, you don’t want it to tarnish your user’s opinion of the entire product.
All these suggestions apply to any reporting product — not just one built in Tableau. However, I’ve found interactive dashboards built in tools like Tableau or Power BI especially fall victim to poor hand-off. This is largely because (1) they are so strongly advertised as easy to use, and (2) there is just not enough written for their application in the context of enterprise reporting. Each organization and situation will be slightly different so be prepared to adapt as necessary. Just don’t underestimate how valuable it can be to have a dedicate hand-off phase for promoting take-up of your Tableau dashboard.