 Thanks. So I hope everybody had a good lunch. I'll try to keep you awake from your food coma. I wanted to talk today about the work that I've done at Carbon 5 to mix lean user experience. And when I say that, I mean design thinking and lean startup with agile development. So a bit about myself. I'm a tech lead at Carbon 5, which is a bit of a weird title, but essentially what that means is I'm a developer. But I'm a developer that works closely with the client and with their designers to ensure that we're building a product with a process that's going to be effective and efficient. We don't really have project managers or product managers at Carbon 5. We really like everyone to be contributing in some way to the product. So I'll go a little bit more into that later, but everyone on the team is really engaged for the duration of the projects that we do. I've been doing this since like 99, which honestly isn't a ton of time, but it's enough time to have seen things change so fast. So the pace of technology today is just moving at astounding speed. You know, we don't do traditional software application anymore. We aren't doing six month cycles, everything. Are the traditional applications we used to create for personal computing? We just don't do that anymore. Everything's in the cloud and the web is ubiquitous. We take it everywhere we go. It's mobile and it's incredibly social as well. So we're not just connecting pages to one another in HTML. We're connecting people and we're connecting experiences. So something that I see happening now is that we're not just doing software development. We're creating products and we're creating the companies that surround those products. We're crafting experiences and we're having to understand the services that are going to support those experiences. So this is very different from what we used to do, where you'd have all these people working effectively in silos from one another and kind of tossing things over the wall to each other to implement. We're understanding now that because of the way and the pace that things are moving, we have to efficiently work differently. So these silos are breaking down. And what you're seeing is that in today's world, designers are oftentimes getting way more interested in development because it's way more accessible, right? They can start to develop in browsers and they can see what that looks like and they can have more confidence to do it. And then you're also seeing developers that are getting more keen on what user interfaces can do because it's just interesting. The technology in browsers now is just really deep and it does so much. And then you see product managers also that want to be able to span those gaps. So these silos are really quickly breaking down and they're breaking down because of the emergent technology. So the browsers that we see a lot of our applications created for are expanding rapidly. So you've got just for like Chrome and Firefox, there's 1,500 people working on each one of those. And over the course of their lives, that's about 2,000 years worth of development. It's more than that. So you can imagine it's things that are getting released in these browsers, the type of capabilities that you can harness in your applications every single month, every single day that's changing. So the open-source software projects is one of the coolest parts about my job. This idea that people are committing code really every single second of every day to places like GitHub. And you can harness that and you can also contribute it. So it's this total community of people that are standing on each other's shoulders to create better and better technology moving forward. So this is one of my favorite websites. It's the evolution of the web. And this thing goes all the way further on the left. So I'm just showing you kind of the snippet of the most recent. So you can see there's kind of these nice lines that flow into this just like crush of waves. And this is really just the amplification of development that's happening in browsers today. So super cool technology from Audio, HTML5, CSS3. I mean, that's just like touching the surface. The things that are created now in browsers that we can use in our products, it's just overwhelming. And it can be overwhelming. You're kind of like, how do I keep up with all that? You know, as a designer, you want to ensure that you're designing things that are harnessing the capabilities of the browser. And then as a technologist, you got to figure there's this stack of technologies that you have to keep up with from the back into the front end, you know. And like where do you put your efforts? Do you go broad? Do you go deep? And then as a product owner, you have to think about wanting to be at the cutting edge. You want to put things out there that people are going to be excited to use because they're new in their novel and they're harnessing the browsers in ways that they've never seen before. So there's this kind of overplayed notion of like a unicorn or a ninja or a rockstar developer. And I'm not here to say that that doesn't exist. I've had the pleasure of working with some incredibly talented folks. But honestly, if your product rests upon this one person, you're kind of going to be dead in the water. If your product is anchored by one person, let's just say that talent is fickle. And if they leave, you're done. So what we found at Carbon 5 is what you want to do is you want to create a culture of people that are working with one another, that are solving problems collectively and developing a process to capture their solutions so that you can put that towards your product and move forward. So we like to think that you get by with a little help from your friends. And honestly, if it takes a village to raise a kid, it sometimes feels like it takes the city to build a product. So I wanted to talk a bit about some stories of some clients that we've had the pleasure of working with that have helped us come to a process and a cadence that allows us to do effective product development. So I've been talking a bunch about this, we. So I'm going to tell you a bit about Carbon 5. We've been around since 2000. We do software development, mostly web and mobile. And we have about 35 people right now, probably 80% of which are developers, 15% maybe designers and then the rest are some operations people that keep us all sane and fed. We've worked with a variety of clients. So we do startups. We work with growth companies. We work with enterprise companies a lot of the time if they have Skunkwork projects. And what we're really looking for in our clients is for people that are interested in working with us in the way that I'm about to describe. So people that understand that you need to have a culture of flexibility, of innovation, of creativity and collaboration. And so, honestly, we've been very fortunate in some of these clients that we've had. Our basic team is this. It's the product team that you hear a lot about. It's the developer, the designer, the product owner. And these roles can kind of flex in the number of people in each one of the roles. So oftentimes, particularly at Carbon 5, you're going to see more developers. But this is the basic triage that you want. And I've mentioned this before. We don't have managers. And the reason is it's kind of this idea that you want everyone in the Fox hall, everyone working together in order to commit to the product and to be invested in the product. And I think that ends up creating this culture where because people have had their say heard by the product team and they actually see their input in the product that they're developing, they're consistently invested and they're consistently excited to see this thing succeed. So it's really important for us that everyone's participating. And it's really this larger lesson that there's this increasing complexity. Whoa, this is not working. Can you guys hear me okay? Okay, sorry about that. There's an increasing complexity to human knowledge today. And in order for us to tackle that, the escalating difficulty of those problems means that we're either collaborating with one another or we're failing alone. And something that I love to kind of associate this to is there was this great building that was created at MIT during World War II. And it was this building that was erected really slip-shot. So super quickly. And everyone thought, oh, we're just going to throw this up now because we need a lot of this faculty. We need to house them. They need office space. We're just going to throw this up. We're going to tell everyone that it's pretty temporary. It's going to come down at some time. And so they put nuclear scientists in it. They put the linguistics department in there. Noam Chomsky was there. They had piano repair people. So it was this idea of a structure that was housing a diverse variety of really curious and intellectual people. And because they knew it was temporary, some of these people completely recreated their offices. They actually would turn like a one-story office into two-stories because they wanted to build this crazy thing. And then they would run into each other in the hallways. And so they'd come up with these kind of crazy conversations that would inspire them and they'd go back to their work, having had kind of this different viewpoint that they had heard and they could have a different take on what they were working on. And what they found was that this building was, it was responsible for a stunning list of breakthroughs. And they ended up keeping it around longer, way longer than they thought that they would. And it's credited as being the magical incubator of MIT because of so many breakthroughs coming out of it. And people really believe it had everything to do with this variety of people that was in there that could collaborate with one another. Steve Jobs was actually very interested in this idea and when he was overseeing the development of the Pixar offices, he really took this to heart. And so he became really involved in the layout of the offices and he started doing things like switching around where the bathrooms were, switching around where the mailboxes were to ensure that the computer scientists, the designers, the content folks, the janitors, whoever was running into each other as much as possible so that they could be inspired and could collaborate in unique ways. So what we've found at Carbon 5 was that we wanted to put in place a way where the designers and the developers and the product owners on staff could have a process to collaborate and a flexibility in order for those collaborations to be captured and put towards the product development and have it run in an iterative way. So we developed this kind of idea of a cadence and we realized that one thing that Agile development really gets you is the reduction of risk. It's one of the great things about Agile. And Lean Design and Lean Startup has so much to teach us and we wanted to bring those two things in concert in order to reduce risk and to maximize the creativity that you could put into a product. So I'm going to talk about a couple of techniques. And something to keep in mind is that these aren't prescriptive. These are things that you can use with your teams. You might not use all of them. You might use none of them. But the idea is that these are things that you can pull in during your cadence that can potentially help to make the collaboration easier and to capture the effects of that collaboration. So we like to run things as experiments. So we do our iterative sprints as experiments. And what that means is that the entire team is coming together and they're agreeing upon something that they're going to test out with users every iteration. And for us, our iterations were weeks. And at the beginning of the week, what we would set off to do was try to figure out what the highest risk, highest reward feature was. And this is really not the highest reward feature that your Rockstar developer is excited to look into. And it's also not the feature that you think the designer is really excited to put out there into the open. This is the thing that is going to have the most reward to your users and potentially has the highest risk for the overall product. So this can be a tricky one to figure out. How do you really know what your highest risk, highest reward feature is? Something we found really helpful was you throw a big hipster cross up on the wall and you have your product owner walk up to the wall with a bunch of stories that you've written and put where they feel those features fall into this quadrant. So the biggest bangs, top left, the smallest ones are kind of in your bottom quadrant. And then you can have the designers and the developers sitting right there and saying, all right, this one's going to cost this much. This one is a huge overhead. And what you're looking to get, obviously, is the biggest bang for the buck. Another thing is getting your story straight. So this is something that will happen every single week. You're writing your stories, you're doing your estimation, you're having these conversations. What you want to have come out of those conversations is really three things. You want actionable stories. So do your developers and your designers know how to work against those stories? Then also, does the whole team really agree that those stories are the next most important thing to meet the objective that you said, highest risk, highest value? And then also, if your product were to completely end, your product development end on that Friday, do you have a whole deliverable that could potentially live on its own? If you can aim for that, it really keeps people kind of understanding and having cohesion around your objective for that sprint. So this deliverable whole idea is pretty tricky, but it's something that's really important. If people feel like they're just slopping on a bunch of features onto something, it's going to be A, difficult to test, and B, it's going to be difficult for people to really get behind that idea and both develop and design for it. So always having that deliverable whole that you're working incrementally towards, it's a great thing to do if you have a huge design that you need to kind of split out into chunks, or if you're doing a big refactor. So the idea of design, this question always comes up, right? Where does design fit in? Traditionally, you had designers that would step away and do a lot of upfront work to kind of get the overall visual voice for the product. Something to keep in mind when you're doing Lean Startup is that when you're putting things against users every iteration and those users are giving you feedback and you're starting to realize that your product market fit might be slightly different than what you originally had intended, if you've done a bunch of design work and you've come up with your visual voice for this product and all of a sudden the personas that you see that you're aiming for are subtly different, you're going to have to go back and completely redesign that. So we like to run with this idea of just-in-time design and what that means is that you want things to look good, you want things to look cohesive, but you also don't want to overthink things too much or overdesign them because there's a high likelihood that you're going to have to rethink that along the way. So if you can get yourself to have a lot of conversations that will start to steer where you need your visual voice to be and then slowly increment that design and then taking points throughout the product development process to step back and be like, okay, we're ready to do another pass-on design at this point because we feel like we've got a good product-market-fit idea. Having that kind of just-in-time design to get you to that point will really save you in the end. Another thing at the very beginning of a project that is extremely helpful to do seriously just for empathy with the team is to have everyone sit in a room and have these question cards and it's really these really scary assumptions or fears that you might have in addition to kind of your hopes for the product and people writing those down on these big cards and putting them up on the wall and just talking about them, getting kind of all of that open and out into the air. And so this can be something that's as overwhelming as what if we build the most expensive X and it completely fails, right? Even just putting that out there almost like sets the bar where everyone's like, all right, we get it, like it could go that bad and we've talked about it and we're ready to move forward. So this is something that's just like a good thing to run at the very beginning of our project. So I'm going to jump into the case studies. So these are two clients that we're just exceptional to work with. They're both great clients and also just the projects were really fun because of the process that we did. So BookRunner has a wonderful objective. They are looking to make education more affordable for students, mostly by tackling the issue of purchasing textbooks. So they brought us on to develop a web and SMS app that would allow students to go to their university bookstores and really see a cost comparison between their options for purchasing textbooks from Amazon from the bookstore or renting them through BookRunner. And ShareThrough is a company that is, it's really looking to the future of advertising by doing embedded brand content. And we worked on a product for them called Nibley. So they have this idea of an embedded video. And what we were trying to do was track how this video was being shared once it kind of went out into the wild. So it's both the shares and the views and how long people viewed it. It's a lot of data that would come in from this network of videos that was being sent out. And we needed a way to really visualize that data so that brand managers could understand what the impact of their videos were. So for both of these products, this is what a week at a glance looked like. And just to keep in mind, this week is, again, it's not boilerplate. This isn't completely strict. You're definitely going to be flexing on your week. But at a glance, this is Mondays. We would reflect and define for the week. On Tuesdays we would specify. And then on Wednesdays, sorry, this thing keeps getting, we would build and refine. And Thursdays also we would be building and refining. And then on Fridays, that's when we would go out and we would get our customer feedback. So again, I want to reiterate that this schedule, a lot of people come back and they're like, seriously, you're talking and designing for three out of the five days. And the reality is you're not. So at the beginning of the project, when you're kicking off, it's going to look a lot more design side of things and a lot more discussions. And then as you move through your product development cycle, you're going to see that there's a lot more development happening. This is a flexible schedule and that both the roles and their time spent in these different endeavors are going to change and flex as time goes on. So Mondays, you had your user reviews on Friday. And Mondays is where you get to sit down and really talk about that. And it's nice to have the weekend to digest some of that stuff and to really come in fresh with ideas. Sometimes it was painful what you saw happen on Friday. Sometimes it was inspiring. But regardless Monday, you kind of have this fresh moment to sit and really have the team get together and reflect on what happened. So this is where you start to kind of ideate and you can do design shreds at this time. So we found that some of the design thinking exercises such as like six up sketches, doing personas, there's a variety of ways that you can kind of facilitate pulling out design from what happened on your Friday sessions and having the whole team in their developers and designers. This is where you get these very natural conversations to happen and really you get that empathy moment where people are talking, they're agreeing on things, they're putting them out in the open and then you're going broad. You're allowing people to really have that expansion of ideas, right? So like your technologist can be talking to your designers about new ways that they've seen that they could potentially handle some issues that they saw with the users on Friday. So the retrospective, I had a problem recently on a project where I skipped a couple retrospectives and I can't tell you how much of a difference that that made. It is imperative to run this. It's even if you have it just be 15 minutes but the opportunity for your developers, your designers and your product owner to sit down at a table and basically talk about how things went, how things should go and things that you want to change. So we run this with, I wish, which is kind of things that didn't go great the last week and then an I will component of how you'd like to change things and then, actually I'm totally forgetting, and then an I like. So great things that happened last week that you want to bring over to the next week. So it's a conversation that can happen quickly and it's a facilitation exercise that maybe can be only 15 minutes but it keeps your team in collaboration with one another, empathetic with one another and understanding kind of what the pain points are. So the next thing we would usually jump into was talking about the customer feedback. So the way that we would do it is we like to capture our customer feedback and what we used was stickies and we used them virtually. So we actually created this application that we have called somewhere between boardroom and stickies but it's a virtual way of capturing sticky notes and so people that weren't present for the session for the user testing could actually add their ideas to this board over the weekend or if they were watching it through a video. But in some manner, shape, form you need to capture feedback from your users. So we would sit down and we would talk about the learnings that we had and do a facilitation exercise and that inevitably led to someone coming up with ideas and so they would jump up and they would get onto the white board and start wireframing. So we would do this kind of ad hoc wireframing. This is actually the product owner from Bookrunner and we were doing mobile in line with SMS so we had to really look at those two pathways in tandem to figure out the most efficient way to address both of them. So he would oftentimes, on Monday mornings after we had gotten this user feedback he'd jump up and be like, okay, I think this is the way we need to approach it. He could just get the wireframe out, we could discuss it, ideas could be generated and then you were really just capturing these things with photos. So this is where the team really gets to sit down and do hypothesis definition and it's getting everyone behind the hypothesis that you want to test that Friday with users and really writing that down. Writing down what it is, what outcome you're hoping to see from users on that Friday. So again, you're always trying to prioritize to a full deliverable there so that what you're testing against feels like a set of features that have cohesion. And then at the end of Mondays another thing that happens during user testing that's kind of awesome as a developer is that you're seeing people use your application and you're seeing the bugs and so this is your opportunity to go back and do your refactoring and clean up and prep and also for the designers to go back and kind of clean up what they want to see happen in the interface. So Tuesday you've gone broad, now you need to really dive deeper. This is where you start to do your story writing and there is a total art to story writing. We have started to use some templates for it to really just bring back some discipline to it and what a story is is it's really, they call it the placeholder for the conversation and if you can have a template that captures that conversation efficiently when people are going back and looking at this stories they have a clear understanding of what the intent of the story is and what the acceptance criteria is. So this template is actually straight from Dan North's BDD template that he created and BDD stands for behavior driven design. So you'll see kind of that bottom scenario here. This is straight from Cucumber which is a testing framework. So this is really requires a lot of discipline to have every story look like this but it allows you to have a very clear path moving forward so it's good to be disciplined. So then you're going to have more conversations, you're going to do story breakdown, you're going to need to estimate and prioritize. Something that always comes out of this is you end up doing a lot of pair sketching. So this is again an opportunity for designers and developers to sit together and sketch things real time with one another instead of having these huge blocks of PSDs that they have to create that the developers are waiting on. They're really like understanding things that you can work on right then and there. And then you'll end up at some point in your project with a ton of stories. So there's the ones that didn't get into your sprint and they're sitting there in the backlog or the icebox. Something that's really good to do over time is to have that meta view to step back and do a story map. So pulling out your epics and understanding really what the bigger picture is and where you're headed in the long term so that you don't feel like you're constrained to these week by week by week cycles. So Wednesday and Thursday, this is when the work gets done. This is when the conversations have already been had and also the ability to have those additional conversations has been put into place. So you'll see that the culture of the team at this point is such that if they come up to an issue if the developers are stuck, they can grab a designer, jump up and do some more whiteboard wireframing. And then the other thing that we have implemented at Carbon 5 is we've started to have these living style guide and visual assets that the developers have as kind of a kit. And so this is again something that you can do the just-in-time design, right? So at the initiation of a project, what this probably will look like is Bootstrap, right? And then as the designers start to deliver more of the visual design, Bootstrap starts to morph into these assets looking more and more like the final visual voice of the product. So if developers have this kit to work from, they can then start in on a story that maybe doesn't have complete design. And then what they can do once they're done with the story before it's done-done is they can pull in a designer. The two of them can sit together and they can really pair, right? So you can pull up the inspector in Chrome and you can start to do your pixel tweaking right then and there. So you don't need the pixel-perfect PSD. You have your designer right there going through the interactive site, seeing the hover state, seeing all of the interaction. And they're able to say, do this, do that. And the developer real-time can sit down. We used to put in chores. We used to put in snippets of time on Thursday where the developer and the designer would sit down and pair and get things ready for the user testing on Friday. So story acceptance. The one thing I want to say about this is if you're a product owner, this is so critical. It shows the team that you are critically looking at every story. And honestly, sometimes getting rejection is better than acceptance because you know that your product owner has looked at this, has tested it, so Friday comes. So this is basically how did we do? How is our hypothesis? So first, you kind of want to do some prep. You want to understand what it is that you're testing. You have your hypothesis, but what's the manner in which you're going to capture this feedback? And just having a brief narrative or outline or plan on how you're going to run the user test and how you're going to get feedback from the users is really critical before you jump into it. So we had a webinar because we wanted to test people in the physical space of a bookstore. What we would do is we could go and grab five students and we'd bring them into the bookrunner office and we wanted to test both the store tags as well as the app that we were creating for those store tags. So we'd grab five of these people on Friday and we'd call it five on Friday and they'd come in and we'd give them you know, a gift certificate to Amazon. And we'd have them walk around the stores with their SMS phones. Someone would come in with their WebKit phones and we'd have them kind of cruise around and we would just listen to them and get their feedback and ask questions. And it gave us such great insight into how we needed to change the app in order to meet their needs. One thing that was hugely helpful with the Nibley project was this thing was incredibly hard to understand how we should do the data visualization, right? We wanted brand managers to be able to really quickly look at this graph. And be able to see how much that video was viewed how often it was shared which networks it was shared on and who the influencers in those networks were. So obviously that's a lot of data to show someone and we wanted to make sure that they understood what they were seeing. So we had many different iterations on this and if we had to wait every week for a new iteration to test this stuff out it would have taken way more time than we wanted to. So what we ended up doing, this is Rob Fan, our product owner is that we would take the same iconography and kind of visual language that we were using for the working interface and we'd first test them on the working interface and we would take our notes and then we would say, okay, well how about if we did this and we would print out these icons with stickies on the back of them we'd throw them up on a big white board and we'd start to just draw different interface possibilities and have them go up there with their finger and start to pretend their finger was a mouse and see how they understood it if it was implemented in that way. So this saved us so much development time and it's kind of along that type of rapid prototyping that we all talk about but with a component of physical interface that they had seen working. So this was our way of capturing customer feedback and try to make sure that your team is watching. If you have to capture it with video, great, but ensure that people are watching this. So this is something that I have to constantly remind myself. This whole process does feel weighty. It feels like it takes a lot of effort but once you get into it you actually realize that the cadence kind of takes care of itself but you need to maintain discipline. And then the real lesson here and what this cadence and this culture is trying to instill is that you're going to get conflict in your team but that conflict is actually really, really good as long as you have a pathway to resolution and a way to capture that. So this is kind of our working agreement, the foundations of the way that our teams work. We want to make sure that there's conversations, that you're surrounded by talent, make sure that you can have that talent work collaboratively together and capture those learnings. And that you have this culture of cross-collaboration that people are comfortable with one another to go up and grab each other and talk. There's no aversion to wanting to have to grab a developer. That developer, you've already talked with them like 90 times every Monday, right? So you can go and you can grab them and talk with them. And then finally, it's the cadence, right? So once you start running this, it runs itself. You've got your meeting scheduled up, you understand how your week is going to go, and it's very comfortable for everyone. So I wanted to maybe save time for questions, which I totally didn't, but thank you. If you have any questions, come grab me. You can tweet me, you can email me. I would love to hear feedback. Thanks so much for your time. Thank you very much, Courtney.