The FIVE Phases of Prototyping – AWDG

Thank you very much. All right, well, I figured I would start off the talk, the prototyping mastery talk, by showing a prototype to kick things off. Alright, so this is a project that I worked on, I don't know, three or four years ago. And I'm not going to give you any context. I'm just going to let it play and you can behold. All right, Isn't that great? So this is actually really horrible. You should never do this. There's way too much going on. Like, I built this in Flash because that's what I know. And this is, you know, HTML website. And I learned a valuable lesson after this. I even posted this to Dribbble and was like, oh, this is going to be great shot. And then I had people like, oh my gosh, people are going to be looking for the back button. And I was like, no way, man. The user is going to know that the. Obviously this needs to go over there when you're searching and then you got to see the results later and then after about 30 minutes, like, this is really bad. And so just because you can do something doesn't mean that you should do it. And yeah, so I've built lots of prototypes that way and made many mistakes where I was thinking, oh, this will be amazing. And I just built it because it's easy to make stuff move across the screen and make it seem cool. And I just kind of keep this in the back of my mind, just because you can build something in Flash doesn't mean you should. And so you may have seen this quote going around on Twitter. Prototype is worth a thousand meetings. I did some digging to try to find out, like, who to attribute this to, and I'm pretty sure it's David Kelly, one of the founders of ideo. But I also saw people attributing it to Mike Davidson, who used to be the senior vice president of Twitter of design or something like that. And then some other random guy from IBM said that, he said it, so I figured I'd just hack on a few other ones as well. And actually I prototyped this joke on Twitter the other day and I figured, you know, 41 likes is not too shabby, so I would just throw it in there. So the power of prototyping right there. So before I get into like actual real prototypes, I want to ask a question. What is a prototype? Depending on your experience or your circumstances, you might define a prototype a certain way. Sometimes it's animation, sometimes interaction, sometimes it tells a story on. So I'm going to queue up some Group participation here and ask, what is a prototype to you? How would you explain a prototype to someone else? Anybody? Prototype. What's a prototype?

A proof of concept that shows the interactions before they're developed.

