 I'm Louisa. I'm on Twitter at WCB, so I have to use mountain pictures everywhere I can. So I'm a developer and a designer at HotCodeWorks, and we're a small consultancy based out of Longmont, Colorado. And I'm a chapter leader for Girl Develop at Boulder. And then before we get started, I just want to really quickly run through how I've set up my slides. So as you may know, we are in Texas right now. And Texas has some famous cows. And cows need cowboys. And cowboys ride horses. And horses are a lot like ponies. And I drew a lot of ponies from my slide deck. So now that that's taken care of, we can go ahead and get started and talk about design. So unlike the popular perception of what design means, it's actually much bigger than the elements to come together to form what we typically associate with visual design. So like typography, color palettes, and layout. I think designers often get a bad rap for being overly sentimental about these things. And even though they may have a slightly unhealthy fixation on letter forms, these elements really are just details of what a designer's job is and don't encompass the full breadth of what design is actually all about. So at its core, design requires the ability to take a set of restrictions framing a problem and find the best solution within those limitations to maximize impact, usability, and engagement with users. So design is all about people, and it's about how the things those people need actually work. So has anyone here ever built something that was super cool, but then turned out to be pretty challenging for the people that you shared it with to use? Like, I know I have. I have. It's happened. And maybe your app was so challenging to use that those people just didn't use it, and they just didn't understand something that, from your perspective, made perfect sense. And that's a pretty frustrating experience, right? Like, it's not fun to have something you've put a lot of effort into not really be appreciated or understood. But there's a silver lining to going through that. Because it is actually a great thing to have experienced. So going through the process of seeing firsthand what happens when someone doesn't understand or relate to your thought process, and then by association doesn't understand your product, means that you've taken the first step and welcome to design. So it's a glorious place where you get to build cool stuff by figuring out how to make things that are relevant and useful to other humans. So clearly the code that you write is important when you're building software, but design is just as critical a component. And this is because products that offer unique and effective solutions to human problems that are also intuitive for users to understand and relate to really set themselves apart from the crowd of competitors. So how many times have you heard something along the lines of like, it's like Twitter for cats, or it's Uber for dog walking. And this is because coming up with original ideas is really hard. And it's easier not to, and instead just use established successful products like Twitter and Uber as a starting point and then just tweak them enough to make them yours. And this isn't always a bad approach, but what it means is that if you can come up with something that's unexpected and better than those established models of solving users problems, that it's going to really get people's attention. And creative design solutions are a major deciding factor in the choices that lead to those novel approaches. So, since design and creative thinking is something that can be a big part of what sets you and your work apart from the crowd, how many of you consider yourself to be creative? Okay, awesome. Now, how many of you think of yourselves as designers? A few. Okay, that's good. A few. So, I really want to help everyone in this room feel like they have the ability to be creative and then also to participate in the design process and to feel like they can make positive design contributions to their teams and their projects. And so, on that note, I think it's a good time for a story. So, I went through one of Jeff Casimir's early developer training programs before he started touring school of software and design. And I have this very distinct memory of him telling our class that we were not allowed to use Bootstrap to build out the front ends of our projects, that we'd be presenting at our demo nights because Bootstrap would, in his words, make it too easy to win. And he told us this like a day or something right before the demo and it was followed by this sort of giant collective groan throughout the class because we really hadn't been learning about front end and Bootstrap would be like a time and sort of sanity saving resource that we could use to make things look okay while we were just focusing on getting our projects to actually work and then getting them successfully deployed on time. And then just like that, he just was taking it away from us because it made it too easy to win. So, chew on that for a second. Like, we'd spent months writing and studying Ruby and now we were building these Greenfield Rails apps in very short timelines and showing them to people who could very well turn into our employers. And what of all things is Jeff worried about teams using to their unfair advantage? A tool that gives you just a little bit of help with very basic visual design. So we were building complex back end systems and that was what we really wanted to show off, right? Like, why would getting some outside help polishing the user facing part of the app be such an issue? Like, he was justifiably worried that teams would use a clean looking user facing product to compensate for crummy back end code. And he was worried that teams that only got the minimum project requirements completed would sway the crowd with a slick looking front end while teams who went above and beyond with the back end but had a less usable front end wouldn't get the attention from the community that they really deserved. So I really love this story because it emphasizes something that developers and I think especially devs who spend the majority of their time writing code that isn't user facing can really too easily overlook. And it's that users don't care how you built your product. They only care if it works and their first impression of it really counts for a lot. So you know the saying, don't judge a book by its cover, your user is going to ignore that. If your product looks good, they're more likely to trust it. And they really don't care about the code that's actually powering it. So before these angry ponies run me out of San Antonio with pitchforks and fire saying the code doesn't matter. Let me just clarify it real quick. So obviously the technology stack that you use is a very important part of the success of your product. Like I'm not disputing that and I think we're really lucky to be working in this industry where the sky's the limit when it comes to what you can make. And we're surrounded by and getting to build cool technology 24-7. But this saturation of connection is a double edged sword because living and working at a time when technology is constantly making these very fast, very big leaps forward means that our users have really high expectations and developers are constantly chasing the next best tool for the job. And as a culture, we are totally immersed in digital things all day, every day. So the tech itself is not novel for users anymore. It has just turned into another part of how they navigate through their lives. So technology has become so ubiquitous in our daily lives that it's taken for granted unless the user's experience with it is so exceptional that they can't help but notice it. So basically what this means is that you all have done your jobs so well that nobody notices anymore. So digital tools are everywhere and they're used for everything. And we really ask users to put a huge amount of trust in our products, which means that we're asking them to put a huge amount of trust in us. And we're asking them to give us their email addresses, their home addresses, their social security numbers, and their bank account information. And I mean, that's asking for a lot, right? And they should expect a lot from us in return. So users expect and they quite frankly deserve to have digital products that are tailored to work for them and that they feel good about using. And again, they don't care how you built it. What they do care about is that it does what they need it to do. They care that it solves a problem for them. They care that the value it offers makes using it worth their time and worth their money. And they care how it makes them feel. Like, do they feel dumb when they're trying to use it? Do they feel frustrated? Are they able to easily do all the things they needed to do and wanted to do without any trouble? So this all boils down to the fact that prioritizing design, creative solutions, and the needs of your user and your software approach to software is a lot bigger than just making things pretty. It's a business decision that can have a very real impact on your bottom line because it determines whether or not people actually use your product. So think back to Jeff's restrictions on Bootstrap and our student project for demo night. Because good design focuses and delivers on something that your user needs. And that does make it easier to win. And when building software is your business, that's exactly what you want. So the key takeaways here are that your users have high expectations. You really need to understand your user's needs. Technology changes all the time and the ability to generate new ideas will never lose value. So knowing how to leverage design as a tool to understand your users and shape your product has huge benefits for developers. But I've had a lot of conversations with devs who say that they can't do design or that they aren't creative. And so I expect this is a combination of not really liking crafty things or feeling like design would take valuable time away from writing code and that design is just simply not their job. But this attitude always kind of gives me pause because design is really interesting and developers are some of the most creative people that I know. And as developers, you have a great advantage when it comes to learning about design because you come to the table with a really deep understanding of the complex technical piece of the puzzle. So it's very worth the effort it takes to gain a deeper understanding of the human side of the equation because it will lead you to this powerful combination of technical knowledge and creative thinking, which in turn provides you with the power to generate amazing ideas and amazing products. And amazing ideas and amazing products lead to happy users and successful organizations. So I love design. I'm a designer. I'm also a developer, but I'm a designer first. And a big part of why I love it so much is the depth of thinking and the process that goes into a design project. So the larger idea behind why and how something came to be, like whether it's a product for business or a piece of artwork, is just really interesting to me. And in my personal design philosophy, I've considered this bigger picture ideation to be concept focused thinking or CDD, concept driven design, meaning that the implementation and details are growing outwards from a core concept that's based on the needs of your user and this drives the approach to your solutions. So it can be that the idea, so this can be that the idea that a digital product needs to bring families together away from a computer or that a company wants to branch out from a core product and needs help figuring out what this new market or product should be or because I did exhibit design for museums for a long time, how signage in a physical space can maximize visitor engagement at museums. So it really can be any scenario, but the lineage of this final product can always be traced back to that core concept. So another story time. So this way of thinking came from my undergrad experience. I actually went to an art school and in the freshman year program, everyone went through this foundations program that exposed every student to the full range of techniques and materials and processes that were used in all the different departments. So you're doing sculpture and painting and drawing and that sort of thing. And by going through this foundation program, you really got a solid starting point for the rest of your educational career and your actual career. And so this curriculum means that you aren't going to be restricted in your work because of a lack of skills, but more importantly, it means that it's taught you how to think about problems. And this program assumes that no one is mastered how to think creatively, so it starts at square one and it teaches every student how to do that. At the start of my foundation year, my studio professors kept telling me that my work wasn't deep enough and not conceptual enough. Very arty critiques of things. But then they really struggled to clarify what that actually meant so I could fix it. And that kind of drove me crazy. And I wasn't really doing badly, but there was this sort of indescribable and intangible issue that was preventing me from doing the quality of work that I expected of myself. And it was really frustrating that it couldn't translate this feedback into something I could use. And then at the end of that year, I took a short workshop with a professor who broke this idea of conceptual thinking into steps that I could understand and actually apply. And then suddenly, all of those prior conversations clicked into place and I understood what they meant. And it took some practice before I was consistently able to work concept first, but it was a major turning point because I understood how to push my ideas further to do better work. So it was this teacher who took the time to break down what concept is and then teach it to our students who gave me the tools to absorb and utilize what other professors had been telling me without clarification for the rest of the year. So fast forward quite a few years and to my current company, where my official job title is developer, but our recent project needs have given me the chance to spend some time on design work. And I was a designer for a long time before I stepped away from it in 2013 to focus on rating code. So it's been really a lot of fun to dive back into it and find new resources and inspiration. So during this period of investigation and research at work, I started reading about a design methodology that not only supports my own design approach and experience, but expertly expands it into a repeatable human-centered technique to help people outside of traditionally creative careers like art and design leverage the power of human-centered design in their work and their organizations. So it shows you how to get to the concept consistently. This approach is not necessarily a brand new idea, but it's very relevant, useful and powerful. And it's basically doing what my college professor did to me. It teaches you a way to think and approach human-focused problems through real actionable steps that allow you to break down problems and take full advantage of your inner creativity to arrive at unique, successful solutions. So it basically just gives you the tools to fast-track the design learning process that I went through in my foundation year program and through the applied practice of design thinking. Slide pony, I'm so glad that you asked. Let's talk about what design thinking is. So the sort of broad 10,000 foot view is that design thinking is about driving innovation through focusing on human needs. It's a repeatable formula for identifying problems and creating user-focused solutions that's been championed by and refined by IDEO and the Haso Platner Institute of Design at Stanford, which is also known as the D-School. So using this approach trains you to think differently about how you tackle problems faced by your user through gathering critical feedback and being open-minded about trying novel approaches through gathering feedback, prototyping, and then being open-minded about trying novel approaches you ultimately are able to produce the best product for your user. So this application of an approach to design helps sift through the idea static to expose the highly creative innovator in everyone. So one of design thinking's base constructs is building what David Kelly, the founder of the D-School and IDEO, refers to as creative confidence in people who may not view themselves as creative in the traditional sense. So these are the folks who say, I'm not an artist, I can't draw, I'm not a designer. Like those kinds of things. Like basically the kind of statements I've heard a lot of developers say. So this process actually helps its practitioners change the way they view themselves and the way that they view their creative capabilities. So this mindset shift around how you view your own abilities is a really important milestone in the process of learning to embrace design thinking and it's an idea backed by the work on self-efficacy by Albert Bandura, a Stanford psychologist. So I say he's a Stanford psychologist but he could probably be more described as like the Stanford psychologist. He's one of the most respected and well-known modern psychologists and he's probably the most famous living psychologist and he's been awarded like 16 honorary degrees and his research around human agency and social cognition is really groundbreaking and important. So self-efficacy as described by Bandura is the belief in one's capabilities to organize and execute the courses of action required to manage prospective situations. So basically it's all about your perceptions of yourself and that you see yourself as someone who is capable of something and in this case that's something is the ability to be creative. So it's similar to the school of thought that success is not dictated by raw intelligence but rather by a student's grittiness or the possession of a growth mindset so which is the belief that if something is hard it's still learnable through effort and hard work or rather than a fixed mindset which is thinking that if something is hard it's just unlearnable and you can't do it. So design thinking and creative and developing creative confidence is about approaching problems with the belief that there is at least one solution and probably more and that you are capable of finding it. So rather than letting setbacks derail you you are using them as evidence to, or rather than letting setbacks derail you and using them as evidence to back a claim of non-creativity, you see them as a learning opportunity and a chance to help you fine tune your work and ideas. So I've heard people on both sides of the creative and technical fence use exactly the same reasons to explain why they aren't suited to do the work that the other side is doing and I really don't buy it and I don't think that you have to either. Embracing design thinking and taking your user into consideration will not only help give you skills that make you a stronger asset to any team you work with but it will help you make consistently smarter business decisions and reduce risk because you'll have a deeper understanding of the what and why behind your product. So without this understanding you really have no way to know if your product is actually relevant to the market and the people you want to be using it. So the key takeaways here are building creative confidence is important, design is fun and so can you and it's a huge value add to your skill set as a developer. So IDO and the D-School have over many years of practicing this methodology developed a formulaic design thinking strategy to help you leverage these approaches in your work and the good news is that these techniques and these steps will probably feel pretty familiar to what you do in your development work. So like do you pair program every day or sometimes, sometimes pair programming? Do you submit pull requests and then participate in code reviews? Yeah, do you use TDD and then work through a red-green refactor cycle? Hopefully, maybe not depending on how your day's going. So it turns out that these are all strategies that with a little bit of adjustment can be applied to the user-facing side of your product to help you better understand the people who you want to use it and then what their needs are and ultimately how to focus your product and what it does. So the D-School outlines these following steps as key process states to work through. So these are empathy, define, ideate, prototype and test. So let's dig in to each one of these. So the definition of empathy is the ability to understand and share the feelings of another. And this is a central element in human-centered design because it allows you to understand your design challenge through the eyes of the people you actually want to be using it. And why is this important? Because you aren't solving this problem for yourself. Just because something is good for you and makes sense to you doesn't mean that it's good and makes sense to other people. It's back to that problem when you build something that's super cool but doesn't make sense to anyone and they don't want to use it. So how do you do this? How do you accomplish this level of empathy? So step one, through observation. You can get really great information from the insights you gain from simply paying close attention to what people do. So we generally tend to filter things based on our own experiences and preferences. So it's really critical to see that from someone else's eyes, like through someone else's eyes in the point of view. Second step, by engaging with people. Yes, you're gonna have to talk to some humans. It's terrible, right? Oh no. So directly engaging with people reveals a lot about what they think and what their values are. So if you're listening and paying attention to details and watching what they do compared to what they actually, watching what they say compared to what they actually do, you'll really understand their beliefs and world view a lot more clearly. And then just watch and listen. So ask someone to show you how they do something. Have them go through the steps and then talk you through why they're doing what they're doing and let that process guide you in asking better questions. So define, after we've gone through the empathy stage, we're gonna define things. So define means to state or describe exactly the nature, scope, or meaning of. So in this context, that means that this state is gonna bring clarity and focus to the information collected in the empathy phase and focus on the design problem and what form it will take. So this is your chance to really shape the challenge you're tackling based on your findings about the user and the context of the problem that they're facing. So ultimately, it's about making sense of all the information that you've gathered. So you're taking all these unrelated parts and putting them together. So why would you do this? So it's giving you time to take your scattered insights and then combine them into a more focused thought and direction and then this lets you find your point of view which is the explicit expression of the problem that you want to address. And then the more focused your point of view is the greater quantity and quality of solutions that you can generate in the next phases. Which brings us to ideation. So this is when you really concentrate on idea generation. You're combining your understanding of the problem and the people that you're designing for with your imagination and at this stage it's really all about pushing for the widest possible range of ideas and not just finding a single best solution. So you're looking for a broadness rather than depth of solutions. So don't worry about getting it right at this point because the user feedback that you get in later stages will help dictate what the best solution is. So why would you do this? So it really helps you step beyond obvious solutions and it pushes you outside of your comfort zone. If you happen to be working in a group going through these processes it helps harness all the strength and input of your team and lets your ideas build on one another. And it helps you find unexpected areas of exploration and it helps you get the obvious solutions out of your head and then let you push beyond them sooner than later. So now we get to prototyping. This is the fun part. I think this is the fun part. So prototyping is the iterative generation of ideas to get you closer to the final solution. So especially with the early, especially early in this phase you really wanna create quick, simple prototypes and just get feedback early and often. And these sort of lo-fi examples will tend to get better feedback because people don't worry that you are going to have your feelings hurt or that you're overly committed to a certain direction. So they're not gonna worry about throwing the wrench in the works so they're gonna give you better input. So at this stage it really should be clear that nobody's overly attached to a specific idea and that it's wide open for input. And this means that you're gonna get better feedback. And I think one way that the D-School describes it is that it's building to think. So you're working your ideas out in a physical way and you're just trying to get them out in the open. So why would you do this? Because it starts conversations. It allows you to fail quickly and cheaply so you're able to figure out if something isn't gonna work sooner than later so you're not investing a bunch of time and money in it. And it really allows you to test all the possibilities. And it also helps you manage the process of building your solution so you can just clarify and guide yourself better. And the really great thing about this step is to start. You just start building things and you don't have to spend too much time on one prototype and you can just focus on getting your ideas out of your head and turn them into something you can get input on. And then testing, and this is where you are actually getting your prototype into people's hands. So we aim to be open-minded that this could be an unsuccessful solution when you show it to somebody. And don't just test how your solution is succeeding and keep asking why and then be willing to pivot and potentially even scrap the current idea for a better one. Really take the opportunity to refine your solution and make it better. And a good rule of thumb is to prototype like you know that you're right, so with great confidence and then test as if you know you're wrong. So you're really making the user prove to you that this is the right solution. And remember that this is the opportunity to get feedback on your ideas and the assumptions you've made about what the problem was and how to solve it. And then you might have to do it again. Don't be afraid to go back through the process again and to refine your ideas and make them stronger. And that might seem like a lot. And maybe it's too much talking to humans. And maybe you already do too much at work. And that's okay. And it may sound like a lot or just seem too far outside of your normal workflow, but let's go back and look through these steps from a more familiar angle because they're actually guiding you through a process that's very similar to what you do as developers and you can incorporate them in your workflow. So let's think about the parallels between this user-focused process and then the TDD cycle that you work through. So with empathy. So before we write any of our working code, we want to write a test. And to do that effectively, you have to have an understanding of what you actually want your code to do and what its place in your app is and then what the implications of adding the code to your code base will be. And so you're finding the right question to ask about what you want your code to do and then you're finding the right way to ask them at this stage. Define. So now that you have a solid understanding of what you want your test to cover, you might write some pseudo code to help you lock in what you want your test to do and then test. And then you're going to write your test so that it frames the questions that the questions and needs that you established previously. And for ideating, we're actually gonna be writing our working code and we're letting the test guide us. So you're going through the letting all the error messages tell you what to write next. And then for prototyping, we're gonna refactor, make it better and make it cleaner, make it more reusable and keep getting it back to green. So you're getting a nicer cleaner solution. And then testing in this phase would be about submitting a pull request, having your team doing a code review and then possibly going back and doing additional refactoring. And then once it's been approved, merge it into master and then deploy. Grab the next story, do it again. And then just in case you're still thinking that this is a load of hooey and your skills are fine as is or you don't have space in your schedule to learn about how to think like a designer, I just wanna add this. So I've gone through this mindset shift not once but twice. So initially I learned to think creatively and conceptually and then years later I learned to program and think like a developer. So basically I decided thinking I couldn't do things for whatever reason was a horrible excuse that was actually poo. And now I'm a designer and a developer and I do a lot of work with organizations that teach people to code. And how I view myself and how I view my ability to learn has totally changed. So there are no more unpassable obstacles and no more pooey excuses. And if I can do that, you can do it too. So thank you.