Diagnose and Fix UX/UI Problems

Captions provided by White Coat Captioning (https://whitecoatcaptioning.com/). Communication Access Realtime Translation (CART) is provided in order to facilitate communication accessibility and may not be a totally verbatim record of the proceedings.

JASON: Hello, everyone, and welcome to another episode of Learn With Jason. Today on the show, we have -- oh, my god. I just realized I forgot. Is it -- Ceara. I'm so sorry. I think I mispronounced your name a few days ago on stream when I was talking about upcoming episodes. Realized that I did it, and my brain short circuited and did that thing where I was like, oh, no. All right. We're off to what I would call an audacious start here. I'm killing it already out of the gate. Welcome to the show. I'm so sorry.

CEARA: No problem. You know, I'm super not precious about it because it's very counterintuitive. So I'm all good with it. Don't you even worry.

JASON: Okay. So me butchering your name aside, for folks -- I'm very excited to meet you and to have you on the show. We've talked a couple times now. I am very impressed by the body of work you've put together, by the way you've kind of presented things. So I'm super excited to have you here. For folks who aren't familiar with your work, do you want to give us a little bit of a background on yourself?

CEARA: Yeah, for sure. So I run a company called Pencil and Paper. We focus on enterprise user experience exclusively. So all the complex UX stuff. So it's kind of like, I don't know, UX on steroids sometimes. So I sort of came to the UX world through science originally. So I'm kind of bringing an interesting lens to some of the work that we do. And I think that's kind of a quick summary of myself anyway.

JASON: I have a follow-up question. So you came to UX through science. In my head, I just pictured you, like, in a lab coat with a beaker and some glowing green chemical. Then you were like, you know what, this could look better. And you just pivoted. So I imagine that's not how it happened. So what branch of science did you come from?

CEARA: Not quite, yeah. Well, I mean, the fact that I sucked so bad in the lab --

JASON: (Laughter)

CEARA: -- like, so bad. I remember sitting there with one of my lab partners at one point, and we're supposed to do this dilution. It was supposed to be really straightforward. We took past the whole lab time and still didn't have it. The lab tech was like, oh, fine, just whatever. I was like, so I don't think this branch -- this part of science is really going to work for me. So I was in biology. I think the kind of thread there that brings it together is just the systems sort of perspective. Because all of the really technical sort of chem and stuff like that is not going to fly. I'm a little too --

JASON: You know what, I was having this conversation with my partner yesterday. We were watching -- there's a lot of producers on YouTube who show their musical creation process. So they've got something like Logic open and they're walking through their layers and all the knobs they're tweaking. She's like, this looks like Figma. So yeah, you've got all these layers of sound and processing, and then in Figma, you have all these layers of designs and effects. Then in code, you've got layers of code. It's really interesting to me how all of these kind of organizational principles that we have are way more universal than they might feel. Like, when you're in specialization. So did you find that was the case? Like your education in science -- you know, how much of it overlapped when you move into UI and UX?

CEARA: Yeah, super good question. So I think with the science education piece of things, it's like you really learn how to think around a lot of detail. Then when you get into the more advanced courses, later on, you start to connect the chemistry stuff and the cell biology stuff and the -- you know. So to me, learning how to think, learning how to logic through that work was like the exact same as design. Yeah.

JASON: You just articulated, I think, maybe the best argument for why a college education is worth considering. Because a lot of times you hear people talk about college education in the context of I didn't learn the skill any faster, any better than I would have learned that skill on my own. That part is generally true. You can learn a skill through college. You can learn a skill on your own. But learning how to think and learning how to apply logical processes is not something that most people will take the time to learn outside of school.

CEARA: Yeah, and it's so -- and pushing your brain like that is so uncomfortable. It, like, hurts, you know. So being self-directed enough to make yourself do that is wild.

JASON: I am one of the people who like read all of those kind of college -- because I didn't go to college, right. I read a lot of those books that were like challenge your perspective, be able to take the opposite position and argue against yourself and understand all those sorts of how to think, how to apply logic. I don't have a full education on it, and I feel like I'm learning stuff all the time. But it was -- I don't have -- like, I have business books I bought or self-help books or self-improvement books, human psychology books. I have a stack of them. I get like half a chapter like, I can't do this anymore. I feel like when I was in my 20s, I had the energy. People who can take cold showers, right. There are people out there who can force themself every day to take a cold shower. Yeah, makes me feel great. I look at a cold shower like, I'm getting back in bed. I don't care if I hurt. I'll take the joint pain.

CEARA: 100%. Bring it on. Bring on the joint pain. That's wild to do that. Cold showers, oh, my god.

JASON: Yeah, not for me. Okay. So I've started getting a little maybe too far off topic here. But learning how to think, I think, is a really interesting foundation to build this off of. So when you made the pivot into UI and UX and ultimately ended up with Pencil and Paper, what are some of the foundations here? I think what makes UI and UX overwhelming to a lot of folks is that when I look at a design, so much of what's in that design feels like it is I am a designer, I sat down and looked at a blank piece of paper, and I said let me create something beautiful. Me, as a non-designer, I'm looking at that same thing going I don't know -- like, beauty is such a subjective thing. How can I create something beautiful? So I've seen enough of your work to know that you would argue that it's not just beauty. There's a lot of regimented and scientific approach here. So how do you, I guess, approach that with people, getting over that initial fear? Oh, design is magic and you just can't do design unless you're good at design.

CEARA: Yeah, totally. Like, there's a weird connection that people have between design and creativity and having to be an artist or something. But because it's in such a logical world, it's just not like that. You know, we're not coming with the razzle-dazzle.

JASON: Razzle-dazzle. Jazz hands!

CEARA: Yeah, totally. And people are just weird about thinking of themselves as creative or not. So even though literally everyone can creative, you just have to loosen your definition a little bit. But you know, one thing that really drew me to UX in the first place was that basically the appeal of it was that I don't have to be this, like, perfect person that just knows the answers because I'm just blessed, right. It was the fact that if you are really up against a really tough problem to solve, you actually have others, users, that can basically give you enough clues for you to figure it out.

JASON: That's a really -- I like that inversion. I like that.

CEARA: Yeah, it's not up to you. If you apply the process, you'll get an answer.

JASON: Yeah. As a quick aside, I'm seeing in the chat frectonz likes cold showers. All right. So there are dozens of us, dozens. Okay. Also, Eco, this hat came from a random gift shop on the Oregon coast. I don't even remember the name of it. I just walked in and needed a hat. But yeah, so let's talk a little bit about what we're going to do today. So we're kind of framing this from the perspective of I'm a developer. I work on the front end of my app. I'm implementing things, and I'm going to see a lot of UIs. A lot of UIs, if you really break down what the vast majority of the internet is, it's like 95% forms and 5% hero boxes, right. That's basically the internet. And so when I'm working through these common elements, I'm looking at form controls, I'm looking at different user flows through sections of the app. I might feel, I might have this instinct that something's not quite as good as it could be, but I don't have the tools to articulate that. What I think you're doing well is you're providing us with a toolkit as developers to look at these things and say, ah, I now have the right language -- oh, welcome, Bryan and friends. Good to see you. Thanks for raiding. We're talking about UI/UX today. But so you're providing us with a toolkit with the language to take that instinct like I feel like this could be better and articulate what could be better. How do you go about doing that? I guess, how did you end up in this space where you're kind of communicating design across that boundary?

CEARA: Yeah, I think -- so I've worked across a lot of projects with a lot of teams, lots of product team type groups. I noticed that we get stuck as a group, and we get stuck as individuals. And there's a bunch of things within the design way of doing things that get you out of that. Like, they can kind of interrupt that feeling that you have of, oh, what do I do next? Or we've argued about this modal 27 times. This person thinks this is bad. This other person thinks something else is bad. It's like, it's not actually that serious, and I just felt like it was important to kind of make this stuff a little more accessible and a little more concrete. Because we don't want to be -- like, I really don't want to be operating in a world where it's like, well, we're the magic people that have all the knowledge. I wanted to open it up a little bit because everyone that's working on this stuff is smart.

JASON: Yeah.

CEARA: You know? You all have a logical base in our minds of how to work through problems and stuff like that. I think that it's actually, if we can apply just a few prompts and a couple of practices, then you get a lot of the way there. You don't have to have -- you know, it's not necessarily, like, follow these five steps, you'll find this at step one, this at step two, but it gives you enough to bounce off of yourself. That's kind of the approach that I'd like to take with it.

JASON: I like that. And I feel like what's interesting about what you're saying, too, is that it's breaking things down into a sort of foundational principles that aren't subjective. And I think about this like cooking. Cooking is very subjective. I like some flavors. I don't like other flavors. But when you get down below the surface of cooking, it's still -- it's a very principled way of doing things. If you boil water, it will do certain things to certain ingredients. If you put something in an oven or broiler or saute pan, different things happen. Different reactions happen. So those things remain true. And the subjective part comes when you start combining those objectively true things. And I think that, you know, design in my experience is that. You know someone needs to be able to see a button and identify it as a button. Now, subjectively, you can make some decisions about what makes a button identifiable and interactive looking. You know, maybe you skew morphic. Maybe you go flat. Whatever. But at the end of the day, it's still that one principle. If someone has to do something on a page, they need to know what it is that they clicked to do the thing. So I like that you're kind of taking it from that principled standpoint of like, hey, if you want to make it boring, you can make it boring. This can be science. It can be a checklist. Because I think a lot of people want to make design scary and creative. Like, ah, I have to have a blank canvas and throw paint and know all this magic stuff. You can make it boring if you want. You can make it a thing you just make sure is right before you ship it.

CEARA: Yeah, and you can get a large part of the way there just with that, you know. Assuming we're not talking about innovation and the tech space doing things people have never done before. It's like, most of the stuff that we do, there's a pattern. There's a way. There is a way to do it that will be easier for people.

JASON: Absolutely. Yeah. To go back to that cooking example, you can be a chef. You have to study hard to be a chef. There are a million skills you need to be a chef. But if you want to cook a meal that tastes good at home, you don't have to study cooking. You can just learn a few principles and you're going to get it right. You're going to have a great meal.

CEARA: Totally, totally. Or just learn a couple recipes.

JASON: Exactly, right.

CEARA: That you keep on doing.

JASON: (Laughter) Okay. So I'm really excited about this. I feel like there are a million things that we can potentially cover, but it might be easier to just start looking at things. So let me switch us over into the desktop sharing mode. I will start by giving a quick shout out to our captioner. We've got Rachel here with us today from White Coat Captioning, who is doing what you're seeing on the screen here, doing live captioning on the show. That's on the homepage of the site, for anybody who wants to follow along. And that is made possible through the support of our sponsors, Netlify, Fauna, and Auth0, all of whom are kicking in to make this show more accessible to more people, which I very much appreciate. If you want to follow Ceara on Twitter, you can do that. Head over there and click that follow button. And Pencil and Paper is the company. You can check that out. And that's as far as I've gotten. I'm not completely in your hands. What's the first thing that we should do here?

CEARA: So, let's -- so I've kind of got two overall steps to to -- kind of a diagnosis process. So we can maybe chat through what those are then crack into some examples to see how we can improve the interaction or UI using that.

JASON: Yeah.

CEARA: Nice. Cool. Okay. So maybe I'll just talk through quickly, like, step one. I'm assuming you're working on something. You're like, what's wrong with this? It just feels wrong, compared to what I thought it would feel like. To me, this is usually, like, a feeling where you're stuck. You don't really know what to do next. You've been right in the weeds for a little too long. Is this familiar?

JASON: Oh, yeah. This is every design project. This is every project of any sort that I've ever taken on. You look at it too long. It stops making sense. You know, you've done that thing where you've looked at the same word in a thousand fonts, and now that word doesn't seem like a word anymore.

CEARA: Yeah. So, step one, step away from the computer. So that's what I would say is a good step. When you're using the most high-fidelity tools you have, code, Figma, whatever, you just can't get any distance or perspective. So my first step is kind of like if you could switch to just your notebook or maybe a scratch pad kind of thing, really taking a moment to just reflect on what are you building, what is the scope of it, and what were your goals when you started building this thing. Sometimes what I'll sort of describe is like if you were going to talk to a friend, you know, a buddy of yours and you're like, hey, this thing is weird, can I just bounce it off of you? What are the things you would describe to them?

JASON: So, I'm going to borrow a term from the programming world here and talk about rubber ducks. One second. Okay. So when you have a problem, you explain it to the duck, right? And so this is a joke that I've heard a bunch of programmers tell. This is a long road that led to me getting into the rubber duck business. This is the Corgi duck, which you can guy at lwj.dev/store. But this little rubber duck here is specifically designed so that when you're having a coding problem, you can say, okay, listen to this, it was supposed to do this, but when I started doing this, this, and this, it didn't work. Then you go, oh, wait, I forgot to do that. (Laughter) That's the idea, right? As you verbalize it, you have to simplify.

CEARA: Totally. You have to simplify. And then you start to articulate your own logic. Then you see where you went into fairyland, where you just started thinking weird. And doing things in kind of a bizarre way. So I mean, that's kind of a step one I think that would apply to if you're working even on a little feature on a page or you're working on a whole flow. You can kind of have a reflection exercise. It's sort of a little bit like, woo, designer thing to do, but I think I know a lot of people, I know a lot of devs like, yeah, let me crack into this. Then they get into the code immediately. That's the main material that you usually use to make stuff, right.

JASON: Mm-hmm.

CEARA: But sometimes that's just, like -- it's just hard to follow the track of your logic if you don't sort of note it down. But you can do it retrospectively, and it's really useful.

JASON: I love -- so, I tend to do it almost as like this cycle, right. I'll start by, in a notebook, I just write a bulleted list of what needs to be true. Then I'll start building it. When it stops making sense, I'll go to my whiteboard and make a flowchart. When I get back, then I'm working on a specific element, and I can't get it to do what I want. So I'm trying to draw it, paper prototype type of thing. But these different methods of working on a thing, am I trying to solve a practical problem? Like I need pixels on a screen. Or an abstract problem, like I don't know how to think about this thing.

CEARA: Absolutely. Yeah, that's great. I'm sure you save yourself like hundreds of hours a year because of doing that switch. Like, I think that's really powerful.

JASON: Yeah, that makes me more efficient, and I have a thousand ways to make myself less efficient. It all balances out in the end. (Laughter)

CEARA: Yeah, totally. Totally. It's a process. You figure it out over time. You're like, hey, this reminds me of the time I was also confused. What did I do that time?

JASON: For sure, yeah.

CEARA: Okay. So anyway, once you do that, you can figure out basically if there's any huge flaws in your logic, and maybe that's enough. That's enough to go on to kind of get unblocked. Then you can also kind of zero in on more specific areas within your experience that you want to fix. So you could pop over to the Figma if you want. I have a visual sort of thing in the examples tab.

JASON: Yeah, so here's the examples tab. Should I, like, play the prototype? You did all these cool things in your demo where you really made this amazing. I feel like there's a whole body of work that I would love to dig into just around making cool Figma prototypes because this is extremely cool.

CEARA: Oh, yeah. We're so obsessed with Figma prototyping nowadays. It's like, you can just do such cool stuff.

JASON: Absolutely.

CEARA: And just use it as like a fluid communication tool. That's kind of what people are doing now. So it's pretty sweet. But if you pop over to zeroing in on issues, this is kind of like a subset of things. There's some standards that you can apply to some really big things. So the first one that I'd like to focus on is nav. So, navigation, this is a really good kind of sanity check moment for any experience because if people don't know where they are, they don't know anything of what's going on. Think about the last time you were in a city you didn't know. You're like, ah. You don't know how to do anything. You're disoriented, right. So if you can kind of go through your screen or screens and ask yourself a couple of these questions, it can help you to identify if there's any stinkies in there.

JASON: Any stinkies. (Laughter)

CEARA: Yeah, so to borrow a developer term, code smells. We're always talking about design smells. Because it's the same vibe. So if you can look at that specific screen and you can say, okay, where did I come from to land on this page in this state? Where are all the places that I can come from to get here? That's a bit of a -- you're kind of doing a mapping there. So yeah, what are all the paths I took to get here? Sometimes I can unravel some weirdness. Is there like a nested menu, a secondary menu? Is there any breadcrumbs? Are all of your breadcrumbs relevant? Why are you showing them? Would anyone understand them? Is it totally straightforward? That's kind of what I would say.

JASON: Yeah. And this is something that -- like, it's really important to get feedback here. What I've found is that as I'm working on an app, I start to develop my own vocabulary, my own set of contextual understandings of how things work together and what things are. Like, I was reading a description of an app yesterday where everything was a code word. Like they had metaphors for everything. I bet those metaphors were amazing, but the description that they gave was like, I'm going to use nonsense words to not out the company, but they were like, you take the ducks and then you invest those into your watches. Then those become trees, which bloom. It was like, okay, each one of those things is probably a really powerful technical concept, but I have literally no idea what you're talking about. Like, you could have said any number of words, and I would have been like, uh-huh. (Laughter)

CEARA: Mm-hmm, totally. Yeah, yeah. Totally and that kind of brings me to the next block here, which is around -- if you just control a little. Information architecture. And language. This is totally tied to navigation, but I wanted to really separate it. What I would suggest is especially if stuff is getting really weird, like a full product for example, you want to do an audit of the words that you use.

JASON: I've been making arguments that a lot of -- like a lot of different problems at work could be solved by starting with a meeting that defines a glossary.

CEARA: Oh, my god. Yes.

JASON: I've been in so many meetings where we fought for an hour because we were both saying the same thing with different definitions. Like, I was saying one word, and you were saying a different word. We both meant the same thing. I can't tell you how many meetings I've seen completely derail because somebody was saying we should be agile, and somebody else was saying we should do short amounts of work and review our work. Violently disagreeing on whether or not one or the other was the right approach.

CEARA: Yep, I totally had that exact moment yesterday. We were looking at a design backlog. We're like, okay. In design work, you're always calling things a dashboard and a homepage and a thing like that. We're like, yeah, yeah, that thing is like done. There's only a loose end or two to kind of tie up. So we went through the whole meeting. That's the assumption. At the end, we're like, oh, you meant this other feature set that we just started a concept on. Sweet. Cool, cool, cool, cool.

JASON: (Laughter)

CEARA: And we had a good LOL, but it was pretty hilarious because it happens all the time. Like, oh, man. But it would be awkward to start every meaning like, so what's the glossary for today?

JASON: I know. But it's one of those things. Back in the context of information architecture and language, I have to assume that somebody is going to land on miscellaneous pages on my site. Not everybody is going to go to the homepage and follow the onboarding. They're going to show up in the middle of the docs because they Googled something. If the docs start off with a sentence like, you know, here's all of our jargon in one sentence, oh, my goodness.

CEARA: Totally. Yeah, you can't make any assumptions, especially on the web. Like, you can't imagine that anyone has learned anything by the time they come to your thing. So yeah, I would say if you're going to do -- really think about language. I think the hardest part of design is actually the language part. So, partially because when we get into complex software that has AI in it and whatever, these different data -- like a complex data model and things like that, you basically have to make up a word for something that's abstract and then use that same word consistently across your error messages, your pages, your buttons, all of that stuff. If you change it, change one of those words, it's like people are so confused. If you've ever paid your taxes or anything online and you have a paper form in front of you and they're asking you for an input, but the label is different from the paper form to the online form.

JASON: Oh, my goodness. That -- yes. And you see this. This seems like it would be so obvious, but it happens all the time. I've logged into apps where they tell me to name my organization. Then they reference it as a team. And I have no idea if that's the same thing because I've also been in apps where you create an organization and then you make subteams. Now I don't know because there was never a clear delineation, and there's never a mention of the org again. Am I using the same concept, or am I using another concept? And it leads to huge messes. When I was at IBM, for example, inconsistency of language led to having to maintain some really gnarly legacy code because people had built their entire business around a misunderstanding of what a feature was for based on the language.

CEARA: Wow.

JASON: It would have cost us so much to either lose that customer or manually upgrade their setup for them. It was like, oh, it's cheaper to just hire five full-time engineers who maintain a fork of our code to keep that running.

CEARA: Whoa.

JASON: It's wild how much this impacts business.

CEARA: Totally. And we have the opportunity to be -- a lot of people are going to be working on new stuff, stuff that's relatively new in its lifecycle. It's not, like, ten years old. Things like that. If we can catch these kind of design debt things early on, then we won't -- then we can save ourselves for later.

JASON: Absolutely. Yeah. I think it's such a little big thing. It never feels like it's that important at the time, and then you do it and you're like, oh. I see why this matters.

CEARA: Totally. Totally. Yeah, I've worked on certain things where there's like a willy-nilly. Yeah, just change this button of this verb whatever. We call it running the process everywhere else. But let's call it initiate here. Or something like that. And it is a synonym, but it's scary, you know. You need to gauge how much people can kind of handle in a high-stakes situation.

JASON: Absolutely.

CEARA: When you work through this stuff, be extra sensitive.

JASON: Yeah, I like it when you see people who really deeply understand this, too. A lot of times the first name that something gets kind of wears a groove into somebody's head. Then they want to call it that forever. So you'll see a company with a really odd name for something, and it's just because that was like the first person who designed it call it that. The product completely evolved from the original idea, but the name stuck.

CEARA: Yeah, yeah.

JASON: I remember when Sarah was my manager, she used to -- she knew this. So she would intentionally name projects things like butts or floobity so we would never, ever, ever publish the initial name for a thing. It was always very clear that the name was an actual project that we needed to do toward the end of the project.

CEARA: That's really smart.

JASON: Such a smart thing to do.

CEARA: Yeah, that's good. No one can get attached.

JASON: Exactly. I mean, you can get attached, and it'll always internally be code named butts, but you can't publicly put that into your UI, right. Well, I guess you could. Maybe that's how you differentiate in the market. But generally speaking, that's not how it's going to work. You're going to have the internal code name, but your code name doesn't leak because it's so nonsensical that everybody just kind of instinctively understands this can't go public. That's not a public name.

CEARA: Totally. Just so off brand, never going to work. Yeah, so I'd say once you have a sense for nav and language, then you'll probably want to get a bit more specific. So if you do a little scrolly-scroll here, the next thing to look at would be visual hierarchy and UI. So if you're looking at your interface, you can ask yourself some of these questions. So the most fundamental one is are the most important things on the page visually the most important things on the page. So is that all matching? Then also, is there a consistent interaction color being used? That's another go-to that can be really handy. Just give the people the clue of this one color. Sometimes it can be a good thing to rely on. Visually, are things really consistent? Are they super different? Are they so consistent they don't look different? Are they so differentiated they look to different? Like, am I on a totally different section here? So you can have both problems.

JASON: Yeah, exactly. I mean, I think I feel like this is a challenge where you have those sort of arguments with somebody where they're like, well, our homepage isn't just for one thing. They're like, we have to emphasize this. Okay, great. Then you do it. They're like, okay, but we also need to emphasize this because what about our enterprise customers. Oh, okay, yeah, you're right. Let's emphasize that. Oh, but we also need to emphasize this. Because we've got, you know, developers and non-developers who are non-enterprise customers. Okay, well, now we've emphasized literally everything on the page. Like, do you think people are actually going to figure that out? Or?

CEARA: Yeah, totally. If you're in a room and literally everyone is yelling, you can't understand what anyone is saying.

JASON: Yeah, if you've emphasized everything, you've emphasized nothing. That's a good way to look at it, I think.

CEARA: Totally. And just because, you know -- I guess it's sort of the order of operations of learning that site or that page or whatever. If you make things bigger, people will kind of learn those things first. Then they'll learn, you know -- they'll basically follow a path with their eyeball. So yeah, that subtle thing about that specific interaction is important, but you don't need to actually know that until you're executing that interaction. Or are just about to or whatever.

JASON: Yeah, yeah. That's a good point. I guess we'll look at this when we get into the more practical examples. But kind of thinking about, you know, what do we do when we find ourselves in that situation. Like, for example, a tip I got from a designer is to kind of squint at the design until everything goes blurry.

CEARA: Oh, perfect.

JASON: And if you do that, it's like, what's the thing I see? Then open your eyes and look at it. Is that actually the thing that I want people to see? Because that's the thing carrying the most visual weight. Do you have any other tips and tricks like that, that we can use that'll help us identify these problems right away?

CEARA: I mean, that's a classic. That one is really good. Again, with the sort of note of if you are actually really confused on what should be the most important things, like what the hierarchy should be, I'd suggest going and whiteboarding it, like numbering it out. And being like, well, I need them to know this page is about user management. I need them to know they can add users. Then I need them to know who the users are. And then I need to know when you added that user.

JASON: Yeah, that's a really good point. And you bring up a good point because you're numbering. Numbering introduces a constraint, which is you can only have one thing per number. You can't have everything tied for first place. Like, something has to be first place.

CEARA: Something has to be first place. And sometimes, too, I think when -- I've got caught in this kind of logic trap before where we are having this conversation of, no, no, this also needs to be here and this also needs to be here. You're kind of conflating a little bit of real estate that you have, that it has to do all this stuff. Sometimes you're doing that because you don't have a place for this to live. So it's an interesting one. You're like, no, no, we're not making a details page about blah, blah, blah. So you just put everything here. So you can, like, make stuff really weird by just trying to jam everything into one spot, especially with a web experience. You want to flow through it. You just want enough to know what that thing is about to maybe go into it or read more or whatever the case is.

JASON: Mm-hmm, absolutely. I think that's a very good point. So, yeah, let's see. The interaction stuff, making sure you know what's most important, 100%. Varying a lot. So we actually saw this yesterday as kind of a prank. Somebody put up a slide where each -- it was like 15 points that were kind of high-level, big targets for next year. Each point, to troll the chat, they put in a different not. It got exactly the desired result. Everybody just started panicking. (Laughter)

CEARA: Oh, my god.

JASON: And I think that it's really the fact that we can use that sort of chaos as a prank that does cause that sort of emotional response. It's a good reminder that we shouldn't do it by mistake. (Laughter)

CEARA: Totally. 100%, yes. Everyone is freaking out. It's like, that's the evidence we need to take it down a notch with all the jazzy creativity.

JASON: Yeah, and this is where design systems come in really handy. We just talked to George Gomez about how to do that on the show -- was it earlier this week or last week? I've lost all concept of time. Yeah, this episode here. So if you want to look at design systems specifically, that's a good episode to go into it with. But yeah, so what else -- do you want to focus on anything else here? I don't know how much further we're going. I'm trying to be mindful of time because I'm definitely off on rabbit holes here.

CEARA: Yeah, totally. That's all good. I would say that just a little flag for when you're wondering about is this cool, is this part of the UI cool, I would just do a quick check for like did I implement anything bespoke just for page.

JASON: Oh, okay.

CEARA: That would be one quick check. That's what we would do also with the design system. We'd be like, wait, why are we actually designing anything here. And if you can make the right argument for that new thing, then cool. But if you just were like, oh, I just did a thing and it's kind of weird, that might be -- you know, you maybe could have done some useful stuff there.

JASON: Yeah, and like being cognizant. Is it because you wanted to, or is it because you solved a problem? That seems like a good question to ask any time you're about to make something new. Like, whether it's design, dev. You're going to remodel your house. Whatever it is. Am I making a change for the sake of change, or am I making a change because it solves a problem?

CEARA: Exactly, yeah. And what level of standard do you want to apply to it? Sometimes you have to do a band-aid solution, like a low self-esteem sort of band-aid. And that's okay. But there's a time that's going to get phased out and get replaced with something or whatever. You can kind of just match those things. Like, this is an actual good decision. So, cool. So it should be judged by a higher standard.

JASON: For sure.

CEARA: Then interaction. That's kind of the other final one that's important and really -- interaction is really hard. So this one is important. Really, I would do a map in here. Are there any scenarios users go through that they can't get out of? So any dead ends that you can kind of get into a weird state. When you look at the steps that the user needs to take to execute this goal, is it more or less than you would think they should be? That would be my other question. Does the interaction map to a familiar UX pattern in any way? This one is a big one. Can you tell the state the system is in on the page? So --

JASON: So did it succeed, did it fail, is it pending, is it in progress.

CEARA: Exactly, yeah. Do you need to do this step so you can do the next one? All of those things.

JASON: Oh, yeah. Like showing dependency in an onboarding flow. You can't do step five without doing step four. If you don't show me that in the UI, then I'm really frustrated when I click on the five and nothing happens.

CEARA: Exactly, totally. Good example. And then just generally, are users driven forward in their workflow? Sometimes you get to a point where you're like, yeah, you had a success, but then you're just like on a page. You're sort of in the abyss a little bit. And sometimes that's a reasonable conclusion. But other times it's like, actually, it's kind of lame. Maybe there's something better we can do.

JASON: Sure, yeah.

CEARA: So those are like -- oops, sorry. That doesn't go anywhere. That wrap up button.

JASON: Okay.

CEARA: Anyway, so if you go back to the beginning, you can just press R on your keyboard if you want.

JASON: Oh, really? That's cool. Okay. I do need to have a Figma prototype session because I have no idea how any of this works.

CEARA: Yeah, it's fun. So I have a couple examples here. We can kind of go through whichever one that you want. Then maybe we can fix it.

JASON: All right. You want to vote, chat? What do you want to see? We have about 40 minutes. Oh, what's up, Georges? So we have 40 minutes. We'll have time for one, maybe two of these. Vote for the ones you want to see, which ones will be most useful for you.

CEARA: Yeah, so I'll just describe them quickly to give a little context. So the onboarding example is just a small subset of a full onboarding flow. It's just like enter your financial information. So it's just a few screens. The UI example is a pretty ugly UI that we can figure out how to fix. The error example is like just a really bad interaction for an error state. So we could look at how to make that more good. Then we got a success example, which is like, okay, the interaction is kind of meh.

JASON: Yeah, I gotcha.

CEARA: And it could be awesome.

JASON: We got a couple votes in the chat for the error example. So why don't we start here.

CEARA: Sweet. Nice. All right.

JASON: So I'm looking at this. I see a page. It's got -- okay. So this is a thing I like. This is your clue. This is the thing that is interactive. So I'm going to come in here. I'm going to say, all right, I am senior. I'm junior. Okay.

CEARA: Then if you click out, it reverts.

JASON: Yeah, it broke. Okay. So I'm expecting this to change, and it's not changing. No nothing.

CEARA: So basically what's happening in the system is that action is not allowed. You don't have permission.

JASON: Okay.

CEARA: So this is what I would describe as a passive-aggressive error interaction. It's just like, no.

JASON: I'm not going to tell you what to do, but I'm not going to do it.

CEARA: Not gonna do it, and I'm going to ignore you. So yeah, do you have any initial thoughts on what would be nicer in this scenario?

JASON: So I have a few thoughts. Like, my general questions looking at this are, you know, if there's a thing that I as a user am able to interact with, I want to see it in an input. If I'm not able to interact with it, I kind of feel like I don't want it to be an input. Maybe it should just be a list item that shows me what my level is because I can't change that. Or maybe the input is disabled. At the very least, if I try to change it, show me a pop-up or outline it in red and say you can't do that, you jabroni. Something like that.

CEARA: Yeah, totally. I definitely agree with you on that one. So, you could have multiple scenarios. You could have that you can't even interact with this input at all. Then you could also have it where you just can't select that value. You're not allowed.

JASON: Oh, so this is a potential I can select some of them but not all of them.

CEARA: Yeah, potentially.

JASON: Oh, okay. So that changes some of my feedback. Actually, you just pointed out something good, which is I should have asked more questions before I started jumping right to solutions. Honestly, if I have one -- people joke about their toxic trait. That's my toxic trait. I start fixing before I have full understanding.

CEARA: I think we all do. We all want to get it done, right? We're on sprints here.

JASON: (Laughter)

CEARA: We're terrified. Yeah, totally. So I think what you're touching on is really interesting. Regardless of how we handle it, what you're talking about is actually prevention of the error in the first place. So assuming the system knows that this is not allowed at the time, that this page is loaded and stuff, you'd want to prevent -- as we work through creating a really good error interaction, that to me is the ultimate. The error interaction doesn't even happen.

JASON: Right, but you bring up a good point. This could be data pulled from a third-party system, and maybe that third-party system will show me somebody's status in the options but not permissions. So I have no way of knowing whether or not somebody is able to choose a certain option. All I can do is send it to the API and check what the response is. So in that case, I can't do it ahead of time because there's no way for me to know.

CEARA: Yeah, exactly.

JASON: Another question I should have asked before I started designing solutions. The silence speaks volumes. (Laughter)

CEARA: Well, it's just like so relatable. I've gotten myself into this scenario many times.

JASON: I love it so much.

CEARA: Hey, developer. Can we actually know this thing?

JASON: (Laughter)

CEARA: And they're like, not really.

JASON: I see you've designed a solution. Would you like to check that with reality?

CEARA: Yes. A little cross reference would be good. So let's just say that, okay, we have to just show that it's not allowed somehow. So we could maybe brainstorm some ways we might want to do that in here.

JASON: Yeah, so should I go into the Figma itself to do this?

CEARA: Yeah, for sure.

JASON: Let me see. It was error -- here. So we've got our bad thingy. So my thinking is should I pull this out to a new frame or something so I can mess with it?

CEARA: Sure. Yeah, if you want. I have other copies too.

JASON: All right. I'm going to pull this down here so we can start messing with it. So I want to design the error state. My thinking is, like, my gut instinct is make it red and add a little message right there, like right where you changed it. If I have to click the save button, maybe it goes, you know, right near the save button so it's contextually relevant to where I just clicked and where I'm looking. So I'm thinking maybe if something goes wrong, I can take this button here. Maybe I make it red. Maybe we say -- I'm not going to change that, but I am going to take this text and copy it down here and say you can't edit that, you jabroni.

CEARA: (Laughter)

JASON: Then we can maybe that red. I don't know if the contrast is working. I guess we'll find out.

CEARA: Yeah, nice.

JASON: Then it makes me think maybe we want the stroke to be a shade of this red but a lighter shade. So it's clear that something is wrong.

CEARA: Yes. Yeah, nice.

JASON: That looks like an error to me, right. Hey, you can't change that.

CEARA: Yes. Nice. So I think you touched on a couple really good points there, which is if you can localize the message of the error, that can be really useful. It's right, exactly as you were saying, where your eyeball already is.

JASON: Because I could have put that up here, right? But then I click the button, and -- am I even looking over here? There's no motion or something to draw my eye, I'll just miss it. And I've seen that happen. I have been the person who completely misses the error message. Then I'm mad and getting on Twitter to yell. Then I read the page again. Oh, there was an error message.

CEARA: You're taking the screenshot like, oh, wait.

JASON: (Laughter)

CEARA: Yeah, totally. So the localized approach is really good, but what if this was longer? What if the form was longer and the focus wasn't there.

JASON: So if -- let's say the error is here, but the form is so long that I'm down here I can't see it. It's off screen. Okay. So maybe in that case, I'm just going to make a mess out here. Whoops. Take this one and maybe that one lives, like, down here-ish. And we could do something like -- uh-oh. Where does that live? Maybe I make this one red. Then the text goes white. I'm trying to remember how -- no, go away. Fill. There. Something like this, which gives us the -- like, this is hideous, but it kind of -- it's down by where I did things. Kind of a general thing. Instead of a message like this, it would be, say, you don't have permission to edit the seniority level. What do I do? This? Right?

CEARA: Yeah. Totally.

JASON: So we have a thingy.

CEARA: Yeah, and I think you touched on something really good, which is what I was going to ask you next. So with an error situation, you want to say what, right. You want to say, uh-uh, you can't do it.

JASON: Uh-uh. (Laughter)

CEARA: Like, don't even go there. So you want to say that, but yeah, if you can then communicate system logic into that error, then you're going from basically an FYI into a richer and more informative kind of message.

JASON: Yeah, so we started with no information. Then the next one, which is like something went wrong, is more helpful than nothing but still not super helpful. My least favorite is when you fill out a multipage form and it says something is wrong with your input. Then you have to go scroll back through the whole thing to figure out which thing is broken and just hope they marked it red because if they didn't, then you got to read each input and guess which one didn't pass the formatter.

CEARA: And it may not have communicated any criteria about what should go into those inputs.

JASON: Yeah, so this then takes us to more of a -- like, we've now given some context. A thing went wrong, and that thing is this.

CEARA: And this thing. Yes. So in the spirit of really kind of taking it full circle, is there anything else that we could do to help the user achieve their goal?

JASON: We can show them the available options maybe. Like, you could choose this option or this option.

CEARA: Yeah, totally. Like in the input, for example. You could be like, stuff you can do, stuff you can't do.

JASON: Yeah, what else?

CEARA: Well, so when we were talking earlier about flow and stuff like that, does this -- one of the questions was does this propel the user forward. So we could potentially try to do that here. So for example, maybe the ultimate error message doesn't even happen in the first place. That's cool. But when we do have to have one, it tells you what it is, tells you what the problem is, and maybe it could also tell you how to fix it.

JASON: Okay. So to do that, we just kind of expand our error message here. And we say please choose a new option. Or, like, what's your --

CEARA: Like an allowed value or something. I mean, that's probably bad UX writing. It's very computery. You could probably do two things. You could choose something you're allowed to choose, or you could contact the admin of the thing to give you permission, I think. Those would probably be the two things that you could do there. Because this is magical world we're making up right now.

JASON: Yeah. So something like that.

CEARA: Something like that.

JASON: Also, showing off some coolness with Figma being multiplayer is always cool.

CEARA: So cool. I love it. It's so handy to get around.

JASON: Absolutely. And this is good. There are a bunch of questions that we would need to figure out in terms of how we could make this actually happen. Am I able to get a list of the allowed options? Would that let me do something helpful? Could I validate on the fly? Like when somebody chooses an option, could I show them the error right then instead of waiting until they get to the end of the form? Or better yet, what we talked about originally. Just figure out what they're allowed to do and only let them edit the stuff they're allowed to edit. Don't create land mines for people, right. Like you said, we want to propel the user forward. Giving somebody a thing to trip over is not going to help you in that goal. So if there's a disallowed option, get it out of there. Don't even show them it's a thing.

CEARA: Totally, yeah. Or also, getting into a really deeper way of -- a holistic way of thinking about it, we could also think about why do these permissions work this way in the first place? You know, maybe the most appropriate thing here would be change the permissions model or create an approval flow or something like that. I do from free reign over my stuff, blue it does have an approval layer to it. So I can just do that.

JASON: Oh, yeah. Because that's also interesting, too. In a lot of cases, at scale obviously, adding a human review is probably not a great idea. Like you don't want 10,000 review requests every day to go to one poor person who is having, like, the biggest career crisis. Like, what have I done? (Laughter)

CEARA: Yes.

JASON: But, you know, there is a world where I'm in some software as a service app. Each person on the team -- we have maybe eight people on the team and I'm the admin. I do want to know if people are going to change what they have access to. So rather than trying to make the computer smart enough to know, just email me. Say, hey, so-and-so is requesting this permission. So-and-so is trying to change their role to this. Confirm or deny. You're the admin. Then the UX for the person requesting just changes. Instead of saying saved, it says requested or something like that.

CEARA: Yeah, exactly.

JASON: Okay. Yeah, that's a good way to think about it. And you know what just happened. By asking that question, we got out of thinking about the program and started thinking about the people. I like that you were able to do that without asking me to think about the people. You just asked a good question, and we ended up there.

CEARA: Yeah, totally. It's interesting when you have the micro solutions. Then if you keep on applying that -- like, is this really good? Is this really pushing you forward?

JASON: So, there is a trap here. I say this because I've fall into this trap. Where do you draw the line on that? At what point do you stop asking that question before you go, are we really in the right business? Should I get out of tech and start a farm?

CEARA: Totally.

JASON: What's the right level? How many layers of galaxy brain do we want to get to before we say, okay, you know, this is as far as we want to go to get this project done. Or is that something you just -- it depends.

CEARA: Totally. I mean, most of the time you're not going to default to let's go start a farm or coffee shop or something. Because there's a real business there. So with the design practice I work within, usually it's like we do kind of innovation tracks where you are like, let's go into fairly land. Let's just go nuts on ideas with stuff like that. But most of the time, the lens that I'm applying is like, is this an excellent interaction? If not, can we get there? And the reason why I think that's an interesting or relevant way to look at it is that these products are getting so competitive. If you look at the project management world for products right now, it is like really cut throat. They are coming out with crazy amounts of features and stuff like that. So I think that maybe our overall standards for user experience are getting -- rising.

JASON: Yeah, I think it's definitely a kind of creeping normalcy where you see somebody innovate in a certain way. I can't remember who made this comparison, but they were talking about the iPhone. When the iPhone came out, it was revolutionary. No buttons, touchscreen. Now if you drop a phone with no buttons and a touchscreen, unless you're deliberately doing a, hey, are you somebody who hates touchscreens and wants physical button, it's kind of wild. You'd be like, wait, why doesn't this phone do phone things?

CEARA: Totally.

JASON: We just move the goalposts. Something pushed forward what we were expecting, and I think that Sass apps are probably one of the most competitive spaces here. You see like Stripe drops a payment form, and it's so much easier to use than most payment forms out there. Now the goalpost just moved. If you're not as easy to use as Stripe, you're losing. You're not average anymore. You're now bad.

CEARA: Yeah, totally. Totally. It's pretty wild. And it's even getting applied to industries that have been historically pretty -- like, don't know how to use a computer, you know. So it's an interesting, huge leap, I feel like is happening right now. Even in our re-design projects, they're super enterprise.

JASON: Definitely. And you mentioned spaces that aren't historically techie, but it feels like fintech products are getting pretty aggressive with their UX. I didn't feel like my bank site was easy to use four years ago. It was super confusing. Now today they're all dropping these really flashy UIs. It actually is kind of nice to use. You can do a bank transfer in one click versus printing a form and faxing it. It's like, dang, we caught up. But now the goalpost moved again. Even with all these changes, it's like, this still isn't as easy to use as whatever has the flashiest UI right now.

CEARA: Totally. Fintech is a really good example. The differentiator is like, can you do payments? Yeah, all of them can. So the nice to use, really easy to adopt, not scary, those things are becoming such key differentiators. It's wild.

JASON: Absolutely. Okay. So we have like maybe 15-ish minutes left. Do you think we have time to do one more of these examples?

CEARA: Yeah, I think we could probably fit the confirmation feedback one in.

JASON: Yeah, let's see here.

CEARA: So if you pop over to your other tab on the right, go back into the prototype mode.

JASON: Prototype, aha. Press R. Amazing. And this one?

CEARA: Yeah. So this scenario, here is basically you're on this list view. You're going to upload three files to this project.

JASON: Okay. I've selected my three files. Chat, did y'all just see Figma animate a toast? I did not know that could happen.

CEARA: Oh, it can happen.

JASON: Oh, my goodness. Okay. That's amazing.

CEARA: I feel like we're on a Figma ad right now.

JASON: You know, I swear there are some tools that every time I use them, I'm just like, hot damn. What a great tool.

CEARA: I know, I know. It's really life affirming.

JASON: Figma, come sponsor this show. We're clearly sponsoring you here.

CEARA: Yeah, come on. Give us a discount or something.

JASON: This is wonderful. Okay. So anyway, Figma is great. This success was okay, but the three toasts, a couple things jump out at me as weird. I did one action and got three success dialogues. That feels weird. That implies to me there's a world in which two of the files would upload and one of them wouldn't, which is also confusing. I think if I look back here, just running that one more time, it doesn't tell me which files uploaded. So if one of them failed, I have no idea which one it was. I'd have to go own the thing up and look at the files to see which one was gone. So there's a lot of mystery meat going on in this success.

CEARA: Nice.

JASON: Because I would have treated it like one transaction in my head. I have three files, please upload them. Great, I have uploaded them. Success. Instead of I took the first one, done. Took the second one, done. The computer is violating my expectations here.

CEARA: Yeah, totally. It's really interesting what you just communicated in terms of the logic that all of that implies. I think it's worth taking a moment on it. One thing you said was I'm not sure if one uploaded or multiple or some failed or could fail. So these are the kinds of things that people are running through in their head. Then they're like weirded out. And they can't always articulate how they're weirded out by is, which I think is really interesting.

JASON: I will say I have significantly fewer ideas on how to fix this one. Like, the error message one I felt pretty comfortable with that one. I don't know how to fix this one. So what would you recommend? Or I guess let me go -- do I go in here?

CEARA: Yep, yep. Pop back over there.

JASON: Should I go to this one, do you think?

CEARA: Yeah, maybe where the toasts are active.

JASON: I'm going to go to this one because I'm going to make an educated guess here that we're going to get rid of the multiple toasts and have a single one.

CEARA: Sounds good.

JASON: All right. So here we are. We've completed our task, right. I also just noticed it is doing separate things. You increment to five, then to six, and then to seven. And that makes my little programmer heart very sad. I want a transaction real bad there.

CEARA: Like, just get the whole thing through.

JASON: Yeah, it either succeeds or it fails. It should tell me, hey, one of your files was too big. You need to shrink it and try this group of uploads again. Or something like that.

CEARA: Yeah, yeah.

JASON: Do it like Google Docs, where when you drag three files in, it pops up a thing and shows me the progress of each file with a check mark for each one. So if one fails, I'm like, oh that, file didn't work. What's the reason? Just anything that tells me what the heck is going on.

CEARA: Yeah, totally. That's a super good point. And I would say one thing that we always want to do with the feedback and interface is make sure it actually matches the importance of what just happened. So here, I mean, a file was uploaded, a file was uploaded, a file was uploaded. It's like, whoa, mama. This should be pretty standard. It's not like we're doing confetti or anything crazy here, but it is kind of -- it's a lot of feedback that doesn't actually tell you much that is a bit much kind of.

JASON: Gotcha.

CEARA: You're also kind of touching on, in terms of our different solutions, I would say for the toast, aggregating that information is a great idea. But what kind of information do you think you would want to put in that toast?

JASON: So I guess thinking about what I'm doing here, I am looking at some kind of project, and I want to attach something to it. So I want the computer to know enough about what I just did for me to feel confident that it was actually done. So if it shows me, like, three file names and check boxes next to each file name or it shows me, you know, successfully uploaded, file name, file name, file name. Some indication that it actually knows what the files were and wasn't just, like, the form and after a time-out you show me a success and we have no idea if it ever worked. Not that I've ever built that. (Laughter) But those sorts of things. It's very clear that the app is not just telling you that it worked but confirming, like showing you evidence that the thing worked.

CEARA: Exactly. That's such a good word to use, evidence. People say, oh, I did this thing and whatever. But give me some more details. So I think that's super useful, what you're saying around that logic or the questions that people go through, the questioning. If you actually did it, tell me what you actually did. Right? So the same kind of principle applies that we put into the error. Don't just say a thing happened. Tell me what the thing was that happened.

JASON: So we can say something like -- if I can spell -- successfully uploaded three files. At a bare minimum, this is better. At least I know what happened.

CEARA: Yeah.

JASON: It shows me clearly that the thing did what I expected the thing to do.

CEARA: Yeah. So I would say we could even take this a little bit further. This UI is disembodied from where the thing happened. So where did you successfully upload these three files? Maybe I'm doing batching of this. Maybe I just did like 15 and they're all taking different amounts of time.

JASON: Okay. So what if I do, like -- oh, no.

CEARA: Sorry, everything is grouped.

JASON: Let's see if I can do this without breaking it. Yes, I can. Perfect. Then I can take this. Maybe I just put this right down here.

CEARA: Auto layout is kicking in.

JASON: Oh, I get it. I understand. Let me pull this out of the frame. Then we drop that thing right in here.

CEARA: There you go.

JASON: Could probably use some actual design love, but at least it shows me what's going on in the place where I did it.

CEARA: Exactly, yeah. So we could kind of hit on two points with this solution. Then if there were lots of use cases where things were getting batched or were happening on multiple parts of the screen at the same time, then there's probably a good use case for having something at the top that just tells you what's up across the whole page. But we can just assume for this one, that's not so much a thing.

JASON: Sure.

CEARA: So it's nice to have that localized feedback that's a little more detailed.

JASON: Yeah, I would agree. And there's a question in the chat. This episode is not going to feature any coding. We do have a ton of episodes, most of which I think at this point are featuring coding. But today we're learning how to think about design, which is pretty critical as we're coding. So yeah, I like -- I mean, you know, I think I would probably want someone who is a professional designer to go in and make this look a little more cohesive because it is kind of floating. We've got some things like drop shadows that are popping it up above. I guess if I just turn this off -- can I just turn this off? What have I done? Down on the banner. Just pop, get out of here. So that kind of drops it in a little bit and makes it feel like it's sort of part of this thing. But it now feels like part of the element. So I click, I upload. The thing that I changed shows me that something worked and happened, and it has some information that indicates it knows what the thing was that happened. This would make me more confident than the toast, toast, toast. Is there anything that you would do in addition to this? Or other things that -- like if you were going to be the one redesigning this?

CEARA: I would also consider just in terms of -- so whenever we take a really localized approach to conveying the feedback, it's great. But I'd need to do the check with the dev crew to see that we would actually be like maintaining focus in that part of the screen.

JASON: Yeah, because if it pops back up to the top and this gets lost, gotcha.

CEARA: And it's like all that front-end effort would be kind of not always going to work. But you'd still get into that scenario where the user could be like, so did it work? At all?

JASON: So you're bringing up a couple good things here. First, as developers, we should be asking these questions. We shouldn't jump straight to solutions. We should start thinking about, you know, what information am I trying to convey? Why is this on the screen? What does it accomplish? Then as designers, the same thing. You should be asking your developers, is this thing I'm thinking of possible? How does the system work? What's actually going to be available to do? As I started designing that error message, I was making assumptions about the system. In designing this contextual success message, we're making assumptions about the system. If we don't validate those, then we might end up in that scenario where we send the design over, and the dev team goes, that's not possible. Like, we can't do it that way. So it's a collaboration, right.

CEARA: Absolutely. 100%. It's such a collaboration. One of my beefs in our kind of tech world is that we don't really explore and talk about our workflow between design and dev. We should -- my idea around this is we should really be talking about this as co-creators of the thing. Because that's what we're doing. That's what really great teams are doing. You know, I think that there's a lot that we can kind of develop in terms of our workflow together.

JASON: Absolutely.

CEARA: So make this awesome. Yeah.

JASON: Yeah. Okay. So we've checked that this is going to show up, that we're not going to use it on the UI. Is there anything else you would do in this case? Or do you feel like this is the right amount of simplicity and contextual approach?

CEARA: Yeah, so I would do some exploration of exactly how long to run that feedback for, you know, because it will probably fade away. Any feedback needs to fade away at a certain point. Look at different UI ways to do it. Then I would check on the kind of focus question that I talked about. And then if all of those things are figured out, then the feedback should be really robust overall. So I think that, you know, check, check, check, if all those things are done, then you have a really excellent success interaction.

JASON: Nice. Well, this is great. So with this, I think that's about all we're going to have time to do today. So let's talk a little bit about what somebody can do if they want to learn more. So for somebody who's watching today or somebody who starts watching in the future, what would you suggest is next steps for somebody who wants to dig in and start building this set of instincts and skills for themselves?

CEARA: Nice, yeah. So we actually developed a course called Design SOS, specifically for developers. Let's see if it shows up. It's kind of a new one. Anyway, you can get the link from the Pencil and Paper site. Basically, we go through all of these examples and talk through how to make the design better, how to think about things differently, and how to give you the tools that you need to do a bunch of this stuff on your own. So if you just look at the main nav, we have labs. Maybe we should fix that. So this is all the info on the course here. If you're interested, you can get involved with that. But we're also doing really super hardcore deep dive articles on specific UX patterns. So if you want to look through our different articles and check those out and kind of nerd out on that stuff --

JASON: Oh, yeah. Just straight-up pattern analysis. So these are the sorts of things that if you're a developer, you might look at something and go, this isn't for me. I guarantee you when you look at this, you'll recognize things that you do every day in these types of pattern analysis articles. Design dev collaboration. That's wonderful.

CEARA: Yeah, we actually had a startup founder reach out. We have a data tables one as well. He was like, I redesigned my data tables off of this article. Tonight. And they're done and here's a screenshot. I was like, oh, my gosh. So when you're diving deep into some of these, solving some of these problems, this kind of thing can be helpful.

JASON: Oh, wait. Is this a -- oh, that is cool! This is such a good idea. Okay. All right. Everybody go to the site and click through all the articles so that you can see before and after comparisons. That is worth the price of admission right there. What a great way to show this stuff. I always want to see comparisons, and I never open the -- like, I have one open every here and one open over here. I'm thumbing back and forth trying to figure out. This is perfect. This is so good.

CEARA: It hits you right in the eyeballs.

JASON: Right in the eyeballs. (Laughter)

CEARA: So we're going to launch -- we're going to release three more of these and launch a master class series on them in Q1.

JASON: Very cool.

CEARA: Early in the new year. So keep your eyeballs peeled for those.

JASON: Probably, I'm going to guess, somewhere at the bottom there's going to be how to get more -- oh, my goodness. There's so much information in here. Wow. Maybe just drop your email in here, y'all. So you get notified when new things come out. But this is super, super helpful. And we just scratched the surface. Look at all of the material that's in here. That's just on the one page. So much information in here that we didn't have a chance to really dig into. So, yeah, this is -- this can be a rabbit hole, but I do think this is one of those things where, you know, knowing nothing and you struggle a lot because you don't know what you don't know, and then there's kind of getting over that initial hump to recognize there are a lot of things that you are aware could be better. You don't need to know exactly how to fix them. That's what professional designers are for. But as a developer, if you can pull this out and say, hey, I'm noticing this interaction problem or noticing this pattern is a little confusing, I don't know how to fix it, but I'd love to talk through it with you, designer. And you can make such a big impact on the quality of things you build by just even developing that part of your brain that goes, ting, something's not right. And you don't have to do a ton of work to become that good, right.

CEARA: So true. Plus, plus. Times 1 million trillion.

JASON: Okay. So Ceara, at this point, are there any parting words or final links that you want to send people to? I'm going to start dropping a few in the chat while you think and talk.

CEARA: Yeah, I mean, I think we really covered it in terms of sort of links and things like that. I think that a lot of the stuff is a lot more accessible than it kind of seems. Like, we have all these cute UIs and stuff like that. It seems sort of really fancy. But a lot of this stuff is just an extension of the logic that you're already using in development. It's just a slightly different lens to kind of apply at different times. So I think that this stuff is really doable, and you can get far, far into it. You know, you can go a long way without knowing a whole bunch and being a total specialist. So words of encouragement.

JASON: Good advice all around. All right, chat. I think we're going to call this one. So stay tuned. We're going to find somebody to raid. Before we leave, though, let's do another shout out to our live captioning. We have had Rachel here with us all day from White Coat Captioning taking all these words down. And that is made possible through the support of our sponsors, Netlify, Fauna, and Auth0, all of whom are kicking in to make this show more accessible. While you're on the show site, make sure you take a look at the schedule. You can click this add on Google Calendar button to automatically have the shows added. It doesn't notify you or anything, just puts them there. You can always follow on Twitch. Hit that bell button so you can see when things are happening. And maybe tune in next week. We'll have Max Stoiber on the show to talk about GraphCDN. We're going to do some GraphQL stuff. We have Shadid coming in to talk about next.js and Fauna. We have so, so, so many good things. There are more being added all the time. So make sure you head over, get on the schedule, and keep track of that. So, we're going to go raid. It looks like Alex Trust is streaming. So let's head over there. Thank you, Ceara, so much for spending time with us today. Chat, as always, thanks for hanging out. We will see you next time.

CEARA: Bye, thank you.