A proof of concept that shows the interactions before they're developed. Does anybody else have anything, like, completely different? There's no wrong answers here yet. Sketches on a notebook. Last chance anymore. All right, I will move on from the awkward silence. Okay, so I like to get kind of nerdy with words sometimes, and this time is no different. So I looked up the word prototype just to kind of, you know, just to get the real understanding of the actual word. You know, how, like, we designers are always debating on who's a designer and should we code and, like, the deep existential questions of life. So the original or model on which something is based or formed, the original or the model. The other. Another definition is something analogous to another thing of a later period. So some characteristics originally that will apply to something later, and then lastly, to create the prototype or an experimental model. This is obviously the verb prototype. And I feel like this last definition, experimental model, kind of led me down another Webster's Dictionary rabbit hole. And so I was like, well, let me look up experiment and model and see what this means. So we have the word experiments with a crazy pronunciation. Apparently, this is a scientific procedure undertaken to make a discovery, test hypothesis, demonstrate a known fact. So, you know, an experiment. Everybody probably knows that already. Model. I thought this was pretty interesting. A system or thing used as an example to follow or imitate. And I don't know, I feel like experimental model just felt like it had a better definition than the word prototype. There's lots of different things that goes into creating a prototype, and you can obviously make things go crazy, and that's definitely an experiment. But you kind of have to know. You have to know when and why to do an experiment and a prototype instead of just, like, how to do it. And I feel like knowing when and why is equally as important as knowing how to do it. So based on my experiences, like creating all these crazy Flash prototypes and then moving on to some better tooling, even though I still do a lot of stuff in flash, I kind of came up with these. At first, I called these prototype types or types of prototypes, but the more I dug into it, I felt like they were more like phases, like a prototype. So loud word. They have these phases. And so I feel like the first phase is more of, like, a conceptual phase, and I kind of want to throw a disclaimer in Here, like prototypes, they don't have to be only conceptual. And start off this way and then go through this phase. I feel like you can create a prototype and then sometimes it's conceptual, and sometimes depending on who you're talking to, who you're showing the prototype to, it can change phases. So we got persuasive, we got validative. I'm pretty sure I made that word up just because it felt weird to say validation instructional. And then you have the actual thing. I feel like this is kind of where the design systems fall into category, you know, like if you're just throwing together a quick idea with a system systematic design, like Bootstrap, or someone that's created a custom design system, kind of, it feels prototypey and it kind of falls into this category. So I want to talk about each one of these phases and then show some prototypes that I've created that I feel like falls within these categories. And so first off, this conceptual phase, I feel like this is where new ideas are born. This is where things are experimental. You're testing things, you're shaking things up, you're just playing around, you're exploring, finding happy accidents or mistakes, as you saw earlier, and just trying to answer the question, like, what if? What, what if this thing does this? And I feel like if you tell yourself up front you're building a conceptual prototype, it kind of frees you from judgment and you can just like, no, this is just a prototype. I'm just playing around here. You don't have to, you know, come down on me hard about all the flying around and stuff. So you're asking this what if? Question. And so the next couple of slides are just some random one off conceptual prototypes where it's like, I worked with Roadie a couple years ago to help design their apps and the first version of their website. Things look a little different now since I was involved, but this was like. Just like a simple little home screen animation. I think I also may have built this in Flash just because I know Flash from way back in the day. It's just easier for me to bust that stuff out. So this was just kind of like, hey, what if we. Is that my mouse cursor? No, that's Screenshot. This was just something simple, like a small, quick little animation. Like, hey, what if we did this? Some more stuff from Roadie. This was like, hey, what if we had this little animated squirrel crunching numbers while they tried to. I feel like this is more of like the animation prototype. I think when we're talking about Prototype in this sense, I'm thinking like, ok, animation, how are we going to make this one screen? But if I'm thinking that while you're thinking, oh well, the interaction model, there's just like two completely different prototypes. And you could even make the argument that this is not a prototype, I don't know. And then we saw this monstrosity already. I will just let you see that one more time. This was conceptual also, and this is another conceptual prototype that I designed like back in 2013 or 2014. Like this little idea of this label floating above an input field. And it turned out that a lot of people thought that was really cool. And it started kind of being used in Google Material design. And you can see it in like Slack's iPhone app and a lot of different places. So that was kind of an interesting result to a conceptual prototype that I just put it to put together. So I think even though I have made really bad prototypes, I've made sometimes okay prototypes as well. So the second, the second phase of the prototype, am I making that screen shake? It looks like it's kind of like just the screen. So it's like if you're, if you're in the persuasive phase, you're trying to tell a story with your prototype, or you're trying to prove a theory, or you're trying to build trust or convince someone of something. Maybe you're trying to convince a client that it needs to be done a certain way, or you're trying to convince a coworker that it needs to be built a certain way. Or maybe you and the client together are trying to convince investors that they should invest in this product. Because look at our prototype. This is our idea. It's kind of our first proof of concept. And I definitely think that a lot of what I do falls into this category. Whether it's working directly with a developer, trying to persuade the development team that they should spend a little bit more time building this custom thing or showing them something and be like, no, that would take two weeks longer to build it that way. Let's not do that. And so it's kind of like a give and take. I feel like trying to convince someone is always a two way street. So here are a few persuasive prototypes. This is digging deep into the archives. IOS6, I don't even know what year that was, but this is kind of another embarrassing example. We're trying to convince the client that we needed a navigation drawer and that you could go back to the drawer and go to these other areas, which, I mean, it's not too bad, but we felt like it made sense to put this in here. So the third phase, the validative phase, validation, I should probably change that. I feel like this is where you're trying to cover technical feasibility. I'm trying to talk to a developer, just say, hey, can we do this? Is this even possible? Or would you be willing to do this? Trying to visualize things and you're going kind of beyond theoretical and you're, you know, it's like this is getting closer to be what we're working with here. And instead of showing a bunch of boxes with arrows drawn between them, you know, we're actually kind of showing the flow. Everything seems like it makes sense if I'm, if I've ever done wireframes and I've got this like, nice bird's eye view and everything is all right. There's the login and there's an arrow drawn to this screen and then we go there and then there's a decision point and, and you can just kind of see it all. You're like, yeah, that makes a lot of sense. And you show it to other people on a giant PDF and maybe you whiteboard it out and it's like, this is a nice looking flow, but then nobody ever sees it that way. I mean, I do enjoy thinking through things that way and I think it's very, you know, there's an advantage to seeing the bird's eye view of everything and having the holistic picture. But at the end of the day, you're still going to be doing things on one screen. And so I feel like at this point, validation stage, showing the flow and actually going through it, you can get much better feedback than you can just visualizing this never ending long square pointer thing. And then you can also do user testing at this stage if you have workable flow and prototype and you're asking questions about your prototype. So some validative examples here. This was a, this was a desktop app for a cryptocurrency called My Monero. Anyone into cryptocurrency in here? I'm not either, although they did pay me in Bitcoin, which was very interesting. I can tell you how to get that into your bank account if you need to, but this was. So I never really created a traditional prototype and it just kind of depends on the project in terms of like, what I decide to use. Like, sometimes I'll just go straight into sketch. Sometimes I'll use a Word document or a markdown document. Whatever. This one, I'm designing all of this stuff in Illustrator because I wanted to have these, like, I did want to do some of these, like bird's Eye flows. Because this, this was not easy for me to understand. I don't understand cryptocurrency very well and I needed to like really get the whole picture before I started. So I'm just like, this is, these are some, some of the final Illustrator wireframes. I'm like, hey, if you click here, you go to here and if you do this, you can go and do that. Here's a drop down thing. Not really a prototype, but it's to Sean's point, this is kind of a prototype esque, some different things. And then once I went from there, I kind of designed all the stuff in Sketch. Once I had all the low fidelity stuff and the developer's like, yeah, this looks good, we can build this. So I was doing all that before. I worried about the colors and stuff. And then I copied and pasted the Sketch flat files inside of XD because it was quick to make some hotspots and export this quick little. Literally the only thing I was doing right there was trying to find out if the slide up or slide down felt better. Because we were doing somewhat of an unconventional desktop app. We weren't strictly following Mac iOS guidelines. And I wish I could fast forward through some of that, but it was really just. I was chatting with the developer during the whole project and so they're able to sign off on a lot of the interactions before I have to really show them. And so once I get to a certain point, I can just create these little tiny validation prototypes where it's like, oh, it feels good to slide up from the bottom or it looks good sliding down and then I can click this, go to the next thing. It's just like a quick little, like, yeah, that feels good. And it doesn't have to be this crazy big prototype thing. It's just like to prove a quick point, build it in like a few minutes. And then same thing, I exported these sketch files, sketch or jpegs rather whatever they were PNGs into XD drew some little rectangles on them and literally for this tiny prototype, the address flies down. You got this little drop down, like, yeah, that feels pretty good. It just toggling between two different screens. And that was my prototype, that was another small little validation prototype. And I sent the URL to the developer and he was like, yeah, I feel like we can, that'll work. And I feel good about that. Like, it takes you a couple minutes to put that together and you can just move on. You're solving a really specific problem. You have a very specific goal that you're trying to achieve with something like that all feel free to, like, stop me at any point. Sometimes I just keep going. Yes, you mean the. So, like, so we would do a screen share and I would share my screen and I would walk them through and say, like, here's this screen. Here's all the functionality when you click here. Then I'd pan over on my document and show, like, then you would go to this screen. And this is what I'm thinking. And I really needed that because I didn't know what. They knew way more about cryptocurrency than I did. I was just like, just learning about it. And I needed. You really have to have that subject matter expert. It's like your user research at all times, like pulling from someone that knows about it and they say, oh, well, this doesn't make sense because we validate this key on the server and where you have that. I'm like, okay, I'll change that. And so I'm actually like, in Illustrator, like, moving files around while we're talking and making little notes and trying to solidify the functionality before I got too into colors and fonts and gradients and all that. And so I don't do that for every project, but for this one, since it was a little more complex, I wanted to have a really good functional foundation that the CEO felt good about, the head developer felt good about, and that I was like, okay, we're not going to make any crazy changes. It's not going to be like, I'm going to go away for three months and then unveil the curtain on the cryptocurrency app that I didn't even know how it worked. And then once we got to the design phase, everything was pretty much fleshed out minus the last 10%. And then we were just introducing some interactions and stuff like that. But for that project, I was in communication with a developer almost every day, just asking questions nonstop. And, you know, you can come up with ideas too, that they have done a certain thing a certain way. But then you're like, oh, we could shoot anyway, it's just good to collaborate like that. Did that answer your question? Anybody else?

Why did you do the Locality?

Because I really like Illustrator. I was a graphic design major back in like 2003, 4 or 5, and went, we use Illustrator all the time. And I just got really good at Illustrator and I know all the quick keys and I can move stuff around really quickly and it's way easier to draw lines and add stuff and it's like a vector powerhouse and so I really like it. Sometimes I start off in sketch for low fidelity stuff, but if I need some complex user flows and interactions, like trying to draw a line that does this and sketch is like kind of a painful thing to do. So it just depends on the project. Some fellow sketch line drawers over here. Illustrator. Oh, yeah. Okay, so this is another. This is another kind of like validation slash persuasive prototype. There was a company called Siempo that wanted to create a new smartphone, like a minimal smartphone that was like no distractions, like minimal distraction free. And they actually tried to kickstart it, but they tried to raise a lot of money. They did not raise a lot of money. And so they're doing something else. But before they did that, they hired me to come up with some new interactions and I actually built a lot of wire frames in Illustrator and then I did a lot of designs and sketch, but then I built this prototype in Flash. But I feel like this one is way less suckier than my first one. So I'm just going to play this thing. The top part was like a giant input and as you typed, everything was almost like an auto complete field. And as you selected things, the things below it would change. And I could say like, oh, I want to text Jessica. And then I could text Jessica right there. And at any point I could, after I'm interacting with things, I could go and hit the X in the top right to make that go away. But it's really hard to do this without animation. It would be very difficult to do this inside of an InVision prototype, even though they do have things that are interactive. Screen to screen to screen is not going to be very compelling because even when we were doing this, they were thinking about raising money with investors and they just needed something that looked cool, that showed off their product. So, yeah, build this in Flash because I know how to use Flash really well. I did a lot of Flash websites and that's why I still use it. Yes.

