Driving Adoption with User-Centered Dashboard Development

Okay. We're going to go ahead and get started. It's five after. Welcome. Before we get to today's content on driving adoption with user-centered dashboard development, I wanted to make a few introductions. So Kendra, if you could go to the next slide. Maybe this is your first webinar with InterWorks or maybe you're revisiting. Either way, welcome. We're really glad that you're here and we're really excited about the content that we've got to show you today. And you may be wondering what InterWorks does. We do a lot and sometimes it's a lot to explain. But simply what you should know is that we specialize in data strategy. In the photos here, this is a group at the top that is our APAC team. And then the bottom there is a group from Europe. We have a large team also in the United States. And everything that we do is powered by people. They're experts in what they do. They're very knowledgeable, and our goal is to just take time to share our knowledge with you. Kendra, if you could go to the next slide. Also, just briefly, I wanted to cover our partnerships. So these are some of our top partnerships. These are technologies that we recommend. We just want to make sure that we can help you navigate to the right tools that align with your goals. If you're looking for more resources on data or analytics, we have a world famous blog. I can say that proudly. It's a great knowledge base for you or anybody in your organization, so maybe check that out today. And yes, our webinar will be recorded and a recording will be sent to your inbox if you registered in just a couple of days. We'll also have a copy of it available on our blog in a few days. So yes, it will be recorded. And then finally, just a quick request on how things can operate. Make sure you use the Q&A function to queue up the questions for our presenters. We will get to questions near the end of the content. And then we will use the chat for a little bit of exercises that Kendra is going to cover here in a second. But yeah, Q&A is the best place to put that if you could do that for us. Yeah, I think that's it. Kendra, let's do some introductions. Like I mentioned, my name is Jenny and I'm on the marketing team. We've got Kendra and Keith here with us today to cover user-centered dashboard development. If you all could provide some introductions about who you are, what you do at InterWorks, how you got here, and maybe even get some context as to why user-centered dashboard development is important to you and how it works with your customers. I'll let you guys take it away. Sure. Thanks, Jenny, and thanks everyone for joining. We're excited that you all are here. So I'm Keith. I'm based in Washington, D.C. And I work as an analytics consultant for InterWorks. I actually would say that I accidentally became an analytics consultant. I was a middle school teacher for several years and then was looking to do something slightly new, but loved the school I was working for. And they had an opening on their data team. I asked the boss if they thought I could do it. I said, I taught math, so I think I'm decent with numbers, but I don't know anything about this tool called Tableau. She said, That's okay, we'll teach you. It was great because I brought a perspective on how data could be useful to people. They taught me how to analyze the data, and the two came together really well, and that's why I'm really passionate about this topic. So I'll turn it over to Kendra to introduce herself as well. Yes, hi everybody. My name is Kendra Allenspach. I'm an analytics consultant based out of San Jose, California. I've been with InterWorks for about three and a half years, but working with Tableau for about six and in an analytics space for about ten. And honestly, this topic has been born out of a lot of curiosity and asking questions of how can we make analytics teams work more efficiently and more effectively. I've been on the client side, I've been on the consultant side, I've been a consumer of dashboards, I've been a developer of dashboards. And so all of these different perspectives have really come together to confirm that the best way to approach dashboarding is really with a user-centered approach. And so that's what we're going to talk to you about today. And like Keith said, we're both extremely passionate about this and we prepared this talk and it was presented at Tableau Conference this year. And we're super excited to get to share all of the content with you today. As Jenny mentioned, we really ask that you put any questions you have about the content or questions for me and Keith in the Q&A in your Zoom menu. That will help us keep track of it and separate so that we can come back to it at the end of today's presentation. Then we'll also be asking for your feedback and participation in the chat. It's so great to see the chat so active already. Please keep that going. That really helps us to make sure that everyone's following along with the content and enjoying the content. We have a few prompts for you that we will get to soon. With that, I think we're ready to get started. Keith, you ready? Yeah, let's do it. Awesome. So I think we probably have a variety of Tableau experience on the call today of participants, but I think regardless of how long you've been working in Tableau, you can probably relate to this meme on some level. You built a great dashboard, and then you were so disappointed to see users exporting that data to Excel. We're curious to hear from you actually if you could drop an emoji reaction in the chat section. So pick the emoji that best represents how you feel if you've ever seen this happen before. I would personally be picking the zany face right now because it makes me feel a little bit crazy when people decide that they would rather use Excel than Tableau. Kendra, how does it make you feel? We see lots of reactions in here. Yeah. The facepalm emoji is such a good one. Yes. The crying one. The crying emoji. Right. The wine one. Thank you, Kevin. Yes. Yes. Yeah, I think I've had all of these reactions at some point or another. It's just a mixed bag of emotions when that happens. Yeah, for sure. We can certainly relate. And I think, you know, obviously lots of feelings of frustration, maybe some curse words, and all of those reactions I think are only natural for us as developers when you invest a lot of time in creating a tool to see people not use the tool can be really disappointing. I do think that reaction has us as the developers at the center. What we want to do today is just shift our perspective a little bit and put users back at the center. Because even though it can be frustrating to see people use a Tableau dashboard in a way that we didn't expect or maybe even not use it at all, what we want to consider is what we can learn from that situation today. Because if a user is leaving a dashboard to do their analysis somewhere else, there's something that tells us there's some way in which that dashboard isn't meeting their needs or some way in which they don't understand how to use it. And so we want to consider today how we can put them back at the center and learn from those examples to create great tools for them. Exactly. Yeah, we have a few small mindset shifts that we want to recommend so that you can change your tone in moments like this from frustration of like, why are users doing this, to more of a tone of curiosity and being more in wonder of like, I wonder why users are doing this. So Keith and I are going to share some things that we've learned on how you can transform your design and development experience by taking that more user-centered approach. We have three key principles that we're going to walk through today. The first is users first, start with users, not with the data. The second is users during, so not just users first, but users throughout the entire development process. And third is users after. So don't build it and forget it, but build it and nurture it. So like I said, you can think of these as users first before development, users during development, and users after post-production or post-development and in production. And you'll see these indicators on the slides throughout our presentation so you can track along with where we're going today. But before we dive in, Keith and I are curious to know which phase of the development do you find it hardest to connect with your users? We're going to talk about all three today, so there's no wrong answer. But we're curious to hear from you what you find to be the most challenging when connecting with your users during development. What do you find most challenging, Kendra, while people take a minute to respond? I would say probably users after. It's really easy to just publish a dashboard and then move on to the next thing. But users during can be hard too. There are a lot of people that resonate with you. Lots of people saying after. I saw a few durings and a couple firsts as well. We've got, you know, a broad swath of people represented here. I'm excited to know that at least the whole presentation will be relevant to someone. That's good to see. And we're not alone. Well, I think we're actually going to dive in with a quick client story and just kind of set up the problem for you. So I just want to talk a little bit about how Kendra and I, we get the privilege of working with a number of different clients in our role as analytics consultants. And in my role, one of my favorite clients recently that I have been working with is Johnson & Johnson. And I want to walk you through an example that kind of sets up the problem. Johnson & Johnson came to us last fall and they asked if we could help them to refine a dashboard that they had prototyped that nobody was using. And you're seeing an image on the screen that represents something pretty similar to what they had originally prototyped. It was a large crosstab, there were a lot of filters, there was a drill-down tab, but it was a little overwhelming and I could see how users were a little bit not inclined to use this. When I initially saw this, my initial reaction was let's visualize that data. Let's actually show some stuff because there's probably great insights buried in the chart. Anyone have a similar reaction? You can just kind of respond with a quick yes or an emoji again in the chat section if you want. But I just wanted to say, let's take this out of a crosstab and let's make it so people can see what's going on in the data. Yeah, it looks overwhelming, right? But I think what I have challenged myself to do recently is not to start with the data and what I think I should do for the users, but actually to put myself in the user's shoes first. So on this particular project, I asked the J&J team if we could talk to some people first and actually have them use the current tool. And I think they were like, we know this tool isn't great. Do you want to watch them struggle with this tool? I was like, that's exactly what I want to do. I want to find out what's going on with them. I had them actually, I had two users pull up the tool. I had them start clicking through and narrating what they were doing with the tool. And they basically said this: when we use this tool, we apply a filter first, and then we immediately export the data to Excel. And I said, tell me more about that. Why are you exporting the data to Excel? And they described for me how the tool was really slow to load and so it was just faster for them to use Excel. One of the users said I'm not even able to sort the data, which wasn't actually true, but she didn't realize how to sort the data. That was a key piece of functionality for her. And so just in this really quick session, we started to get some immediate insights into how we could make that dashboard better. Yeah, this client story is all too familiar to me as well from consulting experience, and it highlights a key user-centered development principle for us, which is start with users and not the data. So a thought leader in this space named Brian O'Neill says that if you want a human to use a thing, then you should talk to those humans first. And just like Keith said, my first instinct years ago when looking at a dashboard like that, a giant crosstab would have been to find the data story and build some charts without truly considering what the user's needs were. But now with my advanced experience, I'm understanding that it's important to really get into the minds of those users and better understand what they're needing out of their solution. At InterWorks, we've embedded this into our core approach for dashboarding by naming the first step in our process Understand. We invite all of our consultants to start their projects by talking to users and, like I said, getting into the minds of those users so that we can create really robust solutions that address the user's needs. The most common scenario that I typically encounter as a consultant is a client coming to us with a list of technical requirements, and that can be really helpful. But sometimes we lose that truth in what the users were looking for. And the clients are coming to us already in a solution space when really we want to uncover the problem space. And so this is when it's our job as consultants to help our clients step back and start thinking less like a developer and more like a product manager, because we want to fully vet and understand our users' needs before we jump to any conclusions on what type of dashboard to build. This has been an ongoing practice for me. It doesn't happen overnight. It's taken years of changing my mindset, getting into those phases of frustration, changing my frustration into curiosity, as well as educating our clients on the value of this approach to put the data aside and think about the people that are on the other side of the computers that are consuming this dashboard. But if you're willing to take that patience or be patient and be curious, I think you're going to find real benefits in the long run. Because when we take this time upfront, it's going to save us a lot of heartache and dashboard changes down the line when our dashboards don't get used because they don't meet the user's needs. So that leads us into the next phase of development. So at this point, we've understood our users' needs and we're getting into the development cycle. And our principle here is not just users first, but users throughout. So while it's important to talk to users at the beginning, fully vet and understand their needs, we also want to take a people-first approach during development so we can make sure that we're incorporating the solutions to the user's problems as we go. And we have a few tips and tricks for you here. The first thing that you want to do is determine your MVP early. And no, I don't mean most valuable player, although I like to think my dashboards are the MVPs of people's Tableau servers. They are. Thanks, Keith. In this case, I'm talking about minimum viable product. Now this is probably a term that you've heard tossed around in like the software development space, and it can feel really official and often daunting, but all this really means is figuring out what are the most essential parts of your design to include in your initial build. So if we take away all of the nice-to-haves and fluffy features, what version of our dashboard is going to get our users from point A to point B most effectively? And what's going to allow us to start building something rapidly so that we can get user feedback sooner rather than later, which leads to our second recommendation here, which is rapid prototyping. So with your MVP defined, now your job is to get something into a prototype. And what I mean by prototype is basically anything that gets ideas out of your head and into a tangible format that users can react to. So this might look like the first version of a dashboard, it might look like a wireframe, some sort of prototype in any sort of format, but you want something that users can see, touch, feel, and then react to. When I first started building dashboards, I would aim to get things to their most pixel-perfect state before I showed them to my end users. We want to put our best foot forward, and so I wanted them to trust my experience. But ninety-nine percent of the time, there were always change requests that left me feeling defeated because I'd spent so much time making this pixel-perfect design. And then I would feel like I'd wasted all that time because it just ended up changing. So now by asking users for their feedback throughout the development process, I get to answer that question of, am I going in the right direction a lot sooner? And I'm usually less emotionally attached to what I'm building because I've spent less time on it. So when those change requests come, it's a lot easier for me to be flexible and incorporate those changes because I want to make sure I'm meeting users' needs. And this is something that Keith was able to do really well in the Johnson & Johnson project, which he's going to tell us more about. Yeah, so we incorporated a lot of these ideas of prototyping and testing along the way at Johnson & Johnson. And I'm really glad we did because it turned out there was actually something that we missed in our initial design. Someone just jumped in in the chat and said, you know, sometimes users don't even really know what to ask for at the beginning. I think that point is so true. You might talk to someone at the beginning and have a sense of what to build. Then when you show them that, they realize, that's not actually what I need. Because sometimes it's hard to know. Sometimes if you're building something from scratch, it's hard to envision what you could possibly even need. It's great to test along the way. But let me talk a little bit about what happened on this J&J project. Kendra, if you actually want to jump forward to the next slide. So one of the things that we discovered in talking to users is that there were some key pieces of functionality that they needed. One of the things that they were often doing is filtering the data first to get down to a narrower dataset. And so we actually created a space on the left-hand sidebar to house all those filters just as a natural place for people to see that. And then the next slide I'll show that we also called out a place to identify the options they had for sorting the data. So since one user had mentioned that was such a key piece of functionality, we wanted to make sure that was really clear. And this is just a very rough working prototype, again anonymized data, but we just wanted, we had some pieces in place and it was enough for people to react to. Then we put this in front of those two users and here's what they saw when they pulled up the dashboard. So one of the users had a smaller screen and her screen resolution was zoomed in as well. So she only saw a piece of this dashboard and as she started clicking around it, she said, well, you know, I can filter this really easily and the dashboard loads a lot faster and so that's great, but I still can't sort the data, Keith, and so I still need to export this to Excel. What I wanted to say is just scroll to the right, it's over there. I didn't forget. I remembered you said that was important and I built a specific section for you. And if I'm being completely candid, I also frustratingly wanted to say you can click on any of those headers and sort by any of those columns. It's built into Tableau and it was there in the original prototype. But the reality is that that is intuitive to us as Tableau developers, and it's not really intuitive behavior for users. And one lesson that I think I've really learned is that when I run into these situations where things aren't intuitive, don't change the user, change the design. The people I was working with on this project were digitally literate people. They were used to interacting with dashboards. This was not me trying to teach my ninety-year-old grandpa how to use a dashboard. And so the reality is if these smart people weren't able to see, if it wasn't intuitive for them how to sort a dashboard, I needed to go back and make the design more intuitive. Because if they were going to miss it, there were probably hundreds, maybe even thousands of other people that would not understand how to use this. And rather than fighting that uphill battle of trying to change every user's behavior and make them do something that doesn't just seem natural and intuitive, if there's a way that you can bring your design in line with what feels natural and intuitive to the users, you're just going to have a better tool. And so investing a little bit of time to make those updates, it can be annoying right, because it's more work for us as developers. But the reality is, you invest, you know, fifteen, thirty minutes, sometimes even a few hours, that can add up to really significant time savings over the long run for your organization. You're saving every user a couple seconds of confusion every time that they use those dashboards. Yeah, Keith, that's so true. I've been in those situations before where I've thought, okay, it's okay, I'll just train up the users on what they need to do once the dashboard gets published. But really that education, like you said, it's an uphill battle. And I realized, oh, I'm going to have to explain this to all one hundred users of this dashboard, and that's just not feasible. And a dashboard design change is really the way to go in those situations. Okay, so as we're moving through, we have now developed our dashboard, we've talked to our users, we've gotten their feedback, and we've probably iterated a few times, and now our dashboard's ready to go into production. And it's really easy at this point to think, okay, cool, like my dashboarding development process is over, but really in user-centered dashboard development, it's not. This is where we really have an opportunity to stand out in the way that we work with our users. Because our third principle here is don't build it and forget it, but build it and nurture it. And in this case, we're talking about the dashboards. If we truly want to shift the mindset of how we approach dashboard development, we need to think of our dashboards as products that have ongoing lifecycles and should be improved upon over time. So if you think about the apps on your phone that you love and use every day, or even if you think about Tableau, they're constantly releasing new versions to be up to date with the changing needs of their users. And the dashboards that we build for our users need to have that same feel, where the business needs are changing. And so what the dashboard provides for the users needs to change too. Based on what people said at the beginning, when we asked about what phases people had the most struggle connecting with their users, a lot of people said users after, and so did I, because from my experience, this is one area where analytics teams have ample opportunity to really transform the way they think about their dashboards. So like I said, instead of checking that box that says done, which is oh, so tempting—I'm a big to-do list girl, I love checking things off my list—at this point, we really need to think about how can we foster an ongoing relationship with our users to know whether these dashboards are working for them after all is said and done. We really need to come up with a way to collect and organize feedback. And at InterWorks, we've been working on ways that we can help our clients do this better. And for those of you that are familiar with our Curator product, it is a beautiful solution that allows you to embed your analytics from various tools in one beautiful, cohesive space. And we've recently been promoting a new feature within Curator for dashboard feedback collection. In fact, if you are a Curator customer, you may have gotten an email from me just last week asking if you knew about this feature and if you wanted my help setting it up. So if you got that email, shoot me an email back. I'm happy to get on Zoom with you and talk you through how to use this feature because this is something that we're actually working on evolving and we want to hear from you guys, from our Curator clients on how this feature could be improved for your use. We hope to advance it, add some natural language processing to the feedback, and create an analytics layer so that you can analyze your feedback to better understand how to implement that feedback into your dashboards and turn that into robust product roadmaps. So like I said, this is very exciting. It's something new that we're working on. And if that speaks to you and you're like, oh, yes, we want this for our organization, or we want to give feedback on what this feature could do for us, definitely reach out to me. My email will be at the end of the presentation. But this is really something that's super important in user-centered dashboard development, because from my experience, that post-production feedback is one of the messiest parts of a dashboard's lifecycle. I mean, you can be getting feedback from so many different channels. I get Slack messages, I get Teams messages, I get emails, I get texts when it's urgent. And it's really easy to just lose track of the feedback that's coming in and to then at that point feel disconnected from your users, or rather your users feel disconnected from you. And so all of that relationship building you've done during those users first and users during phases could get lost in users after, if you're not continuing to connect with them. And so by fostering this ongoing feedback loop, we ultimately create the spirit of support and partnership with our users so they can know they can continuously come back to us, and we will create dashboards for them that provide really great results for their business. So with that, I'm sure you guys are all dying to know what happened at Johnson & Johnson with Keith's dashboard. So Keith, how did it turn out? Yeah, so interestingly enough, the more that we talked to people at Johnson & Johnson, the more we realized that the original prototype that they had was actually not that far off from what people needed, which probably sounds crazy. The use case that we started to understand here is that there was a really large dataset and people needed to narrow that dataset down to just a handful of records. But the way that they needed to do that was really dynamic and flexible. So everybody loves a good before and after, right? So let's show the before. Okay, this was what we started out with: gigantic crosstab, tons of filters, drill-down setting, very little formatting, kind of overwhelming. Oh, Keith, you muted. Sorry, I hit my space bar in a second. Yeah. What you're seeing right now. That's okay. You want to go to the next one? No, that's totally fine. What you're seeing right now on the screen is just an anonymized version. It has kind of the same structure of what we created there. And Kendra, I think it's a GIF. If you press play, yeah, it'll show what we ended up creating for the J&J team was a dynamic sidebar that users could expand and collapse because they had a huge set of data that they needed access to, but they only needed a couple pieces at a time. And so what we decided to do is create these categories of data. They were either looking for doctors who had patients in certain age ranges or perhaps a concentration of patients in certain race groups or a particular location. But again, those needs were really dynamic and flexible. And so users needed the ability to tell us and basically construct their own table so they could build a table that was most relevant for them. If you show on the next slide, because the users had called out that sorting was so important, I just moved it over to the left-hand side. It was a really simple design change and that guaranteed that every user saw it right away, no matter their screen size or resolution. No one was going to miss that. We took some extra effort to make that list dynamic as well. So it's only showing you options based on what you pick to add to the table. So the goal here was really to show users everything that mattered to them, but nothing more. And they needed to just pick a few things, and then be able to work with that small dataset with a really curated view. If you click next, I think the ironic thing about this dashboard is, if you would have told me at the beginning of the project that I was going to improve a crosstab by essentially just delivering another crosstab, I would have said that is crazy and nobody should pay us money to do that. But as it turns out, this is actually what the users needed. Every decision that we made here was really driven by conversations with the users at the front end and along the way. And if you click one more slide, we'll put up a QR code. I think if you're interested in the techniques behind that dashboard, particularly that left-hand sidebar that expands and collapses, my colleague Linus wrote up a blog about it, but I'm going to warn you that there's a lot of steps involved. There are a couple layers of set and parameter actions that have to work together and it's not easy to set up. What we accomplished I think was something that, although it was complicated on the back end, it felt really easy and intuitive to users. And it felt really simple for users to engage with the dashboard. I will say though, just because you can do something in Tableau does not mean that you should do it. So don't go create the sidebar just because now there's a blog showing you how to do it. Only do it if it's really what's necessary. We tried a lot of much simpler approaches that we prototyped with the team along the way. We tried using like the out-of-the-box Measure Names filter, and the list was just so long that it was overwhelming to users that we had to think a little bit outside the box and think of new ways that we could kind of push Tableau to do things that weren't necessarily easy to do. But again, if that is what your users need, go for it. If there's a simpler way to do it, you should go with a simpler way because it's just easier to maintain and it also gets you a valuable product much faster. This did take a little while to build. But again, feel free now that I've thoroughly discouraged you from looking at my blog, feel free to go and check it out if that feels like a useful technique for all of you. Yeah, Keith, this is great. We have a lot of positive reaction to the dashboard in the chat, very similar to the reactions I had the first time I saw it, which was, is that even Tableau? Which yes, everybody, that is Tableau. And yeah, I'll reiterate what Keith said here too, which is that, and I see Danielle really liked this comment, just because we can doesn't mean that we should. Everything needs to come back to, is this something that gets your users out of their problem space and into a solution space? And so constantly going back to saying, is this what the users need, going through different rounds of prototyping and iteration, watching users interact with the dashboard led us to what ended up being a complex solution that solved the user's needs. But we have a lot of other experiences as well, where really what the client needed was actually much simpler than what they came to us asking for. And we found that out by uncovering the user's actual problem. Keith, thanks for sharing that with us. That's very exciting. Chloe Russell had a great question. She said, do they still export it to Excel? And I think that they do not actually. This dashboard has gotten really positive reception from the users. And people have started talking about how it actually gets them the data that they need. It performs much faster. And so they're actually staying directly in that tool and using it directly there. They may at some point export when they get that list that they want. But for the most part, it's gotten really positive reception and has opened up some other opportunities to work with J&J for us. We call that a successful user-centered dashboard development story. Okay, everybody, we covered a lot of ground today. So thanks for sticking with us. We want to close by recapping our three key principles for you. So the first one, start with users, not the data. If you want people to use your dashboards, involve them in the development process. Talk to them about their needs, understand their workflows and frustrations, and spend time getting into the problem space with them before you move into that solution mindset. Don't involve users only at the beginning, but involve them throughout the process. If you can get in the habit of prototyping with your users, testing things along the way, it's a great way to confirm that you're heading in the right direction. And again, to reiterate another point, sometimes it's hard for users to know what they need in that initial conversation. So you can start building things and have them react to things and you can quickly course correct if they decide actually that's not quite going to meet my needs, and ensure that you develop a useful product before you invest too much time in developing something that's heading in the wrong direction. And finally, don't just build it and forget it, build it and nurture it. So find ways to collect feedback from users. So as they begin using your dashboard, that will help you understand how to iterate on it and define your next MVP for that next version that you're going to release. And while I think that this comment, you know, build it and nurture it is about the dashboard, I think it's also about nurturing that ongoing relationship with your users. So I like to think it has a twofold meaning. Okay, so I actually have a very exciting announcement today. This was not part of the live talk at Tableau Conference, because today we are launching our User-Centered Dashboard Development workshop. This is an eight-hour workshop that I've developed in collaboration with my colleagues over the last seven months to bring UCDD principles, frameworks, and techniques directly to you guys so you can begin implementing them in your business. It's a workshop that's full of content, activities, live consulting discussions with an InterWorks consultant, so that you can understand how to incorporate a lot of what we talked about today into your day-to-day business. So if this is something that you're interested in, scan the QR code on the screen, or there's a link in the chat to download some more information. And we'd love to get you on the calendar and help you guys incorporate this concept of user-centered dashboard development into your development processes at your business. I will say Kendra has been super thoughtful about that course. And I just signed up to take the course myself because Kendra is delivering it internally. So there's lots of great content in there. We'd be happy to share it with you if you're interested. Yay. Thanks, Keith. So excited. Okay, Jenny. Yeah, we're going to hit the Q&A here in a second. I did want to call out a few things before we wrap up. There will be a survey to fill out when you close out of the Zoom, when the webinar ends. If you can just give us some feedback about what you thought about today's presentation, how we can improve the experience, and there's a couple of questions for the presenters. If you could give them some feedback. If you do have questions for Keith or Kendra, their emails are on the screen here. And then, of course, if you are interested in the UCDD workshop and you want to bring what you've seen here, the concepts, broaden that, take it to your team, please let us know. We'd love to chat about that with you. If you'd like somebody like Keith or Kendra to come visit you and your team and customize for you, that's a great opportunity. So I do have one more plug again before we get to the Q&A. We do have another webinar coming up next Tuesday with our partners at Tableau and Fivetran, and it is about scaling beyond the Tableau extract. I'm going to drop a link to that in the chat just so you're aware if you want to check that out. That is next Tuesday, but I think we do have some Q&A to get to, so Keith, you want to hit that? We've got some great questions here. I'm just going to go through them in the order that they came in. Kenneth had a great question and he was talking about at the beginning of the dashboard cycle when you're talking to those users. He said, the challenge with keeping users in mind is that if a dashboard serves many people, maybe you have like ten different users, then they have ten different ideas of what you should be building and that could be hard to manage. Kendra, any thoughts on how you deal with that when you've got a variety of people that all think they need something different? Oh, wow. Yeah, this is a real situation and a tough one to be in. And I can share a quick analogy that often comes up at InterWorks. We talk about like Swiss Army knife dashboards, where if you think of a Swiss Army knife, it does a lot of things. It has a lot of different tools, but it doesn't do anything terribly well. So you're never going to use a saw from a Swiss Army knife to cut down a tree because it's just not a very good saw. And so those kinds of dashboards that evolve into like trying to do everything for everyone, they can be tricky. If you get it right, and I think the example that I showed is actually one place where we had to customize things and make it really flexible because there wasn't a very clear pattern of what the users, what specific data the users needed. You can make some thoughtful decisions there. But once you start trying to do all the things, you might actually start thinking about breaking things out into more specific focused dashboards for specific groups. What do you think about that, Kendra? Yeah. That was going to be my suggestion too. At some point, you kind of hit the point of diminishing returns on a dashboard that does everything. So I think in that situation, if I had a group of users that had all these different needs, I would be doing a lot more question asking to fully understand like, okay, why are these needs so different? Are these actually different user groups or user personas that need different dashboards? And maybe we started out thinking we just needed one dashboard, but then throughout this process we've uncovered, we actually need a suite of solutions to solve one problem. And so I think that, yeah, I think I loved the Swiss Army knife analogy, and I think that in some cases those types of dashboards can work well. But then you also need to look at going beyond if you need to get to that deeper level of analysis for something more specific. One other thing we try to incorporate into a lot of our dashboards is just some basic level of flexibility. Parameters and case statements are easy ways to swap dimensions or measures or time periods. So if people aren't all on the same page about what's the most important way to cut the data, you can give them some options. And that also allows you to create one dashboard that has some flexibility built within it. Yeah, Avery has another question. Sorry, did you want to add something else? No, no, just affirming. Yeah. Okay. Avery asked, where is the line between changing the design and training the user? Some of our users actually are not the most tech literate. Yep, totally understand. There's definitely times when if you've done everything that you can in Tableau and made it as simple as possible, there's still going to be times where you need to teach people, this is how you interact with this, this is how you get from one page to the next. So I didn't say that to write off the importance of doing user training. But if there are ways where you can make something so simple that it doesn't need training, I would say always try to go for that first. What do you think, Kendra? Any other thoughts on the line between changing the design and training the user? Yes, it's a very fine line. I think there's a lot to consider: the number of users, how often the dashboard will be used and accessed. If you are interested in learning more about ways to educate your users about dashboards, this is something we talk about in the UCDD workshop. We have a whole section about education around dashboards and different ways that you can incorporate that when you launch a dashboard, because it can look like a lot of different things. Actually, I'm going to skip ahead real quick, Keith, because there's a question from Kenneth about user guides for dashboards. And that's, I mean, that's the same thing. It's like, do you incorporate how-tos within the dashboard itself? How much do you need to include? And I'm the kind of person that always goes with over-explaining because there's a lot of different types of learners out there. Some are visual learners, some like to read, some like to watch. And so hitting these different points of education for dashboards by putting the same information in different places, either in the dashboard, outside of the dashboard, in a live training can really help at getting that user adoption that you're looking for. But I agree with you, always go with what's going to be most intuitive for the user, but then think about what about that one user that's going to go to the dashboard that didn't come to my training? What do they need to know? So there's a lot to consider there. Another question here that I think I'm going to tee up for you, Kendra, because Kendra is like our documentation queen. She's great at it and loves writing documentation. A user, an attendee asked, should dashboard documentation and FAQs exist on the dashboard or linked to another page such as Confluence? What do you think, Kendra? Oh, I do love Confluence. I've gotten to use it on a few different clients. I'm like, oh, I wish I had this for myself. But I would say in this situation, the best thing to do is keep your dashboard documentation within the dashboard itself, because we don't want our users feeling like they have to leave their experience to get the information that they're looking for. So I always go with either incorporating like an information button that they can hover on the dashboard or having a separate tab within the dashboard if we need more elaborate explanation. I think Confluence is really great when you're doing documentation that's like developer-to-developer documentation, more of that back end. But when you're trying to communicate with your end users, I definitely recommend keeping that within the Tableau experience. Yeah. I think we've also started to think about, you know, internal documentation for developers, sort of the back-end stuff that end users don't see, and then also documentation for users, which is more explaining how to use the dashboard. But I agree with Kendra, the more that you can keep that located in the same place, the more likely you are to keep people in the flow, like if it's a user, the flow of their analysis, or if it's a developer, the flow of their development. So sometimes you just can't fit it all in Tableau, and then it does make sense to add something on an external site. But the more that you can keep them in that tool, I think it's often better and easier to maintain. Someone also asked a question about if we typically prototype in Tableau, or if we use a different tool. I feel like there are multiple answers here at InterWorks and different approaches. So I'll talk about my approach and Kendra if you want to jump in with yours, that'd be great. If there is data that exists and the data is in pretty good shape, I like to just go straight to Tableau with it. Me, I like to actually build things and start to arrange the pieces and see, you know, it's hard for me to start from a blank sheet and envision what something can be, so the data gives me some pieces and components that I can work with. But I do think that in situations where there really is, maybe there's not even an idea of like what kind of data we're going to be working with, people have a business problem and they want to solve it with a dashboard, but we don't even know what to start with. In those instances, I think it can be really helpful to use a wireframing tool, even sketching in a notebook. That used to be my preferred way. But I'm starting to get familiar with tools like Figma as well, which are an easy way to get some things from my head into a form that people can react to. What do you think, Kendra? Yeah, I typically will start by putting the data in Tableau just so I can get an idea of what metrics and dimensions do I have to play with and incorporate. And then I'm a big fan of pen and paper because it takes away that restriction of like, can the tool do this or not? So that you're really thinking about just what is the best way for me to convey this information or to solve whatever this problem may be. I'm a big FigJam fan now. We recently got FigJam for the company, and I don't know how I organized my brain without it before. I'm like, what was I doing for these last years? No wonder I felt so chaotic because FigJam has been great for me to get everything that's going on in here into a format that, yeah, people can react to. And actually I had a colleague this week, Danny, because we had a situation where we wanted to build like a low-effort prototype for the clients. We didn't want to invest too much time in building something robust in Tableau before we got the feedback, but the client was dead set on having some sort of wireframe with their actual data in it. And so Danny had this hybrid approach of building out some basic charts with their actual data in Tableau, taking screenshots of those worksheets, and then putting them into FigJam and rearranging them into a dashboard there because clicking and dragging is a lot easier than adding them to a dashboard tab in Tableau and like formatting and everything. And I thought that was brilliant and the client reacted really beautifully to what he had, and we were able to iterate now three or four times on his design. And so that's honestly, I think going to be my approach going forward because it's the best of both worlds. It's like, here's my actual data and here's what I have to play with, but it gives me the flexibility to rearrange things without a lot of risk like you get in Tableau. So I think that that's going to be my MO. Daniel jumped in with kind of a follow-up question. Is there a specific wireframing tool that we recommend? I don't know that we necessarily have a recommendation for one over another, but I know some common ones: Envision is a common tool, Figma is another one. And then Miro is another tool that a lot of our consultants have found pretty helpful in the development space as well. Any others that you would add to the list, Kendra? PowerPoint even can be an easy way to get something visual that people can react to. Yeah, no, I think you covered it. Yeah, PowerPoint, FigJam. I think that's it. Pencil and paper. For sure. Yeah, and I think what I tell people too is do whatever's most efficient for you. If you're someone that knows how to put things together quickly in PowerPoint, go for it. If you like Figma, go for it. If you just want to sketch or if you want to go straight to Tableau, I think whatever makes sense for you is the best choice. So I try not to force people into any particular tool. Another question in here just about any recommended extensions. I'll be candid and honest and say I haven't used a whole lot of Tableau extensions. I did have a chance to work with InfoTopics which has an extension. They have a couple different things that they do: Super Tables, they have a write-back extension. I played around a little bit with that for a client project in January. There's, I think there's actually an extension that makes it really easy to make Sankey charts. Sankey charts are a source of contention here at InterWorks. They're very complicated to build, and a lot of times they look really cool, but don't tell you a whole lot. But if you ever have to build one, I think there is an extension that makes it a lot easier. You may want to check it out if you ever have a use case for that. Kendra, have you played around with any extensions that you would call out? I have not. This probably sounds a little cheesy, but my favorite Tableau extension is not an official Tableau extension, but it's Curator. Basically anything that I am like, oh, I wish I could do this in Tableau, like, whether it's like building out a report, like a PDF of my dashboard, getting feedback on a dashboard, Curator has it. And so I always get excited when I work on a client project and the client has Curator because I'm like, oh, man, this is going to make my job so much easier. Yeah. We'd love to hear from the group though. If any of you on the call have an extension that you've used, feel free to put it in chat. Someone was talking, somebody asked about the type of charts, a Sankey chart is one of those charts that has curved lines and it shows flow from one state to the next and usually involves data densification and all kinds of crazy things. They're tricky to build, they look really cool. And in the right circumstance they're a great chart and very insightful. Sometimes we see them used for things that we're like, that doesn't actually really tell you anything. But it looks great. Tommy jumped in and said there's an Export All extension that may be worth checking out. So we'll see if there's anything else that people suggest. If there are any other questions, yeah, feel free to drop those in as well. I think we've gotten through everything. I didn't accidentally dismiss anything, but I'll take a quick scan through the chat as well just to see if anything came in there. Someone asked about a gauge extension. I don't know off the top of my head if there is a gauge chart extension. There are other charts that are really difficult to build in Tableau without a lot of kind of custom data modeling. We did have some questions in the previous deliveries of this last night that we can cover, and I thought they were really good since we've got some time left. Yeah. One of the questions that came through last night was how do you determine an MVP, minimum viable product? So what do you think about that? How's that determined? Yeah. This is a tricky one because, again, you want to give your users everything, and you want to build something that's really cool. But in MVP, the best way that I can think to determine it is to look at your problem space, look at your solution, and then look at the list of features that you're hoping to incorporate. And if that feature is essential to getting them from the problem to the solution, then it gets included in the MVP. If it's maybe like a nice-to-have, I put it in a nice-to-have list, and then I try to incorporate one or two of those into my MVP. And then if there's features that I like to think of as like the cherry-on-top features, that's like, wow, it'd be really cool if we could do this, but maybe it's like a higher level of effort or it's not essential for moving them from the problem to the solution space but enhances some sort of experience, then I would say that usually doesn't go into the MVP unless there's time allowed for it. And I usually try to add those things later after I've gone through a few rounds of iteration. So that's the way that I like to think about it. Keith, do you have any other perspectives? I think you nailed it. You said everything that I would have. Yeah. Yeah. Great. Okay. One more question from a previous delivery. Somebody asked in the process of asking questions, no matter what phase you're in, do you have any example questions that you'd like to ask that kind of help move the process along? Yeah, I love to ask the question, what are you going to do with this data? I love to understand if I'm building something for people, how is that actually going to advance their goals or objectives, or what are they going to do after they use a dashboard? Like once they find that insight, what's the next step for them? And that can help me to anticipate, well actually they might need this next or they might want to answer this question next. And always kind of pushing through those surface-level answers to like, okay, well then what comes next can help you create a really useful tool. What else would you add, Kendra? Yeah, I like to look at what happens before and after they're actually using the dashboard or will use the dashboard. Because I think if you get a full understanding of the systems or the process that they're operating in and where this dashboard is going to sit in those systems or process, that's where you're actually going to uncover a lot of insight as to what they're looking for. You know, like we talked about during the presentation and some of the attendees were commenting, a lot of users don't actually know what they need. They're not going to tell you, I need to see an over-time chart with this label and metric, etcetera. But they can tell you the problem and the frustration that they're having. It's our job to then interpret that into the type of chart that needs to be built. So just really trying to understand their frustrations and processes is the best way. I will give a quick plug for my workshop here because in the workshop, we talk about this in a lot of detail, and we do have conversation guides and lists of questions that we go through that you get to take away with you from the workshop to help you with those experiences with your users. Yeah, we got another question here, but I actually don't have any experience with Google Data Studio myself. Kendra, have you ever worked with it? Google Data Studio? No, I think I looked at it once, but it was years ago. Yeah, I don't have a ton of familiarity to talk about the differences between the two and when you might hit that tipping point of making a hard sell to your boss about maybe it's worth investing in Tableau. There's obviously lots of data visualization tools out there. We find that for most of the customers that we work with, Tableau has been the best fit. But I don't know specifically about the differences there in terms of what features you might not have access to that you would in Tableau versus Google Data Studio. Yes, it looks like Chloe, one of our attendees, said that formatting is so much easier in Google Data Studio than Tableau, but she's mostly a Tableau user. So thanks for chiming in there, Chloe. Yeah, there was somebody I followed on Tableau Public and then I realized he was actually creating all this stuff in Google Data Studio and I was like, that's why it looks so great. But it was in Tableau Public? That's confusing. Yeah. He used both of them actually. Maybe it was on Twitter that he was sharing some stuff on Google Data Studio, and I was like, that looks fantastic. Yeah. We have had a couple people reach out in the Q&A about the price of the UCDD workshop. If you are interested in that, either hit up our contact form on the website and somebody will reach out to you to get you more information, or at the end of the webinar, if there's a question that you can answer in there, let us know that you're interested in that. We can give you that pricing. Did we have any more questions come through? Are we good? How do you handle unreasonable or impossible requirements? Tell them no. I don't know. Yeah, that's the answer to that. In a more serious answer, yeah, sometimes the answer is like, I can't do that. There's just actually a limitation and it's best to be honest with that rather than try to promise something you can't deliver. But I do always try to say, tell me more about what's driving the request and is there something that I can build that gets close to that or that is approximate to that or that can be a complement to that. If I dig into like what's really behind the request, sometimes I can find an answer that may not immediately be obvious. Yep. Go back to that curiosity over judgment mindset in those situations and just try to see what you can uncover. And I agree with Keith that honesty is the best policy in these situations of saying, you know, that's not going to be possible due to whatever constraints, the tool, the time, the budget, but see where you can maybe find a compromise. I think that's all of them. So many great questions. This was super fun. Thank you all for joining. Yeah, this was a lot of fun. Thank you guys for being so active. It made the hour fly by. Perfect timing. I just dropped another link, just a reminder on the UCDD workshop. Download that, maybe send it to your team leader or your manager if you're interested, if you want to get more of this content customized, brought to you for you and your team. Thank you, Kendra. Thank you, Keith. Super excited about the launch of the UCDD workshop and everything you brought here. We will have a recording in your inboxes in a few days or check our blog back in a few days and we will have this posted there. Appreciate you all joining us today. Kendra, Keith, thank you so much. Thanks, Jenny. To everyone who joined, especially the multiple Bens, love to see all of you. Yeah. Bye. Thanks, everyone.