Good afternoon, everybody. Thank you so much for joining us today, for Dashboards Reconstructed. We're gonna begin at five past, but just wanted to run through a little bit of housekeeping with you. So for the duration of the webinar, the lines will be muted, but feel free to use the Q and A section or the chat panel to ask any questions that you have, and we'll be happy to answer them at the end. The webinar will be recorded and we will be sending through a copy of the recording via email to everybody who has registered for today. The webinar is brought to you by the Interworks Assist team. So if you joined a couple of minutes ago, you would have noticed some really cool gifts that we've got going on. The first is a link to Interworks Assist, which is your one on one support that you can book with one of our consultants for any Tableau or data related queries that you may have. We've also got imagery there for Curator, which is the embedded dashboard, and completely customizable version of Tableau and Server Care for completely managed services for the Tableau server infrastructure. So let's start with a little bit more information about Interworks. So Interworks was Tableau's first ever gold partner, and we've been working with Tableau for well over ten years now. We are global, so we've got two fifty consultants all across the globe. Our most recent offices opening up in Singapore. We've got a world famous blog. So if you haven't already been over to the Interworks blog, to learn all about, everything that's happening in the BI landscape, please go ahead and check it out. Interworks is well known as being a Tableau dashboard consultancy, but there is so much more that we do. So we help with the entire data landscape, whether it's IT solutions, data analytics, experience, platforms enablement, and so much more. So really we want to work with clients at the very beginning, the initial steps of their analytics, BI landscaping, all the way through to handing those projects off to your own internal staff who are there to support you. And we are thrilled, to this year have been awarded a Tableau Partner of the Year. It's a huge accolade and is awarded to one partner. So we are absolutely thrilled to have that award with us. So leave me to introduce you to our speakers for today. We have David Duncan and Chelsea Morgan who are both from the experience team. With that, I'm going to pass you over to these guys. Thank you. Thank you, Vicky. I'm just going to do one bit of housekeeping on my own accord and make sure do not disturb is on. We're good. Cool. So hello everyone. I am David Duncan. I'm the user experience team lead here at interworks. I've been with the company for a little over eight years now. Started as a graphic designer, helping out rebrand the company and design the website and printed materials and things like that. But over time, we wanted to get a little bit closer to the product that our analytics consultants were putting out. So we started figuring ways that we could make the analytics experience a little bit more user friendly. So that's what we do today with the user experience team. And I'm joined by Chelsea. Do you wanna introduce yourself? Yeah. Hi, everyone. My name is Chelsea Morgan. I've been with InnerWorks a little over two years now. And, yeah, I'm on David's team, like he was just I'm also from a more traditional graphic design background. So it's been a really fun challenge and also, yeah, just journey and exploration to jump into the data and analytics sort of world and get to know what it means to apply the graphic design background and skill set and expertise to that field and sort of like pioneer Tableau designing in a way. So really just making the most, the best and most intuitive experiences for people is what our goal is with clients every day. And, yeah, that's sort of what we're here to talk to you about today. Yeah. So a little bit more detail, we're going to cover our creative process of how we get into big projects and get out of difficult projects. So hoping to give you some examples of the different types of output that we do throughout our creative process, and hopefully illustrate major impact that design and planning will have before you start developing a dashboard. We truly believe it does make the development phase so much smoother. It makes consultants happier that they have something to build off of. And hopefully, we can give you some examples of ways that that has happened in the past. So this is the team that we're a part of where it's the experience team. We design and we build and Chelsea and I do not develop, but we are next to a bunch of really smart developers that build our product of Curator, which Vicki mentioned earlier, it's where we can host dashboards in a web environment and customize look and feel and customize navigation and have a lot of options for changing the way that people need their data and experience it and navigate through it. That also means that we're the designers of dashboards. And so a lot of work comes our way to just make people's data look more approachable and to change the way that it is experienced, whether it be through navigation, clever designs, more on brand designs, you name it. So Chelsea, if you want to talk about how this work comes in. Yeah. So basically, we have this illustration showing that clients kind of come to us in a variety of different ways. So some of them come in this top option that's basically they have a lot of vision and ideas and concepts in mind of what they're looking for in a data visualization realm, but maybe their data's not ready yet, it's not cleansed, things like that. So we can work with them to sort of figure out and ideate on, okay, we'll take your vision, run with it, help you to improve that idea before the data's ever ready. And then whenever it is ready, you can implement it and sort of apply and just plug in all of that information to what we've already created and designed. Whereas in the second option, some people come to us with no idea of what they're looking for and their data is ready and ready to consume, ready to be worked with. And so, we can help them on the flip side of that and basically, yeah, just show them many different options of what we could do with that data, dependent on their specific constraints and what they're looking for in a dashboard. So, yeah, that's sort of the ways that clients come into us, we can work with all of them, because we work through this sort of three pronged process. You might have heard of it sort of called design thinking, but we like to think of it more in terms of, like, our UX team process and workflow because it's what we work through instinctually every single day with every single client. And I'll give you a brief overview of what each of these things is. And then as we move forward in the presentation, we'll get more into up to each of these things. So essentially, it's first researching. What that entails is basically just spending time understanding and sort of interviewing users and really empathizing, putting ourselves in their shoes to understand how are they navigating through the data? How could that journey be better, more clear, and improved? What are they really looking for? What are the constraints here? Yeah, just asking the right questions and getting to the heart of what is really needed on a project. And then we take that information and understanding, and we move into this UX or user experience phase where we're sort of creating the structure overall, the layouts and the bones and skeleton of what everything will be. So UX is more focused on the functionality of how things are working and, what interactions are happening. When I press this button, where am I taken? Are the experiences what people expect and anticipate to happen or not? And that's a really important piece. And then when we feel confident in that phase, we move into this user interface or UI phase that is more of the applying people's branding, making sure everything is aligned with their styling overall. Yeah. It's really styling things out and thinking through people's preferences on colors and how are we really presenting things aesthetically to people and visually. So that's sort of the overall process. And like I said, we'll go into more depth. So moving into this next slide, we like to use this analogy to sort of break everything down and make it a bit more tangible that building a dashboard is sort of like building a house. And in that, what we're sort of thinking through is when we think of this process of this department, maybe comes to us and they have a need for a dashboard, they have this data. And a lot of times the process looks like this, where they're like, okay, I need a dashboard. And then immediately jump into Tableau and start developing. And as you can see here on this, like, calendar outline, it's like, that can take many months. Or maybe this is what's expected is just, okay, we'll work through this process and immediately go through that. But then it ends up looking more like this, where the journey, because they immediately jumped in without sort of the forethought and planning is a bit more tumultuous, and there's a lot more highs and lows, and maybe they hit a lot more speed bumps along the way and frustrations because it's more complex than that. And maybe their dataset is very complex. And so spending more time putting in the consideration in the forefront is important. So just relating it back to building a house, it's this understanding that you wouldn't, as you can see here, you wouldn't just jump immediately from, I really wanna build a house to, yep. We're building it like the next day or the next week, because you'd wanna talk to architects and construction workers and builders and all these things. Yeah. As you can see here, it's like, that's not what we wanna do. We want to spend time planning, thinking, making thoughtful decisions that are very intentional. And so the idea that we're introducing here with the house analogy is essentially that this planning phase is really, really crucial and important to the entire process, and it'll make all of the rest of the steps of the process a lot smoother. When we move into development, testing, and deploying the dashboards, that's just going to work a lot more smoothly because we've spent the time doing these sitemaps, personas, interviews, all the things that you see listed here. Yeah, thanks for that. So to kind of go back to the analogy of building a house, we picked that up just because we found that getting into the design space around analytics and dashboards and different analytic services, different applications of the skill set. It was just kind of hard for our clients to grasp and wrestle with, and there's not always the right verbiage and terminology readily available to talk about the different phases of this project and all of the different nuance that goes into designing and planning a really big dashboard project. The way that we think of the first step that you would go through in deciding that you want to build a new house would be something like, well, you would first need to figure out where this thing is going to be. Is this what continent are we on? What city are we in? What neighborhood will this new construction exist in? And then it's a survey of the land. So are the is the soil right? Is the ground suitable for a structure like this? Does it have the right minerals? Is it connected to the city's electric or plumbing? It even suitable for living? Or maybe there's a bunch of wildlife there? That's the very first step. So we're going to try to understand yep, what will be built basically. Then if we get closer, and we say like, maybe this is the right place, we're going to think about laying a foundation. To do that, we're going to have to maybe decide, okay, this thing we're going to be building is X width by Y height. It is this many square feet, it will have garage, it will have a kitchen, it will have three bedrooms, we might have to edit the land that we're on, we might have to maybe bring in some construction workers, and we might have to maybe remove a tree or edit the flatness of the ground. Overall, we're hoping to just be able to get the groundwork in place to understand like, yes, this is suitable before we start nailing wood together and actually building the structure. And then once we can visualize that foundation, the amount of space it's going to take up, then we want to try to see the end result. And so this would be understanding like, okay, so we are going to have three rooms, there is an entryway, there is a garage on the south side, the sun's going to hit it from here, the materials, it's going to be built out of this specific type of wood and mortar and brick. This is the color that it's going to be. Is sort of how we would expect. You know, we're going to put a lot of money into building a brand new construction, we will want to see what we're actually going to be building to just make sure that everyone is on the same page of like, yes, that is the house that I also want. And yes, I will pay for that. I feel really confident about going into it. And so when we marry that with our dashboarding process and rewind, Instead of surveying the land, we have our research phase that is trying to do the same things. Want to understand who is going to be using this. Want to understand the neighborhood, if you will, that this is this whole project is taking place in. So that would be things like understanding tools and applications that maybe our users or clients are used to using and trying to maybe pick some of the user interface conventions that they are comfortable with navigating and applying them to this new environment. It will be interviewing users to understand why they are frustrated with the current implementation of their analytics environment, whether that be any number of tools, Excel, ThoughtSpot, Tableau, or what have you. I just want to hear what has prevented people from doing their best, most effective work. We're going to assess their technical abilities and their familiarity with these tools. If we are trying to design for a group of new users to Tableau, we will take that into account to design something that is easy to navigate, especially when you consider hiring new people, and being able to bring new people into the fold and start working immediately on dashboards that have maybe existed for a few years already. And so through this research phase, we're trying to really decide the scope of what to build. Then when we would be laying a foundation after we've surveyed the land, we would then move into our UX phase. And so this is where we get to experiment with different layouts to iterate and figure out what's going to be right for our use case. And so this could be going through a number of screens, basically trying brand new rectangles and brand new arrows that connect to these rectangles to say, Hey, what if this is how you navigated through your data environment? Sort of like if you had, if you were on one of those house shows where they say like, hey, you could take house A or house B or house C. That's kind of the fun of getting to watch those shows because you're like, wow, I would totally take a but they went with B for some reason. We get to kind of propose those types of things within this UX phase because we can try really wild, different approaches and iterate so quickly. So in this UX phase, we're going to be trying new ideas, hopefully establishing navigation and interaction conventions. If there are a whole bunch of dashboards in your environment, we're going to be trying to do an audit to understand, do all of these dashboards still need to exist? Could we maybe merge some of them? Do we need to add any? Maybe we need to add in an overview dashboard to sort of summarize a group of dashboards. We're going to try to get to that point here. And then we move into visualizing the end result. So this is the UI phase for our dashboarding work. So we're going to hopefully be bringing things to be more on brand and make them feel like they're coming from within the organization that our clients are working within. So this is basically the wrapper around those bones that we've sort of figured out in the UX phase. We're going to be trying to establish color as a functional navigation tool, as well as visual analytics tool. And this is the thing that we can surface up to our clients, and they can surface up to their stakeholders, project owners, colleagues, and have something to point at to say, Yes, that is what I am anticipating this dashboard to look like. Yes, I do agree that everything is on the screen that we need to have on the screen. So let's begin development, no matter how many people are touching it, we all have this one source of truth we can go back to to say, this is what this thing is supposed to look like. So to sort of summarize this three phase approach, again, our research phase is where we're going to be doing all of our interviews, identifying the pain points of your users, and trying to empathize with them and meet them where they are. So one of the outputs that we might do from that phase, among other things, we could do a design audit deck, which is something where we put together a whole bunch of recommendations, and give it back to our clients to say, Hey, here's a bunch of things that we think could use a lot of work. Why don't you assess this on your own and decide when it's right for you which things to tackle and when. And then we move into the user experience phase, which is where we'll be working on those low fidelity wireframes, trying to establish a structure and these bones of the whole project, trying to figure out the navigation pieces, and especially considering if we're using that curator tool that we mentioned earlier, the ability to host your dashboards in a web environment, have tons of customization for styling and navigation. We're going be involved in that too, to just make sure that we have a great experience for when people log in, they get a great welcome graphic, they have really slick animated GIFs from all their dashboards are loading, all to sort of push adoption and give a well rounded structure to their data environment. Outputs from that phase would be things like low fidelity wireframes and sitemaps to help everyone find things that they can all point to to say, there are fourteen dashboards or yes, there are fifty five dashboards, and they're all going to link together this way. And then we move into the UI phase, the user interface phase to just push things a little bit further to make them feel on brand. Would be deciding things like what the iconography will be for various sections. Will be, you know, if we decide in the UX phase that we're going have a left hand navigation, then the UI phase is deciding what that navigation looks like, how wide that column is, how it looks like, where the buttons are that actually encourage our users to interact with it. And outputs from this phase would be something like high fidelity mock ups or clickable prototype that we would want to test before we begin the development process. So I'll kick it over to Chelsea to do a little bit of a deep dive into some examples of these types of outputs. Yeah, so just to give a little bit more depth and detail on each of these things that David was just talking about, we'll start with, again, in the research phase. Essentially, with the audit deck that David mentioned, we would provide things like this, which are overall feedback and recommendations on just design principles, really, that we see as lacking or just needing overall improvement. So it's basically going through we can do it in a number of ways. It could be like any of these examples where it's just maybe providing a new example of something. Maybe it's low fidelity, but it's more just recommendations overall and sort of like a sketched out idea of like, here is general interface and border and chart usage recommendations that we think would help you. And these are just overall feedback points that we would be putting together in a deck for people. And in this slide, can see that it doesn't always have to be those four that we saw before. It could be any number of different elements that we bring up to people, just depending on what you're bringing to us and what you are bringing to the table in the project. So we wanna make everything look really unified, and we wanna take all of the principles and the background that David and I both come from of traditional graphic design and, like, applying that to the data world and saying, these are the principles we think that not only aesthetically would help you, but also just functionally would help everything to flow better and functionally work better. And here's your navigation tips. So basically tips and tricks from us that will help people to have the best and most intuitive experience overall. So we can put together a deck like this that has many recommendations of all of those things. And then, the next slide, we are talking about the another phase of research, which would be assessments or sort of like user inter interviews and, just spending time understanding what people are really looking for. And what that means is each of these points. So how adept are your users? So are they really familiar with the tools like Tableau that you're using, or it could be anything else like Snowflake and, yeah, all of these different tools that we have. So basically, are they really familiar? Are they really new to it? What does that mean for your dashboards and how simplified or complex do they need to be thinking about the constraints of size and format, where will these things be loaded? Are they gonna be really slow, if we are loading them, on an iPad versus a TV screen versus a desktop computer? Just thinking through all of those things for not only formatting and dimension sizes of the dashboard, but also performance and functionality. And then even thinking through and asking really pointed questions about styling preferences. Are there specific visualizations that your company or industry as a whole needs to use? Or, can we switch those up and edit those and help you to choose the best ones? Or is there a list? Does there need to be filtering options? What are the styling choices that do you have a style guide? All of these things are questions that we'd be asking people in the research phase. And then moving into the next phase, we have UX outputs that I was talking about. So this is an example of a sitemap that we've created, that will show basically how everything is correlated and works together in the hierarchy and the structure of your dashboard. So you may have an entire complex workbook that has many different pieces as far as a landing page and a login page, and then drill downs, and then even further detailed drill downs from there. And so we want to take all of that information and lay everything out in a way that's like this, where we see the connection, we see the correlation, we understand how to navigate through all those things and make sure that we're all, as a team, aligned on those things. And then once we do that, it's moving into this next phase of wireframing those things and understanding how are people approaching these dashboards. Are they they're gonna be looking, we know from data and research that they'll be looking in the top left first. So, are we making sure that we're putting that priority one information there? And in the hierarchy of those things, we wanna put the most important information there and then move downward from there to the least important information in the bottom right. So just thinking through those things and making sure that we're prioritizing the information in a way that flows well. And then, yeah, just creating wireframes that connect those things in the same way that the sitemap does. And then in the next phase, we'd be talking through UI outputs. So it'd be things like mockups that are a bit more polished and refined and closer to that end product. So then we're thinking through at this phase, what are what is your branding like? What does that styling look like? And how can we apply that branding and styling and color usage to your mock ups and to these dashboards? And thinking through design conventions and sort of patterns that we want everything to follow so that we don't have to reinvent the wheel every time we come to a different chart or header or title. Thinking through, like, this example, you know, like yeah. Again, styling, but also just like the hierarchy and structure of everything. And when we establish those design systems, making sure that it's consistent and cohesive across the entire dashboard or set of dashboards. So then from there, we move into this testing and prototyping, phase where we can create a high fidelity prototype that's interactive and put that in front of people, put that in front of users, and see how they interact with it and understand from that, are they doing what we expected them to do and anticipated and desired them to do with things functionally? Or do we need to edit things so that they will have that same, reaction that we're looking for? And you'll notice here that we have this we've highlighted the prototype and test within our planning phase because that is part of our UX UI process. But then there's also a test a test phase that comes later after development. So it is totally fine and actually very helpful to test in both of those ways. So in the phase where we're just working with prototypes and mockups, it's good to test those things before development and then spending time after development in case anything has changed. Also testing again to make sure that again, we're aligned on these things and everything is the most intuitive and the best product in the end. It's a great description. We think it's really important to do this multiple rounds of testing. Because when we're in this planning phase, we're testing things like navigation, understanding, making sure that things are on brand making sure that the right amount of real estate in a given dashboard is as expected for our end users, they might say like, Why is that so small like that should be way more important, or they could say like, I don't see this on the screen. That's what we're trying to figure out when we're testing prototypes whereas it's good. It's crucial to your Tableau workbooks or whatever it is that you're going to be deploying. It is connected to data, because then you're going to start experiencing things like the load times and what the calculations that Tableau is having to do. Maybe you're going to experience something that we don't hit in when we're just clicking through a prototype. And so the prototypes are super helpful for figuring out a large portion of how this is all going to shape up, but then you just kind of have to make sure that we are going to do this other testing phase, because maybe something won't be performant. One of the fascinating things that I've been able to position more over the several past years here at inner works was this idea of when you have slow performing workbooks that it's got to be a data issue. And I try to argue that, there probably is a data issue but there's also probably a design issue. And maybe we can change the way that you are even getting into this dashboard is loading. 1000s of rows, maybe we can prevent it from loading a couple thousand of those rows and maybe we can try to be a little bit more careful about you know what we don't need to load one hundred percent of this huge list of tables for you're going to just like scroll through endlessly immediately why don't we land you at a simpler screen that just has a few summarization metrics that allows the user to navigate and find these little waypoints to choose like, yes, I do want to experience this really long load time. Am willing to accept loading hundreds of thousands of rows, or no, I don't really need to bother with that. I'm going to just choose a small slice. We can use design that way to change the way that people are experiencing these bits of data. And that's why I think it's important to go back and forth. Maybe you end up finding something in the test phase after development that says, Hey, let's go back to the prototype and see if we can change a couple things. Largely preferable scenario than having to do all of that once these things have been deployed. So to just give a little bit closer look as to how we would use a prototype, I'm going to back out of this PowerPoint presentation, and I'm going to navigate over to this application called Figma. And real quick, Figma is a design tool that we love. Create our low fidelity wireframes in here. It comes preloaded with lots of great templates. It is just a great way for us to basically draw shapes and wireframe things. Saw some of these things earlier. We also have a great library of assets so we can pull in charts that have variations of them. We can pull in KPIs that allow our consultants to edit them live with our clients and confirm names of KPIs or confirm names of whole sections on a dashboard. So this is the FigJam component. This is more of the whiteboarding tool. But then we also have the FigMa component, which is more full featured design, and we get more nuanced controls over the way that things are rendering, right? So gradients more angles custom corners things like that. But through using those tools we create a high fidelity design kind of like this, this is a dashboard mock up, this is a fake completely fake dashboard. But this is just for the sake of this call, right? I just wanted to show this is something that we could put in front of a client. And this tool is wonderful because it comes built in with a comment feature, which saves us a ton of back and forth around emails. Our clients come in here and say, Hey, this color is totally wrong, or this shouldn't be called category one, this is something totally different. They can tag Chelsea or I or anyone in our experience team to say, this is an issue, we'll get a notification about it. It's tied directly to our designs, and we can thread conversations just around the font choice on one section or the color on one section. But I think that more impressively is this allows us to put together this clickable prototype, right? So in this case, this suggestion to the client would be, what do you think about this concept of having these white buttons to navigate to a different dashboard? And so we can cue them to say, Would you think to click on this button? Does this take you to where you anticipated going when you clicked that Go to dashboard button? We can propose things like filter slices on the left. So maybe we say, what do you think about this convention? Is this something you want to pursue? Test it out. Click one of those like that. Does the screen react in the way that you're anticipating? Or maybe we say like, oh, you know what? I was totally anticipating there to be more of a reaction or some charts to change. Cool. We will take note of that when we are testing this with the end users. We will take note of things that they find maybe frustrating to identify. Maybe they don't notice this highlighted color of instructions here. Maybe they don't notice this back to overview button here. Those are the types of things that we're going to use this clickable prototype to understand like, yes, we do have everything covered on this screen, or maybe we don't, and we need to go back to the blueprints and add to them. So that's just a really simple Figma prototype. Some techniques that we recommend for doing that testing phase. So obviously you have to have your prototype together that has your main features established. This would be like if you're going to try to have separate navigation, or have filters on the dashboard, or maybe you click a card on a dashboard, and it takes you to another dashboard. Those types of features we need to have figured out because in step two, we're going to create a script to ask users really pointed questions around those features. So it'll be like, what would you click in order to filter twenty nineteen data down to XYZ? Were they able to find that easily? Did they look on the right edge of the screen? Were they looking at the left side of the screen? Chelsea and I are trying to notice even just their eyes, like are they scattered? Are they comfortable? Are they frazzled? We're going to record those findings. And then we're going to analyze the findings, gather them in probably an Excel document, or put it put push it into design audit deck like we had shown earlier, we can share that with the team. So that could be internally or externally with the clients, they can share it with their own stakeholders and strategize around there. We'll then take that feedback from the prototype and say, Do we need to edit this prototype? Was that one person out of the ten people we surveyed, they couldn't find this one button? So is that something that we should address? Do we want to take that as maybe ten percent of all of our users might have similar problems once we do roll this out? When we're doing a small group, it's not that big of a deal, but these are the things we want to address before we do roll it out to one hundred or one thousand users or 10s of 1000s of users. And then, again. And why not keep editing the blueprints before you do dive into the actual development process, but then start developing and deploy once you feel confident with the test results. Purpose of this phase is to try to just meet your users needs and understand where they are. We see that there's some conversations that don't always surface up naturally within a single organization. They've some of our clients find it nice to have this sort of third party to ask maybe some more difficult questions. Maybe there's some users that are afraid to critique a series of dashboards, or they're afraid to critique a data environment because they are working under the person that created it, maybe. We get to be this third party that takes these conversations away from them, or we help facilitate them for them, but we want to get a really diverse roundtable of people when we do these conversations. Small users and large users, people with lots of data and people with not much data, people that are really used to analytics tools and people that are new to tools like this. We don't want anyone being fearful that they are going to be without a job because now there's all these clever visualizations and analytics tools. We're going to help them understand that this is a gradual change. They're still very important, and we are going to just evolve the way that they are doing their work and hopefully saving them time and energy overall. And if we can have a global perspective, that we are not just living it within our bubble that we contend to do. We want to get perspectives from all over, so that we can address language barriers or any sort of cultural differences that might not really be apparent right off the bat. Bobray Accessibility needs to be at the forefront of these conversations. We're trying to understand if things are easy to locate on the screen, if they are legible, or people are having trouble discerning certain things, they're unable to understand something, or if they look at something and they're like, I don't know what I'm even looking at. That's a huge red flag. We want to make these things user friendly, so respectful of their time and hopefully easy. So I'm going to toss this back to Chelsea for a minute to just kick off this section about SuperStore. Yes. So we have a question here of, have you heard of Superstore? I think if you've done basically anything with Tableau, you probably have, because it's essentially just the fake data or like fictional data that you can use to sort of kind of mock things up in a way and throw ideas out there in Tableau. So we see this example here of things that we pulled from SuperStore of maybe a product drill down that's more showing more detailed views and the heat map. And then we've got this bullet chart talking about sales and profit with product names. So maybe we're having some comparisons and then also the sales performance versus target. So maybe we're trying to track things overall. How are things doing? Positive, negative? Where are they at? And then we've even got, a line chart to show things over time and maybe how things have changed profit wise or sales wise. And these are all different views that we can just pull even from this example of Superstore. So we're throwing out this idea of with Superstore, what if we took that and we have this fictional client that we're gonna do SuperStore for a marketing team? So, if you take this idea just to show you a more tangible example or like a physical example of this, We take all of those insights and all of those example charts, and we now want to put them all together. We wanna merge all those things into one dashboard. It needs to be external facing, so it needs to be really on brand. And then we understand that the users are new to Tableau, so they're not as familiar with the tool, and we need to make it simple so that they can understand it. And then we would move into something like this, which is just understanding what the pieces are, breaking it down into pieces, and just sort of laying them all out. Maybe it's something like this where we just take screenshots of specific charts and then put them all together on a singular layout here to understand what we're looking at. And then we would do something like this where we, are taking notes on each of these things for ourselves really, and also to make sure that we're aligned with the client on, this is my understanding of what I'm seeing here and what needs that you have that I think it's meeting or not. Maybe we talk through, do these visualizations make sense for these things? Or maybe there's better suggestions that we have. So it's just writing out our understanding and aligning on those things with a client. And then we would move into something like this. Low fidelity mockups. And this is just a time lapse to show basically our process and workflow of how we're working through these things. Yeah, just looking back at all these titles, trying to make sure that we're getting all of the naming conventions correct, or maybe we're renaming things along the way to be more clear, to provide more clarity and, depth on different pieces of it. Yeah. It's moving things around and understanding yeah. Like David was mentioning earlier, we have this sort of library we can pull from to throw in some different examples. And maybe we're thinking, like, he has in this top view of that arrow, like, how are people gonna be looking at this? What is their eye direction gonna be? And how can I prioritize the information and structure it in a way that meets that? Yeah, it's just moving all the puzzle pieces around because this essentially is a puzzle that we're piecing together. And like we mentioned earlier, thinking about the real estate of the dashboard as a whole, we understand the sizing that we're working with and those constraints. So, working within that space and understanding how much real estate needs to be taken up, what is the percentage for each of these items, depending on how important or not important they are, and where things need to be within that hierarchy as well. Yeah. So it's just a matter of, like, labeling and getting these low fidelity options out there. And what's great about this process is you don't have to feel as married to your ideas or as sort of like high pressure because this is low fidelity and it's it's more of a sketch. So it's easier to kind of toss out ideas. You're not feeling so attached to them because you haven't spent like a hundred hours in Tableau trying to like match all your data and make sure everything's perfect. It's yeah. Just like that time lapse showed, we can work through this really like quick and dirty sort of ideating and just duplicating things easily and providing new options for you. Yeah. And then with that, we push it just a little bit further. This is taking it into the high fidelity step of adding just a little bit more flavor and personality with textiles, colors, maybe gradients, trying to get closer to what the end product would look like, right? And this is totally just a fake example that we created for this presentation, but this is very much the process that we would go through of first step, low fidelity wireframe, then we're going to put a little bit more color and personality to it. We're at this stage trying to understand, okay, if this is a categorical thing, maybe what colors can we use? How are these colors going to look when they are next to each other in a stacked bar chart? We're even going to consider what the instructions are underneath each of these charts. Should the instructions be bolded or should the chart title be bolded? How many lines of instruction are there? Because that will change the size, the height of the container that those top two sort of summary metrics are displaying? Yeah. And I think this piece and the last piece, both of these time lapses kind of show that our process is really fun and a lot of our clients find this sort of like brainstorming piece of it more fun than just maybe a lot of people are just always hidden behind the screen working with data. And so I think sort of bringing design into the process and bringing in this planning phase can make this a bit more enjoyable and it can lead to higher adoption rates and people being overall more satisfied because we're spending more time doing things like this, moving things around. It's sort of like we're doing a lot of the hard work on the front end so that when you get to that back end of development, things can be a lot easier. Yes. So as you can see, this allows us to iterate really quickly, wild new things without too much effort. So once we get to a point where we have these high fidelity mock ups, then we would be able to share these with our project owners or stakeholders and say, Hey, what are you liking? Which one are we going to pursue? And since today is focused on the design conversation of building these things, we don't actually get to show how we would build these things in Tableau, although we have tons of other webinars that you could tune in for things like that, how to actually build these things. But from a designer's perspective, here are some tips for pulling this off in Tableau. Recommend having a style guide to document some of the conventions you've ironed out, such as your type styles, your variations in color, things like that. Limit your variety when possible. If you create one great looking dashboard that has a solid structure, let's try to stick with that and maybe just push that in small places rather than creating an entirely new structure for your users to figure out because it's going to be just one more challenge for them. Whether that's dashboard variety or charts styling variety, try to just limit that. Fight for breathing room when possible. Tableau likes to fill up the screen space for you. We find that a lot of our clients really value just a little bit of that breathing room, adding a bit more white space, adding in a blank container to just say, Hey, we understand you are busy, you have a lot going on. We're still in the middle of a pandemic. Here's some free space on your screen, you don't have to just be overloaded with everything all at once. Your font choices to three to four variations of a single font. Is going to help establish your hierarchy and be clear for your users to navigate. Go into your project understanding, hey, is this going to have a background image? Do I need to float my containers? Is this a fixed size dashboard? Do I need to be prepared for a flexible width dashboard? All of those things have their own pros and cons, but there's different approaches to everyone's workflow. And finally, lean towards simple at first. And so to summarize everything that we've talked about today, you know, we've talked about our research UX UI phase, and we married it to how you would go about any other really large projects such as building a house. You would first survey the land, understand, is this something we're going to tackle? Is this the right environment? What are the other things at play here? We're going to try to lay the foundation to say, Yep, it's going to be this big, we have this many dashboards, this many items in play, then we're going to try to visualize the end goal so that we all have a single source of truth to point to to say, Hey, everyone that's involved in pulling this off, we have this thing to point to, it's got to look like this, it's got to perform like this. And hopefully through this phase, you see how we have gone through the process of dashboards reconstructed. So thank you for that time, everyone. I know that we ran, we just have seven minutes left before the top of the hour. But Vicki, curious if there's been any questions that have come in or anything to address. Yeah, absolutely. A couple of questions have come through. I think probably we've answered some of these as the webinars gone on. But if we can quickly revisit them, that would be great. So the first question is in the no vision have data scenario, what are the key questions to ask to get the essential info to drive dashboard design? So no vision, but yes data. So the types of questions we'd be asking are, okay, who's doing what with this data? Who actually has responsibility to answer something or turn in a report about XYZ. There's probably some sort of process around maybe pulling together an Excel report or letting maybe a superior know about the status of a category or a product or a region or something like that. We're going try to meet with them to understand like, hey, here's how these meetings go today. Normally I print out an Excel document and I slide it across their desk. It can start from something that is that simple. It is understanding like, okay, well, what is on that piece of paper? It's probably a few things that are pertaining to this category or this region that this person is tied to. So we're going to try to zoom out a bit and say, I wonder if there are other categories or regions that might need the same sort of reporting. So we're trying to go through that UX process of just ideating. If there was this one screen that had a bit of a distribution chart or a summarization or a table that could all pull these things together. We find that, you know, trying to visualize things in that really early phase starts getting everyone's brains kind of turning around. I didn't really think about these two pieces of data being on an interactive screen. Why don't we test that out and see what can come of it? Hopefully through a lot of iteration, we would get to something that is useful. Yeah, I think a really simplified version for myself that I come back to with every client conversation in consulting is basically just like who, what, when, where, why, because it's like, who's gonna be using this when and how are they gonna be using it? What information are they really trying to glean from it? What is the value that is added from this dashboard? What are they trying to get out of it? Why are they coming here? And then, like, where are they going next? You know? Like, do we need to lead them to a specific website or into another drill down from there? Like, what does that mean? And so working through those, like, really simple questions of like who, what, when, where, why, I think is an easy way to think about it. Thank you. We've got another question, which is what tools or software do you use in the UX phase? Yep. So we use FigJam. It is a part of Figma. So you could go to figma dot com and fig jam is a cheaper. It's, there's a, I believe a free tier where you can have just like access to a couple art boards, but we find it as a really great tool for putting together wireframes. Thank you. And then the final question that we've got, so please feel free if you've got any questions, pop them in the chat section or in the Q and A is what are these tools you are using for lo fi and hi fi mock ups? I'm guessing that's Figma again. Yep, so I can just bounce out really quick and show that again. This is Figma. And we're in a play mode but when we start a new file we can choose between a full Figma design file or a fig jam file and fig jam is sort of the whiteboarding tool. Design files are the more robust things where we're, you know, maybe being a little bit more specific with color, because when we go into the fig jam files. There's a reason that they limit us to just a select few colors here, we just have eight colors because at this point, we really should not be worried about the exact hex code. With our text style so they limit your text styles in here to about five different weights, So they have small, medium, large, extra large. You might think, that's not the numbers that I'm used to seeing. But we find that this sort of limitation allows us to, it allows all users to sort of think with a sharpie at this moment, we're not trying to, you know, be in there painting the final wall color, we are trying to understand like, this is the hierarchy, yes, this text will be larger than this text and this text will be even larger than that text or not. FigJam is the component that sits right next to FigMa. Wonderful. It looks like we have come up to the hour just, and we don't have any more questions coming in. So all that remains is to thank everybody who attended today. We'll be getting the recording out to you. That's going to have contact details. If you do have any additional questions that you have for the Interworks team, even David and Chelsea, please feel free to send them there. Oh, one last quick question. Are you able to quantify research and UI UX time with user adoption? Unknown I mean, I don't have an exact number there. But yes, so we find, you know, I guess I do have an example, there was a project that had seven hundred hours of development time, And we spent about two hundred hours in the planning phase trying to understand how these seven hundred hours were going to be spent. Been colleagues of the people that were on that larger development cycle, hearing all of the other elements that were at play with like, Data is not ready. People are having trouble making decisions. We had to publish this ASAP, and there's all these fire alarms. There's so many use cases where it's like, wow, have we not had those blueprints? There's no way that this would have gotten across the finish line. There's no way that we would have had something to reference back to say, hey, we're off track, or this is a scope creep. Just through experience, you're going to have a smoother project. You're going to have confidence from your consultants that are trying to build these things because they don't have as many question marks floating around, and overall, it gets everyone on the same page. Brilliant, thank you. That was definitely the last question. As I said, any other questions that you have, please feel free to reach out to us and we're more than happy to support you. Thank you so much, David and Chelsea. I'll let you get back to a very well earned coffee. Thank you. Thanks everyone. Thanks everyone. Bye. Bye.