So would you say that Flash is still a viable tool for animated prototypes or is there something kind of.

It is for me. They paid me for this and it's actually Adobe Animate now. It just feels weird calling it that. I would not suggest going and learning Flash or Adobe Animate.

Ok, sure. For someone who doesn't have any experience.

Doing animated prototypes, I mean, I Don't know.

Just write it in csm.

I mean, honestly, the reason I like Flash and Animate is because you can take a red ball and create a keyframe and then you move the red ball over here and you create another keyframe and then you say, I want a tween. And then you hit play and it says brr. And you're like, oh, I just animated something. It's very simple. Yeah, so I've done some After Effects animation, but it's just like, it's like Adobe animate times 1000. There's just a lot of stuff going on. A lot of people do amazing stuff in After Effects. I just feel like very overwhelmed every time I open After Effects and I'm like, if you had a choice to learn Flash or After Effects, I would probably do After Effects. Yeah, yeah, do After Effects. It's probably got a better rendering engine anyway. Bless you. One more Flash prototype. This was a. This was called Flow Mode. You could like push a button, a hard button on the side and you would go into this like distraction free, almost like do not disturb in your settings on your iPhone. This was just showing another interaction. This is my debut as a hand model here. And so again, these are prototypes that we were using, they were using to try to persuade investors. And I feel like these were straddling the persuasive phase and the validation phase because their developers were also building like an Android root Android build of this stuff and they're using a lot of these as kind of like some models to build off their interactions. It's a great finger. Yeah. So the fourth phase, instructional, it's pretty self explanatory. This is how it should work. Build it this way. But you got to be careful with this. You don't want to instruct someone, especially if you're not the developer and you hand it to a developer and you're like, hey, build it this way. You don't want to instruct until you're persuaded and you don't want to instruct until you've confirmed with the developers. There's been plenty of times where I've done things that are crazy and it's like, oh, yeah, we're not building that. Because I just had no idea of the constraints of the technology. And so if there's any developers in the room, anyone? Yeah, yeah, everyone's like giggling about it because they're like, oh yeah, I've seen that. So yeah, don't instruct people unless you've already persuaded and you're like, okay, now that we're all in agreeance. This is what should happen. And so I've got just a few examples of instructional prototypes. This was another deep archive iOS 6. This is like the top of an iPad app back in iOS six days. And it's hard to explain, but I wanted these animations to happen. It was like, hey, I made these CSS animations because we were building this with web technology at the time, which is, I don't think is a good idea for native stuff. But I did want to show, like, hey, this is what the blinking light should look like, because there were these different phases of the project. And it was like, hey, I literally wrote all the CSS for you. Please use this css. And so I felt like this was. You could see that there's a CSS bug in the last part, but that was. I feel like that's an instructional prototype. Like, hey, I did all this work for you. You don't even have to dig into the files and pull out instruct someone, especially if you're not the developer and you hand it to a developer and you're like, hey, build it this way. You don't want to instruct until you've persuaded, and you don't want to instruct until you've confirmed with the developers. You know, there's been plenty of times where I've done things that are crazy, and it's like, oh, yeah, we're not building that, because I just had no idea of the constraints of the technology. And so if there's any developers in the room, anyone. Yeah, yeah, everyone's like, giggling about it because they're like, oh, yeah, I've seen that. So, yeah, don't instruct people unless you've, like, you've already persuaded and you're like, okay, now that we're all in agreeance, this is what should happen. And so I've got a few. Just a few examples of instructional prototypes. This was another deep archive iOS 6. This is like the top of an iPad app back in iOS six days. And we have. It's hard to explain, but I wanted these animations to happen. It was like, hey, I made these CSS animations because we were building this with, like, web technology at the time, which is, I don't think is a good idea for native stuff. But I did want to show like, hey, this is what the blinking light should look like because there were these different phases of the project. And it was like, hey, I literally wrote all the CSS for you. Please use this css. And so I Felt like this was. You could see that there's a CSS bug in the last part, but that was. I feel like that's an instructional prototype. Like, hey, I did all this work for you. You don't even have to dig into the files and pull out the. The stuff. You know, write a little bit of CSS. Even wrote some JavaScript for those button functions. And I don't feel comfortable writing much JavaScript, but, you know, Google goes a long way. Here are some. Some great iOS6 slides of this iPad app. I just couldn't resist. This is not part of the prototype, but it was just pretty crazy. It's kind of. Kind of cool, but also not great. This was also another iOS 6 app, and I really just was like, hey, developer, I want the animations to do this. It was hard to explain it. So I just built this in Flash real quick. And I wasn't sure how to do. I didn't want to write a bunch of parallaxic code. So I feel like this is another instructional thing. I know it's possible to do some delays on some animations just based on my limited development skills. So this is another way to have an instructional prototype. Another roadie example, this is another instructional prototype where I was like, it'd be really cool if we had these little animations. You saw the Squirrel animation earlier. This was like a pull to refresh concept where it's like, hey, maybe somebody's delivering a little truck. What if we did it where when you pulled it down, the truck came in? So it's like, it's conceptual. But then once they approved it and I persuaded them with it and it kind of moved through these phases, then they used it as reference to actually build it that way. And I think. I'm not sure, I haven't used roadie in a while, but I think that animation's still in it. And I threw this back in here because this was another instructional prototype back from the Law app. It was like, hey, this is the code that I wrote. You don't have to use this code, but this is kind of how you could build it. So, yeah, instructional prototype, straight up HTML and css. I feel like the last phase is kind of like the thing. It's kind of moved beyond prototype phase. You're actually building it, the actual thing. And so like, with this phase, which may or may not even be defined as a prototype, it could be it's like building quickly something with bootstrap or somebody's design system. You're just throwing together components Maybe you're just firing up your text editor and you're writing some Chrome prototype. Like, hey, I did all this work for you. You don't even have to dig into the files and pull out the stuff. You know, write a little bit of css. Even wrote some good old fashioned HTML and css. You're shipping early, you're iterating, you're launching your bet, building the MVP design systems. They're the hotness. Right now. Everybody's Building Design JavaScript for those button functions. And I don't feel comfortable writing much JavaScript. But Google goes a long way. Here are some great iOS6 slides of this iPad app. I just couldn't resist. This is not part of the prototype, but I feel like design systems are kind of like prototype, because as you build the design systems, you're kind of developing it as you're designing it. And it's just kind of this big hodgepodge of like prototype, slash the thing. And when you're done, it's the thing. So here are a couple examples of the thing in which I've worked on. So this is not a prototype, but it will lead up to it. So I made a ux. It was just pretty crazy. It was kind of, kind of cool. But also online UX course with Illustrator just because I liked using it so much. And I was like, hey, it'd be cool to teach how to use. Not great. This was also another iOS 6 app and I really just was like, hey, developer, I want the animations to do this. It was hard to explain it, you know, so I just built this in Flash real quick and I wasn't sure how to do. I didn't want to write a bunch of parallaxicode. So this was, I feel like this is another instructional thing. This is Illustrator for UX design, especially when it comes to like responsive web design. And I was pretty stubborn about it and decided, hey, I'll also build my own course platform to like host it on. And of course I got to wireframe it, I need to develop it and design it. And so I made a couple of wireframes for the course platform and then I was like, well, I want to write all the front end code for this, so I'm just going to go straight from here. I know it's possible to do some like delays on some animations just based on my limited development skills. So this is another way to have an instructional prototype here, straight to HTML and css and so all this whole screen. Another roadie example. This is another instructional prototype here, which was like, I feel like it's okay. I didn't design anything with a. Where I was like, it'd be really cool if we had these little animations. You saw the Squirrel animation earlier. This was like a pull to refresh concept where it's like, hey, maybe somebody's delivering a little truck with sketch or anything. I just wrote the HTML and the css. I think Sean watched me do a lot of this. So, yeah, it's responsive. It's kind of like a prototype. I wasn't really that happy with it. I felt like it worked. And the developer partner that I had was constantly building stuff, and it was like it was working and I felt like it was more of a prototype. So then I ended up building this, and then I went back to sketch and refined it a little bit. And what if we did it where when you pulled it down, the truck came in? So it's like. It's conceptual. It's conceptual. But then once they approved it and I persuaded them with it and it kind of moved through these phases, then they used it as reference to actually build it that way. And I think, I'm not sure, I haven't used then just kind of redid it a little bit and then recoded it. And so I feel like, because I built the prototype and then I went and designed it, it was easier to go and just like, adjust the theme and make some adjustments to have to turn the prototype roadie in a while, but I think that animation's still in it. And I threw this back in here because this was another instructional prototype back from the end of the thing. And so even though I wasn't dealing with a client or anyone else, it was that process of iterating through the different phases of the prototype. This project I worked on with a company called Skyscanner, who is like a travelocity of sorts from Scotland, although they just sold to a giant Chinese company for like a bajillion dollars, the Law app. It was like, hey, this is. This is the code that I wrote. Like, you don't have to use this code, but this is kind of how you could build it. So, yeah, instructional prototype, straight up, HTML and css. I feel like the last phase is kind of like the thing. It's kind of moved beyond prototype phase. You're actually building it. The giving stock. Negative. Yeah, so I did a lot of, like, mobile design, ton of work for this. This is just like one tiny sliver thing. And so, like, with this phase, which may or may not Even be defined as a prototyper. But they were building everything in angular and I don't know angular but I was tasked with designing this dashboard with these charts and you know, like anytime a designer gets to design some charts, like the temptation is strong to like do these like gradients with like Nike plus stuff and you're like ooh, look at the type. It could be it's like building quickly something with bootstrap or somebody's design system. You're just throwing together components. Maybe you're just firing up your text editor and you're writing some of these long shadows like looking at dribbble and like oh that's so awesome. But I knew that this team had a deadline to launch this project or the two co founders of the old fashioned HTML and css. You're shipping early, you're iterating, you're launching your beta. The smaller app that they acquired weren't going to get vested in their site. They're not going to build custom charts when they're trying to hit this deadline. So I was like, I'll do some research and I found highcharts.com I was like building the MVP design systems, they're the hotness right now. Everybody's building design. So I'll pop these in here and like see what like I'm not going to design these. Like there's code you can just pop right in. And so I built this little HTML prototype with some like, you know, some of their real data and like hey, these charts are responsive. It's not like the best. I feel like design systems are kind of like prototype because as you build the design systems you're kind of developing it as you're designing it and it's just kind of responsive build in the world. But it was just like a quick idea to kind of confirm with the development team like hey, can we use this instead of designing all the stuff like another instructional the thing prototype. This big hodgepodge of like prototype, slash the thing. And when you're done it's you know, it's the thing. So here are a couple examples of the thing in which I've worked on. So this is not a prototype but it will lead up to it. So I made, I made a ux. So yes, that was Skyscanner. Alright. So the last project I want to show is, is a project that I worked on last year and I don't feel like it's that necessary to go through all the different things. But it was a design system that I got the extreme pleasure to work on with Dan Mahl and Brad for online UX course with Illustrator just because I liked using it so much. And I was like, hey, it'd be cool to teach how to use. And Josh Clark. And I'm so excited that Josh somehow convinced the people who's Illustrator for UX design, especially when it comes to like responsive web design. And I was pretty stubborn about it and decided, hey, I'll also build my own course platform to like host it on. And of course I gotta wireframe it. I need to develop it and design it. And so I made a couple of wireframes at ExxonMobil to allow him to talk about it, because now I can put it in here. So I worked with them on a design system for ExxonMobil and it was for the course platform. And then I was like, well, I want to write all the front end code for this, so I'm just going to go straight from here. Completely iterative. The whole time we were designing and then we're writing code and then we're designing and then we're writing code and then we're taking screenshots of that. And there was really no prototype. It was like the prototype was the thing and we just made the thing the whole time. Then when we got done, it was always the thing. So there's just like a little video that goes with it. Actually, I do have audio on this one. Slide. Where's my man at? There you go. Audio. I forgot. Are we good? All right, here, Straight to HTML and css. And so this whole screen here, which was like, I feel like it's okay. I didn't design anything with a. With Sketch or anything. I just wrote the HTML and the css. I think Sean watched me do a lot of this. So yeah, it's responsive. It's kind of like a prototype. I wasn't really that happy with our.

