January 6th, 2014
Nate is joining us to teach one of the daylong workshops in Denver, CO April 7-9 as part of the UX Immersion Mobile Conference. For more information about Nate’s and the other 5 workshops, visit uxim.co.
The “designer who can code” has been dubbed the elusive unicorn of the UX realm. But more important than being equally good at both skill sets is being able to communicate with the other side. If designers understand even a little bit about code it breaks down silos within the team. Greater communication leads to shared understanding. This collaborative environment allows for faster iteration and better design.
Nate Schutta believes that prototyping in code helps solidify this communication. Being able to visualize and demonstrate your ideas not only provides for greater understanding, but a faster workflow. Even though this code won’t make it into the final product, it gets a representation of the final design in front of users and stakeholders.
Which is exactly the thing you need to do if you want to create web based prototypes. And in fact he’s going to be talking to us at the UX immersion conference in Denver on April 9th.
Nate Schutta: Thank you so much for having me. Great to be here!
Jared: There’s been this thing that I’ve gotten myself wedged into. Which is you know I started as a developer. So for me it seems straightforward. A lot of designers are scared of touching code.
They think that the minute that they learn how to program, they’re going to be shipped off to some IT development farm…
Jared: Siberia, yes, where they’re going to be heads-down in front of green screens writing code for the rest of their life that will only be used to take inventory of pig futures. The fact is that programming, A, you tell me, but I don’t think it’s that hard.
Nate: There’s a lot of misconceptions, I think, about programming and how hard or easy it is. I think you’re right. I think there’s a lot of folks who, for whatever reason, just have it in their head that, “I don’t want to be a programmer.”
I go back to when I got started in this industry, and you can see this shift in the personalities that are drawn to programming, just the approaches people take. I saw it just within my college career, the difference between the graduating class of CS majors
When I was a freshman, versus, by the time I graduated, it was a very, very different type of person, group of people. I do think there’s maybe a little bit of truth to that Siberia thing, though, because the demand for IT services has far outstripped supply.
Since I think the first time someone showed a businessperson a spreadsheet and said, “Look what you can do,” and ever since then, we’ve been running at this deficit.
I think there’s a lot of value in being able to bridge those two camps, though. I’ve spent a lot of my career, as a developer, trying to be a design advocate when there were no design people around.
I think there’s a lot of value in the design people being able to speak some of the programmer language. It helps everybody, I think, collaborate better and work better together, and gain some mutual respect there. Instead of just viewing one or the other as that strange person, who does this thing I don’t understand.
Jared: You don’t have to jump from knowing nothing about programming to being the world’s best IT developer. There’s this sort of middle ground. In fact, it’s actually really useful if you just know a little bit of code. It’s not one of these things where it’s dangerous to know a little bit. Is it?
Nate: Right. I don’t think so. That’s a good point. Nobody’s born knowing how to program. That’s something I think some folks maybe think that just because maybe some of us have been doing it for a very long time. Let’s be honest. None of us were in first grade learning how to program most likely.
We all start somewhere. We all get better at it as we practice. The same with design. You don’t start right out of the box being able to design really good interfaces either, and so, no.
I think there’s a lot of value in at least understanding what’s going on, and understanding why some of these things that may seem really easy and straight forward on paper, when you show it to your developers, they sort of freak out and go, “Oh, my God! There’s no way that we can build that.”
You look at a designer and they say, “But this is so simple.” It’s like, “Right. Except for all these technology constraints that I have that make that really hard for me to actually implement.”
I think having a little bit of that knowledge can certainly help in that regard to appreciate the other side of the coin. I think that’s a two-way street. They say I have long been on the developer’s side trying to convince developers to care about doing design, and that it isn’t a magical thing either.
Jared: Let’s talk for a second about getting developers to care about doing design. What’s the real value to having that bridge crossed for them? I think that we start in this world, where we just give really detailed specs, then we’re done, right?
Nate: Yeah. From my standpoint, it’s understanding the importance of it, and why it isn’t just some subjective argument over a shade of blue, that there are really good reasons to do these things.
One of the things that I have battled almost my entire career is you run into this thing where it’s like, “Well, it’s just one extra click,” or “It’s just an extra five seconds, or a minute, or whatever.” It’s like that’s true, except when you start doing the math on that.
You start to understand, “Right. That’s going to effect how many users? How many times a day? How many times a week?” You start doing that math, and then you kind of see their eyes start to open up a little bit.
It’s getting people to understand, that it isn’t just this subjective, “I like this better, because it’s prettier.” There’s science to it too. I think that is a revelation frankly to some developers that think it’s all just drawing pretty pictures, and that there’s a lot more to it than that.
Jared: It’s funny. We know that there’s a lot more to design than just the drawing the pretty pictures thing, but then when the developers come to us and say “That’s hard,” we think, well, they just don’t want to do it.
Nate: Right. [laughs]
Nate: Let’s be honest, sometimes that’s true. Sometimes it’s, “Ah! I don’t agree with you.”
Jared: Sometimes design is just picking a color out of your butt. [laughs]
Nate: Sure, absolutely. Hey, we’ve all been on that project where it’s like, “Why is this purple? Oh, that’s right, the VP’s favorite color’s purple. OK. All right.”
Jared: My favorite one was, “We can’t use that shade of green because the CEO’s ex-wife wore a sweater that was that shade of green and he never wants to see it again.”
Nate: OK, all right. I can understand making that emotional connection. That seems a very limiting thing to the palette, but OK, all right. I’ve worked with weird constraints before. Yeah, it is interesting, I think, how that works.
Where you need to appreciate both sides of that coin and understand that design is a lot more than just drawing pictures and development’s a lot more than typing. I think a lot of those same mindsets that work for one help in the other.
I’ve long been a big believer that code is far more artistic in nature than it is scientific in nature. I’m certainly a proponent that code can be beautiful, maybe not to the average layperson, but I certainly can appreciate the craftsmanship that goes into it.
I just think having that appreciation is very helpful to folks. When you’re on a team together, especially if you’re on an agile team, everybody’s in the same room, it really helps to understand that.
“OK, I thought what that guy did was really simple, but then I tried doing it for a few days and I realized that, yeah, there’s a lot more to it than I first thought.”
Jared: There’s this mutual respect that comes out of understanding the craft, right? If I realize that you understand the effort it takes, it’s easier for me to try a little harder.
My favorite things are when I’m talking to developers and they go, “Yeah, we can’t do that,” and then the next day they come in “I was thinking in the shower, and there might be a way we could do that.”
That sort of willingness to come partway, because you’ve gone partway, I think, really does make a difference. You’re like, “Yeah, OK, I get it. This is really hard. You’re putting in some really, really difficult effort here.”
I think there’s also something that comes from this, from the design standpoint, in knowing your medium, right? If the design that you’re creating has to be implemented through the tools, there are things the tools can do, there are things the tools can’t do.
There are things you can do easily, there are things that it can’t do easily. You can get more done if you choose things that can be done easily every time. If you choose things that are hard, then it’s going to take more time, it’s going to take more effort to QA, so the costs are higher.
It’s going to mean you get to do less. Understanding the medium, doesn’t that give you some advantage there?
Nate: Absolutely. You hear about these stories, physical designs with cars or water heaters, things like that, where the original design people aren’t talking to manufacturing, and once manufacturing gets it, it’s like.
“My God, this is going to be nearly impossible to make, or it’s going to be really expensive because you’re using all this material.” When those two groups start chatting with one another, it’s like, “Oh, we didn’t realize that it had that effect.”
We can tweak the design. You make a small change to the design, you get the same output, but all of a sudden, it’s easier to make, cheaper to make, less material, et cetera, et cetera, and you end up having a much bigger win all the way around.
One of the appliance manufacturers ran into that, where they brought a whole bunch of design and construction work back into the US, and that was what ended up happening.
In order to make it work economically, they got everybody working together, radically changed the design on this particular appliance, ended up making it far cheaper, far easier to build, and more efficient, all at the same time. That’s a pretty big win when people are talking to one another.
To me, that’s the whole goal of so many of these approaches we’re using in software today, whether it’s agile or Kanban or lean or whatever you want to call it. It’s all about getting us to talk to one another and get rid of these walls where you just pitch it over and, “OK, I drew all the boxes.
Now somebody’s got to make those boxes real,” and then they throw it over the wall to somebody who makes sure that the boxes do what they’re supposed to do.
This stuff works a lot better when we’re talking with one another and bouncing ideas off of one another, coming to an approach together, as opposed to all being in our little silos.
Jared: Do you ever find yourself in your work granted, you’ve been doing this for a long time so you’ve got a lot of skills but do you ever find yourself throwing together a quick idea.
Knowing that the code that you’re making is never going to ever, ever, possibly be the production code, but that doesn’t matter because you just want to show somebody an idea?
Nate: Oh, absolutely, that’s very common. I built a couple widgets last year with that exact thing in mind. It was not production code. It was just OK. This is what you’re asking for. Does this look right to you? Is this what you really had in mind?
Here’s the implications for what you’re asking for and are you OK with that. At least one case that worked really well for them to say. Oh. Well now that I actually see it, I’m not so interested in it. You know so, to me, that’s a huge part of it.
Is getting an understanding of alright how hard is this to actually build? What might this look like?Then to get a chance to really play with it. I’m a huge believer in paper prototyping and I have been you know essentially my entire career.
But, let’s be honest. You get to a certain point where it’s like you know I really need to see what this feels like. What is this actually going to look like when its rendered you know especially if we’re talking touch interfaces these days. Is it going to work right or not?
There’s really not a great way of doing that, at least from my experience without getting that out there in some prototyping code.
Jared: When you’re doing this, and you’re getting that feedback right, the actual quality of the underlying code is really not the issue at the time then?
Jared: It’s OK if it’s really sloppy. It’s, the whole point is just to get it on the table.
Nate: Right. You may evolve that code into more production ready code. But you know let’s be honest. We’ve all done something quick and dirty to get some feedback on it to see what it looks like and. You know hopefully we don’t just copy and paste that into our production app and leave it as is.
There lies danger. But just being able to conceive of that idea and see it as opposed to drawing it and sort of looking at it in a flat world you know to me is a very powerful tool to have. Getting back to that whole collaboration communication thing, this is another part of that that can be so useful.
You look at modern operating systems that have multi swipe gesture type things built into it. One of the things that they have to try to describe this to you, what does it mean to do a three finger drag? Here’s a video of someone’s hand going across the track pad.
That’s a lot easier to get that idea conveyed than trying to describe that in words. You can come up with this really elaborate design, maybe you can get it down on paper. But sometimes the only way, or the best way to communicate that with your developers or with your users is.
Hey! I’m going to code it up. I’m actually going to show you what I mean. As opposed to. One of the kind of want it to look like this. I want a little bit of this sort of fadey kind of looking thing and then I want it to do this.
Just you know code it up. Then let’s look at it. And again, it isn’t that hard. Especially with libraries like jQuery and jQuery mobile and some of the things we have at our disposal today. It’s gotten quite a bit easier than what it was back when the only thing we had in our toolbox was and alert statement.
It isn’t as unapproachable as I think some people have trained themselves or out of fear. They’re well I don’t want to go near that ’cause it sounds dangerous. there’s semi-colons involved. It’s OK. It’s just typing basically.
Jared: Let’s talk about this. Right so, jQuery mobile. This is a library of functions that basically let you do things in phone based apps. Is that right?
Nate: Yeah. It’s basically take jQuery and what would it look like on a mobile device? What kind of widgets would people want, what kind of page structure. It’s lighter weight obviously since we care quite a bit about page weights in the mobile space these days.
Eventually you’re going to obviously on anything, non-trivial. But you can get an awfully long way just playing with HTML, which for a lot of folks that’s more comfortable to them. Even though, I mean c’mon, it’s still code.
It’s still a language. Just a different kind of language but still same general ballpark. It’s very approachable in my experience for a wide range of skill sets.
Jared: If I wanted to start to work on, what our app might look like with the navigation and putting in some sample content and maybe showing how it works with a couple of gestures. That’s not rocket science here?
Nate: No, not at all. That’s the kind of thing you can get up and running really, really quickly. I gave a talk a couple of years ago on jQuery mobile. Just a 90 minute talk. In the period of that 90 minute talk, I had a guy sitting in the front row who had an app up and running against live data.
In the 90 minutes it took me to describe the stuff to him. In real time basically as I’m describing these concepts he’s sitting there you know with his laptop you know clicketedy-clacking away and when we broke he came up with his phone and showed me this thing running on his phone [laughs]. I was like…
Nate: Yeah, that to me was pretty impressive that he was able to do that. It doesn’t require years of learning at the feet of the masters in order to do that. You don’t have to go become a monk or something before one can be approachable here.
You can do something quickly, you can get up to speed quickly and start producing stuff pretty much right away. Obviously the further you want to go with it, the longer you spend at it, the easier it gets, etc.
Jared: That dude he wasn’t just sitting in the front row playing Farmville. He was actually coding it up?
Nate: Yeah, he was building it right there in front of me. I was really impressed. I’d never seen anybody do that. I’ve certainly run workshops where people have built stuff. But this was just a regular 90 minute talk and in that 90 minutes he got enough of.
What am I doing here to build real simple here it is and got it deployed and running on his phone. That to me was pretty impressive. Now, granted he had some technical knowledge. He knew what an app server was and he had all the deployment pieces and what not in place.
But it’s amazing it is remarkable to me just how far you can get even just with your local browser and a text editor, to be brutally honest with you.
Jared: This jQuery mobile thing, it’s sounding like this is just not a hard thing to pick up? If you’re decent at CSS or something you probably can get it pretty fast, right?
Nate: Yeah, that’s certainly been my experience.
Jared: Given that, what sort of prototypes can I then start to build if I’ve got, let’s say a day’s worth of this stuff under my belt?
Nate: I would I think you could make some pretty rich prototypes. Especially if you’ve got a little bit of familiarity with the jQuery approach to the world and how that works. If you’re comfortable with CSS and kind of their theming concepts.
You can build a pretty rich, robust prototype in a shockingly short amount of time. Again, not going to be production ready code necessarily. May involve just some more static data. You may not be talking to an actual web service or something like that.
But in terms of getting something out there that you can show to the decision makers, show to your product owners, run by subject matter expert type people. That’s definitely something that can be done very quickly.
We actually have a pilot app right now that’s using jQuery mobile and is being very well received in the field and from the conversations I’ve had with the guy that built it, it was very straight forward for him to get this thing up and running.
It shows different stuff when you change orientation, they change the columns based on orientation and it’s very nice clean layout and they designed it for the iPad. But it looks really nice and it works really well. From what I’ve heard is being quite well received by the field.
Jared: You say it does the orientation change. That’s pretty slick. That always get’s ooh’s and ah’s from the audience. What other sort of ooh and ah type inspiring things does this app do that they built?
Nate: It’s pretty simple, all things considered. But I just think the fact that people can actually do this on their iPad and it was done in a pretty short amount of time, is really what got people’s attention. It’s touch based obviously.
Jared: It’s feeding real data out of something?
Nate: Yeah, absolutely. It’s talking to web services. It’s production level stuff and it involves all the security things that go into that and what not. It ends up working really well because it solves a problem for the business that they had and they’re delighted to have the solution.
We’re pretty happy that it’s working form. See how it progresses. I think the next step for them is what capabilities do you build on top of that and what else makes sense in that space. Because it’s pretty clear that mobile is eating the world.
Jared: Have you found that getting the real data into a prototype just brings it to, like, a new level of, “oh, I get it”?
Nate: Yeah, it certainly helps to have realistic data. It doesn’t necessarily mean that you have to talk to your dev web services or something like that. But to at least have realistic data, I think, is pretty important.
I’ve certainly got into those conversations doing paper prototyping where it’s like, “Oh, but this isn’t realistic. This just says 99999, and that’s not, really it would be 1342.”
It’s like, “OK, well, just pretend that’s the number that’s there and let’s move on.”
Certainly for a lot of folks, they get really caught up in, “But this isn’t realistic. We don’t actually have an account called Bird Seed Farms.” OK, just suspend your disbelief. Yeah, certainly getting more realistic stuff in there is usually a very good idea.
Jared: Years ago, we were doing some prototype testing with fund managers at Fidelity. There’s like 45 of these dudes and they control all of Fidelity’s hundreds of trillions of dollars of assets.
We could only work with them like after the market closed. We would only get their time for very short periods of time. We’d put these prototypes in front of them.
I remember once very vividly, we had this prototype that, it just had made up data. Just had made up data in it. But it had, like, stock prices, it had, like, IBM 85.5.
I remember the first time that ticker came up and it said, IBM 85.5, the fund managers just got this sort of stare and just sort of stopped and turned blue. Then sort of looked at me and said, “That’s not the actual price right now, right?”
I said, “No, we just made it up.” He says, “Yeah, OK, good.”
Nate: Thank goodness, because I just thought we lost a billion dollars.
Jared: Exactly. We learned in that minute that we could not have the prices be too far off. What we would from that moment on was that right before the session would start, we have this little table, and we’d go in and we’d put in the actual prices of whatever it was at that moment.
This was years ago, we had to do it by hand. But we just did it, and then the prototype had the right prices. Suddenly, that made everything much better.
Nate: It’s always interesting what people catch, isn’t it? I did a test years and years ago, paper prototype. It’s like my fourth or fifth person that I was testing it on. Like a lot of apps, it had a cancel button.
The scenario I set up was, “OK, let’s pretend you’re in this account, you’ve made a few changes and you realize, oh crap, this is the wrong account. I really wanted Bird Feed and I’m looking at Bird Song or whatever. What would you do?”
She just kind of looked at me and she froze. She says, “Well, I don’t think there’s anything I can do.”
I said, “Is there any button on here anywhere that you think would maybe take you back to where you came from and get rid of your changes?”
“No, I don’t see anything.” Said, “Well, what do you think would happen if you pressed the ‘Cancel’ button?” She said, “Oh, I’d never, never press that.”I said, “Really? Why not?” She said, “Well, that would cancel their policy.”
Jared: Oh, wow.
Nate: Oh, yeah, that’s right, because you’re in billing and if you don’t pay your bill, after a while, guess what we do? We cancel your account, so yeah, she thought that meant we’d cancel. I had to rename the button. It’s like, oops.
Jared: We just had a design recently that had a dialogue box for confirming that you wanted to cancel. The dialogue box said something, “Is it OK to cancel this account?” Then the two buttons were “Cancel,” “OK.”
Nate: Yeah, cancel. Nice.
Jared: The user just sort of stopped and just said, “I have no idea what I’m supposed to press here.” I looked at it said, “I have no idea what you’re supposed to press there.”
Nate: I have an entire collection of dialogue boxes that are like that. Where it’s like, really, what are you asking me to do here? It’s hard, though, I mean, I’ve done it. It’s hard to come up with what that stuff’s supposed to be.
Jared: That Fidelity IBM thing, it wasn’t even the important part of the design. Right? That was the thing. We were not testing whether they could read the stock prices accurately. It was almost like decoration around the thing we were actually interested in.
Which was this whole flow management system for building institutional investments. We just had to have something in a price. That was the problem.
We didn’t realize until that moment how much that stuff has to be real and it has to be represented in a way that was absolutely critical.
Nate: It’s the same thing with what we’re talking about here in the mobile space. You can talk about a swipe or a gesture, but are they really going to do that? Are they going to recognize that?
Let’s try it. For a lot of this stuff, the easiest way to do that is, well, let’s get it on a device and see if they figure it out.
One of the examples I like to use is, how do you email a tweet? For most Twitter clients, that’s a hidden action. I agree that it should be, because, I mean, let’s be honest, that’s not something most people do.
The important things are, can you read a tweet, can you reply to a tweet, can you write a tweet. But it’s there somewhere, so where you find it and it’s always interesting to me to talk to people and sort of say, well, what would you try?
In my experience, there’s a percentage of people, and it varies from audience to audience of folks who get that, oh, yeah, you just do like a long hold or a triple tap or something like that.
But let’s be honest, a lot of folks aren’t going to realize that and how would you sort of bake that into a paper prototype. That gets a lot harder to do those kind of demos.
It can certainly simplify things to say, OK, I’m going to put you in front of this. This is on an actual physical device.
We remove some of the suspend your disbelief that this piece of paper is the same size as your iPhone or your iPad. Now tell me, how would you email a tweet and see what they would actually do.
Jared: Right, being able to get those ideas. It’s just something simple like you want the change data to have a yellow background for just a second so that you can tell what it is. How do you test what kind of yellow and how long should that yellow be? What’s the fade?
Nate: Should it be a second? Should it be two seconds? Should it be five? Let’s actually see what it looks like when it’s at that length. Oh, yeah, that’s too long. Ooh, that’s not long enough.
That yellow looks really horrible against the rest of our branding. OK. The easiest way to figure that out is by trying it.
Nate: Yeah, and it gets us into that iterative mode. I was thinking about what happens when we have these silos between us. As a designer, you decide this is what you want. You give it to the developer, they go build it and they go test it. Well, now you want to tweak it.
Now, how long does that take if you have to go through the code gatekeeper, as it were, as opposed to just try it yourself. You want to change the color, go in here and tweak this value. You want to change how long the fade is, go tweak this value.
It’s, again, not rocket science. It’s not like you need to have a PhD in computer science to be able to go in and do some of these things. You just need, I think, frankly, the confidence to try it, a safe environment to try these things in and to understand that, hey, this is actually something I can do. This isn’t a black art.
Nate: Basic HTML and CSS is, to me, really, the prerequisite here, to be comfortable in what the HTML structure looks like, to not be frightened by angle brackets and some of the quirkiness that’s inherent there.
Computers don’t have as flexible a grammar as we human beings do. They’re very literal, so you need to be comfortable dealing with the fact that, what if you don’t close this tag, it might not look the way you want it to.
That’s just the way the computer is, so just close that out and just accept that that’s how things work.
Jared: Do I need to understand the dark world of CSS specificity?
Nate: JQuery certainly involves a lot of selectors, at least being aware and understanding some of the types of questions you can ask, I think, is helpful. As a developer type, we often sort of are expected to know these things, but nobody ever wants us to train them in them. Nobody ever wants to like have a class on how to do this.
But when you start showing people that you can actually ask that question in a more straightforward way if you understand how the CSS selector works and if you know that you can ask for like child and parent and sibling and things like that.
I was working with a guy earlier this year, he had this really complicated jQuery selector and I kind of stared at it for a while. I’m like, man, there’s got to be a simpler way, because he was like getting a collection back, erring, over it, and then it’s like.
We did a little bit of digging, it’s like, oh, yeah, so the structure you’re done on, I was just like this’ll just do parent child. I can’t remember the exact thing but it made it much simpler to write, much easier to look at and go, OK, I actually understand what you’re trying to do here, as opposed to what was kind of a mess before.
It helps to have a basic grounding in some of those things. But to me, the real important criteria is that you understand HTML well enough to know how those tags function, how they work together.
CSS helps, obviously, especially understanding the selector side of that game. Just being comfortable working in a text editor and some of those things.
There’s a lot of different ideas these days, but I find myself more often than not, maybe that’s just because I’m old. That I lean back towards just a good old fashioned text editor.
Jared: I mean, the tools for this are pretty straightforward. Well, I’m excited to learn how to do this. I would like to be able to produce these prototypes and make this work.
Nate: Yeah, it’s not as hard as some people think it is. Maybe I’m not supposed to say that as a developer. Maybe I want to keep some of that mystery there.
But I’m going to be honest with you, I want both camps talking to each other. I’ve spent a lot of years as the developer telling developers about design and why design matters.
I, for one, am really excited about having an opportunity to talk to the other side of that coin a little more directly, say hey guys, what we do isn’t that mysterious either. You’re all capable of certainly cranking out a prototype in this stuff.
You should, that’s the other side of it. Much like I think developers should dip their quill in a little bit and try to do some design, again, if for nothing else than an appreciation of what it is our design folks are doing for us and why that’s so important.
To me, anything we can do to increase collaboration and that understanding of the rest of the team, to me, is just the positive, no matter how we slice it.
Jared: This is exciting. I can’t wait to get my hands on it. I’m going to have an opportunity, because you’re going to be doing a full day workshop on this at the UX Immersion Conference.
Nate: Yeah, I’m really looking forward to it. I think it’s going to be a blast.
Jared: Great. For those of you who are thinking this could be fun, check out Nate’s session at the UX Immersion conference, which he’s speaking on April 9th. The whole conference goes from April 7th to 9th. It’s in beautiful Denver.
Nate: Love Denver.
Jared: Yeah. It’s going to be a great time. There’s all sorts of great sessions on responsive design and testing. You can take Cyd Harrell’s session on usability testing and then do Nate’s session on creating prototypes to test and that’ll be really great. All of that’s going to happen.
Give that a look. It’s at uxim.co. That’s the UX Immersion Mobile Conference, April 7th through 9th in Denver, Colorado. Nate, thank you so much for taking the time today to demystify this stuff for us.
Nate: My pleasure. Thank you so much for having me.
Jared: I want to thank our audience once again for taking the time and spending it with us. Hey, if you’re not subscribed to our newsletter, UIE Tips where we publish stuff just like this on a regular basis, you might want to check that out.
It’s uie.com/uietips. Just put in your email address and you’ll get on the list. Of course, all sorts of good UX stuff there all the time. You can unsubscribe at any time as soon as you get bored with it. That’s OK, we’re cool with that.
Thank you for taking the time to listen and once again, thank you very much for encouraging our behavior. We’ll talk to you next time. Take care.