[MUSIC] 0:00 [SOUND] Cool. 0:16 I am really embracing the Vegas, so I am dressed accordingly. 0:20 Cuz Vegas is really fun and sparkly. 0:24 Like Elias said, my name Katie Kavalson. 0:29 I am a designer at Sparkbox based out of Dayton, Ohio. 0:31 And today I'm gonna talk about collaboration, 0:36 which is like this magical buzzword that everybody's always talking about 0:39 that's gonna fix all of our problems. 0:43 But why is it this magical buzzword that's gonna fix all of our problems? 0:46 And to think about that gonna take a little history lesson and 0:51 talk about Bill Bernbach. 0:55 He was a art director in an advertising agency in the 1940s and 0:57 he worked at Grey Advertising. 1:02 Where they did a pretty traditional advertising structure, where 1:04 the copywriter would write all of the copy and then walk it down to the hall, and 1:09 put it on the art director's desk, who would then lay it out. 1:13 And the results were pretty boring and uninspired layouts, 1:18 of just like an image and the text, and that was that. 1:22 And he wanted to do things differently. 1:26 He left there and formed Doyle, Dane, Bernbach or 1:29 DDB and wanted to take this approach with creative teams. 1:32 This was his team, and it consisted of an art director and 1:37 a copy writer working together from the beginning. 1:42 To come up with ideas and he called them creative teams, and 1:45 it totally revolutionized the advertising industry and 1:50 the results were impressive pieces like this. 1:55 Where the words and the imagery work 1:58 together to deliver really a powerful message, like the, Think small, campaign. 2:01 It's interesting to me that in 2015 we're still kind of 2:07 making those same early advertising industry mistakes. 2:11 Where designers are kind of working on things 2:15 in their own little silo and making a nice picture of the website. 2:19 And then walking down the hall and 2:24 putting it in developer's desk and saying, here, build it. 2:25 And that just Isn't really working to produce some inspiring results. 2:29 And we're also holding everything on the project to this picture of a website, 2:34 and not an actual living, breathing, in-browser experience that is a website. 2:40 So it's interesting that we get signoff and approval and 2:46 everything on JPEGs of a website, and not actual live code that is 2:50 much more realistic to what the website is going to look like. 2:55 And also, we feel sometimes like we're making the same website, 3:00 likw two, three, even four times between doing the wireframing and 3:06 then doing the mockups, and then the code, and maybe prototyping. 3:11 We're rebuilding the same thing a lot of times, 3:14 rather than just working towards that one end goal experience. 3:17 So working this way, just like in advertising industry, 3:21 something has to give. 3:24 And It's usually gonna be the budget or timeline. 3:27 We're gonna run out of those, or money. 3:32 But ultimately our creative iterations and 3:34 our sanity of wanting to create these really great experiences. 3:38 So I think it would be great if we start to think and 3:41 function the work in relationship between designers and 3:46 developers to function more like those creative teams. 3:48 Because ultimately again the more realistic expectations can be met in 3:52 the browser, when we serve the client's actual coded designs in the browser, 3:57 and tweek the feedback accordingly rather than tweaking a picture of a website. 4:03 And you might be sitting there like, yeah, duh. 4:09 Developers have been trying to design and code in the browser for years. 4:12 I design using CSS. 4:16 But I think a really important caveat is to let the designers 4:18 design in whatever method they are most comfortable in. 4:23 At least for a little bit. 4:27 Whether that's Photoshop or Sketch or whatever. 4:28 I think we're pretty quick to shame designers for using it. 4:31 I feel guilty for still using Photoshop sometimes, but 4:35 that's what's most comfortable for my creative expression. 4:37 And I think we need to just accept that that's okay to a point. 4:40 We're also really quick to tell designers that they need to learn to code, and 4:47 not necessarily the reverse, that developers need to learn some design. 4:51 I wrote an article about this earlier this year, about 4:55 expanding skill sets to kind of bridge the gap and work better together as a team. 4:59 Not just designers learning to code, but developers learning some design as well. 5:04 So if we kind of think of skill sets as being this spectrum of, let's say, 5:09 design being this pink color, and back-end being that blue color, 5:13 and front-end being the purple in between. 5:17 I'm probably somewhere around here, where just purely design, 5:18 a little bit of front-end. 5:22 And if I were working with a back-end developer who 5:24 just was in that blue area and dabbled a little bit in front-end, but 5:27 wasn't really comfortable in it, we have a gap then, in the middle. 5:30 And that needs to be filled somehow for us to properly communicate and 5:34 work effectively together. 5:38 So aside from adding a third person to the team, 5:39 one way that we could get around that and have better conversations, 5:43 is by me learning a little bit more front-end and my team mate also learning 5:46 a little bit more front-end so that we kinda cover all of our bases there. 5:50 I think another really great way to work better together is to have 5:55 designers work in the developer build tools. 6:00 S-V-Gee is a really great example of this. 6:03 I worked on my website with Chris Coyier and he showed 6:08 me really great things that we could do with S-V-Gee's that I had no idea. 6:13 I thought that this was just a technical thing that developers could do. 6:16 It's just a file format. 6:19 I didn't know that there was so much cool things that I, as I designer, 6:20 could be build around for something that I thought was technical like SPG. 6:24 Until a developer showed me, and said, 6:27 hey we can animate these, we can do cool things on hover, and I was like, oh yeah. 6:29 I'm all about that, so we built it using. 6:33 Jackal, and there was a Grunt file, which I'm not technical, but I know enough to go 6:37 in Terminal and type a couple words, like grunt serve, and grunt, and then run that, 6:40 and then some magical stuff, that I don't really understand, happens. 6:45 But, a developer wrote that, knowing my needs, so 6:49 that I can just quickly go in and see, make a little change. 6:52 Let's say I wanna change that word from design to Not design and 6:56 then I hit save and it updates. 7:01 And we're working together in the same tools, 7:04 cuz ultimately what we're building is in the browser or website, so 7:05 our tools to be comfortable reflecting that and then we're working together 7:10 in the actual same environment and cool things will happen then. 7:15 And it's also important for 7:20 designers to explain their design decisions to the developers. 7:21 A lot of times I think in my head, this is a very obvious layout. 7:25 My grid is so obvious. 7:29 This is lined up with this. 7:30 And that's not usually the case. 7:32 Some developers overlook a lot of those things because they don't 7:34 have that trained design eye. 7:37 So, we can work together to bridge that gap, by explaining those design decisions. 7:38 This is a design that I'm gonna get to here in a little bit. 7:43 But the tablet experience was so important, and so that 7:46 there's a completely different typographic scale at the tablet experience. 7:50 And to the developer, that might not be so obvious, that there was just a little bit 7:55 of shift in the line height and the scale and everything. 7:59 That's something to explain, and explain the reasoning, and how we tested it, 8:03 and arrived at the solution. 8:06 And that will help the developers to understand and 8:07 make better design decisions as well. 8:10 Ultimately, it takes two skill sets to create a really 8:13 wonderful pattern library and extendable design system. 8:18 That doesn't necessarily mean two different people. 8:22 If you're one of those superhumans that possesses both of those skillsets, 8:24 that's awesome. 8:28 But we wanna work together to be these cool little emoji girls and 8:30 deliver an awesome design system together. 8:35 I think that Dave Rupert really puts it best when he describes these 8:37 pattern libraries as being like tiny bootstraps for every client. 8:42 They're these custom frameworks that we build for them, 8:46 that they can then plug and play and pull together to use and 8:48 extend what we build for them, rather than us just handing them some pages. 8:53 At my last job at Happy Cog, this was what we used to use, a pattern library, 8:59 and we built it ourself and it it housed, you can see like the wire frames and 9:05 the mockups and the code, and also all the other project stuff. 9:08 And it was based largely on Brad Frost's atomic design principle, 9:12 where we have the atoms being like the smallest elements on the page. 9:16 Like a button. 9:20 Then we put a couple of atoms together to make a molecule and so on and so 9:21 forth until we get the full pages. 9:24 From there, built pattern lab which is kind of the framework built around 9:26 that atom design principle, where you can build your modular code together in there. 9:32 And this is kinda what it looks like just with the Lorem ipsum and 9:38 generic images and stuff. 9:42 Back to the one that we built, you can see that it has the same principals of 9:44 the biggest six building it together [INAUDIBLE] the fragments. 9:48 Then we have the layouts with the full pages. 9:51 Sparkbox, this is one that's just simple. 9:55 You can just have a simple list linking to the different patterns. 9:57 It doesn't even need to be as complex of a project tub as the previous one. 10:00 So, to kind of demonstrate a good working style together between the designers and 10:05 developers, I'm going to walk through a couple different projects that I've worked 10:10 on, and sort of the wins that we saw along the way working closely together. 10:14 So, this is a site that I wish existed. 10:19 I wish that there was a wholesale skull and crystal distributor, but there's not. 10:22 This is actually a real client project, but I can't talk about the actual client. 10:26 So, I swapped out the content to be things that I like. 10:30 But, the process is still the same. 10:33 And, I'm also gonna walk through what Sparkbox and 10:35 CodePen have done working together to re-design CodePen. 10:40 We're still in the middle of that, but we're still designing that in the open. 10:43 So you're gonna talk about some of the things that we've done working closely 10:46 with their team. 10:49 I think the most important thing is having everybody involved from day one. 10:50 I don't like to design without knowing what developer I can have 10:56 on hand to talk to and answer questions for me. 11:00 And I think it's important for the developer to be kept 11:02 up to speed from the beginning on how we've arrived at certain design decisions. 11:05 And we can also start from the beginning creating goals together. 11:10 If we want to try and do something like a performance budget, 11:14 which talked about earlier and it was really an amazing talk. 11:16 We can establish that together before design, so 11:22 that we're not at the end scrambling to kind of retrofit these goals 11:24 into a design that wasn't meant to house them. 11:30 And if we have different ideas about how we want to prototype, 11:33 different parts of the sight, 11:36 we can talk about that from the beginning before we ever even start design. 11:37 Because how many times do developers have in their head, 11:41 I want to try to this really cool technology or framework, or plugin. 11:44 There's these things that I want to try. 11:48 But that's not ever voiced to the team. 11:50 And then they get really frustrated that, oh I'm handed this design that I 11:53 can't do all the cool things that I wanted to try on, again. 11:58 But if that were brought up in the beginning we could say, yeah, great idea, 12:01 let's figure out a way to make that happen. 12:05 So this is kind of like a typical project timeline working together, 12:07 where as design's ramping up, development is sort of checking in. 12:12 And then as development is ramping up, design is tapering off, but 12:16 still involved. 12:19 A lot of really great conversations happen in this part. 12:21 Where the developer is involved in the design reviews and looking at it and 12:23 pointing out any red flags or things that they don't necessarily agree with, 12:28 or if it would be difficult to build, and things like that. 12:33 We can sketch out different solutions. 12:37 I worked with a really great developer who was so good at sketching out ideas on 12:41 the fly, and saying I'm not sure about that pattern or that interaction. 12:46 And then we would just whiteboard it together. 12:49 And they were always amazing ideas, 12:51 coming from someone who wasn't a quote unquote designer. 12:53 And I've also had project managers who have really great ideas. 12:56 It doesn't need to be this ego thing, 12:59 where just the designer has all the ideas and has the final say. 13:01 We can have some really great conversations in these design 13:06 reviews with the entire team. 13:08 It's also really important to educate the client from the beginning. 13:10 We're pretty quick to complain about clients in our industry, and 13:15 I don't like that, because when the client is being a quote unquote bad client, 13:20 or not letting us do the things we wanna do. 13:25 It's cuz we didn't properly educate them from the beginning 13:28 to tell them why they should care about that, and how we're going to build it. 13:31 And all of the conversations that we wanna have, like we're gonna build you 13:36 this pattern library, we're gonna deliver our designs and code, all of that 13:41 conversation needs to happen at the very beginning when sales is talking to them. 13:44 We don't want it to be at the end of development and we're like, whelp, we're 13:49 gonna deliver you this code this way and they're like, where did that come from? 13:52 We don't understand it. 13:56 It's gonna be really frustrating. 13:57 So, the sales conversation is so important to setting up the foundation for 13:58 the team's success. 14:02 The setting up the expectations. 14:04 The quote unquote Coven Project we set up 14:06 those expectations from the beginning that you have gone through a redesign before. 14:11 You are used to seeing typical mock ups, a bunch of mock up and 14:16 approving those before we build it. 14:21 But we don't wanna build it that way because of these reasons, and we're gonna 14:22 start showing you designs and code a lot earlier than you're probably used to. 14:26 And they were on board. 14:32 They got it because we set that expectation from the beginning. 14:33 And we also wanna use the same language. 14:37 A lot of times a word like template can mean 14:40 vastly different things to different people. 14:44 And I've even had clients call the hamburger icon the basement. 14:46 That's fine if that's what they learned but 14:50 that means something different to everybody. 14:53 So we should probably talk about that at the beginning and say, hey, 14:55 when we say this word, we mean this. 14:57 And then we can all speak the same language. 15:00 Now we're gonna move into establishing the design direction, 15:04 which I tend to still do statically. 15:08 That's again just how I can make design decisions the best. 15:11 And I think a lot of times people also are quick to 15:15 figure out the wire frames first before moving on to the visual design? 15:18 And I think that they can be done simultaneously, 15:24 because they are separate pieces. 15:26 So what I like to do while working on wireframes is do something like an element 15:29 collage, which is this idea that 15:32 Dan Mall has coined where it's literally a collage of elements. 15:35 It looks like pieces of an actual page, but 15:40 it's not the full page, it doesn't include the layout. 15:43 And it also helps because a lot of times clients get really hung up at the content 15:46 of the design more so than the design itself and 15:51 they're like, can we change that word? 15:53 Yes we can change the word, but what about the aesthetic. 15:55 You can quickly knock out several different aesthetics. 15:57 And this is for same client, and you can see how the different 16:00 directions that these could take, and each of these took less than a day to do. 16:05 It's a really great way to get out that aesthetic. 16:09 This is the one we did for CodePen which is pretty bare bones. 16:13 We just wanted to figure out how we can elevate the type styles and 16:17 make more sense of the colors and thing like that. 16:20 So it can be as kind of quick as you need it to be to get your ideas out. 16:23 And, from there, once we sort of get the approval like, 16:30 yes that's a good direction, let's see what you come up with. 16:33 We could then move into the full page of combining 16:35 the wireframe sort of with that element collage. 16:39 Again, this can be static. 16:43 This is the one that I came up with that coven design where 16:45 also figuring the tablet layout simultaneously. 16:51 You can see getting some quick type styles out, the layout and everything else. 16:55 And then just wanting to hear that, okay, yeah go on from the client. 17:00 And when starting design from the page, 17:05 I like to think of the epicenter design principles. 17:07 Which is kind of thinking of the true, main piece of that page, 17:10 and making sure that we really nail that before figuring out the rest of the page. 17:15 And this plays nicely with things like the pattern library and 17:19 atomic design of building out. 17:21 In the example of CodePen, what's more important to CodePen than the pens? 17:24 That is what their entire product hinges on. 17:30 We designed the pen first and really made sure we got pen the looking right and 17:34 looking the way we want to, before then moving on to say, a collection of pens. 17:38 And what do six of those pens look like together, 17:42 and then kind of adjusting the design accordingly. 17:45 Okay, now that we have a group of them, okay, 17:48 let's switch some of the elements around. 17:50 And then from there we can add in the rest of the page. 17:52 What's down below, what that sidebar is looking like. 17:55 And so you can see how we build out from what's really important on that page. 17:58 And in this step I also like to think of more 18:03 realistic fidelity than being the pixel perfect comp. 18:06 So you can see on CodePen, this is just a lot of copy and 18:10 pasting of the same content, the same image. 18:13 But you get the picture, you get the layout. 18:16 And that's pretty easy to communicate, just like, yeah, it's a white box, but 18:18 it will be something. 18:23 And it communicates well enough to the client that they can say, yeah I get it, 18:24 I like where this is going. 18:28 Or, Maybe we want to shift that element around on the page. 18:29 And we're not wasting a lot of time perfecting this picture of the website, 18:32 because all of those details of polishing, we'll get to in the browser. 18:36 And I also at this stage, 18:41 like to keep sort of a blank document open that I can copy and 18:43 paste all my styles against to make sure that I'm not getting unruly with them. 18:46 So this is the one I had working for CodePen. 18:51 And you can see by doing this exercise I can see that the recent activity 18:54 in my recent pens are like almost the same style, but not quite the same style. 18:59 And I should probably condense those, 19:06 because I don't have a real reason to have those be slightly different. 19:08 Or if they do need to be different then maybe I should drive those further apart. 19:12 So it's a really great way to keep track of the styles that will then 19:17 help inform our pattern library that we're building. 19:20 And a tip that I really like for delivering these static markups 19:24 early on is to get the client comfortable with viewing things in the browser, and 19:28 this will help prime them for 19:32 looking at our designs when they are coded in the next step. 19:34 But to put the JPEG centered, just really quick HTML and 19:38 CSS, just centering the JPEG. 19:43 And you can see here in the mockup, that's just a JPEG in the center. 19:45 And then we take a one pixel repeating background, and repeat that behind it. 19:49 And that helps the client to feel what the site looks like in the browser. 19:53 And again, that will make that transition to the coded design a lot easier. 19:59 But yeah, that's just an image. 20:03 So, from there, it's really great to start with this style guide of 20:07 just kind of outlining those key patterns that we've been working on. 20:12 So, for CodePen, they didn't actually have one documented anywhere. 20:17 And they're, obviously, hip developers that understand these things. 20:21 So, this was rare luxury that we were able to have the client quickly come up with 20:26 the design patterns on the fly. 20:30 But so, they made this page in a day, and we're just, yep, 20:32 here's all of our patterns. 20:36 That was a really great starting place for 20:37 us to begin thinking about the design system and 20:41 what we needed to cover based on their style guide. 20:45 And this is again, back to that repo that we had at Happy Cog. 20:49 You can see we have the typography as the basic elements and icons and buttons and 20:53 things like that. 20:57 So, it can kind of be as complex or simple as you need it to be. 20:58 And it just has quick little bits of code in there to talk about what it is, 21:01 and buttons and fields. 21:07 Again, they're just building on each other. 21:09 So, once we're sort of like simultaneously figuring out the style guide, and 21:11 we're working on getting our design nailed down. 21:15 And now we've shown the client, and we got their feedback. 21:18 This is a really important step in sort of evaluating how close we got 21:22 to not having to make a ton of different changes. 21:26 So, the feedback that we got from this was that that sidebar, 21:30 they felt that the My Orders headline was running into the important news 21:34 section a little too closely, so they wanted that to be separate. 21:39 They wanted us to work on this hero area and 21:43 figure out how that looks a little bit more. 21:46 And they also wanted us to just add a line to those specials and 21:49 closeouts to include a little tagline about the reduced price. 21:52 And that was it. 21:55 And that seemed like those were simple enough changes that it would be faster for 21:56 us to make those in code than to do another Photoshop mock up. 22:00 So, once you kind of feel that balance, we're almost there. 22:04 That's when we can kind of then move to the browser and 22:09 make those iterations there. 22:12 And this is kind of where it really starts to get good, 22:14 now that we're getting into the browser. 22:17 The very next deliverable that we did for 22:19 that Coven project was showing them that homepage as code. 22:22 And this was really interesting for us. 22:25 This was the first time that my team had done that. 22:28 And the feedback that we got was about interactions and stuff, and 22:30 we're like, oh no. 22:34 It's not about the design. 22:35 And then, a light bulb went off, like, oh no. 22:37 This all design. 22:39 So, it was really awesome that we got to think about this stuff really early on. 22:40 We were able to catch these drop downs. 22:43 And you can see that there's some subtle animations to the arrows and icons and 22:46 things like that. 22:50 All of these things that usually get overlooked or wait until the end, 22:51 until development is starting. 22:56 We were able to catch that by the second design deliverable, and it was great. 22:58 And the client was able to really feel what the design was looking like. 23:02 And all of these iterations we're caught so 23:07 early on that normally would be tracked as bugs at the end. 23:10 So, for example, the My Watched items. 23:13 We didn't even think about how to unwatch them. 23:16 But the client seeing it in a browser and clicking things, they were like, oh, 23:18 how would you do that? 23:22 And we were like, oh, yeah, we totally glossed over that. 23:23 Let's figure that out. 23:26 And we were able to just flop that into that design really easily and 23:27 catch that early on. 23:32 The next step then is smoothing out and 23:34 really finessing our designs by working together, 23:37 by paring, as well call it at Sparkbox. 23:42 How we like to do it at Sparkbox, 23:46 is we have the designer with their laptop pulled up. 23:48 We have sketchpad because we're probably going to try 23:51 to sketch out some ideas together. 23:55 Different devices that we want to test on and address. 23:58 I guess, sorry I thought there was another one. 24:00 Whoops. 24:05 Got it. 24:08 So, back to the Coven project. 24:09 For example, like graying out the other tabs. 24:11 That was something that we figured out, 24:16 sort of just sitting together like, oh, yeah. 24:17 Let's try to really, subtly elevate all of these things and 24:19 figured out, like oh, your messages. 24:22 We can add a little bounce. 24:25 And this was just me sitting with the developer for maybe like an hour, and 24:26 sort of just smoothing out all these interactions. 24:30 And again for thinking back, this is the second design deliverable. 24:33 This isn't at the end just like trying to burn some hours while also addressing 24:36 bugs, because a lot of times clients are really quick to say, oh, 24:41 the model didn't close when I clicked in the gray area. 24:45 I have to click the X. 24:48 Can we fix that? 24:50 I want it to close when I click in the gray area. 24:50 And they track it as a bug and 24:53 we're trying to do all of the other actual bugs and not address all of these things. 24:54 So, it's important to recognize that these are design iterations. 24:59 That's part of the design, and the designed experience. 25:03 That's not a bug. 25:05 It's not broken that it didn't do that. 25:06 That's just a preference in a way that you wish it were designed, so 25:08 those should be caught in design. 25:11 And, we also wanna make sure that we are documenting all of our code that we 25:15 are building, and making sure that it's modular and extensible. 25:19 So, if we go back to this one, we have our homepage. 25:22 We can click in, see the footer, and that's all the live working code. 25:25 And you can interact with it and see all the hover states and everything. 25:28 We can also dig down into the stories, and you can see that's all that's there. 25:32 Here's the code that the client can then, 25:37 if they made a new page where they wanted this module, copy and paste that over. 25:40 And then, we can also click down and see what makes up that. 25:44 Oh, okay it makes one news item. 25:47 So then, you can see how just one of those components work together. 25:50 So, we're kinda just drilling down and seeing how it builds on top of each other. 25:52 And I think, mail trim does a really awesome job at documenting. 25:57 They have all these notes over there next to the code. 26:01 And sometimes, we've even done like videos for clients, 26:04 if it's a really intense piece of code that they need to implement. 26:07 So, you want to make sure that you document everything and 26:12 educate the client again ongoing, so that we can set them up for 26:15 success for them to maintain this once the engagement is over. 26:19 And this is kind of the step that gets like a little wishy washy, where, 26:23 I don't have a good answer other than just really be fluid and 26:28 work closely with your teammates to iterate back and forth and 26:32 kind of see what you need to figure out next. 26:36 So, this was the next page that the client wanted us to design, 26:39 like a search results ending page, and back to the realistic fidelity. 26:44 This is just a screenshot that I took of the other page. 26:50 It's the same exact module. 26:52 I didn't need to redesign it or touch it or do anything. 26:53 This is, obviously, the same header that is on all of the other pages, so 26:57 I didn't really need to redesign that either. 27:01 So, all I needed to do on this next design deliverable was the sidebar filter and 27:03 also the tags and breadcrumbs and stuff. 27:09 So, that's all that the developer was like, yeah, 27:12 that's all that I need from you. 27:14 So, I was able to really quickly just design those up, and 27:15 throw them over slack, and then we could jump into code. 27:19 And then from there, now the client can interact with that actual filter, 27:23 see how those tags are popping up. 27:27 In this next design deliverable, they didn't even see that static mock up. 27:29 And then, they requested that the filter be sticky, so that was really easy for 27:33 us to just throw in there once they saw the code live and we're playing with it. 27:39 And then, if we go back to our pattern library, we can see what makes it up. 27:45 Again, those articles, and then, oh, here's the filter that we just added, 27:49 how to implement it, documenting how it works. 27:54 And again, all of that is just living in the same place that we've been using 27:57 the whole project. 28:01 So, back to my site, this was another page I mocked up. 28:04 But at this point, I was deciding, 28:09 I don't know if I'm really digging my color scheme. 28:11 I kind of just chose some colors I liked, 28:13 I don't know if they're necessarily working together. 28:15 So, I tried playing around with some different colors. 28:17 I wanted to see if I could make pink and blue and red work. 28:20 I don't know, for whatever reason. 28:24 And then, funny enough, just trying to iterate on this, 28:26 I was watching Cool Runnings. 28:30 [LAUGH] And the opening titles, I don't know, I just thought they had a lot 28:32 of energy and cool, and a really interesting color scheme. 28:37 And so then, I settled on these colors, which are not directly Cool Runnings 28:41 colors, but i don't know, they were definitely inspired by Cool Runnings. 28:45 And because I was used to working in those same build tools, 28:50 and updating the developer environment and just kind of talking back and forth and 28:53 stuff, I really quickly could just go in there and 28:57 play around with all these colors on the actual live code. 29:00 And that's like a really empowering thing for 29:03 a designer to be able to do is do the design explorations on the actual site, 29:06 and I think that that is really cool. 29:11 And the most important thing, obviously, 29:13 as we talk about collaboration is to just have really good communication. 29:16 Not just with our team, but with the client team as well, 29:21 and make sure that we are communicating every step of the way what we're doing and 29:24 why, and to be able to, again, catch those iterations and things. 29:28 So, at Sparkbox, we have weekly check-ins with our clients, 29:32 where that's just a standing meeting every week, 29:36 where we just talk about what we did for that week, and working this way. 29:39 Dan Mald says, he likes to think of it as just saying, go on. 29:43 We're just going to keep working, keep plugging away, keep iterating on things 29:46 until the client tells us to stop because somewhere we made a wrong turn. 29:50 So, I think this is a really good way to think of working is to not have these 29:54 rigid approvals, if you can. 29:59 Again that goes back to setting expectations really early with a client, 30:01 but working in this way of just, we're gonna keep working at this end goal, 30:05 that is the finished website, until you tell us to stop. 30:10 So, by now, we have set a pretty nice foundation in the design for 30:13 the developer to then take and extend it. 30:19 And we can work really nicely together to just figure out where those holes are, 30:22 where we need to fill them, where I need to jump in and design, where it 30:26 might be in Photoshop, it might be in code, it could be all over the place. 30:30 And I highly recommend seeing Sophie Shepherd's talk tomorrow where she talks 30:34 about pattern libraries and how she builds them as well. 30:38 [SOUND] So, going back to Bill Bernbach, this was a quote that I really liked 30:41 by him, let us prove to the world that good taste, good art, and 30:46 good writing can be good selling. 30:50 I think, if he made websites today, he would say that it's good design, 30:52 good code and good content that can be good selling, because, if we look, 30:57 when we don't talk to each other and don't collaborate, we can have pretty 31:01 uninspiring and boring results of giant images with a lot of boring text. 31:06 And our websites can start to look the same way with just having giant, 31:10 boring images with a lot of boring text. 31:15 And let's work together, 31:17 let creative teams to deliver some more inspiring results. 31:19 Thank you. 31:23 [APPLAUSE] 31:24 [MUSIC] 31:25