New ExxonMobile design system. That makes building exceptional.

The client did the voiceover faster than ever. That's kind of fun.

Is a set of ready to use UI components and page templates that developers use to quickly assemble interfaces. It's as simple as copying.

I feel like it worked. And the developer partner that I had was constantly building paste to bring these.

Components into a project. By reusing these UI components across projects, developers can create beautiful, intuitive interfaces with less work stuff.

And it was like it was working and I felt like it was more of a prototype. So then I was.

Unity is built on a foundation of modern best practices for user experience.

I ended up building this and then I went back to sketch and refined it a little bit and then just kind of redid it a little bit and then re coded it.

Markup is fully responsive, so it works great on any screen size.

Because I built the prototype and then I went and designed it, it was easier to go and just like Adjust.

Also embraces high standards for accessibility, usability and performance.

The theme and make some adjustments to have to turn the prototype.

Unity was built on ExxonMobil's existing brand guidelines, so apps get the right look and feel right out of the box. Unity styles the basic colors, fonts and icons so developers can focus their energy on real channels challenges. Get started and learn more at Goto Unity. Let's bring unity to ExxonMobil's apps.

There you go. All right. That was Unity. There you go. Figured that would be more interesting into the thing and so even though I wasn't dealing with a client or anyone else, it was that process of iterating through the different phases of the prototype. This project I worked on with a company called skyscanner who is like a travelocity of sorts from Scotland, although they just made talking about a bunch of like, there you go. I would like one Unity, please. Okay. Hard Transition, a prototyping tool sold to a giant Chinese company for like a bajillion dollars. Not actual tool tips, but just like tips for prototyping tools. And we've kind of covered this already, but I've got a slide for it, so we'll go with it. Just use what's available, you know, like if you've got after effects, because you have creative cloud, just use after effects. Use what you're comfortable. Negative. Yeah. So I did a lot of like mobile design, ton of work for this. Just like one tiny sliver with the software. Doesn't really matter. Like as long as you have a specific goal and you are achieving that goal. And like maybe it's to have an animated GIF or. But they were building everything in angular and I don't know angular, but I would gif if you're weird or movie was tasked with designing this dashboard with these charts and you know, like anytime a design or like a movie to put into your deck or something like that and just a little thing to make you feel better. I still build most of my animation prototypes with Flash. So you still feel pretty Designer gets to design some charts. Like the temptation is strong to do these gradients with Nike plus stuff. And you're like, ooh, look at these long shadows. Looking at dribble and like, oh, that's so awesome. But I knew that this team had a deadline to launch this project or the two co founders of this smaller app that they acquired weren't going to get vested in their site. They're not going to build custom charts when they're trying to hit this deadline. So I was like, well, I'll do some research. And I found highcharts.com I was like, I'll pop these in here and like see what like I'm not gonna design these. Like there's code. You can just be good about whatever you're using. Just use what you're good at. It doesn't really matter as long as you're like, unless there's like a very specific thing that a company was like, oh, we use Axure for this and we use, you know, then you might need to like conform to what they're doing and some quick little like prototyping do's and don'ts. I feel like this was kind of necessary. Some of this is repetitive, but I feel like it's worth kind of driving home the points, hop right in. And so I built this little HTML prototype with some like, you know, some of their real data and like, hey, these charts are responsive. It's not like the best responsive build in the world, but it was just like a quick idea to kind of confirm with the development team, like, hey, can we use this? Like instead of designing all the stuff dos, you need to have a very specific goal. You don't want to just create a prototype just for the sake of creating a prototype. Even if you're experimenting, it's like, I just kind of want to play with this thing and I know I'm just experimenting with motion patterns. If your end goal is to find a cool motion pattern, at least then you have an idea of what you're even doing. So you do want to test and explore new ideas, but with a caveat, like another instructional the Thing prototype. So yes, that was Skyscanner. Alright, so the last project I want to show is a project that I worked on last year and I showed you an example of when I was testing a new idea at the very beginning and it was like the crazy thing. So just make sure that you're not going too crazy with it and you know, I'll let that one lie. And you want to, you do want to show specific flows like, and what I mean by that is you don't need a prototype for your entire app and everything's clickable and here's every Drop down. And here you click around, like, every static screen. And I don't feel like it's that necessary to go through, like, all the different things, but it was a design system that I got the extreme pleasure to work on with Dan Mahl and Brad Frost and Josh Clark. And I'm so excited that Josh somehow convinced the people for the entire app is all clickable. I personally feel like that's a waste of time. But if you're going to show a very specific flow, like this is the onboarding flow, click through here, and you can make decisions about a very specific flow. And you might have a giant app with a bunch of different flows, but maybe a prototype for only a few little pieces. And it's just, like, to help make decisions. So I feel like you do want to show specific flows, but not, like, everything at ExxonMobil to allow him to talk about it, because now I can put it in here. So I worked with them on a design system for ExxonMobil, and it was just completely iterative. The whole time we were designing, and then we were writing code, and then we're designing, and then we're writing code, and then we're taking screenshots of that. And there was really no prototype. It was like the prototype was the thing. And we just. And you want to tell us it's helpful to tell a story with real content. I could have made that law firm app with a bunch of Lorem Ipsen, but then it just wouldn't have made sense. And the people they were trying to pitch it to, they wouldn't have known what it even meant. And so just the fact that we picked a guy, his name was Donald Butler, and he got his neck hurt in this accident. Like, we kind of crafted all these details. The names have been changed to protect the innocent. Made the thing the whole time. Then when we got done, it was always the thing. So there's just, like, a little video that goes with it. Actually, I do have audio on this one. Slide. Where's my man at? There you go. Audio. I forgot. Are we good? All right.

