 All right, thank you guys for coming. My name is Jonathan, and I'm going to talk today about working better together or mixing Lean UX in with Agile Development and User-Centered Design. Last time I was in Chicago to do Rails stuff was 2006. I got right there, a little less scruffy, but somebody pointed out last night that this looks like it's the crew for Obi-Wan Courtney's band hanging out. So I come from an architecture background of the building variety, and a lot of these stuff I'm going to show you today comes from a couple different places. One is from my freelance work over the last 15 years, which is meticulous. A lot of this stuff is from the almost three years I spent at Living Social, heading up the internal UI for all of our internal apps. And then recently I've been doing work at a new startup called CargoSense with Rich Kilmer and Bruce Williams. I also wrote this book, it's a little out of date, but there's some good stuff in it, and Pragprog has a 40% off ticket right now if you guys are interested in any Rails or Ruby eBooks. So, experience matters. Experience is really anything that you as a user are going to see when you're working with a tool, a book, anything. I mean, go back to 1983, these were our two main experiences that we had. So it's changed a lot since then, but it's still something that you can think of. There's a very big difference in how I'm going to work with these two different platforms. Experience is also something you see in everyday life. The one on the left just not working as well as the two on the right. You're going to turn it upside down, what's going on? Think about this too. You ever go to an ATM and you just cannot get the sun angle right and you can't see the screen? That's a bad experience. Or doors. The handle would imply pull. Horizontal bar kind of implies push. But here you have to put a label on it. Now you can apply this to a lot of things that you've probably worked on where it's so unintelligible that it has to be overly labeled and overly documented because the experience is not clear. And this is always a fun one. You know, it's... But why do exterior doors go out? Well, Chicago, Illinois, in fact. Iroquois Theater. 1903, 600 people died in a fire because they tried to get out of the building. The doors opened in and they crammed up against the doors and couldn't get out. We're gonna talk about that here in a little bit, but that's something to think about why those doors work that way. Why is that experience that way? So when we talk about UX, what is UX? We're gonna define that real quick. It was created in the early 1980s, usability broadly, to refer to what was a number of vague and subjective attributes of a product and its user-friendly characteristics is what they call them. And this marked the beginning of a shift from a phase that we're focused on the features and to a term that was becoming more concerned with the various facets of how people worked with those features. So the International Standard Organization, ISO, this is ISO 9241, is that usability is the effectiveness, efficiency, and satisfaction with which specified users achieve specified goals in particular environments. Pretty dry, pretty generic. Jacob Nielsen gives us a nice little five-point thing. You can love or hate Jacob Nielsen, but he is kind of one of the big human factors guys of software development. So he says that it is the promptness which with users learning something, the efficiency that they attain making use of it, how easy it is for them to remember how to use it, how error-prone that is, and then the level of satisfaction they attain from using the system. And so it comes back to a lot of these things are applied because they're the experience of many years and many mistakes. So going back to the Iroquois Theater Fire, architectural building codes changed a lot in the early 1900s. They actually started to come into, really started to be happening between the San Francisco earthquake and events like this. You really started to see them say, you know, we should say that you legally have to build a building this way. So now you'll notice any commercial building. The exterior door will open out or it will break away. So you'll notice on revolving doors that you can actually kind of break away. Like if you cram into a revolving door, those doors will give with enough force. So that's, you know, over time, we've learned these things. We've applied them and they make the experience better and safer for everybody. So let's get into looking at design specifically around software. So there's various processes and methods and I want to kind of compare and contrast some stuff for you real quick. The first is waterfall, which I'm sure most of you have heard or experienced at some point. Large deliverable documents, excessive documentation, but this comes from projects and engineering like of traditional engineering and architecture where the design is finished and approved before you start building it. And this is something from a project management tool, like Microsoft Project or something like that. It's called a Gantt chart. The red is the critical path. Things that have to happen in a certain order and have to be finished before the next step can be completed. Now any delay in there can really mess up the whole timeline of a project. And this is what typical waterfall processes look like. You define the problem, you come up with a design that solves that problem, then you build that design, you test that and you deploy it. And this is usually the entire enchilada. We are not even gonna go into like, this is, you shrink this down really small and it is kind of in a way agile, but we're gonna not even bother talking to engineers, we're gonna go spend six months writing up requirements. Then the design guys are gonna go for three months and work up all these designs and have a 300 page document that they turn over to engineering, but then builds that. So that's just one of these little things here and that can take a long time and while you're doing this work, the business and the world is changing. So the likelihood of you building the wrong thing and being two years behind the power curve in this process is high. And it all comes down to this was all about deliverables. So as if I was running a design agency, I wanna maximize the deliverables because that's maximizing the amount of time I'm gonna be spending working on building this stuff for people. Wireframe's big, you'll see these documents where they have the whole screen laid out and everything is specified by pixel and instead they could have just made a prototype and had been testing it already instead of having to say, this is 21 pixel Vardana. Just put it in CSS, build it, go. You'll hear people fight against it, they're not waterfall and the developers will say, but hey, we're agile. Well, the developers may be agile, but each silo is still throwing things over the wall or over the transom as some people will call it. So within product, they're kind of turning on their stuff and then they go talk to design and they have a handoff and then design works on their stuff in an iterative fashion, but they're not iterating together. So this is still waterfall. Product talks to customers and the developers don't get to talk to customers. When you start having all those separations, you know you've got a problem. So instead of relying on this mythical design hero to come in and say, here is the solution that will solve all your ills, we're gonna start talking about the misappropriated but adequately named Lean UX. So it's really about design facilitation as opposed to here is my beautiful design that you will build. So when we talk about Lean UX, it's really a three-part process. It involves design thinking, it involves agile and in the traditional agile manifesto mentality and it pulls heavily on the Lean startup book from a couple years back. So design thinking came out of Ideo, which is a big product ideation. I hate that word, but it's what they do. They come up, they create products and the CEO came up with that and it's innovating based on direct observation about what people want and need. So instead of going in and actually thinking and saying what if, what if, they actually go and start talking to real people and finding out what they want, finding out what they need and then coming up with solutions that fit those problems. And they use sensibilities and methods to match these needs with something that's actually a viable market product. Part two of that is agile. Melissa Perry posted this a couple days ago. She's a big UX person and I think this is probably when every manager says agile what every developer thinks is going to happen and it's the, that was your training. And pretty much whenever I hear some managers say this and it's obvious they don't really know what they're talking about, I kind of just feel like this and it's just, no, we're not gonna do that. So agile manifesto, you should be, everyone pretty familiar with this or at least have heard about it before? This is from 2001 and it really talks about these four principles and it's really in response to the software development of the time and how things were being built. But I think it really applies a lot more to kind of orienturing and I'm talking about map reading and land navigation when I talk about orienturing. So the good old Boy Scout method with sitting there and trying to figure out how you're gonna get from point A to point B. So in orienturing, the first thing you need to do is find out where you are. Then you shoot an azimuth and choose your target and you say, this is the angle I'm gonna go to get there and there's a target that I'm going to walk to. You move to that target and you repeat and you keep doing this. And it's not just about getting yourself from point A to point B but it's about leading a group of people all in the same direction and sometimes doing complex things. So when you talk about agile, Dave Thomas sums it up this way. You find out where you are, you take a small step towards your goal, you adjust your understanding based on what you learned and you repeat. Which also comes down to the lean startup mentality of build, measure, learn. And you're gonna repeat that process. So it's not the measure in the sense of which of these 40 blue shades is the right button but measure in the bigger sense of is this, when we have a design idea, we're gonna try and solve this problem. Does this actually solve the problem or not? And we're gonna measure the efficacy with which it solves that problem. So this is kind of the UX process inside lean and this can really be applied to the whole thing because it's not that design is separate from development. Everybody's working together, everybody's involved. So instead of having your designer go off and come up with something, designers, developers, product people are all working together through these steps. So we're gonna come up with a concept, we're gonna do a really quick prototype, just get the idea enough that we can work with it and show somebody. We're gonna validate it and then we're gonna learn from that and we're gonna repeat the process. So the formal definition of Lean UX here is from the Lean UX book and it's trying to bring the true nature of a product to light faster. And there's a couple of tools that really exist in this space to help us with that. One of them is personas. So you can have personas that are kind of formal like on the left or really kind of laid back like on the right. And this is really along the lines of BDD. So if you're doing as a user the system admin will give him a name, give her a name, go ahead and make that a person, pin them up on the wall, talk about them like a real person. It really takes it out of this theoretical, well here's a QA admin that's doing blah blah blah give them a name, a personality and it lets you care about them in a different way than this theoretical person. You can also have a little more like formal documents. These were things that we wrote up when we did customer support. We've rebuilt their system at Living Social. So we didn't draw up something but we came up with kind of like here's the points that we wanna talk about and you know it's the name, what's the name of the person? Like a title. Cause there's a lot of in bigger companies a lot of titles start to really define roles effectively. The duties, the goals, the fears, the aspirations. What are their computer skills? It really matters. Cause if you're dealing with experts you're gonna build a different system than if you're dealing with the computer novice. Means of communication. How do they like to talk? Do they use IM? Are they on email? Would they rather pick up the phone and call you? Again, it's gonna affect the way you design the system. And instead of sitting there and making big documents you break out paper or you break out the whiteboard. This is a flow diagram for a project I was working on at home and took me 10 minutes to sketch it out and kind of figure out the flows of what I wanted to do. This was for reviewing creative materials. This is something we did for email. We were handling multi-city emails at Living Social. That is the design. We took that, we went right to code. You do a lot of sketching. I prefer to use architectural trace paper. It's 12 inch roll, 50 yards long. You can lay it over another sheet very easily like you see here. That's one sheet laid over another. So I can get elements that are repeating very quickly. If I want a modal, I just draw the modal and then boom, there you go. You can talk about it. So then I can pin these up on the wall or we can sit there on the table and just talk about what's going on. And it's not, I don't like this font. I really don't like that green or is this gonna be this big? No, it's a sketch. And you can hand the pen to the person. Everybody can scribble. Ryan Singer, I think, has a lot of great examples of where they even do copy and it's little just lines. There's no formality to it. This is a block of copy. This is a headline and it's a squiggle. And that's great because you don't feel like, oh, I need to be an artist. So applying these things, I've done this a couple different ways and we didn't know what we were doing. One of these things that we did a lot with the InfoEther days is that we did working in parallel. So our first client meeting would go something like this. We'd all be in the room together with the client and I'd be sitting there working on flows while somebody like Rich or Chad were actually pulling out domain objects. And actually teaching the customer, you can say model. We actually wouldn't sit there and try and make up a new language for them. We teach them what a model was. We teach them what the domain meant and we'd actually get them into our headspace. And so we'd come out and build and we'd have usability and functionality. They already were committing to the Git repo and we had a bunch of sketches either on a whiteboard or on paper about how that flow was gonna work. Sometimes we even had diagrams of page layout. So it's really about sketching and building simultaneously. These are some charrettes I did for the State Decoded which is a Knight Foundation Operating Government project. These little things on the left are an inch square. I was trying to come up with some early ideas of how the main landing page would lay out. And so just, there's very little detail there. It's like maybe copy here, maybe headline here, here's a feature image, here's some other images. And I like the third one I did so then I developed that a little better but you can see it's literally squiggles. There is nothing there of copy outside of the name. And then that goes, and I took that into Photoshop to get something a little more formal because I didn't have any brand built around to get any kind of vibe. And so we took that and did this and then this went to build. Now while this was happening, while the JakeWidth who's now running in the Open Data Institute was building this code in PHP with no idea of how my front end was gonna look and we married him up later but we knew the functionality. We had agreed upon how things were gonna work. And so sometimes this comes down to prototyping and looking at things from a big picture level. And a couple of things you can do. If you don't know your end users, one good way to learn really fast is to do what's called a mental model. Indy Young is a UX person. She was at Adaptive Path for a long time and now she's out consulting. And it's really about identifying, like this would be somebody's morning mental model. Prototypical morning. Excuse me. So it's drawn organizing factor to figure out what the users are doing before you type any code or before you even draw on a design mockup. And it's a visualization of your research data. So if you know what's going on, you don't need this but if you have no idea what's going on and you really don't know your users or you're on a system that's been around for a while and people are complaining that it doesn't solve their needs anymore, this is a great exercise to find out what those needs are. You can also do stuff with just kind of big picture ideas. When I first started doing the design at Living Social for our internal tools, they kind of said just come up with, combine all these things together, go talk to people, come up with kind of like an ideal world. And so I put together about six mockups that were about at this level and I took them and we presented them to Aaron Battalion who was the CTO. And engineering was already moving towards, we had already started breaking up our monolithic app at the time and they were moving towards a service-based architecture. So we kind of had an idea of what we were doing but we hadn't really finalized it yet. And Aaron Battalion just looked at me very seriously and said you do realize that's 18 months of work like what I had put in those six screens. And so yeah, but what was great about this is we had an idea of what could happen. So then we were able to talk about that, pull things out, break things apart and things evolved from this. And over time we started working on different projects solving different problems like this was our scheduler prototype that we built. And you start putting these in front of people. So we went down to our actual people that were scheduling deals and we did usability testing. Now usability testing is hard because you often can end up in this situation where you're trying to be all chipper about it and the person's just like this is awful, this is horrible. It's great, I love it, yeah, that's wonderful. So we started recording things with Silverback. And with Silverback, what you do is you end up getting a screen like this. And so this is one of our live tests we did with Jeanne O'Reilly, who was one of our senior scheduling people. And basically instead of all of engineering that was working on this project, sitting around her or making her feel uncomfortable, we had one person talking through some stuff with her. Just getting first impressions, how would you do this? Very leading questions, you want the door wide open. But you basically get all her clicks and you can see how often she's doing select all and things like that. But it's really interesting to see how somebody starts interacting with something they haven't seen before. And this records her video down in the bottom from just the camera on the Mac and you also get audio. So we could then sit there and review these. Each one was a 20, 30 minute session working through various questions. And we took those back and then iterated on things. Sometimes you're working in such a big problem that you have to kind of do the rewrite. So this was our customer support tool that we rebuilt. It was originally Salesforce. They were working in Salesforce. This is backed by Salesforce, but this is a backbone project on top of a Rails app. And it's super complex and it's two screens. So they have two 19 inch monitors. This is the left and this is the right. Now, all these things that we were doing, we had done so much shadowing. We knew all these pain points, all these things they hated, but building all this again, this is one of those took a year to kind of get to this point. So what we started doing is that we went in and fixed the pain points when we could. Instead of waiting to build that perfect screen, we went on the production system and fixed that one little interaction that was driving them nuts. And then we'd go and do the next one and go and do the next one at the same time of what we're building. And so this is really comes down to kind of a better way of doing things is almost what I call just in time. So you start with a big picture design process. Then you apply that design. You codify it into a living style guide. So this is a code style guide, not a print document. And your revise as you go. So with a just in time kind of project, you know, UX joins at some point. It may be the very beginning, it may not be. And you know, you're starting there. You just kind of get your legs, get a feel for where you are. And you do an really intense design push at the beginning. You do a big spike. You get your overall design stuff happening. You get your design language established. And you are right in on tickets. And so some of that stuff we did, we built a living social for our internal apps, something called Wild. If any of you saw Ed Wang's lightning talk before lunch, he was talking about the system they used for the customer facing side. This is all the internal tools stuff. So we built this as a Ruby gem that people could pull down and install. And it immediately gave them all of this kit of parts to build apps with. So instead of having to worry about do I put this here, do I put that there, they immediately had kind of a framework for an interface to build their applications. It also had built-in documentation. So all of this stuff they could go in and find out how to use these different things. We took parts of Bootstrap, we took parts of Compass and Bourbon, and we kind of brought all this together into a big SCSS framework with our own design elements. So some of these like this is very much a derivative of the Bootstrap styles for alerts. As well as some of the buttons. We would change up and make, we did some different things with buttons, but a lot of the stuff is very derivative because we were taking things and saying we like these pieces, but we don't want the whole enchilada. And as you're going, new design elements come up. So about a year after we first built Wild, we built this timeline element for our sales staff. And this is actually a UI built on top of Salesforce, believe it or not. This is completely backed by Salesforce. But this timeline element, we were able to extract out the CSS and HTML and make it available for people building other apps. So now if somebody in another app wanted a timeline, they could pull this code in and they didn't have to go and reinvent it. This also helps because users who are used to one style, if they switch to another app, it's not a whole different world. It's not a whole new interaction paradigm. I've done a lot of consulting and so a lot of these clients are these kind of long running projects. I've worked on one banking client, for example, since 2008, on their internal tools. And what happens is we've done a lot of these kind of big picture design things with them, but it always comes down to little interactions. So instead of sitting there and saying, let's go rebuild our document manager, we say we're just gonna sketch what documents look like. Here's two states of a document, now we're gonna build that. And so this is the kind of deliverable that they get. It takes me five to 10 minutes. I sketch it out, I send it over, they build it, I come back in and style it. And this helps when you have that living style guide, we break everything up into SCSS files and we do a big import and merge it all together. So we now have all these components. So things that are used everywhere become components, things that are one-offs get placed in areas. And then you have variables and you have a whole bunch of stuff. So some of this stuff, again, is derivative from Bootstrap. Some of this derivative from Compass. We've kind of shifted now to being reliant upon Compass because we realized we were including 95% of it. So we stopped kind of chicken and egg and just said we'll take the whole thing. My current situation is CargoSense. And I'm working with Rich Kilmer and Bruce Williams and I call this the mad dash. This is, CargoSense is a logistics company. We're taking off-the-shelf node variable tech sensors which are Bluetooth 4 and we've got an iPad app written in Ruby Motion and then we have a web application. So we use the data in logistics shipping to detect takeoff and landing with pressure changes and we use data to figure out temperature excursions. So pharmaceutical needs to keep insulin within this temperature range and then we can tell if it's been out for five minutes we raise an alert, things of that nature. So this is the story of a shipment. This is the timeline again. So it's some of these design elements you created 10 years ago. You're gonna be like, yeah, I did this. So we can reuse that kind of concept. But it's these simple four parts again. Big picture design, we came up with an overall brand look and feel. We started applying it and we codified it into a living style guide. In this case it's called Kevlar, not Wild and we revised as we go. Most of our things, this is a Bauer package instead of a Ruby gem because we're working in Angular but it supports, I mean you could use it to support anything. And a lot of these things, these are designs that, these are relatively high fidelity sketches. These go over to Bruce or Rich and they comment on them and then if we need to for marketing purposes or things before we have built that we're gonna go for sales purposes, I'll do these kind of mock-ups. So a lot of this stuff is coming down to really fast and really just kind of see to your pants, pulling stuff off. But when you have a small team, you can do that. And a lot of these design elements, like some of these things like the right hand side or the header, we're definitely, you know, Bruce at three in the morning saying I'm making an executive decision. This is what it's gonna be. Now Bruce happens to be a very talented designer as well as a full stack developer. So that definitely helps the situation. But you can do a lot of these things where there's not this formal what we're following lean UX. It's just kind of, we're kind of using these principles to make a better process. So what are the issues with all this? One of the issues is called design drift. Design drift is something that happens over time with any kind of creative endeavor. You start off, this is one of our early designs we did at the top and then here's the customer support tool at the bottom. So we started off with a fixed width with margins, you know, tall header and we started realizing that people were maximizing their screens and having huge wide columns and we were not effectively using the space allotted. So we went to pushing everything out to the side and filling the whole thing up. And we really shrunk the header down super small and we collapsed a lot of things away. These are expert users. We can do training. We don't have to have them understand it right out of the gate. Another problem you're gonna hit is if you're working with a traditional UX or design team and they're used to having design deliverables and throwing things over the wall to you, you're gonna have frustration. Ladders.com when they rolled out this, the head showed up to this on his desk. His designers had had a meeting and wrote down what they were pissed off about and this is it. And it's too many projects, devs making bad design decisions, no time to actually come up with concepts and ideas and when we do, nobody builds them. We come up with a great experience and then you don't build it or it never ships. All these things are problems that I've heard and sometimes I've said. And so some of the solutions are really like, celebrate releases. Like if you do a release on Friday, get the designers involved, get them to push. Get them to go hit the enter key, do whatever, have balloons, whatever you wanna do. It works for your team and make time to dream. I know this sounds really fluffy and whatever but really have time to go and be able to spit ball and say what if and what happens when I say this or what happens when a user does this or wouldn't it be cool if the whole system was purple instead of red, whatever. Kind of figure that out. Another issue is if your project management office or your product people aren't on board, it will fail. It will fail hard, it will fail in glorious fashion because it's difficult to see in the dark and what ends up happening is that PMO is thinking we're agile so we have to work in sprints and we're gonna do scrum and they get so focused on this process that they've created. So we're gonna build this complex thing but we're just gonna wing it or I want you to focus so I'm only gonna tell you what we're working on on this sprint and then the biggest lie in software development. We're not gonna tackle that until phase two and you end up with this. So you don't know where you're going. You end up wandering all over the place. It's like 40 years in the desert and instead of saying, hey, we're gonna try and go to this point and we might kind of do this on the way but that's where we're trying to get to. They just say, no, no, we're just gonna make these few steps here. Without any big vision, it's really hard to get everybody rowing in the same direction. Another problem is forgetting the users. We said user-centered design. So how do you deal with your users and how do you bring them in? And lots of times when you first shadow somebody working on a system, you go ahead and you have that moment where Kerry Owls in the Princess Bride says, dear God, what is that thing? And it ends up being you have to watch out for that great rewrite because you're like, I can rebuild this whole system. The design's gonna be amazing and it's 18 months of work. So what we talked about earlier, this is the modification of the just-in-time project. So we do existing system fixes at the same time that we're doing big design fixes on the new system that we're gonna roll out to replace or things that are gonna roll out in time. We go in and just make code fixes real-time. Just pair up, sit down, you got a developer and the designer and you sit down and you say that's ugly and the designer's literally typing in CSS and changing stuff and the developer's doing support on Ruby methods or things of that nature that need to change in order to make something work better. Here's a good example of that. We took, this was a screen out of our admin system, the right hand part and it originally was a very complex system for turning on or off somebody's email subscriptions and we stole some CSS from somewhere that basically made it look like an IE, like this little check box, little toggle and this was a mock-up but we took that little piece, built that in code and deployed it into production and it was like, oh my gosh, it's great. We understand, we can see it visually, what's happening now. So this is something that's important that you need to involve subject matter experts. If you have these users, you need to go find them. If they're in your office, you just need to go sit next to them. What is the problem? Why are you upset? What's your pain point? What makes your life miserable? And if it's something where you're doing, like living social, we had customers outside and inside so we would go to customer support, say what are your top 10 complaints that you're receiving? What's the stuff you spend all the time on? Is it people can't find information? Are they having a hard time with their credit card? What's going on? Take that back to engineering, here's some quick wins and people would go ahead and knock those things out. Another thing to talk about is user testing is hard and all of these systems, the one thing I've always failed with is that it's really hard to formalize user testing and make it part of your process. So often I'll end up with this great thing that we've run and then we go and do a user test after two months. Ideally, you're doing a very small user test every week. One, two people, not much. And the easiest way to do this is to go gorilla. And you can do this anywhere. You can do this at a Starbucks. You can get somebody that you're sitting there. If you're working on something and it's like, hey, I wonder about this interaction. Hey, what do you think about this? And leading questions, again. What are your leading questions? What would you do here? How would you do that? Multiple devices you always hit issues with. Responsive design, right? You have to plan time for this because now it's not just an iPhone. These are just the Samsung Galaxy sizes. Do you even have all of these? And this is 10 pixels here, 10 pixels there, really can start to break designs. So you've got to determine your break points. You have to make this part of your process. You have to say, okay, we're gonna handle responsive and we've built this feature and now we're gonna take two weeks and make sure it works on these devices. And you can emulate a lot of this in Chrome now, which is great, but you still got a plan for it. It just doesn't happen. So what should we do? How do we take all these problems and these issues? And this is kind of my charge to you here. First, you need to gear up and it's pretty simple. Raid the office supply stash and that's about it. Get a whiteboard, get a table. You got your phone in your pocket. This is all you really need. Stop using Agile. Start thinking about agility. Dave Thomas has a great, great article here that he just posted about a couple weeks ago. Agile is so abused and so buzzwordy now that you say it and managers who don't understand better are like, oh, that means we don't have to worry about documentation. Great, no, no, no, that's not, we're gonna work in an Agile fashion. Oh, no, no, no, no. You gotta just say Agility. Stop using Agile, just drop it from your vocabulary. Measure everything. If you don't even know what you're gonna measure, just put Google Analytics on it and turn all the switches on. Just get data in there because you're gonna go back and say what were people clicking on? What were the paths they were taking through the system? And especially if you're doing e-commerce, you can start seeing checking, like figure out your checkout flow and document that because then you can go through and say, hey, we get 30% abandonment on this step. Let's go back and look at that. What's going on? Love your users. Often I know we get frustrated because we're like, they just don't get it, blah, blah, blah, oh my God. My parents can't even do this. What's wrong with them? And it's really about, we're trying to serve them. We're trying to make their lives better with the tools we build. So in doing that, we wanna secure quick wins. Whenever you can secure a quick win, you can build something fast. If you can do it at night, you go home and you've got 10 minutes and it's something you know you can ship, do it, ship it. Get it out the door. No more silos. Get rid of design as a team. Get rid of engineering as a team. Everybody's on build. Project managers, everybody is on one team. And if you have a product, get that and get a micro team. And it's made up of all these people. Sometimes these roles are not clearly defined. Sometimes an engineer is also your product and your project manager. I argue often that everybody should be QA, but sometimes you need a formal QA person who's really an expert at doing Selenium or something like that and can drive those automated tests. But design, front end engineers, everybody's sitting together, working together, even if you're remote collaborating every single day. Developers are not excluded from design meetings. Designers are part of retrospectives. Pull requests workflow. Bruce and I do this at Cargo Sense. We start off empty pull requests to discuss big ideas and you start pushing against that pull request with that branch. And then if it's good, we pull it in. If it's bad, we leave it out. Reusable design solutions. If you've got something that you're generating, if you can reuse it, do so. Developers, learn UX. It's not scary. It's not this like I have to use Photoshop. Go read some books on usability. Defensive Design for the Web by 37 Signals is over 10 years old and every single word of it is still very applicable. Most of Jacob Nielsen's stuff. It's not rocket surgery. I think Steve Krug is a great author. Just go read some of these books. You build things that work. You should know why they work, how they work and how they work efficiently. Likewise, go get your designers to learn how to code. If your designer doesn't understand HTML and CSS at least, how can they possibly design for that medium? It's like a print designer not understanding what happens when the ink hits the paper. It would not happen. Designers, they don't have to do the code. They need to understand the code though. And forgive. And Patchett has a book called The Getaway Car. It's a practical memoir about writing, which is funny. I didn't realize David was gonna do this whole thing on writing when I pulled this. My wife sent me this quote that Andrew Sullivan pulled out, but the real short of it is, I'm just gonna read this real quick. Stop here for a few breaths and think about this because it's the key to making art and very possibly the key to finding any semblance of happiness in life. Every time I have to set out to translate the book or story or hopelessly long essay that exists in such brilliant detail on the big screen of my limbic system onto a piece of paper, I grieve for my own lack of talent and intelligence every single time. Where I smarter, more gifted, I could pin down a closer facsimile of the wonders I see. I believe that more than anything else, the grief of constantly having to face down our own inadequacies is what keeps people from being writers. Forgiveness, therefore, is key. I can't write the book I want to write, but I can and will write the book I am capable of writing again and again throughout the course of my life I will forgive myself. This doesn't just apply to you, this applies to your coworkers. This applies to your interactions with everybody. So build the app you can build today. Because you can sit there and say this process is too hard, this is too complex, we'll never get this done. Just gotta start from somewhere. And so please try and climb the mountain. I know it's not easy, but you'll eventually get there and it will be a better world for it. Thank you very much and appreciate it.