Alright. Looks like 11:02. We've we've got attendees. Thank you all so much for joining. Yeah. I think we'll go ahead and get started with our webinar on design best practices with Sigma apps. We'll really be looking at the, you know, the key decisions that you're making in creating a foundation for your Sigma apps that will not only be user friendly, but also performant. And we're I'm really excited to be here. My name is Kim Aagaard. I'm an analytics architect with InterWorks, and I I build a lot of Sigma Sigma apps, other other dashboards and apps. I work with data governance and project management as well at InterWorks. But I really love design UX functionality, so I'm super excited to be cohosting this webinar with David. I you know, my my own personal plug here is that I just have been working on a Sigma public app, getting so much great insight from David on how to actually make this app useful and fun and and interesting, but also get the users to interact with it the way that I want. So David's insight is wonderful, and y'all are in for a treat getting to hear him. So, David, let me pass it off to you. Cool. Thank you, Kim, and hello, everyone. Thanks for joining today. We are at design best practices for Sigma apps so we can build apps with the quality that our users expect. And to give you just a little intro about myself, I've been at InterWorks for a little over twelve and a half years, and I'm coming to you from Tulsa, Oklahoma. And the, like, way oversimplification of my piece in the puzzle at InterWorks is that we have clients that have all sorts of needs, and we also have a lot of analytics consultants, whether that be architects. We've got data engineers. There's a very long list over here. But I just threw this together to explain that I'm sort of like a middle person to help hear out what our clients might be dealing with and try to envision what could be. Right? And so sometimes we're working directly in Sigma, but a lot of times, we're also working in another tool, like a whiteboarding tool, like FigJam, or we'll use Figma to mock up what things could be, and then we put that into, reality. So to sort of level set here Sorry, David. I'm so sorry. I realized I forgot to do the housekeeping part of things. I was too excited to jump in. Let me let me just jump in real quickly. Yeah. Exactly. Before before we get rolling too much. So just for everyone on the call, we are recording this presentation. So we will be sending a recording of this out within one to two business days to all of you. So no worries. You'll have access to this in the future. And then as we go through this, please feel free to throw any questions that you've got in either the chat or the q and a functionality, which you may have to search in the more button under under your toolbar on Zoom to find q and a. But no difference to us between the chat and and the and the q and a functionality. So we will be able to answer those either as we go along, or we'll try to reserve some time at the end of this session as well to make sure that we can cover some questions for you. So, yeah, thanks so much. Thanks, David. Back to you. Of course. Appreciate it. Thank you. Yep. So to sort of level set here, you know, there's a lot of ways that we might think about design. It's a huge term, and it hits every single part of the things we interact with on a daily basis. And so, obviously, I'm gonna be talking to you about Sigma, but I'm also gonna sort of relate it back to other parts of our worlds knowing that there's still a lot to learn about Sigma. And we've spent a lot of time with other things like our phones and just general websites, and interacting in the environment that we can take some of those lessons and put it into, this world. So to sort of set the stage, right, UX, I'll be using these terms interchange not interchangeably. I'll be using them a lot. And so I just want to make sure that everyone is on the same page as to what we're talking about when we're talking UX and UI. So UX would be our user experience, and it is the way that things are used. Is it a physical menu, or is it an online menu? Do do we have to click into an item to learn about the menu or the menu item, or are the ingredients already listed out? Are there three clicks to send an email, or is it all within the same modal, and we can just fire it away by pushing enter? Alright. That's sort of the UX or the bones, if you will. Then we have UI, and that is just the way that things look. And there are two separate things, and so I I would encourage you to sort of think about when you might use one of those terms versus the other, especially as I'm going through here. So that when I'm talking UI, I'm thinking, is there a lot of white space or breathing room, or is it a really cluttered page? Are my buttons purple down here, or is my text purple right here and it's underlined? Are they really big buttons, or are they small buttons? That's the UI. And we are considering both of those things in tandem, but we've gotta understand the UX first, and the UI comes on top of it. Right? We don't want the UI to dictate the user experience. So why does all of this matter? Well, to put it really simply, people have really strong opinions. And to go a little bit further, people will not use the tools you build if they cannot figure out how to use them or if they don't want to use them. So before I go all in on Sigma right now, let's just talk about how UX and UI might affect things that we deal with on a daily basis. This is a menu for a restaurant that might have really good food, but I am immediately hit with, wow. There's no hierarchy here. The fact that this is all center aligned and prices are sometimes on the same row but sometimes not, that's kinda confusing. It's requiring a lot of effort for us to understand how many things are even on this menu. Maybe we'd say, oh, well, pictures would help. Maybe. But, maybe maybe they'll say, like, well, let's bold some other words. Okay. Well, this is way over the top. This is not really helping anything. Now I'm possibly even more confused, and I actually am just like, you know what? You're good. I'll I'll go somewhere else. Alternatively, we could say, actually, pictures might be nice if we're maybe ordering a drink, and we could get some small descriptions. We've got a larger title of the beverage, and we have maybe an illustration of some of the more popular ones. This will now give people a hint as to what they're gonna get into before they spend the money on it. In a more modern sense, we would see this maybe online at some a cafe. Reading black sesame latte or black sesame hojicha is nice, but if we can see, like, oh, that's my end result. That's what I'm gonna get. Kind of enticing. I'm gonna go with the peach Jasmine. Great. This is a combination of UX and UI that this also could be rendered like this, but one is a little bit more preferable. Right? And so there's things that we can do in all sorts of our world that we we wanna go for the more user friendly approach. Another world that I'm very passionate about is gaming. I think that there is a lot of user experience and user interface in gaming, and I also just wanna highlight how opinionated gamers can be, specifically around UX. So I've highlighted a few key, reviews from some very opinionated, reviewers. Clunky UX undermines every facet of the game. Someone said, if I can't tell how controls or how intuitive the UI is, I'm out. Someone made a video on YouTube with 521,000 views. Can I fix Zelda's user interface using unit Unity? This is a very big game, and there is a lot of opinions on this specific game's user experience. Someone else in on a different game said, I won't say the poor UX has ruined the entire game experience, but it certainly didn't help. Here was a Medium article, the game breaker, how poor UX can ruin your video game experience. This, pretty brutal, post on Reddit. The game industry could honestly collect all of Marathon's user experience and use it as a textbook example of bad UI design. So this is just something that people are very opinionated opinionated about this specific game. It was confusing. There's a lot of colors. You gotta know a lot when you get into it. People aren't sure where to click. They're not sure really where their eyes are supposed to rest or where the hierarchy is on the page. And people had some strong opinions, and they end up putting the game down or leaving a negative review, which can dramatically affect sales and adoption. If you're not interested in what I'd say about gaming, maybe you use a streaming app. Here was someone a while ago. Does Hulu have the worst UI, UX of any streamer? I'll just caveat here. These apps have to be developed for all sorts of different devices, and so some people might have a different experience with an app like Hulu just because of the device they're they're running it on. And, you know, maybe it's gotta be up to date, and it has a different, input device. It might you might be using a TV controller versus your phone. Someone said this is a very old one, but someone said, do the folks who keep redesigning the Hulu graphic user interface actually never actually use Hulu? That's not a good sentiment to, hear. And I also wanna add a copy out, though. This was a Hollywood reporter article. Netflix users say they dislike the new layout, but research says otherwise. So although there might be a lot of knee jerk reactions and a lot of vocal opinions about a color or the way something moves, you've always gotta rely on the data. And you I would say you've gotta watch people use the thing that you're creating to see maybe where they're getting frustrated, and maybe there's a a middle ground. Right? We don't need to react to absolutely everything that we get as part of our feedback. So when it comes to the internal tools or tools you're building for your clients, users won't give you that type of opinionated feedback on Reddit or a store page. They will just stop using your tool. Right? And unless you create some sort of an avenue for this, the the this is what we see all the time is that people are just like, well, I'm not using that because I I wanna create my own way, and I'm gonna go circumvent the the way that my, maybe, organization wants me to do this. Or for building things for our clients, they might just not be happy, and they may not renew a contract because, well, they've seen other interfaces out there that they want to use. So this is all this is a a if you didn't listen to anything I said, you could look at this meme here. We wanna build things that are not painful to use. Right? Okay. So moving on to an example. This is the Sigma public app that Kim just finished working on, and it is all about defining what a millennial song is and the top millennial songs. So I'm just gonna quickly run through it because I'm gonna reference back to it later in this presentation, but it is a really great experience. And I would also just encourage, hey. Sign up for Sigma Public, see what's out there, and also contribute to this this app here because we it benefits when we got more data to work with. So yeah. I would love everyone's everyone's folks in here. If you if you have the time, I'll put the link in the chat. Yes. I would say go ahead and drop that link in there. So, yeah, we we see that we are inviting someone to this with this intro page. We can learn about sort of what we're trying to get at here through this introduction. I am prompted to, choose my own generation, and I can move on. And I can see right off the bat that I'm gonna learn about what we're talking about in this app. We're going to maybe explore the dataset, and then we're going to review some results. And so on this learn page, we're seeing, okay. Here's how we're defining this dataset, and we're giving it a little bit of personality through, you know, this use of emojis and some very punchy descriptions about how the data is broken up. Then we could go on to explore and vote, and we could see all of these key traits and how many songs fall within one of those key traits sorted by genre. We can see it by year. We've got some KPIs here. We've got our song list down here, which we could sort. We could vote, or we could suggest additional songs. I just voted earlier today, so, that is already blocked out. But I could suggest additional song. And we could see, you know, how the voting results have shaken out. We could see how the top songs are listed out, and we could also sort these top songs. So through a combination of hierarchy and font choices, color choices, modals, containers, the UX. Right? We have a flow from the beginning of this. We've introduced it, and now we ultimately end up reviewing the results. This was a really fun app to work on recently with Kim. Hey, David. Sorry. I think you may have frozen there for a little bit. I was gonna move to the voting results page. Yeah. Sure. I wanted to make sure it wasn't just my Internet freezing before I jumped in there. I got a I got notification that my connection dropped for a second. So Yeah. You know, just just running through what this app entailed. We we are learning about the set the dataset. We're exploring the actual song list and how the songs are grouped, and then we could vote or suggest songs to be added to the dataset. You could also review songs that people have suggested and, you know, put on your millennial hat and make some choices for this dataset. So this is a very fun diversion from our normal client work, but it is also a good way to test what is possible in these apps, and it keeps us sort of on our toes. And it also is just a good thing to flex our minds and try some new things. Right? So whether you're enjoying this app or creating something similar, highly recommend doing some Sigma public work and seeing what you can do with a more fun dataset than maybe you are required to for your job perhaps. Okay. So we've sort of seen, like, where we're coming from. I'm now gonna get into nine sigma app tips. Right? So I hope that all of these will be beneficial to you. And if if some of them do sort of stick out as pertinent or insightful, I would love to have some feedback on this. So you could maybe chime in in the chat or let us know if you've had to wrestle with any of these things or if you've solved solved things in a similar way. So, you know, off the top, the number one thing pertaining to what I was just talking about in why it matters, soliciting feedback. Whatever you're creating, let's encourage users to provide feedback regularly. So, when I talk about feedback and when I talk about gathering input from users, I like to talk about this concept of a desire path. A desire path is something we might see in nature, and it is something where humans have paved their own course through an environment. Clearly, the intent of this park was you people patrons, citizens are supposed to walk down the sidewalk here down toward the parking lot, but the data shows us that they are actually trying to go across that bridge there. They don't wanna have to go all the way around. They this might be a quicker way to do it. It could be that they don't have the credentials to get through maybe a gate over there. Right? So this is data in the real world speaking to us. And I think it's a fascinating concept that you can find wherever you are. You could even see a desire path in the carpet in your office, where maybe it's trudged up in an area more. That means that it is a more high traffic area than, some of the other areas in the office. Even when a door handle has a patina on it, that means that that part of the handle is more used than other areas of the door handle. And when we have these concepts in our mind, then we take that into watching people use our apps and our whether it be a dashboard or an app or a report, whatever we're doing in Sigma, you know, let's not just, you know, Kim did not just say, hey. Here's the link, to my Sigma public app. She got me on a call, and she said, here you go. And she was taking notes as I was processing it to say, hey. You did sort of miss this one step. Okay. Great. Let's workshop a way to not let other people miss that step. Right? So let's not just share a link out and say, let me know what you think, because people are going to soften the blow when they give some critical feedback, and, we need our feedback to be honest and critical so that we can build the best tool possible. Another example of a desire path is here where a building owner was tired of the tenants trudging up the grass right in front of the building. Right? And so the building owner put up a fence around there so that they would stop doing that and actually use the sidewalk that is over here on the right. Well, humans are gonna do what they do, and they found the next shortest path. And now there is even more grass that is trudged up, and it's also inconvenient. So what the building owner could have done here said, hey. You know what? It's gonna be a a small expense, but we're gonna build a ramp up here. We see people are doing this. We're gonna meet them where they're at. You know? We're not pouring concrete in the Sigma world. We're maybe duplicating a page and trying something new, or we're moving a bunch of filter options into a modal. Right? So let's be mindful of how we see people stumble when we use these apps and then see what we can do to adjust it. So in short, we're gonna ask people about this app, and we're gonna get them in front of it. We're gonna watch them use it. When we get feedback, don't ask things like, do you like this? Be more pointed. Say, how will this affect the way you handle our weekly stand ups? That's gonna elicit a more rich response with a a bit more nuance and maybe some more adjectives and some more use cases about how it could be, improved or more impactful. Source feedback from people outside of your bubble. Right? As we don't need to only build things in silos, and then we launch it and expect everyone to just pick it up. Right? We've gotta have different perspectives for people who maybe are not in Sigma all the time or people who we want to be using Sigma. Let's get them involved in the feedback process early so that, one, they feel included, and they feel like they're being heard. Right? And we want to build things for our end users that they're gonna like. So consider all feedback, but you don't have to bend to everything. Outliers are okay. So, you know, if something is only mentioned once across a handful of folks, let's acknowledge it. Let's see, like, is that a meaningful thing? If it's something like, oh, I don't like that color of green, then, okay, you know, maybe if it keeps getting mentioned more than once, then we'll maybe acknowledge it, but we don't need to just knee jerk react to all the feedback we're gonna get. Okay. So that's my first tip on feedback. Number two, let's define a flow. So, I'm gonna say that we are going to draw three boxes, and then we're gonna fill in our, actions that we want our users to take. This is the bones of the user experience process, right, what all proceeds our user interface process. And so when we're talking about this, it does come out to be well, let's literally just start with three rectangles. We use a tool called FigJam at InterWorks. You could also use a tool like Miro. You could also just use some sticky notes. You could get, with a whiteboard in a conference room with a colleague and and knock this out. But what we're doing here is we're we're not saying you know, moving from a world where we were maybe really reliant on a dashboard. We are much more reliant on apps these days. In apps, the difference is is that we have a blow for things to take to be get to an outcome. In Cam's Signia Public app, it is maybe learning about it and then ultimately reviewing the results. So I asked Kim. I asked her to use this process, and so we started with the three boxes. What are the three main things people are gonna do with this app? Okay. Well, they're gonna introduce the topic and the songs. We're gonna vote for the defining songs, and then we're gonna present the results. That's a great starting point, and this figures out this makes sure that we're on the same page, and it allows it to sort of get cemented in her mind of, like, yes. This is the flow. But then we iterate. We take it a little bit further and say, well, maybe it would actually be good to introduce the topic. Let's review the NPR playlist, which is where some of the data came from. Then let's vote for the top three songs. Then we'll present results, and then we could suggest a song and review other suggestions. That also sounds great. Now it's a bit more robust of an app. But then we might say, you know, maybe it's not that linear. And maybe at certain steps through this process, it is not just one, two, three, four, five. Maybe there's a couple turns we gotta make, and we're going to use this same process. We're just expanding on those original three boxes. I know this is more boxes now, but this is not that hard to do. Right? So we're gonna now introduce the topic. We're gonna analyze the major themes of millennial songs, then we're gonna review the song list and trends, and we could go to present the results. But we could also look at different song profiles. We could vote for top three. We could suggest a song, which was a great curveball to the entire, app, and we could now review those other suggested songs. Songs that did get enough votes, then they could add it back to the playlist where or the song list where now we can review that beefier song list and keep reviewing the results. Now we have this sort of circular pattern that really helps solidify this app's value. Right? There's multiple ways that people could contribute, and there's multiple ways you could find value in it. And so, you know, we get here, and we start putting stuff into Sigma public, and then we end up getting to review it from a very zoomed out, the 10,000 foot view, if you will. Right? So here's some screenshots from along the way. You know, some of those arrows were pointing to modals because they don't we don't have to totally divert them to a new page. We can use the really nice UX and UI elements that Sigma provides, like modals or tooltips or drawers or action sequences on our buttons to pull off this complex arrangement of a user flow. Right? So this is this is how, you know, 95% of our app development goes where we end up with multiple stages in the planning, and we ultimately get screenshots in there. And then we're iterating, and we're commenting back and forth, and we end up building something that is very refined. So I highly recommend doing that, which to review, we're defining the flow and start with the three boxes. Okay. Moving on to navigation. Let's be intentional about our header and sidebar combos. So you'll notice here, I am presenting to you from Sigma. It is Sigma is very versatile. Yeah. And we could do presentations. We can do apps. We can do reports. And through that, we might have needs for various combinations of navigating around a workbook or multiple workbooks. And so let's be intentional about our combos. Consider your user's exploration path from really zoomed out to seeing that 10,000 foot view to really zoomed in. When you open your workbook settings, you're gonna see a a section for workbook navigation where we can toggle on page headers or sidebars. We can have multiple headers and multiple sidebars. We can also define if our primary navigation is a header or a sidebar. So that is I'll explain that more in a second, actually. So we could have an app where there is no navigation, meaning there's no set high header or a sidebar. We just have it on the page, and maybe we use some buttons within the page to pull up a modal, and that's that's very fine. So this would be great for simple subjects or really concise actions. Or we could have a simple navigation. In this case, you see my simple navigation, with a few options to change. My view, I could go back to the title. I could go back and explain to you why it all matters. I could open Kim's Sigma public link, or I could go back to my nine tips. So here, we've got our main content, but we can change the view here with stuff in the header. Or we could get really complex. We could have a sidebar and a header with options to change our views. So that toggle, I briefly mentioned a second ago, if the header is primary or if the sidebar is primary. This left illustration is that with the header as the primary because what the user might expect is they could make a change up here in the header, and that would then filter down or cascade to whatever renders in the sidebar. Alternatively, we could set the sidebar as the primary, and any selection we make in the sidebar would then cascade down and change what is available in the header. We could have a very complex navigation where there is a sidebar and a header and a tab container. Right? So now we've got a lot of ways to slice and dice this an in a dashboard or an app. So let me just go ahead and open up an example. So this is not how I would treat an app or dashboard using location data. Right? I'm using an analogy here of us zooming into a location per, this tips title. So in our primary nav, we see that we have a a handful of states here. It could go into Kansas, New York, Ohio, Oregon, California. I'm already selected on New York, and so therefore, those options within New York, New York City, Rochester, Mount Vernon, that's all there under New York. I would expect if I click California for that sidebar to change. Sure enough. So I've got lots of cities now within the greater California. But within Los Angeles, I could maybe expect here at the top of the page, probably some really generic information about Los Angeles. And then now that I know that I'm in the right city, I might have more options, further ways I want to explore Los Angeles in this example. Right? So maybe I would say, well, I wanna go to the Griffith Observatory, learn a little bit more about it, or maybe I wanna go to Dodger Stadium and learn a little bit more about it. Right? So that is just representative, of a the hierarchy umbrella, right, and how we might want to think about categorizing level of detail and letting someone discover the thing that they need to go find rather than trying to list all of these options and all cities and all states all on one page at a at a time. Right? Let's use the tools that Sigma is providing us, to create a better user experience to let users find what they're looking for. So, be thoughtful about what combo you use. You don't have to use any of them. You don't have to use all of them, but it is a very flexible tool, and there's a lot of ways you can, make it work to your advantage. Okay. Moving on to tip four, size. Experiment with various widths, then select the, quote, unquote, best one, quote, unquote, because it's hard to say who how it is going to be perfect for everyone. So this is important to bring up the grid. When you are in your workbook settings and if you open up the layout settings, twirl it down, you'll get an option to always show grid. As you are building something, I highly recommend turning on that always show grid. It'll render something like these hash lines you see here in this image. And allows you to understand that, okay. This is a very flexible thing. We are working on a 24 column grid. These 24 columns are gonna persist regardless of which page width you choose. So if you do have a really big monitor, a medium width is gonna shake out to about 1,400 pixels wide, and it's really just constraining how wide it will get. But we still have 24 columns to work with in there. If we choose large, that kinda takes it out to 1,680 pixels, which would be fully rendered with a a large amount of, you know, empty space on the sides if we have a really widescreen monitor. But notice that my 48 font and my 24 font are not scaling down or scaling up. They're staying the same. Right? We just have skinnier columns. We also have the option to do full width, and that's gonna go as wide as our browser will allow. Right? So, that is fine, but part of what I was suggesting at the top of this was we've gotta test it. If if you are building something only for yourself, I think you've got a really huge monitor that you're always going to be using, go for it. However, when you open that up on your laptop or your phone, it is going to be a little chaotic. Okay? So test it on the devices that you expect users to, be rendering this in, and don't fully develop something only on your laptop screen. Don't fully develop something only on your your really wide, monitor at at your office. Do both and make sure that your your containers are flexing like you need them to and that your text isn't getting chopped up in weird ways, and do a lot of testing along the way. So you might run into some grid conflicts as you are putting these things together. Everything is on those 24 columns, but we can have a lot of rows. Right? And so one tip that I have is to, place equal size elements or similar size elements in a row next to each other. This will be, this will allow you to containerize them or move them around in bulk later. Right? So this will also allow this function within Sigma trim space to be of maximum value. So if I actually just turn this on really quick, you can see that I could move this single element up or down. I can hit command z to undo it. I could change this width, but it really helps to be able to select multiple things and maybe put them in their own container. And then I could move these things around as a group so they'll stay together. Sorry. Selecting the wrong one. There we go. And, yeah, it's really nice to be able to adjust things like this when they are next to each other and they're the same size. And then the trim space is something that built into Sigma where if you have a little bit more, real estate that you don't need, this contextual button will pop up, and you can click that, and it will, remove any dead space that is not useful to you or not really needed amongst your content, and it allows it further, exemplifies why we might want to be thinking in this grid structure in solid rows as we go down. Okay. So choose the right size, test often. Oh, yeah. And, also, if you're doing something for mobile, you can switch to mobile view at any time during your build process, and it will shrink the page, and it'll render you know, like, if I do this now, then you'll see, okay. It automatically collapsed my navigation, and it sort of stacked everything on top. But if I had maybe predefined some things that I didn't want, that'd be a great way to see it before actually publishing it and then even rendering it on my phone. Okay. Tip number five. Color. Let's keep it limited. There are themes within Sigma that are great starting points. There's also the ability for you to maybe overapply color from the very beginning. And so this is not what we want to end up with. Right? This is a bit of a jump scare. There's doesn't feel professional. You don't know where your eyes should go. And so our tip when it comes to figuring out color in your app or your dashboard or whatever you're building, let's start with everything in gray. K? Only add color to elements you want people to act on, like when a target is missed. Right? We can maybe create an alert banner up here and tell people, hey. This is yellow. Pay attention to it. Or maybe we wanna call out our buttons that are gonna dramatically change the way that someone's going to engage with our content. Yep. We we should consider that. And then we want we might wanna color things that are very far outside of a normal range. Right? Now we've gone through this flow of slowly adding in color rather than the other way around where color is now dictating, like, oh, well, I've got purple and orange and green now. What else can I use to let people know that they've gotta pay attention to it? Well, we might have backed ourselves into a corner, so you would save yourself a lot of time starting in gray and then slowly adding in that color for the most important things. Okay. So take it easy on color and keep it limited. Borders, don't box yourself in. So give your content room to breathe. Here is a fairly standard dashboard. Well, some terrible KPIs, I gotta admit. I kind of threw those together, winging those KPIs there. But I hope what you're able to take away from this tip is that we have overly formatted this. Right? Let's just acknowledge what is going on on the page. I've got a header. I've got a background, which is this really light purple. I've got a white container. I've now got a purple container that is housing all of my visualizations. I've now got a white container that is housing my KPIs just to say, here's the KPIs, and then I've got each KPI boxed in. Right? It's a lot of boxes. I would say, let's just let's not do that quite off the bat. I would say, give your content room to breathe. If it is a KPI that is sort of informing the entire app, let it just sit on the background. We don't have to put it into a container. Right? If I do want, I could change I could make it so that these three visualizations all do live in a container, which is what I've done. And now I can move these around essentially as a group. I could control the background for all of these things in unison, and I'm I am using breathing room to separate my content. I'm also using hierarchy and relying on the titles of these to inform the user, here's a new piece of content. Right? I'm letting these live above the content so that they are dictating to say, these are important. You should consider these as you're consuming this information. Okay? And so, this tip is on here because I see it a lot. I see too many containers. We end up with too much padding. It's container within a container within a container, and then it becomes, one, clunkier to edit along the way. And two, you've let the tool dictate your outcome. And so, at all points throughout this, make sure that you are saying, like, does that order line really need to be there? Or maybe I could stave that for something that really needs to be styloed off and sort of put in its own section on the page. Right? Because we're gonna reduce the effectiveness of a border when we actually need it if everything already has a border on it. Okay. Use the sandbox. So containerize later. It's easier to manage multiple things this way. So you've heard me say the word container probably more than any other word in this presentation, but it is a way to group content. So this is a container. I've got an image, some text living in a container. That means that I can move this around my grid. Right? What's really helpful is this unspoken hero of Sigma, which is this slider here, because we've already talked about building things in rows and clustering things of equal size. When working outside of containers, we can drag to select many items at once. Okay? So we're treating the background as a sandbox before taking things into a container. So I mentioned to this slider, well, this is really good if we need to maybe say, oh, we forgot to insert a title above, this section of reports. I can grab this slider on the left, and I drag it down, and I've now created a lot of extra space. I could use the, contextual trim space to revert that or maybe clean things up after I've created a lot of space. But the way that I think of this is if you're cooking in the kitchen, it's good to start with a clean countertop. Right? We've gotta clear some space out and say, it's gonna get a little messy. We're gonna have some bowls and some dirty dishes before the full thing is actually ready. Let's buy ourselves some space rather than saying, hey. I'm gonna add a new UI element or a graph, and it's going to then just populate at the bottom of the page. And now we've gotta squeeze it in. And, so buy yourself a lot of space, and then let's trim the space before we need it or as we need. And I mentioned that we can drag a box to select multiple visualizations. I could select just these two, and I could move them around. However, if I was already had these in a container, I wouldn't be able to to just drag a box around those two. I'm now only selecting the group, it becomes a little bit messy. Yes. I could still select a single item, but I've lost the ability to now drag in my sandbox environment and select all the things that I actually want to select. I also recommend against containerizing too early because then it sort of locks you into these patterns before we've really, explored what the best avenue is gonna be. We also strip ourself from the ability to use that unspoken hero, the slider on the side to maybe buy space in here to insert another KPI or some filters. Right? So, let's figure out the layout first and then maybe select everything that we're really happy with, and then click this really nice, create container button where then we would get some contextual controls to maybe edit what is, how this is rendering, change the padding, change the, background color, or whatever it may be. So don't containerize too early. Okay. Next up, number eight, buttons. Pick a button arrangement and stick with it. By default, there are two button styles that Sigma gives you. It's a filled and an outlined, and then there's also text. But I would argue that it's looks less like a button because it does look like a word, but they still function the same. And so my point in talking about this is that we are essentially establishing a design system, which is a series of patterns that our users rely on to confidently navigate our tools. All apps use them. Big and small, your phone, Netflix, Microsoft, Apple, YouTube, even your car. Right? So they are encouraging us to do something. So if we've got a complicated app that is saying, yes, we could add to the dataset. Yes, we could export. Yes, we could send an email. Yes, we could change pages. Yes, we could add a column. Okay. Which one should I do first? You know? But if we are gonna use a pattern, which I highly recommend this one if you want to steal it, put your most important user action as the filled button. K? And I would also recommend putting it on the right of our cluster of buttons. Or, yeah, I I recommend putting it at the right, especially of the container because people might need to process some information, and then ultimately get to their button selections, over on the right side of the page. So I'm just calling this this is an optional action. I'm not too worried if you skip over this one. This is the one I really need you to do, and I'm not gonna beg for too much attention by making them all really stand out high contrast button. I'm gonna use the options available to me. So And if I can jump in here too, I think just thinking of going back to your point, David, about that story progression, those three those three pieces, that's where doing that work up and ahead to think about what you want those actions to be is really helpful. So that way, you've got that idea already in mind of, like, what do I want the user to be doing? How should this be progressing? So this all plays on builds on each other, I guess, in a way that I really appreciate. 100%. Yeah. During that concepting UX wireframing stage, you know, those are things to be considering. How big do we wanna make it? And I would say, in that stage, shoot for the moon. You know? Say what would be really cool or a stretch goal, and then sort of back into, okay. What's realistic given the time limit that I have? Do we wanna maybe plan on what could be more giving more options to the user throughout the entire UX of the app. Okay. So if we consider how this might play out in a realistic scenario, pretend that I've got some primary content here in this white box. Maybe it's three visualizations, some explanatory text, and I'm now processing a lot of data. Well, now I'm putting my buttons down here probably outside of the box just so I can keep the the space inside that primary container really nice and tidy. And I'm gonna say my primary action is the furthest right, and my other secondary actions are to the left of that. Now if we contrast that to something that maybe hasn't gone through this UX and UI thought process, it could turn into something that looks like this, where there's a lot that we want the user to do. It's all important, but we have not taken the time to say what is the most important thing, and do we need to show all of these options at once? Right? It it we have further chaos because we have buttons inside the container and outside of the container. We have primary actions above and below. We have secondary actions above and below. We have stuff on the left and the right. Right? So I would say if you have more than three things that you're prompting the user to click on in terms of buttons, consider making one of them open a modal. Maybe that button is actually titled more filters or more details, and now we can use the modal. Or we could have it open the new drawer feature in Sigma, and we could display a lot more content. But instead of totally rendering all of that directly on the page. Right? We want to reduce the cognitive overload we are requiring of our users to fully, you know, get value out of what they're looking at. So, you know, simply put, pick a pattern and stick with it. And if something feels a little overwhelming, then maybe tuck it into, a model. Okay. My ninth tip is hierarchy. This is the number one design principle. It is you've seen hierarchy present throughout this entire presentation. Hierarchy, when it is done right, can solve the most complex information architecture. It can solve the most complex apps, and it is a a method of letting users know what is available to them but not making it so overwhelming that everything feels super important. Right? So my tip is to step away from your laptop or your machine, whatever it is, and look at it with a few more feet between you and the screen and say and ask yourself, where do your eyes rest? Right? This will help you understand if you do have a hierarchy or not. So if we refer back to our Sigma public app, you know, this is part of what our process at InterWorks is, is trying to figure out where does the hierarchy really sit on this page. So if I look at this, like, yes, there's a lot going on here, but I'm kind of interested in this funky title. I see that there's a player here, and I see there's a call to action at the bottom of the page. And so I'm going to highlight those things and say, yeah, that is kind of where our eyes rested. This this graphic itself allows us to say, like, is that the right pattern, or did we want them to focus on something else? Well, we can assess this, and we can test it with people and make some changes along the way. So another page where we were learning about the dataset, Well, where my eyes focus on here? Probably the things that are bold and the things that have a bit more color to them. That's how my eyes, that's where I wanna rest if I am stepping away and making things a little bit smaller than they might be when I'm actually, in there developing. The, explore page has a lot of information on it, but we can control the chaos, and we don't have to overwhelm them by using some thoughtful grays that sort of push to the background. We've got some airiness around the header content, and we've got a few calls to action. Right? So what might be in focus there would hopefully be the titles, the KPIs, the player at the bottom of the screen, and, hopefully, some of the results. So the this is my assessment on where our eyes might fixate, and I think you might also maybe fixate on some of the bright colors, which is indicating this is where users have contributed data, which is part of why we colored it that way so we can encourage folks to keep adding to that dataset so that it can become more and more robust and illustrate that this has been, user driven. So our review page, let's see where our eyes might rest there. Yes. We want a lot of attention on the leaderboard section, the titles of our main, visualizations, and then, you know, I highlighted these top few colors because those are they have higher contrast. So users are going to notice those things before they start noticing the things that are in eighth and ninth place on that leaderboard. And then we also need to consider not just the home pages, but we should also consider our models and the things where we are trying to push some things into focus. So here, I would hope that we are looking at the title here and then our calls to action below. Yes. This is this is where my eyes focus. We are pushing this sort of falls into the background, this explanatory text, because it's not super bold. It's not huge. And this is where we actually want people to notice things if they are short for time, which if I were to put a summary on this whole thing, all the users you're building these things for are short on time. You know? We need to be respectful of their time and, make sure that they're getting the most value out of it. Right? So if we say, well, it's all really important. You better read these three paragraphs. Like, okay. How about let me know where I can read those things if I need to, but don't put it in the middle of the page. Now you're pushing the real value out of the way. So using hierarchy and trying to assess, like, are users focusing on the right things if they do step away? It's a good little cheat test to see, like, are things headed in the right direction? Okay. So that was my nine tips. Collect feedback. Define your flow. Draw those three boxes. Oh, I changed my zoom throughout that. Define your flow. Let's be intentional about our navigation concepts. Make sure we're developing at the right size, and we're we're testing different screens throughout. Keep your color limited throughout so we're not overwhelming the user and causing them to have a cognitive overload. Don't box yourself in too much. Only containerize when you really need to and when it makes sense to group content together or add a border around it. Yeah. Use the sandbox. Be messy first before you start saying, here's the final layout. Right? You could also use other tools. You could use a whiteboarding tool. You could sketch it out. This will really help you dictate what's gonna end up on the page. Be mindful about how many buttons you're putting on the page and which ones seem like the most important, and then assess your hierarchy. So that is it. Thank you all for the time today. I do wanna give a really quick plug. If you did enjoy this, I give one hour workshops all the time in the form of two workshops here. One is designing for data foundations. It's a one hour workshop covering design principles within the world of data visualization. We talk more about hierarchy, color, layout, planning for big, data projects, accessibility, and more. And then I have got another one that's solely about Sigma, where we unpack all of what Sigma can do in an even more robust way, where we're getting into why we might wanna use reports, when we might, need to use drawers, or how we could change our fonts, and when we might need to assess different times to use the the different fonts, modal creation, and good best practices for modals, actions, loading animations, and more. So, if you have any feedback, I would love it. I want to make sure that this is helpful for folks, and I would love anything that you think might be a good addition to this or if you have any recommendations for how this could be better. I am all ears, and I would love any feedback. Feel free to email me that or email it to Kim if you want. Yeah. Absolutely. Thanks, David. That was that was awesome. And while we're on the topic of things that you do, we've actually got a question in the chat from Alyssa about from this was from a little earlier. She wanted to know how much of your work is in the UX UI architect bucket. So, thankfully, that is what I get to do here at InterWorks. We've got a lot of analyst consultants and analytics architects and not as many UX UI architects. But that means that I get to see a lot, across different clients, and I get to also be involved really early on. But, truthfully, that is my day to day. And I might be touching five different clients in a week. Maybe not. Maybe it's one client a week, and we've gotta really dig in and create a robust app from beginning to end. But a lot of times, I'm either touching the lowest hanging fruit, and I'm getting a glance at, a project and saying, hey. Let's step away from this. Let's acknowledge the hierarchy. This is a confusing page. That is a great voice to be in the room if you are maybe the only one who is thinking about hierarchy, or if you yourself feel like, oh, yikes. This is that thing we've been working on for three months, and it still feels clunky. Okay. Let's take one of these tips from here. Let's just maybe take the color one and the hierarchy one, and let's make a couple changes, maybe duplicate a workbook, and then you could position yourself as, well, maybe I am the UI UX UI architect. Right? I am making some changes to the way that people are going to interact with this. So me, personally, that is my day job, you know, day in and day out. I'll just emphasize. Like, it's such so wonderful to have you as a resource where we get to work with you on client projects where I've done more of that early early on consultation. You've helped me build wireframes, and then, you know, I've gone on and built built out a dashboard. And then also with this app that we keep referencing in Sigma Public, where we got to have a much more iterative process together in in designing that, and that's been so fun to work on. Love to hear it. It's you know, we gotta you've got a lot to focus on and getting that dataset right, and you came up with the idea from it. And I think it is always good. Maybe if it's if it's not even with a UX architect, bounce ideas off of someone that is not in your bubble. That way, you could say, like, do you know what to do when you land here? And if you don't have a UX UI architect on your team, I get it. You know, use some of these resources. Hit us up. I am happy to work with you on these things. This is what I love doing, and have been doing it for a a long time, throughout the industry. But if you don't have access to that, then, you know, get someone's opinion and ask for critical feedback, and try to take take on that responsibility of your own to say, like, okay. I maybe don't call myself a designer or a UX UI architect, but I know when a page looks like it is clear and straightforward. I I think that you can figure that out, and you could use some of these tips here we talked about. We've also got some more resources on our blog, about designing for Sigma. But, please, if you have any more pointed questions, reach out, and we'd be happy to talk through it. Awesome. Alyssa also actually just asked in the chat, how are you using AI in your work, or how do you see it changing this aspect in the next three to six months? I'll be honest. I don't use AI. I find that it has dictated too much of the process usually. And as someone who has been doing design for a long time, I still like controlling, the inputs and the outputs. That said, I have worked with a lot of clients, and I worked with a lot of colleagues who have come to me with various stages throughout a project. So sometimes someone will concept something using full AI, whether this be internal or a client, and they bring it to us. And now we've got it back into saying, like, man, this I imagined a huge app connecting datasets that aren't even existing yet. Do we really need this version of it? This seems really bloated. Right? So let's maybe pair it back and almost start from scratch and dictate it with that really rudimentary draw three boxes step. And let's maybe dictate those steps first. So if you do wanna use AI, I think that that would be a pretty decent way of, like, having it help you work through a UX. You know, I think that that's something that some of these apps are still struggling with is, like, understanding your intent of the UX. And so I would say define it yourself and then maybe take in some of those wireframes to say, hey. Help me pull this off. How could I encourage someone to move onto this phase and maybe give you some ideas that way? Yeah. I I would agree. I think as so much of what you've talked about today has been centered around in like, making intentional decisions that make consumption of these apps and dashboards useful and easy for for your consumers. And so figuring out that way to make these intentional decisions, it's hard to hard to remove the human aspect of design from that. So figuring out the way to use AI as a tool to to do that, maybe. But hard to hard to remove the human design design elements from that. Yep. Great. Well, I think we're actually at time. We're right at noon. So thank you so much for your time, David. Thank you everyone for for joining this conversation. I hope this was this was as enlightening for you as working with David has been for all of us at InnerWorks. Thank you so much for your time. We really appreciate it. Yep. Thanks. Have a good one. Have a good one, everyone.
