 The big red clock is going down, I have to start. Hey, guys. My name is Cameron Dagle. I'm the senior designer at Hash Rocket. We're out of Chicago. Boulder and Jacksonville Beach is our main office. I'm the longest-tenured member of the design team. And we build Ruby on Rails apps. We build iOS apps. We do a lot of different things. So what I'm going to talk to you guys about today is, well, this is going to be yet another code-free design talk. So I hope you guys didn't want to see any more code today. And it's almost an app and website-free talk as well. Because what I'm really talking to you about today are not interactions that you're going to have in a normal context, like on your phone or your laptop. But I want you to discover the interactions around you. So what that means is that I want you guys to be able to build up the ability to actively participate in interactions that you might not otherwise think about, that maybe your habits or that kind of stuff, and be able to quantify those and what you do and don't like about them. And hopefully apply that to how we design products. So my first example, so this is Publix. Who likes Publix? Is anybody from the Florida area? OK. Publix is a really nice grocery store. I don't know what you guys in Chicago have. But Publix is the best we've got in Florida. And it's a really nice grocery store, a really nice user experience, getting your groceries there and everything. You go to Pay at Publix. And this is a regular occurrence for me. You go to Pay. You go play with plastic because it's 2014, I mean cash. And this is the last screen that you see. So I've swiped my card. I've seen the total. I've agreed to everything. I get to the cashback screen. And the little thingy at Publix says cashback. And if I tap no here, the purchase is completed. That no is a form submission, essentially. And it drives me nuts every time because the last thing I tell Publix to get my weekend beer or whatever is no. And so it's this grading experience. But it's just a little detail that really does matter. I mean that every single person who goes into Publix and interacts with them is a store encounters this screen where just for a half a second, they stop breathing. And they're like, wait, and then they press no. And they're OK. In contrast, Target, which for me is about 100 yards from Publix, their final screen looks like this. Now there's a separate issue here, which is that this kind of feels like a weird question to ask. I've literally never wanted it all on the card. I don't know why. And the no is super angry. You notice the no is all caps. It's like, no. But I mean it's a big red and a big green button. You press the big green button to buy your stuff. I mean that feels better. And now the wording is a different issue. But my point here is that the world is full of forms. That we are constantly putting information into something and getting some sort of a result. And so the interactions that we encounter when we're trying to build apps, whether we're developing it or designing for them, have a lot of parallels in the actual world and paying attention to these will help you pay attention to those. So I was in Vegas a couple of years ago. And this is mostly what I remember of Vegas is the traffic and the concrete. But I took a cab ride. I was there with Daniel and our other designer at a design conference, took a cab ride. Ended up paying $18 to go to box or something. And then when I swiped my card, this was two or three years ago, I swiped my card and the little thing inside the cab calculated my tip for me. And I thought, that's fantastic. My otherwise miserable cab experience has made nicer by the fact that when someone built this thing, it didn't matter necessarily what it looked like. So I hate to say it was someone who designed it. Because then you think it's visual. It's really just when someone built the software for this, they thought to take the advantage of the fact that there's an extra step here that's always going to happen. And you might recognize this. I mean, this is in Stripe now. So you see any businesses with Stripe see that kind of stuff all the time. Now in contrast to that, I took a monorail later. Because after two or three days of spending $50 a day on cabs, it turns out there's a monorail that's like way less money. So we were like, cool. We're going to take the monorail. Now we walk up to the monorail display. And this is what we see. I wish I had a better picture, but we were in a hurry. And this is the screen. So single ride tickets, $5 each. First question, would you like more than one individual ticket? No? Or yes, $2,345. So all this has to be is just like buttons of $1, $2,345. And it was this completely baffling thing that we were just floored by. But it was something we noticed. So who knows why this came to be? I mean, it's fun to send all this stuff up. But what this talk is about is understanding why this might have happened. In this case, I have no clue why. They chose to design it this way. I feel like there must be a reason. But so I play a lot of video games. This is from Super Mario Galaxy a few years ago. I wish I had a better photo of this, but I'm not going through Super Mario Galaxy again just to find this one dialog box. So this fat star man says, you've got a saver. Am I right? Am I two options or that's right? And yes. And I was like, eh. That's cute, cool job, Super Mario Galaxy fun joke. But then I thought maybe the reason that they did this is because there's a dialogue prompt object somewhere. And it expects two answers. So maybe it was a funny joke. And maybe they were just like, we're not rewriting the dialogue prompt thing. Just to have an OK button at the corner. So who knows? But sometimes you get a glimpse behind the curtain. And sometimes you don't. Here's an example of getting a glimpse behind the curtain that I never ever wanted to actually see. This is from the AMRA app a few versions ago. And it is to date the most terrifying error message I've ever seen in ILS. In case you can't read it, it's unexpected token wanted and then a really strange list of symbols and commands including the word string with double quotes around it within single quotes and things like that. So you guys are the people that would know why this would happen or where it was coming from. I just took a screenshot and tried to get on with whatever I was trying to do. So honestly, IOS is full of really fun stuff like this where Siri sort of, I mean, she seems confident, but she parsed that sentence in a certain way that makes me wonder about how that's being implemented, like how is this stuff being parsed? And really, I can tell you one thing. The way that it tries to parse phrases is really more trouble than it's worry. So they've decided to try it. Yeah, under skirt oats is what it says. It says that, not me. And what they're trying to do is parse spaces. But of course, as soon as you start showing spaces into your grammatical checker, you're increasing the difficulty of doing this accurately versus doing it hilariously wrong by an order of magnitude. And man, I got these for days. So I feel like the one on the right, I really feel like IOS is getting tired of me making fun of it a little bit. I love Siri. We have a very intense relationship. But my point here is that we judge truly designed not by its beauty or innovation or efficiency, but rather by how well it responds to its original problem. At what point are you sacrificing complexity or sacrificing simplicity, either one, to confuse what problem you're actually responding to? I don't feel like I need IOS to correct an entire phrase for me. It's very impressive when it works, but it's very frustrating when it doesn't. So at what point is the actual goodness of the design being hurt by that? So we're going to look at three separate types of ways to quantify this stuff. So it's one thing to be able to notice it and to make it laugh about it or to figure out a better way to do it. So another thing to actually be able to do so on the basis of a principle. So these are some basic principles, I think, that you could take and use when you notice this stuff. Respect for intuition, having a common language, and having a sense of place. Respect for intuition is very simple. All I mean is does it do what I think it will do, which you think would be very basic, but honestly it's very easy to find stuff all the time where you put yourself in someone else's shoes or even your shoes before you learned how to use the thing and you realize some things are just not what they seem. So this is two coffee makers ago for me. This guy broke, the guy after this wasn't good, and my current one. But this one, this is a very old photo, but I can't not get over this button. All right, I'm gonna ask the room. The brew button, what do you think will happen when I press the brew button? No, that says zero and none of you guys are gonna. All right, so you press the brew button and it wakes up the display because this coffee has a sleep mode. It's a coffee maker has a sleep mode. So the button says brew. It's on the front of the coffee maker. It looks aesthetically, you know, it's symmetrical, it looks good. But the button doesn't do what it says it will do. You actually have to press it again and then it lights up and that means it's brewing coffee. So you've got two issues here. One that the button straight up just doesn't do what it says it will do. It's a lying button. Number two, that the button now is lit up which actually makes it more of a call out but it's actually an indicator. So what you have here is something where you've gotta decide whether something's an indicator or a call out. This is an app that I designed really long time ago in iOS years. This came out on iOS 3, I think. And it was a recording app. This came out before the Apple Voice Memos app was a thing and we designed it, we said hey, this app only needs to do one thing, it needs to record. So let's just make it a big red button that says press to record. Well, the issue with the app that we found after the first couple versions wasn't the press to record, it was what would happen after you press press to record. So initially you press press to record that button would turn bright green because we said or I said it was my fault. I said red means record. You gotta have the button say record and green means go so it's going, it's recording something. But we were confusing people because they thought red meant recording and then so people were like, it needs to turn red when it records and I'm like well then the record button will be green initially, that doesn't make any sense. Even the green is brighter. So there was this disconnect and really the solution that we ended up with was after a couple of versions in the app store is the button pulses. So the button pulses slowly brighter to darker. And so sometimes the solution that you're looking for is you're just using the wrong format. I was in Photoshop. It didn't occur to me to use animation at the time. So that's that story. We're gonna talk a little bit about microwaves. We're gonna talk a lot about microwaves actually. Because microwaves are probably the single most often used bad interface that there is I think that's probably way too strong. I, you know, it's worked well for this talk so I'm gonna go with it. This is a wall of controls. I mean there's just a thousand things to do on a microwave. This by the way is the inside of a U-boat from ages ago and there was a guy who stood there and did that whatever it was. So I really like this quote from Gary Bernhard. Programmers are good at building machines with 17 meta knobs that turn the 90 underlying knobs. They're bad at asking why are there so many knobs? I don't think that's just, I mean he can say that about programmers. I think it applies to anyone. So I'm not just trying to call you guys out. But all right, so we have this microwave and we have the intuition test. Like what does it do what I think it will do? Now if you've never seen a microwave before or you've never seen this microwave before. And regardless of the fact that we've all sort of learned to bypass what the microwave says it will do like immediately, you might say you just try to start pressing buttons or whatever. Well the top left button on this microwave says cook. All right, so it's in the top left which is normally a good place to put an important thing. And it says cook which is normally what a microwave should do. So maybe you try to push the cook button in the upper left. You press the cook button and this is my, obviously my beautiful hands. You press the cook button and the microwave goes AC one. I don't know what AC one is. I didn't actually press start for fear of hurting something. This microwave fails the intuition test. It also fails the other test we'll get to that. Let's finish this section with a button that does do what it says it's going to do which is this is from my Xbox. That button returned me to what I was doing and I was like all right, thanks Xbox. Kind of hilariously wordy so I took a picture of it. But second, common language. So by common language I mean consistency both within an interface and also outside of the interface. Like a consistency with a user's common language. So let's look at a card dashboard really quick. Card dashboards are also this really crazy like heavy interface that tends to vary widely and things like that. This is actually Daniel the other designer. This is his car, I think it's a Mazda. And every person that gets in this car does the same exact thing I did which is they try to use that middle knob to adjust like the volume or anything really. But that left knob is the volume. Let's break it down. So we got three knobs here. This left knob, you push it to turn the stereo on and off. You turn it for volume. Cool, we could argue that it shouldn't be on the left. Someone else could say but it's close to the driver so it should be on the left. So that one could go either direction. This middle knob, you push it to go to the next menu item like cycle through like bass and treble and balance and stuff like that. And you turn it to change the value. So what's important about that is it's not a toggle. The first button when you push it, it's a toggle. The second button which looks more or less exactly the same that walks you through a set of menu options. And the turning changes the value which is sort of like volume but it's important to remember that until you push it this knob doesn't do anything because it doesn't select anything. So the initial interaction with that button it was 50% non-functional until you know how to activate the button. The third one over here doesn't push in at all. And it tunes when you turn it which doesn't apply to like half the things that you're doing with the car. So I mean there's a severe lack of internal consistency here. Here's another example. We're gonna go back to a couple of times. This is the Terminator-esque expensive coffee maker that we have in the Jacksonville Optus. It's very fancy and nice but there are also some very fundamentally non-nice things about it. Let's look at the top. So I've got controls over more than I probably ever would need. I've got nine sizes of cup. I'm sure you have nine sizes of cup for your... I've got flavor and strength. Flavor goes from light to bold. I don't know what... I honestly don't know what flavor really does. We just crank it all to bold. And strength goes from mild to strong to intense. So there's three... Look, you can make a panoply of coffees with this thing, apparently. But so our buttons down here are ways to interact with this coffee maker. We have a single cup button, carafe button and up and down and a strength. So say I want to change the strength of my coffee. I press the strength button which actually cycles between strength and flavor and the proper one is lit up. And then I press my up and down arrows to crank up the strength or crank down the strength button or whatever. By the way, intense is way too strong. Oh, it's really strong. And so I go over here to the cup and maybe I want to crank up or down my cup size. That button, you press that button, the up and down arrows don't do anything. That button actually cycles. It actually walks all the way through. Those two arrow buttons, they do set the clock and they do... Like, obviously we didn't set the clock. But no, I took all these pictures at exactly 12 o'clock. And they do change the strength but they don't function for those other two buttons, even though those buttons function, they do the exact same actual thing in the software side. They're cranking a value up or down. So there's internal inconsistency there. Oh yeah, so there you go. I'm up to XL. Video games, again, video games are great. I think they're really... I like playing video games but also there's a reinvented UI all the time in video games so I think it's really interesting how often those guys start from zero and work their way up into a completely different interface depending on what kind of game you're playing and stuff. But outside of the software, the controller has been the same for a relatively long time. There are more shoulder buttons and stuff but you have a directional control and you have AB, X and Y. Generally speaking, it's safe to say that A means cool and B means no most of the time, right? Would you agree? I mean, since 1985 or whenever the NES came out are actually those buttons reversed but that's kind of... For example, in Mass Effect, this is old in Mass Effect 1, I think, which explains why the iPhone photo is bad quality. A is land and B is leave orbit for this part of the game where you are in orbit and you need to land or not. So cool, like A basically does the thing, B backs you out of the thing. Same exact game, different screen, same spaceship, whatever, A is in our system, B doesn't do anything and X is exit which actually backs you out of the menu. So there's no particular reason for this other than somebody didn't think about maintaining a common language with basically all of video games. At least I assume there is no reason. I don't know, I'm the user on the other side accidentally hitting B, right? So on this screen, my loadout screen, I think this is Mass Effect 2, A doesn't actually bring me to the next screen here. It actually swaps the weapon with another weapon so there's a bunch of stuff going on this page but you're eventually gonna choose weapons and then go into the mission. A doesn't do that, A actually changes your weapon selection. X modifies so it actually activates this weapon mods screen. Y toggles a flavorful sci-fi description. And B confirms and sends you into the mission. So I hope you weren't expecting to back out of this screen because you're just gonna get landed on a planet with angry people shooting at you. So these are off, this is from the next game in the series but this is a common language that is there that needs to be paid attention to and isn't. So really I like this quote, innovate as a last resort. And that applies in so many different ways but the context I'm talking about here, it's that before you start doing something different than maybe you've already done or other people have already done, you need to justify it and you need to be aware of the existing languages or the commonality of the history of whatever you're using. So obviously accidentally, semi-accidentally putting a button on X instead of B is not an innovation so much as an oversight but this speaks to the respect that you need to have for existing patterns and existing user assumptions. Number three we're gonna look at here is a sense of place. So what I mean here is the navigation of an item. Where is a user when they're using your thing? Where are they in your website for example? So Steve Krug says navigation isn't just a feature of the website, it is the website in the same way that the building shelves and cash registers are a series. So like navigation is everything when it comes to helping your users understand where they are and this quote's pretty old. So he means like navigation between pages and stuff. We, with a lot of fat client apps and things like that, it's not just pages, it's modes of interface, it's states, it's what is active and available at any time to me. Maybe my URL hasn't changed for a while but there's all of these different ways I'm navigating, I'm walking into and out of states of interface and flows. But in modes, might get you thinking about something that you're familiar with which is VIM. And one of the reasons that I started using VIM like a month ago, I like it, I guess. So all the hashtag guys are making fun of me. So VIM, if you've ever tried, how many of you have not tried to use VIM? Okay, so there's a few of you. So when you try to use VIM, for you five guys, VIM is really popular. When you try to use VIM, you might try to just start typing a word but it's not going to do anything. It's not gonna do what you think it's going to do even though it looks like a text editor and your keyboard looks like a keyboard. You actually have to, you actually have to go into insert mode which is a specific mode. So the reason that VIM is so complicated is because the modes are not immediately apparent and that's fine for an expert tool. You can do an incredible amount of powerful things with VIM but it is so heavily modal that it is very fundamentally confusing and it can be really hard for someone to get the hang of initially. So something else that's heavily modal is my microwave and it's a lot worse designed than VIM, but let's be clear. So say I want to, for some reason, I want to soften something. Um, so I press soften with my wallet, I go manicured, that's my wife's hand, I press soften and it says one. So through trial and error, I was able to discover what it wants you to do here and what the soften button wants you to do is select a value from one to four and then press start. All right, so the reason that that is confusing is not only, well, not only is there no indicator of what is going to happen there, it's that the microwave has switched modes and the reason that I blacked all this out is because once you press that soften button, you're no longer in microwave mode. You're in softness selector mode, right? So all of these other buttons are still there, but the mode of the entire thing is switched. I'm actually, I've actually walked a step down into, I've navigated somewhere, I've walked a step down into a flow without getting any feedback or, you know, unless you count one on the screen as feedback. I have very little feedback that I've actually gone anywhere. So what the, what badly designed modes can do to you is that they result in a secret sequence of actions, like unless, until I discover what the app or interface or microwave wants me to do, I don't know what it is and if it's a mode, then that will drive me down what is potentially can be a long chain of sequential actions. So for example, with this microwave, I like cooking things on power five because then like it heats a little bit more evenly and you don't end up with like lava combined with ice, if you're cooking a hot pocket or whatever. So like, I would say with this microwave and this is very specific to this microwave. Don't go back and think that this is, will apply to your microwave because this microwave, you can't push the buttons first. You have to press cook time in order to put time in at all. Then you actually have to press power after you have time entered into the display, then you can press five and change the power to five and then start. So this microwave has, like there's so much here but like in order to do what is a relatively basic feature of the microwave, you have to know a specific chain of commands. I really don't want to compare that to Vim but that is pretty much like Vim. But Vim is an expert tool and this microwave is supposed to be for everyone who needs to use microwave. So, you know, but after entering a mode, you have to do one of two things. You have to either force completion of the mode, which is what my microwave does. None of the other buttons will work until you cancel out and panic and just cook on tin and cook your thing too much or destroy your existing progress. So I actually checked with a very similar microwave at my parents' house when I was there over Easter and their microwave, if you start typing and you press something else, it just kills whatever you're doing before. So what will happen then is that you'll switch the power to five but then you'll type in time and then we'll start cooking at tin because when you switched to put in the time it just canceled whatever you did before. So microwaves, you know? So, let's go back to the coffee maker because destroying progress can have very real-world implications aside from accidentally cooking a thing stronger than you wanted to. So this microwave has a very rich user experience when it comes to actually getting coffee into and out of the thing. So you press the open button, this flips out, that thing unfolds. You've got all of this different stuff going on there. Well, it's a grinder too. I should point this out. It's out of frame, up there at the top, you put your beans in there. You get the filter emptied out. You close it up, you hit start. It goes, and starts grinding your coffee. Well, here's the problem. Is that open button fully functional the whole time? So, and this has happened, I would say this has happened a handful of times and it's really bad because you end up wanting to fight somebody before the day has even started. But you're standing there with your mug next to it, you're first in line. You've just started the coffee, it's finished grinding, it's started to brew and some guy walks up and goes boink, and he hits the open button and the coffee maker's like, pfft. You put it back in, you press start and it goes, brrr, and starts grinding a new batch of coffee. So you can destroy, that one button will destroy an entire thing of coffee. Like you don't, it doesn't know why it's doing that. It's really annoying, you have to go in and empty out the filter and reset the whole thing. So you can destroy an entire pot of semi-brewed coffee just by pressing the open button. So that's awful. Here's the coffee maker I have at home now. It is simple, it was not expensive, it doesn't look as much like a terminator as the other coffee maker did. It doesn't have a grinder in it, anything like that. We're talking pretty minimal. It makes water hot and it puts it on coffee. On the inside here, this is the spout. So this is your little water spout that's actually gonna put the water into the coffee. It flips over here. So like you fill up the thing, the tank with water. You pull that over, close the lid. It puts water on the coffee like it's supposed to. Not very glamorous. But here's one thing that I discovered on completely on accident that I thought was great and I got probably way too excited about it. Let's watch a cinematic recreation of this coffee maker and what I discovered. I should have had music. Oh my gosh. I was so excited. I was like, oh, whoever designed this put a little tab thing right there and it slanted just a little bit and it cost probably almost zero dollars. But it was, that pushes the little arm in there to keep you from accidentally just putting hot water back into your tank. And I was like, this coffee maker has developed a low-fi, like very non-technical solution to a problem and this was probably done by whoever engineered the coffee maker. Like it was probably not done by the guy who designed the outside of the coffee maker. It was done by the guy who designed the inside of the coffee maker. But he's avoided a very basic kind of user error. So let's do a future comparison here. This coffee maker was $200. This coffee maker is $35. This coffee maker has a one-button self-destruct. Right? This has a one-tab coffee saver. This thing's got a thermal craft. This has what I like to call a visual quantity indicator. That means you can see how much coffee is in it, which is a whole other thing. All right. Design is the distinction making in the presence of constraint. You give somebody $200 and you want a coffee maker with this giant list of features versus a $35 and with way less features. You're maybe, well, the design of the latter might actually be better. It's not, constraint is not necessarily a bad thing. I really like this quote. So here's what we're not talking about. I've got to speed it up. Here's what we're not talking about. We're not talking about button styles or what things look like. That's important, but generally speaking, we know what a button looks like. We know where it is. Buttons have looked more or less the same up until this year. So that's decoration. It's ridiculously important. But that's not what you'd have to worry about in order to have an interaction feel good. And I also just want to say that as a designer, I want to facilitate good experiences and not have them get hurt at the expense of my design preferences. So Ancient City Ruby was at this hotel last year. This is, or this year, too. This is the Casamanica in St. Augustine. So beautiful on the outside. Absolutely gorgeous, really nice architecture in the whole place. We walk into the room and this is our window. All right, so our window is like three feet tall. It's this little square window. The room is all dim. There's this, if you see up here, there's a little plaque. That's what the plaque says. These uniquely shaped and placed windows, blah, blah, blah. As to why some windows are regularly shaped and low to the floor is known only to Franklin Smith. Who is the amateur architect that designed this building? So he was really into the outside of the building and not so much the inside at the expense of his users, I should say. Here's something that's actually well-designed, but it's not well-decorated. So this is the parking receipt at the airport. It's ugly, you know, I would like to redesign it from a decorative sense, but the actual fundamental design of it is actually all right, because it's probably really low cost to print these things. Like that's like nine lines of dot matrix, right? So there's probably a lot of money saved just in terms of the complexity of the hardware and things like that. And here's the thing you put it in. This thing, also really ugly, but it performs great. There's one slot, you put your ticket in, you put your card in after your ticket, it spits out your card and your receipt. So there's almost no way to screw this up. They actually have instructions. It says insert ticket, insert credit card, take credit card, take receipt. You almost don't need instructions for that, but I appreciate it. It's not pretty, it's not well-decorated, but it's well-designed, and that is solving the right problem. Good design solves the right problem. So when we go back to things like this, we look at the microwave. Why? Like, why did this end up like this? And I really think that it's because microwaves are not designed the way we designed software, or hopefully not designed the way we designed software. And this industry doesn't necessarily work the same way we do. And I think that the process can have all the influence in defining the product. So with that said, let's design a microwave the way we would design a product really quick here. So I want to design, to solve a problem, I want to design, feature by feature, to justify the most important stuff that you would need to have a microwave work well. So let's start with a clean slate. So the first thing I'm gonna need on my microwave is I'm gonna need to know how much time, because the microwave counts down, and I'm gonna need to know, I'm gonna be able to start and stop it. So that's the first thing I'll need. Well, I need to be able to increment and decrement the time. So let's do that. I probably don't have a use case for less than 10 second increments for cooking something, so that seems reasonable. I do have a use case for defrosting or something like that where I don't want to hammer that button a bunch of times. So let's add minute selectors as well. So we can go up to five minutes relatively quickly with very little fuss that makes sense immediately. And I also need to adjust the power level. Well, let's do that too. Let's use our existing design metaphor. Let's use our existing design language and we'll put a power selector right there. And that's it. So what we've done is we've followed user needs and we've followed specific feature needs. We've avoided inconsistency, we've avoided confusion. We've also avoided modes. So hypothetically, if you were to design something that backed this up hardware-wise, you should be able to just change power on the fly. I mean, maybe there's something I don't know about microwaves or you can't do that and you wouldn't be able to use those buttons. But as far as I know, there is no, like, there's no secret sequence of events to set time and power and start. You should just be able to do it. So that's the kind of thing that we could do instead. And so this talk is about, I mean, hopefully at this point, you know what this talk is about. But we need to look at things and we need to look at the interactions around us and we need to learn from them even if they don't apply to our, even if they're not software-based because the way that you design something and fundamentally, like the way you think about it and the way you think about your users is gonna affect the final product every step of the way. And I feel like that's our obligation. We can show people that we value their experiences top to bottom and that we're constantly thinking about how to solve problems, ease friction, remove barriers and serve them in world-class ways. And we have a huge opportunity to change someone's expectations. So what I want you guys to do is discover the interactions around you no matter what they are. Respect your users' intuition, language, and their sense of place, those basic fundamentals of understanding where those things can go wrong. And I really do think that interactions are for everyone. This isn't just design stuff. This isn't based on some science that you don't know. There's a certain level of awareness and a certain level of active experiencing of interactions that I think apply to anybody in our field. So that's all I got. Thanks a lot, guys.