Meet Unity, our new Exxon mobile design system that makes building exceptional.

The client did the voiceover, but it was a real story. Like, a real story that you could kind of follow along. And your brain, for whatever reason, can't resist a good story. And you can just. It's easier to follow along on a story. So when you can tell a story with real content, I recommend it. And you do want to work collaboratively with the developers, with the client. You don't want to run away and build a crazy thing without talking to someone about it first. Like the more you can communicate about your ideas and your goals faster than ever. At the top.

Unity is a set of ready to use UI components and page templates that developers use to quickly assemble interfaces. It's as simple as copy and paste.

It's going to work better for everyone. It's kind of the same thing here. Communicate with stakeholders. Make sure you set expectations. For the law app, I had to constantly remind them, like, we're not building the app right now. This is not. Don't even worry about the tab bar at the bottom. Those things might change. Like we're just showing the messages and how this would work. The expectation at the end of this prototype is that we're going to just have a full flow and then we're done and so we're not doing anything else.

And so paste to bring these components into a project. By reusing these UI components across projects, developers can create beautiful, intuitive interfaces with less work. Unity is built on a foundation of modern best practices for user experience. All markup is fully responsive, so it works great on any screen size.

Unity anytime they would ask about the Uber feature or whatever else is like, no, we're just doing this one story. This is the story you need to tell to your investors. And you know, we're just setting a good expectation from the very beginning. Alright, don'ts color change, don't make it unrealistic, don't make features that can't be implemented. And you're not going to know this unless you know how to implement it yourself or unless you talk to someone.

About Also embraces high standards for accessibility, usability and performance. Unity was built on Exxon Mobile's existing brand guidelines, so apps get the right look and feel right out of the box. Unity styles the basic colors, fonts and icons.

Who knows how to implement it? You know your developers are your friends.

So developers can focus their energy on real challenges.

Get started and learn more developers. Talk to your designers, teach them things. Don't charge forward without talking to your developers or developer. I can't say that enough. It's really important. And don't take every piece of feedback as a new requirement for the project. You know, if you've set a specific goal and you get some random feedback, it's not like, oh, now I got to work in this new thing to the project. If you're very intentional about your.

Let'S bring unity to ExxonMobil's apps.

