“If you don’t know where you are going, you’ll end up someplace else”Yogi Bera
I recently presented 4 concepts for planning your Tableau project to my work Tableau user group & to the Boston Tableau user group. The presentation wasn’t earth shattering, however, it seemed to resonate with the audience.
The most important part of my approach is my belief that I am in a customer service role and my service is data & insights. I believe that when I focus on what the customer needs, I can develop the right solution for those needs. The ideas presented below are not exhaustive of all scenarios and questions, it is intended to be a guide.
1. Who is my customer and what do they need?
As analysts & Tableau developers we need to uncover what our customers need and provide them with the right solution to meet those needs. When I get a new project, I like to meet with my customer and have them describe what they are trying to solve for and why that is important to them. Open ended questions are your friend here. Some questions are:
- What is the problem or question you are trying to solve or answer?
- Why is this important to the business?
- What decisions will this dashboard help you make?
- What does success look like?
- Is this a new problem or question or have you tried to address this in the past?
- Are there any existing dashboards or reports that you are using? If there are what is missing from those?
- Who will be using the dashboard and how will they use it?
- frequent users – Beth checks & interacts with the dashboard on a daily basis
- occasional users – Harry likes a summary page emailed to him and may interact with the dashboard a couple of times a month
- infrequent users – Isabel only needs a summary page emailed and rarely interact with the dashboard itself
2. What are the metrics that will help answer the customers needs
We’ve identified the purpose and have a clear understanding of our customer’s needs, now we need to identify what metrics help the customer answer their questions. These are some of the questions I ask in this phase:
- How is the metric defined, for example if we are building a dashboard that helps our shipping department explain customer service complaints on shipping times we would need to know how the department defines shipping times. Is it the time from order to delivery, the time from fulfillment to shipping, the time from fulfillment to delivery?
- Is this a department goal or a customer experience metric? While a department goal influences a customer experience, these may have variations in how the metric is defined. In our above example the CX metric may be order to delivery and the department goal may be fulfillment to ship. The shipping department focuses on their contribution to the overall experience but they don’t want to measure their teams for things that are out of their control.
- What factors impact the metric? Were there any process or system changes that could impact the data? What inter-department dependencies may impact the data? Is any of the information manually keyed into the system?
- What else do I need to know? Your customer knows their business, asking them this question gives you an opportunity to learn more about their business and factors that will influence what you see in the data.
3. Design Time
I’m skipping over the metric development in this blog. That part needs it’s own blog post.
We are now at the point where we have a good handle on the purpose, the metrics, and the users and have a sample data set ready to go. Is it time to drag & drop? I used to jump right into Tableau and I would end up with a massive workbook with a bunch of unfocused dashboards and I now advocate for sketching out your solution outside of Tableau.
There are different wire framing tools, but I am a fan of old school pen & paper. I have several unlined notebooks and packs of fine tip sharpies that I use to draw out my dashboards. This has helped me keep my dashboard focused and tied back to the purpose. Things to consider here are:
- What chart types work best for the data & my audience?
- Does the dashboard flow and is it focused?
- How will I use color to draw attention where it needs to be?
- How can I use the title & subtitle to help my users?
- What type of interactivity should I use?
- How will the dashboard be accessible to a wide range of abilities and knowledge?
- Is there breathing space in the dashboard or is everything crammed together?
4. Did I End Up Someplace Else
Wire framing is done and you’ve started building out your dashboard, should you review a work in progress or should you wait to review until you have the final version? I believe in engaging my customer throughout the process, it helps keep me on track and helps build confidence in them that the solution will meet the need. A few key benefits to sharing early and often are:
- If a metric looks crazy they’ll spot it. This happens, we may interrupt a definition a different way, not realize that we needed to exclude a sub-set of records, or made the wrong join type in our query.
- Watching them test drive the dashboard without providing direction. Are they getting stuck somewhere, what features aren’t they using, do they understand what you’ve created?
- Get the opportunity to see what additional questions they have of the data. Do you need to build additional views?
Hopefully there is something in this post that helps you create a partnership with your customers. I’d love to hear any tips that have worked for you in this process.