There you Go. All right, that was unity. There you go. Figured that would be like more interesting goal up front and you get it started, then it's going to go better. And definitely, definitely just do not prototype everything. I've seen a lot of people that have like, oh, let me show you this app that we've been working on. We've been designing it for six months. Here's our prototype. And it's like. And then me talking about a bunch of like, there you go. I would like one you to 30 seconds to load the Envision prototype because there's like a million screens in it and then they click and it's the drop down and then you go to this flow and then you go around and it's like, please. Okay. Hard transition to prototyping tool tips. Not actual tool tips, but just like tips for prototyping tools. It's pretty impressive that you spent that much time building a prototype, but it's like, are you going to build. Is there like a. And we've kind of covered this already, but I've got a slide for it, so we'll go with it. Just use what's available version or, you know, and it's just like the prototype became the project and there was not even a developer on board yet. And I feel like that's a pitfall for prototypes. Like, don't prototype everything. And lastly, I want to leave you with a parting words of wisdom from Sir Johnny. I've Johnny, I've Joanie. Johnny. I think it's Johnny. If you are truly innovating, you don't have a prototype you can refer to. There you go. And that's it. If you've got After Effects because you have Creative Cloud, just use After Effects. Use what you're comfortable with. The software doesn't really matter as long as you have a specific goal and you are achieving that goal. And maybe it's to have an animated GIF or happy to answer more questions if anybody has any, or GIF if you're weird or movie or like a movie to put into your deck or something like that. And just a little. I do not. I don't think that it's a bad idea. But I also think that there can be a tendency to design something like without much thought and then like, oh, let's test that, let's see what does that button do better? And like, you haven't even really critically thought about thing to make you feel better. I still build most of my animation prototypes with Flash, so you should still feel pretty good about whatever you're using. Just use what you're good at about the problem yet. And so I'm not opposed to user testing. I think it's really good, but I feel it doesn't really matter as long as you're like, unless there's like a very specific thing that a company was like, oh, we use Axure for this and we use. Then you might need to conform to what they're doing. If you're doing it too quickly. You could just user test your way into not building a product or building something that. And some quick little like prototyping do's and don'ts. I feel like this was kind of like 10 different people told you 10 different things and you're like, oh, let's change this button and move it around. I don't do a lot of that.

When you tell a more interesting story.

Unnecessary. Some of this is repetitive, but I feel like it's worth kind of driving home the points. Yeah, I mean there's definitely some best practices for like forms and things like that. And I mean there are like sometimes it just makes sense like we need that button to go to that screen. I don't really need to test it just yet. Maybe later we'll test red versus blue and see which one the conversion rate is higher. But for forms and things like that, for anything that like requires more complex interaction, like for even that, for that like request quote like thing that flew around do's you need to have a very specific goal. You don't want to just create a prototype just for the sake of creating a prototype. Even if you're experimenting. It's like I just kind of want to play with this thing and I know I'm just experimenting with motion patterns. Like if that, if your end goal is to find a cool motion pattern at least then you have like an idea of like what you're even doing. We had one of the client's friends come in and like click. And they were like, oh my God. And we were like, okay, yeah, this is bad idea. And I mean it's like a double edged user testing for me is like a double edged sword. Like I think it's important but not so important that it should replace like critical design thinking and designing. Yeah. Will your slide deck or a version of it be available? So you do want to like test and explore new ideas, but with a caveat. I showed you an example of when I was testing a new idea at the very beginning and it was like, I will put it online at some point if you follow Me on Twitter. I will. The crazy thing like, so just make sure that you're not going too crazy with it. And, you know, I'll let that one lie. And you want to. You do want to show. I will tweet it out when it's ready. Or you can email me. You can go to my specific flows. And what I mean by that is you don't need a prototype for a website. And dig around and it probably will be the most recent blog post in the not too distant future.

Can you just send me a copy?

Sure. It's actually in Dropbox now. I could just right click and send it to you. Your entire app and everything's clickable. And here's every drop down, and here you click around. It's like every static screen right there for the entire app is all clickable. I personally feel like that's a waste of time.

Even when I try to stay up front.

But if you're going to show a very specific flow, like this is the onboarding flow, Click through here and you can make decisions about a very specific flow. And you might have a giant app with a bunch of different flows, but maybe a prototype for only a few little pieces. And it's just, like. To help make decisions. Yeah. Yeah. So I feel like you do want to show specific flows, but not, like, everything. Yeah, I think that it's just. I feel like it's a tricky, like, personal skill kind of thing. It's like a soft skill where you're like. And you want to tell us it's helpful to tell a story with real content. I could have made that law firm app with a bunch of Lorem Ipsen, but then it just wouldn't have made sense. And the people they were trying to pitch it to, they wouldn't have known what it even meant. And so just the fact that we picked a guy up front, you have to be very clear. And for one, I wouldn't typically put Span. His name was Donald Butler, and he got his neck hurt in this accident. We kind of crafted all these details. If it wasn't supposed to be Spanish or Greek or whatever it is, because little things like that can derail a whole meeting. And no one likes to go long in meetings. So if you do set expectations and you're like, if you're the one presenting it and if you designed it, I feel like you need to be the one presenting it. You're like, the names have been changed to protect the innocent. Okay, this is this type of wireframe. We're not talking about Colors. We're not talking about font sizes, we're not talking about pictures. Not that we can't, you know, hear suggestions about that, but primarily. But we. It was a real story, like, a real story that you could kind of follow along, and your brain, for whatever reason, can't resist a good story. And you can just. It's easier to follow along on a story. So when you can tell a story with real content, I recommend it. And you do want to work collaboratively with. I just want feedback on functionality and make sure this is doing the job that it needs to do. And so if you can just set very clear expectations and even make a joke about, you know, we don't want the meeting to run long because we just want to get the functionality nailed down, then later we can all talk about fonts, the developers with the client, you don't want to run away and build a crazy thing. And so when that happens, and it always happens, you know something without talking to someone about it first. Like, the more you can communicate about your ideas and your goals, sometimes you just have to be rude and say, all right, I think we need to move on to really nailing down the functionality. And a lot of times it's just natural for people to go off on a tangent and someone just. If you've already kind of established yourself as the person leading the meeting, then you can just be like, all right, I think we need to bring it back in here. Sorry, I don't want to be rude, but we need to nail this out before we can move on. And so just kind of have to practice. It's going to work better for everyone. It's kind of the same thing here. Communicate with stakeholders, make sure you set expectations. For the Law app, I had to constantly remind them, like, we're not building the app right now. This is not. Don't even worry about the tab bar at the bottom. Reining it in, somebody else right there, those things might change. Like, we're just showing the messages and how this would work. The expectation at the end of this prototype is, yes, I saved you from the long, boring history lesson about my background, but I'll gladly give it now so that you've pried it out of me. Yeah, so I was a graphic design major at the University of Georgia, graduated into that. We're going to just have a full flow and then we're done. And so we're not doing anything else. And so anytime they would ask about the Uber feature or whatever else is like, no, we're just doing this One story five and quickly after that I was actually doing a lot of this is the story you need to sell to your investors. And you know, we're just setting a good expectation from the very beginning. Illustration like charcoal drawings and paintings and I thought I was going to go that route. Got a job at a place doing all right. Don'ts color change a lot of websites and flash was like really big in 2004 and 2005. It was like pre iPhone. I don't remember what year the iPhone came out. Maybe 2007 ish. And so I was doing just tons of flash websites. And don't make it unrealistic, don't make features that can't be implemented. And you're not going to know this unless you know how to implement it yourself or unless you talk to someone about that's how I learned all of my horribly awesome animation skills. And just doing tons of animation, tons of web stuff and all of that was all self taught. I learned how to program action scripts from reading forums and I knew that before I even knew how to write HTML. Who knows how to implement it. Your developers are your friends, which is way easier. And then slowly started contracting with agents developers. Talk to your designers, teach them things. Don't choose in Atlanta. Like I did some more with Razorfish and Sapien and Macquarie. Charge forward without talking to your developers or developer. I can't say that enough. It's really important. And don't take every piece of feedback as a new requirement for the project. You know if you've set a specific goal and you get some RAM and engage and there's probably some other ones that I'm not remembering. But when I got into that arena of work I realized like, oh, there's people like really thoughtfully thinking about websites. It's not just like let me slap this animation on here. It was like there's a presentation and here's item feedback. It's not like oh, now I got to work in this new thing to the project. If you're very intentional about very thoughtful wireframes and all of the IA's at the time the information architects were modeling all the data and I was like wow, this is like people are doing this like really perfect goal up front and you get it started then it's going to go better. And definitely, definitely just do not prototype everything. I've seen a lot of people that have like oh, let me show you. Actually I didn't even know this world existed. I thought everybody was just kind of throwing out websites, FTP uploads All right, Website. Like that was my. And I was like, wow, this is serious. This app that we've been working on, we've been designing it for six months. Here's our prototype. And it's like. And so I learned a lot about. During that time. IA became the 30 seconds to load the InVision prototype because there's like a million screens in it and then they click. And this lesser acronym of. And then the UX acronym emerged. So all the IA designers were now UX designers. And so I just kind of soaked in what everyone was doing around the drop down and then you go to this flow and then you go around and it's like that I was the graphic designer or the visual designer at the time and I was designing a lot of stuff on top of wireframes. And then finally I started getting some interest from other clients who saw some more work. Pretty impressive that you spent that much time building a prototype. But it's like, are you going to build. Is there like a Merc? And I was like, I could probably, I could design wireframes. Like I've been doing this for a long time, mobile version or you know, and it's just like the prototype became the project and there was not even a developer on board yet. And I feel like that's a pitfall for prototypes. Like don't prototype everything. Fire up Illustrator. I'll just start designing wireframes in Illustrator. And that's what I did. And I started doing more client work and less contracting work and then more client work and then less contracting work. And lastly, I want to leave you with a parting words of wisdom from. Started learning more about code. And so most primarily was just, I mean in terms of UX and ui, it was all self taught beyond like graphic design school. Yeah. Anybody else, sir? Joni? I've. Johnny, I've. Joanie. Johnny. I think it's Johnny. If you are truly innovating, you don't have a prototype you can refer to. There you go. And that's it. Should I pull up the awkward silence screen again? Oh. Oh. Happy to answer more questions if anybody has any. I haven't done any workshops but I would like to start doing some. My studio mates and I just got a really cool new space in Athens. It's like really suited for stuff like that. We got these big tables and I do not, I don't. So if you're interested, if anybody's interested in stuff like that, send me an email or something and it'd be fun to put something together. And not have to drive to Atlanta. I don't think that it's a bad idea, but I also think that there can be a tendency to design something like I kind of want to learn React without much thought and then like, oh, let's test that, let's see what does that button do better? And like you haven't even really critically thought about. But I'm kind of scared of all the packages that I have to like install and stuff. Yeah, I don't know what that is.

It's just the layer.

Like I kind of want to get into React or React Native. And there was a time when I wanted to learn Objective C and Swift just to build like native apps. So I feel like I can put together a quick web prototype but I can't do a mobile like native mobile app. But like as I get about the problem yet. And so I'm not opposed to user testing. I think it's really good. But I feel like if you're doing it too quickly, you could just user test your way into not building a product or building something that like 10 different people told you 10 different things and you're like, oh, let's change this button and move it around. So I don't do a lot of that. More and more design work and stuff. Like it's, I'm always struggling between should I learn that or should I not? So, so it always changes. I am pretty much a one man show except for my wife who also does all my bookkeeping and stuff, which is a godsend. But apart from me there's no one else on the team unless the project, unless they specifically say like, oh, we'd love for you to build this too. And then sometimes I'll do it and lots of times it's just too much for me to handle that and the development. Yeah, I mean there's definitely some best practices for like forms and things like that. And I mean there are like sometimes it just makes sense like we need that button to go to that screen. I don't really need to test it just yet. Maybe later we'll test red versus blue and see which ones commit. So I'll subcontract out people to kind of like build a little super team for that. Preferred rate is higher but for forms and things like that, for anything that requires more complexity for that project. So yeah, just kind of on a project basis and a lot of times interaction like for even that, for that request quote thing that flew around with the clients have developers willing and able ready to build something they Just want somebody to bring in a lot more strategy and revitalize their interface and the flows and all that stuff. So I'll do a big pass at everything and work with their team to get it built.

How useful is it for developers to learn about design and practice design?

We had one of the client's friends come in and click and they were like, oh my God. And we were like, okay, yeah, this is a bad idea. And I mean I have. It's like a double. I mean it can't hurt definitely. Like, you know, like user testing for me is like a double edged sword. Like I think it's important but not so important that it should replace like critical design thinking and designing. Yeah, it's all like very contextual. It depends on what kind of development you're doing. You know, it's like if you're writing Ruby all day long and you're building back end data modeling, it's like, I mean, will your slide deck or a version of it be available? Just use bootstrap or something and somebody else will come and ride a better front end. But if you're doing like front end development, I feel like if you're laying out responsive screens and you're riding mobile first, like and the layout needs to be good, I will put it online at some point. If you follow me on Twitter, I will, I will tweet it out when it's ready or you can email me, you can go to my. It's hard to do that as a developer who doesn't know design, even if you're following a design exactly. And like, ok, I need to make this thing do this. Even if my website and dig around it probably will be the most recent blog post in the not too distant future.

Can you just send me a copy?

Sure. It's actually in Dropbox now. I could just right click and send it to you. I've designed like three different breakpoints in static sketch files and I know what needs to happen. I still feel like 10 to 20% of the design happens in tweaking CSS percentages and like, oh, this looks better as 0.875 rem instead of 0.75 rem and like, let me change it and I'll tweak for a day or two to get it like looking really tight. And I don't know how I would be able to do that if I didn't have some type of design skill that I could apply right there.

On the topic of managing expectations like the product owners and product managers that I work with, they'll get confused between.

The prototype versus apply to the situation. So if you're doing that type of work I feel like it's very helpful. And in fact some of the best front end developers I know in terms of just layout were once designer. Yeah. Or they started in design and then switched to development. But if you're riding other as you get more towards the back end of the app becomes less of a importance. I think that's my opinion.

Mine's in Spanish.

Yeah. My kids, my two youngest kids usually wake up at 6am and I can hear them through the monitor.

How do you like bring in those conversations and kind of bring it back on the phone?

Yeah, I think that it's just, I feel like it's a tricky like personal skill kind of thing. It's like a soft skill where you're like usually overslept. My 5am alarm. Coffee's brewing in the kitchen. I don't know how much detail you want. No, I'm just kidding. No. Like I go into work usually after I take my kids to school. I'll either work from home or work from the house, depending on how quickly I need to get to work. And I keep a pretty regular schedule though I've got a wife and four kids up front. You have to be very clear. And for one, I wouldn't typically put Spanish if it wasn't supposed to be Spanish or Greek or whatever it is because little things like that. And I try to be home at 5:30 on the dot if I can, just so my wife I can derail a whole meeting. And no one likes to go long in meetings. So if you do set expectations and you're like, if you're the one presenting it and if you designed it, I feel like you need to be the one presenting it. You're like, oh, it doesn't go insane. She stays at home with them, has a much harder job than I do and I just try to work a regular day and when I need to I will bust out work at night. But as much as I can, I try to keep good hours and I don't do a lot of work at night like I used to. And if I need to cram, I'll usually try to wake up in the morning and do it. So. Oh, over here, let's go to this side. Okay. This is, this is this type of wireframe. We're not talking about colors, we're not talking about font sizes, we're not talking about pictures. Not that we can't hear suggestions about that. But primarily I just want feedback on functionality, make sure this is doing the job that it needs to do. And so if you can just set very clear expectations and even make a joke about, you know, we don't want the meeting to run long because we just want to get the functionality nailed down, then later we can all talk about fonts.

How do you start a session?

Do you kind of go through, like, blueprint design or do you kind of just free falling? Hey, you know when you were. When you were explaining the.

Lawyer app, is it something that you kind of organize and you kind of did post.

These and was like, hey, you know.

This needs to be organized this way, or do you kind of just, hey, look, how do we. How do we.

Yeah, so it's. It's definitely different for every project. So I feel like every. And so when that happens, and it always happens, you know, you sometimes you just have to be rude and say, all right, I think we need to move on to, like, you know, really nailing down the functionality and project is, like, at a different point. So for the lawyer app, for example, like, I had a conversation with their developer partner, and then I had a conversation on the phone with him, and they kind of explained it to me. Then we had a meeting. I drove down to Augusta and met with them, and we probably hung out for two or three hours. And they were. That's when they were trying to hand me all their sketches and like, yeah, let's do this thing. They didn't really know what they wanted. A lot of times it's just natural for people to go off on a tangent and someone just. If you've already kind of established yourself as the person leading the meeting, then you can just be like, all right, I think we need to bring it back in here. Sorry, I don't want to be rude, but we need to, like, nail this out before we can move on. And so just kind of have to practice. But they did know that they wanted to present, like, a prototype to some potential partners or investors. And so I was like, we just need to tell a compelling story to convince someone, like, this is what the app could do. And so we did start to get bogged down and like, well, maybe the progress bar could be like this. And, well, the Domino's Pizza tracker thing does this and we should. I'm like, guys, come on, we don't need to talk about that right now. Let's talk about what you're going to tell. And so I literally. It was kind of like we wasted time for, like, an hour. Just reining it in. Somebody else right there. Yes. I saved you from the long, like boring history lesson about my back talking about all that stuff. And then I was like, I'm going to fire up my Word document and we're going to. And it's not a word doc, but I'll gladly give it now so that you've pried it out of me. I don't use Microsoft Word, but I put in just, you know, here's this guy's name. What do you do when they come in? And I just forced them to tell me all the stuff I said, all right, now that I have this information. So I was a graphic design major at the University of Georgia, graduated in tuition. I was like, do you guys agree that it would be good to have screens that tell this story from beginning to end? And they're like, yeah, that'd be great. And so what I did was I just took it back to my office and I did sketch out like individual screens and took pictures of my horrible, you know, five. And quickly after that I was actually doing a lot of whiteboard drawings and was like, I'm thinking about putting these screens here, these screens here. And I sent them, you know, like a Dropbox link to those photos of the whiteboard. I was like, what do you think about these? Like, it's not really pretty. I just want to see what your gut reaction is to these screens in this order. And they're like, yeah, that feels, feels right. Illustration. Like charcoal drawings and paintings. And I thought I was going to go that route. Got a job at a place doing a lot of websites and Flash was like really big in 2004 and 2005. I was like, I'll know more when I see it. But that was kind of how I started. And then I just spattered out pre iPhone. I don't remember what year the iPhone came out. Maybe 2007 ish. A bunch of like, you know, 40 different sketch artboards all in a row and built it. And so I was doing just tons of Flash websites and got feedback from them. They, you know, they were able to put their comments on each InVision page and that was pretty helpful. I don't do that a lot, but that was pretty good for that. And that's kind of how that project went. You mean like timing?

Yeah.

Obviously. That's how I learned all of my horribly awesome animation skills and just doing tons of animation, tons of web stuff. And all of that was all self taught. I learned how to program action scripts from reading forums And I knew that before I even knew how to write HT pens. I feel like that lawyer app I worked on ML, which is way easier. And then slowly started contracting with agencies in Atlanta. Like I did some work with Razorfish and Sapien and Macquarie. Like maybe a week. But mostly I like to spend at least a month or two on projects like 4, 8, 12 weeks. I like to think in terms of months. It's easier to sustain yourself if you're billing monthly than hourly or weekly or whatever, which is a whole new topic.

Do you still have time or do you still practice? Like the traditional illustration too?

I drew and engage and there's probably some other ones that I'm not remembering. But when I got into that arena of work, I realized like, oh, there's people like really thoughtfully thinking about websites. It's not just like, let me slap this animation on here. It was like there's a presentation and here's like Kakashi from Naruto. I drew that the other day for my son. I've got a picture of it on my phone. I'll show it to you. That's like the only thing I've drawn in years though. I mean I try to sit down and draw with my kids and stuff. I would love to like I'll do some sketches here and there with the kids. But you know, I just. The very thoughtful wireframes and all of the IA's at the time, the information architects were modeling all the data and I was like, wow, this is like people are doing this. Like really. Priorities are. That's way down right now. But I would like to. I didn't even know this world existed. I thought everybody was just kind of throwing out websites, FTP uploads. All right. Website like that was my. And I was like, wow, this is serious. Yes. Ronald Arnholm. He's still there. He's still there. I taught a class at UGA last semester. Yeah. And I saw him and was like, I cannot believe he's still here. Like he was. He was old when I was in school. And so I learned a lot about. During that time, IA became the like, you know, 12 years ago, but he's still kicking. Great type designer. Lesser acronym of. And then the UX acronym emerged. So all the IA designers were now UX designers. And so I just kind of soaked in what everyone was doing around me.

All right, I think that's a good spot to end. We're 8 o'.

Clock.

So Matt, thanks for coming out everybody.

Thank you very.

Much.

I was the graphic designer or the visual designer at the time. And I was designing a lot of stuff on top of wireframes. And then finally I started getting some interest from other clients who saw some more work and I was like, I could design wireframes. I've been doing this for a long time. Just fire up Illustrator. I'll just start designing wireframes in Illustrator. And that's what I did. And I started doing more client work and less contracting work and then more client work and then less contracting work and started learning more about code. And so most primarily was just, I mean, in terms of UX and ui, it was all self taught. Beyond like graphic design school. Yeah. Anybody else?