 Alright, so I've got a lot to cover, I guess some questions first. How many people in the audience are feeling more interested in the agile content that's going to be within this talk? Agile content? So this is agile design, and what about the design content? Okay, a little more on the design, alright? So since I think I have a lot of content to jam-pack in here, I think as the talk goes on in a very agile way, I'm going to have to start cutting corners as I start running out of time, so maybe I'll go light on the agile stuff, but I'll look for nodding and things and decide at that point if I want to stick on the, if I want to go on and on more about the agile stuff. First, do a little housekeeping, oh this is weird, alright, I'm Kelly Albrecht, KS Albrecht on Twitter and Drupal.org profile in most other places I think, and tomorrow is a sprint day, general sprints, mentored core, sprints, first-timer workshop, right here, I'm sure you've been hearing this in every session, and for feedback, this is node 17034, it's the node for the session, it'd be great to get some feedback on how I did, okay, so I think when we look at a website, and we think of it as a finished product, we think of it as having been designed, and it was, maybe it was a good design, maybe it was a bad design, and I think that that even, that affects the way we think, and it has affected the way we think, we've probably all written a proposal where you estimated it out in phases, and there was a design phase at the beginning, and that was where everything was going to get planned out, and this thinking, this way of thinking about design is normal and has a, it has a history, right, so this is St. Thomas Aquinas, a legendary thinker in our history of thinkers, who felt that wherever complex design exists, there must have been a designer, so you can think about that beautifully designed website, and think about that designer at the beginning, and that's a really natural way to think, and a lot of people have thought about this way over the years. Thomas Aquinas took that further to say that nature is complex, therefore nature must have had an intelligent designer, and what Thomas Aquinas and other philosophers of his day were interested in doing was taking this to prove the existence of God. So this is normal for us to think about, and this is getting me, and it's part of thinking this way, this is the argument from design or the teleological argument, and thinking this way goes all the way back to Aristotle, Plato, Socrates, they all had a version of this, of thinking of design in this way, of there being some complexity, complex design thing, and some designer all the way at the beginning of it. After those guys, William Pele would describe what has become known as the watchmaker analogy, so a watch is a very complex thing, and he tells this story about his version of the watchmaker analogy, it's not the first one, other people had it before him, but his version is the popular one, and it's the story of walking across the beach, if you stub your toe on a pebble, and someone asks you where this pebble come from, you might say, I don't know, pebble's probably been here forever, but if walking across that same beach, you stub your toe on a watch, and you pick it up, and you wonder where did this come from, you'd be reasonable to assume that at the beginning of that watch somewhere, it was designed by some intelligent designer. Here's the watch of William Pele's day, not too bad, pocket watch, but he wasn't the first to have this analogy or this thinking, Sir Isaac Newton also believed that the planets worked in such a way that that they're very specific way that the planets always worked, and that they must have been wound up by some original watchmaker, some original designer. Descartes also felt the same way. Here's the watch from just before their times. Down here, I happened to notice a coincidence when I found this picture that this watch is hosted at the Walters Museum in Baltimore, so I was, so I'm gonna go on a little bit of a tangent here, but I was going to tell you you could go and visit it, but a guy that I work with, his fiancee works at the Walters, and I found out that she just brought it to Germany, so it's actually not there anymore. So somebody could update Wikipedia right now if they were, if they're into those kind of, those kind of contributions. So you'll notice this is a kind of a more rudimentary form of the watch from Pele's day, and also this watch wasn't worn to keep time, because at any given time, it was about four hours off. It was just kind of the idea of having a timepiece on your wrist in true beta fashion, right? So what watch came before this watch? No, this watch never came before. This was like a thing that people did in Sundial on their wrist. That's just a joke, but really before, before people had watches in their pockets or watches on their wrist, we all have watches on our wrists that are much more complex than in Pele's day. There's a long history of timepieces, of an evolution of design and redesign, right? So you've got the long history of timepieces that I'm not going to go into. Then around Descartes and Isaac Newton, the design improves, and Pele gets even better, and now we have modern day. I look a little bit like Steve Jobs up here today, I think. I've got one more thing. So there's an evolution. All right, actually, I wanted to say a little bit more about that. Let me go back to that. So there is some design, and there's advancements, and springs, and levers. There's feedback from users. The watch over time evolved. So this watchmaker analogy has some issues with it. David Hume, another thinker of that era, pointed out that the watchmaker analogy is not realistic. One example that he uses is how a machine or a watch is usually designed by a whole team of people rather than just one person, and that complex machines are usually the result of many years of trial and error, with every new machine being an improved version of the last one. An iteration, if you will. This is David Hume. This is a long time ago. So he pointed out some that it's not really realistic to think that there wasn't an evolution of things or that there wasn't this reality of how things develop. During Pele's day, Darwin lived, and Darwin actually believed Pele. He thought that Pele's watchmaker analogy was hands down the proof of how design comes to be, how things come to be. He was studying his thing, as we all know, and came to understand, came up with a theory of natural selection. He wrote, the old argument of design and nature as given by Pele, which formally seemed to me so conclusive, fails now that the law of natural selection has been discovered. So is there some big designer in front of everything pulling all the strings, or is design involved in an ongoing way as part of an evolution? So any creationists in the room, we're going to leave it at that. Don't worry, we're not going to go any further of that. But what that means, what this idea of evolution means for intelligent design, we're going to leave it for now because this talk is not intelligent design. This talk is agile design. I'm Kelly Albrecht. I'm with Last Call Media, and this talk is going to continue after a brief commercial break. So who is Last Call Media? Who is Kelly Albrecht? I'm a senior producer and agile coach with Last Call Media, working with leading brands, answering the question, what's next? And Last Call Media, who are we? We're a full service agency with strategists, designers, developers. We do everything from the initial strategy to the post launch support. And that makes us Last Call Media, and that brings us to the why. Watch out for the flying guy. We're working on some animations too. But we're Last Call Media. That brings us to the why. Why Last Call Media? Well, Last Call Media, we want to be the last call you need to make. We want to adapt as your needs change, be relevant throughout the life of the project and really be there till the end. And the way that we do that is in how we do that. And we do that by we've built an internal work culture of awareness. All of our meetings and all of our communication is all under the idea that we need to gain an awareness into how things are changing in the relationship, in you as a client, in the project so that we can adapt to that change and stay relevant. And the way that we do that is by working on being agile, being agile in projects. And we're going to talk about what agility is. And we're going to talk about since we do design, we have to be agile in our design also. So before we broke to commercial, we're talking about Darwin. I'm going to put up a quote from Darwin that I've seen. I'm seeing everywhere now. I think I've seen it in two other talks. But really, in some in in some sense, very simply, agility is adapting to change. And this adapting to change requires an awareness. So you can picture your favorite superhero, perhaps they're known for their agility. And they're in some skirmish with some bad guy. And they're maybe they're they're working on defeating one bad guy. And out of nowhere comes a punch. And they dodged that punch with their superhuman agility. They did that with their awareness. Some maybe they had maybe it was their spidey senses. Maybe they can see the future and they saw a punch about to happen. Somehow they were aware of that change to their reality. And their agility was in adapting to that changed environment and ducking instead. So we don't have to be superheroes to do that. Perhaps this this person just had good hearing. And they heard some commotion and they dodged it. So we as non superhumans, we can be agile too. And even in some sense, when you it doesn't feel like the most agile thing when you have to cancel your dentist appointment. But in some sense, that flexibility on everyone's part in that event is on somewhere on the scale of zero to agile. You've adapted to a change. And you're what you were going to do suddenly became not the right thing to do. So you did something different. And so agility is good. Here's that quote from Charles Darwin, where the key piece is not the most intellectual, not the strongest, but the one that is able to adapt and to adjust best to a changing environment. And in a very simplistic sense, that is agility. And that requires awareness. It is the awareness of a changed environment of a changed reality that enables you to react and be agile. We have a lot of tools at our disposal for being aware of things could be could be ping them monitoring your server, letting you know that it's down. Maybe your plans change if suddenly a server is down. But it could also be some interpersonal skills and values that you use on your team to gain awareness into what's going on with the other people in your team so that you can adapt your team dynamic. But agility is more than that, I think. So I for a while I was thinking, everything up to now, that's what agility was. But lately I've been thinking, due to some inconsistencies with just that way of thinking about it, I've been thinking that it's a lot more than that. And here's here's how I'm thinking about this. So if you can imagine, on one side of a scale, you have deliberation. And on the other side of the scale, you have what I'll call hair trigger action. So deliberation is thinking. You're thinking about something. Maybe you've been made aware that this server is down. What are you going to do? You could think about it forever. Just you're deliberating what's the right thing to do? You could you could plan it all the way out. First, before I act, I'm going to log into the server, write it down. Then I'm going to check the logs and write that down. Writing on a plan. You could do that forever. Whereas on the other end of the scale, we have hair trigger action, which is you can think of as like pure reflex, right? My hands on the stove. Ouch, I move it. Just without even thinking, you just do it. Okay. I think agility is how you work from deliberation to action. Agility is measured by the speed and effectiveness of your response. Here I want to talk a little bit about how this talk is called Agile Design. There's also designing with agility. Designing with agility is balancing your awareness and your deliberation of what you become aware of with your speed of response. That's your agility. That's how you act. I think that's a little bit different than when you determine something to be agile, such as design, right? What makes design different than agile design? For something to be agile, I submit to you that it's something that needs to bring awareness to the work and to the people working on it to enable their agility. That thing also needs to have within it a way to allow you to change. Let's try this rule about what makes something that you do agile on a more familiar agile topic. Scrum. Scrum better be agile. That's what everybody says it is. Scrum has a number of things in it. Scrum has ceremonies. Scrum has values. Scrum has iterations. For Scrum to be an agile way of working, an agile way of a self-organized team managing getting their work done, it needs to bring awareness to the team and to the work. So ceremonies, the ceremonies are the things that you do periodically, the meetings, right? So the daily stand-up is a ceremony. The sprint retrospective is a ceremony. Sprint planning is a ceremony. These ceremonies, I think these ones are easy, right? You meet a stand-up, you meet and you say what you're working on yesterday, what you're working on today and where you're stuck. You're bringing an awareness into your team on what you're doing and where you might be stuck, enabling them, your team and yourself to adapt to a place where you're stuck or a place where something's taking you too long. I'm not going to touch on values because that's a talk in and of itself. And iterations, how are iterations agile? So an iteration is a certain amount of time that you decide that you're going to work on something before delivering and reviewing a working increment of some overall project vision. So iterations are agile because they aim to provide an optimized awareness into a larger effort and that awareness enables agility. What I mean by optimized is you're delivering a working increment so that you're giving the best awareness possible and awareness into a broken thing is not useful. You want to work with it for a period of time and get it to a point where here's a good time to look at this to be aware of how this is going so that you can decide if this project is worth continuing or not. And that's how iterations are agile. So while we're talking about iterations, I'll throw a little bit of a wrench in the gears with this statement. You never get a second chance to make a first impression. Who here's heard this statement? This was a very successful head and shoulders commercial. I don't think it was the first but it was one that really took off and it really resonated with people because we all we all understand this, this critical moment that we're approaching where we need to get everything right and we don't want to fail. Designers understand this instinctively. And I think you can understand the pressure and the importance if we imagine some situation like today. I chose my clothes. I had to think about that. I had to decide how much I was concerned with with the impression that it was going to make. I can feel everybody looking at me right now. But it's a lot of pressure and even even studies back it up. This is just you can't read this but I'll put these slides up but you can Google this kind of thing. There's tons of studies where the design appeal can predict rejection of a website. And I added in this other part of the study where personalization of content can predict trust of a website. Both of these things take deliberation and intentional decisions and a strategy to decide to implement them. And so when these are these things are the case you can understand this is a lot of pressure and stress to put on the design team. Where what they're being asked to do is to maybe design something that that produces a trusting situation. Right so that's a lot of pressure. That's something that you want to take seriously. That's where you might feel like as a designer you're on the hook for a big thing. And it can feel wrong to do that in an iteration where basically you're saying this first iteration is just you know some broken part some broken part of the vision that's going to get better. So there's a lot of tension there. And one one of the things that relieves tension and stress and that type of pressure is planning. Has anybody experienced this where you're overwhelmed. What I'm what you know how am I going to do this thing I've got too much to do there's too much pressure. Plan it out get the steps out. Now there's a plan that I can follow. Right so so taking this too far and this has been criticized as we've evolved our way of thinking of about getting work done to be called big design up front. Big design up front is a bad thing. But so there's so there's a tendency to relieve this pressure to and there's a comfort in and a desire toward wanting to do as much discovery and planning and specification as possible. One of the ways that this comes up in scrum is as a sprint zero. So before we actually sprint follow scrum there's the desire to have this thing called sprint zero which is just basically a big a big planning phase and those can take really long depending on who's deciding what sprint zero means. But there are problems with doing too much planning up front when change is inevitable. Larger larger plans have larger releases and have more work getting released and that means more can go wrong. Having these bigger these bigger plans and bigger releases leads to a larger quality assurance effort. More effort wasted and more effort is wasted if the idea of whatever it is that you built turns out to be slightly in the wrong direction. More planning equals more features more bugs increase costs and a lot of this happens in these large QA phases and big planning on how to launch this thing at the end of a project just when everybody's ready for it to be over. So there's been a little bit of a backlash against this idea of big design up front big planning in general but to go the other direction what can go wrong if we don't plan. You know besides the obvious like you leave the house without your coat because you didn't want to take a minute to check the weather and decide what kind of day it was going to be. Other things can go wrong too if you don't plan. Not planning in an agile methodology has consequences. You can think of haste makes waste. For example a partially developed design is risky to show. If you if the design is not well thought through enough if there hasn't been enough deliberation in what we're going to do you can build something that could that is that is a less than product and when that awareness of that not thought through increment is brought to the stakeholders they could cancel something that is actually really a good idea. Right but so you need to think you need to think things through it's important. So we don't want to just throw planning out the window and just be hair trigger action agileists. If you don't think things through if you move too quickly you can actually develop a planning a design or planning debt right where you haven't thought things through enough of enough of the way and then when you're trying to add other things onto the project that can come back to bite you later. So actually not planning in agile is not agile. Agile has tons of planning in it. There's grooming in agile where you're working through the tasks that you want to do and you're thinking about how you're going to work with them and design them both in the architecture of the site and the design of the site. There's sprint planning just straight planning about how you're going to run the sprint. There's forecasting there's sprint releases. So how do we plan how do we design but not design too much. We do this by understanding what agility is and we've been talking about it a little bit but I was talking with my friends and we were talking about how as kids we didn't agility was that one thing that metric that kind of didn't make sense right. I don't know if anybody's seen this in a video game or on one of these cards but this third one down here is agility. Spider-Man has really awesome agility. I always got what strength meant like he would beat someone in an arm wrestling match because he had more strength than them or speed beat them in a running race but agility I never really understood what that really meant but now I think that agility is bringing good thinking to action quickly. So we need to reconcile these two. We have thinking too much designing too much planning too much and and acting on one on one end on the scale of the deliberation to actions. How do we reconcile between doing too much of one or the other and really it's a balance. How do we balance those two? So how do we reconcile those two deliberation and action for iterative maximally effective experience events because you want to have that best impression possible but you want to actually have it because you need to release the work to have it and you want to have it quickly to know that whether or not you're going in the right direction because you need that feedback. You don't want your wristwatch to develop slowly over you know two three hundred years. You want to move faster than that. So you need to figure out what version of this design is going to achieve this successfully to me to get successfully for the team so that we can get the feedback we need to do another iteration on it. So let's start with a traditional graphic design example where the web design is just one of the things that comes out of it. You'll see things in this example get produced like you'd expect. There's actually not really anything newer exciting about how this work comes together but I'm going to describe this work in the context in the mindset that I've been laying out in the talk so far. So first before these little items get produced there's a limited discovery just enough to get some ideas. There are no bad ideas. We want to get to the part where we can start producing these small high fidelity pieces so that we can get feedback on them and converge to a solution. And so I say high fidelity because you need it to be high fidelity rather than just sketches for that optimized awareness into a direction and small so that you can produce them quickly. So from the feedback from this some of the feedback on this particular project was that they didn't want it to be too political. So that crosses out these and this one is just not that great. There was an idea during the feedback session for after these for a state fair and that became this which was the logo that they ended up going with so we converge to the solution. So for a further study on some of the stuff that I'm talking around right now you can google design thinking. Design thinking is part of the effort to think about how we design better. So further reading would be googling up some stuff on design thinking. But logos are great if you can start from a logo. They are small. They can be small and high fidelity and settling on the logo gets you so much more. We're able to do a color aesthetic and a font that was informed by this logo. So designing in this way each piece can build and be informed by the previous piece following the same feedback response cycle each time with each iteration. And you have the logo. You have the color aesthetic. You have different elements coming from each of those pieces and you can pretty easily without much pushback from a client very naturally work your way up to something bigger. So the web design finally comes together evolving out of a very collaborative process of discovery action feedback and response. So does design happen from a designer in a way it does. Obviously obviously if we stubbed our toe on this design on the beach we'd be reasonable to assume that there was a designer or a team of designers right we're not going to argue against that. But we don't want to forget about the evolution of how this naturally came together with collaboration with the client with the feedback. It wasn't just some grand plan that just big bang kicked off some design that came out of the end. It was a collaboration. It was a natural working with the whoever gives feedback on a design so that you can hone it in converge it into something that is the best the best representation of what it is you're trying to show or say or achieve. It even went a little further. This was some flyer material or different signage that they could use and it's all consistent and builds and evolves out of a collaborative design process. And I could have described all of these steps in a much different way but it's possible to understand how we do this work within the context of what I was the whole thing I was talking about in the beginning of the presentation. So another example that I think is really interesting is when you take user testing. So designing in an agile way to get that feedback to bring that awareness to your work is to get something that's good enough for a user to test. This is this is this is incredible. I don't know who's done some user testing. It's it's amazing right. So the most recent site we did was an e-commerce site. One of the questions was do you trust this website? And a lot of people very clearly did not trust the website. The homepage looked great but the interior pages were a lackluster in comparison in terms of design. And this led to the so we can read those studies that I showed that you know you can Google up the studies but to hear it come from somebody who's who's just a real person and to hear it come from them to say that well the homepage was great but when I got to these interior pages I just thought this site was I don't I don't trust this site. I wouldn't buy from this site to hear them like to hear them say that you know it's just like ouch but it's true right. You can't have you can't have that out there in the wild. So when you know something like that why would you not just work to change it right away? Right so that's kind of like the superhero with senses the fist coming out of nowhere. You just you have to do the right thing and that's that's your agility. That's important. How are we doing on time here? We got probably 15 minutes. All right I thought I don't know if I don't know if we're gonna be able to hear this but I included this one this is my daughter just to show you that you don't have to do like a professional user testing service. You can just have anyone other than yourself look at the site is beneficial. I don't know if we're going to be able to hear let me see. No no audio. All right so I'll just talk as it plays. So really what what I asked her was to find out if uh if last call does design work and this version of our website she immediately found the menu and found the what we do. So does last call do design work? Well let's see what they do. This version of the web page had just our client logos on it and the idea was that here's what we do as seen through who we do it with and that sounded cool and everybody was on board with that but by asking her to find out if we do design work what was obvious with this was she found the what we do page and she found the logos but then it was obvious that by watching someone else use the website that we were asking our users to hunt and peck through our clients to see if there was some evidence of design in that in that portfolio of that client work and so that was a big that was that was bad and then what would you do is if people were going to come to the site they weren't going to know what we did and so she kept it was funny she kept she'd go into one of the clients and then she'd go back to what we do as if there's going to be something different on the page this the second try but um but it very you know she's 10 and she's like this was confusing you know it said what we do it should be in here so you know you don't have you can just ask anyone to use use your stuff and you're going to get some insight and awareness and your design and your agility is what you do with that so we were sprinting on this project I brought this to the to the team right away design and development we're all working on this together and we just this was urgent this had to change there was we weren't going to launch it like this and just like change it in phase two like that doesn't make sense this had to get fixed and so you can go to the website you can see you can email me tell me if we fixed or not but we made a change we didn't do a big change we we figured out what can we do quickly that's not going to you know delay our target for launching this so we we deliberated and we acted quickly we balanced that deliberation against the action and I think we came up I think we came up with a pretty good compromise that you know we'll get back to it we'll we'll make it even better but but we had to act while we're talking about how's everybody doing so far so while we're talking about agility and and design here's an example we might as well talk about design sprints I don't know if everybody knows this but I read somewhere that 2016 was the year of the design sprint did anybody know that for further reading you can google google ventures design sprints they have this this whole thing about it they're they're super into it and it's really just a week when each each sprint each design sprint is a week and they lay out what you do each day to to get the ideas out to prototype the best ideas and then refine the best idea into something working that you can that you can decide whether or not your product is going to get off the ground this went a little bit different than that but but it's worth mentioning that you should check that out for for agile design so let's do a quick design sprint story I might get this a little bit wrong because our creative director was the product owner for this design so he's the source of truth on the details here but on day one there was an extensive onsite meeting with the client to learn what they do and what they want and an internal follow-up meeting to bring the team up to speed so gain and gaining of awareness a discovery a bit of deliberation on how we're going to move forward to that next reviewable point day two designer and the illustrator worked with the product owner designed as many aesthetic directions as possible in a short amount of time as they had on day two and produced illustration assets for use in the designs and they were able to get feedback on this day three they expanded the aesthetic directions and refined the illustrations and they scheduled an end of the day check in to establish a path forward so here's what we've done so far what do we think are we going in the right direction which one you know which version of these it feels better what what do we need to do to adapt to correct course day four applied the selected aesthetic to a single page of a website design deliverable and they had there was an end of the day client check-in for the single page of design before it was applied to the rest of the deliverable so a lot of inching forward doing good quick doing good work within a short amount of time and getting feedback and then doing a little bit more and feedback and a little bit more so logos weren't originally in the project but I think that things moved ahead a little bit quicker than than people anticipated so there was a we should do around logo designs let's see what we can produce quickly and so on day five around the logo designs expanded the single page design to a full website design deliverable so the very small website scheduled another check-in to select a logo for feedback and a full site deliverable this was the logo they ended up going with I'll just bounce back for a second this one right here so these were all produced this one was more or less settled on with some refinements and pretty easily became this one on day six so this is actually a seven day effort not a five week five day week-long effort so it's a little bit different so on day six the logo was refined the web design was polished up a little extra design work was squeezed into this day and I have a note here that there was a scheduled client check-in for high fives so here's some shots of what was originally designed this wasn't a building it wasn't part of this whole thing but it was able with a with a with a good relationship with the client a lot of synergy and alignment on on aspects you know so there was we're fortunate to have some of that you don't always have that it is possible though if you have those things to move to move that quickly and put something like this together so on day seven a website design was handed off to the client's developer and we even exported the image assets and uploaded the designs to Zeppelin for the for the developer to work with okay so that was a design sprint seven seven days so it's possible but really the the collaboration and the feedback and the gaining and awareness and adjusting course you can you can inch and evolve your way pretty quickly to a final product all right so I told you earlier that I'd reworked this talk and I was worried about running out of time so there are some other stories that I that I pulled from it so that I could do this one and leave time for QA or anything but before I tell this last story one of the things I cut and I think I'll try to insert it into this last story a little bit is you can also do design if you're doing in a scrum project and you're working with your initial backlog or you're grooming your backlog as you go you can include design in what it takes to get alignment on each one of those items how many people are familiar with what a backlog is in a scrum project okay pretty good okay cool yeah so any one of those epics or stories could have attached to it like here's how this needs to work and if it could look like this we'd like it to look like this as much as possible so you can attach the designs to that or you know wireframes working with the client this is how we think it's going to work you could even prototype it out Drupal is great to prototype things so they can try and feel it and feel some of the workflow all that is possible during the backlog grooming process just to get that alignment on how things are supposed to work let's see another story that I cut was about having to design involved in the development process a lot of people are nervous about this I think one of the one of the potential risks that you might think of right away is if we have this designer in the development process they're going to scope creep this whole thing they're going to come up with ideas they're going to change directions this is going to we need to we need to get design out in its own phase and get them to do their thing and then we're going to develop it but actually what had a couple of stories that I cut that were basically about how what tends to happen instead is that the design tends to be more realistic because you're working with developers on what is the sensible thing to develop and there's a lot of back and forth on what how should we design this so that it's the most realistic to build and so you actually get more efficient designs that are more efficient to build so this last this last story is so we don't want to wait if we're watchmakers we don't we don't want to wait for the perfect watch to be designed before we start developing it right so we didn't wait until something as complex as an Apple watch was designed before we started developing watches we designed just enough so that we could build something that then we could improve on we make it then we make it better and then we make it better again so designing with agility is designing just barely enough to get to the making and then designing more and I learned something interesting the first time that I tried to do this on a project we had a project where it's not launched yet but it's the Utah Museum of Fine Arts and we started with minimal so I'm trying so on this project I'm trying to stay true to some of the things we're talking about in this talk so we started with the minimal design required for initial backlog refinement and wireframe so we had wireframes prototyping but only enough to get alignment on some of the aesthetic alignment on how the functionality would work and we began development as soon as there was alignment on the functionality so if we so the site supposed different parts of the site are supposed to work certain ways let's get started on that so this is different than jumping right into development that soon was different than a more traditional way where you do discovery until the discovery is over then you do the specification until the specifications over and then the designer does their thing and then you develop but what I found in doing not a full design phase and starting developing right away I found that people are really comfortable with these phases and the separation of the phases and the process involved there's a I think there's a there's a safety people feel and a comfort in having a phase all to themselves where they can focus on it and having the phase before their phase being completed fully and being fully handed off to them so they can take that and they can complete their phase fully and hand it off to someone else there's a comfort in that to do it all at the same time feels chaotic so I discovered that that was something that we needed to work on so first I tried to design pieces of functionality with the intention of then taking all those little pieces and then tying them together in one overarching design and that didn't that didn't really work so much one of the things I discovered there is that when you're trying to design a website you're concerned with an overarching aesthetic a general affect that the site is going to have on its viewers and to go piece by piece you can't really you can't really develop that that overall feeling that overall experience so there was a conflict there that needed to be reconciled then so that was one thing and then developing the functionality before the designs one thing that surprised me is in sprint planning there was a lot of explaining that we needed you know we needed a content type to do this thing but then the question was but what's it going to look like it's like well it doesn't really matter just we just need to fill out the form it's like okay so that one doesn't matter and get to the next one we need to have a view of these items that have gotten added before that just needs to be a you know how about a table but what's it going to look like you know that like the development was used to or comfortable in having this idea of how it was going to fit into a bigger picture and it was very unnerving to have that taken away so that was another that was another thing to cross so dealing with these things took some conversation you know retrospectives were important it was important to for design to be able to do that over overarching aesthetic we just have to do that you have to have that that bigger picture piece one of the ways that that plays out is in the when you're developing different pieces of functionality we do a pattern library so is everyone familiar with pattern library there's been a lot of pattern library talks so it's really getting alignment with everyone on the team that you can develop that piece in the pattern library and if the overall aesthetic color scheme spacing of things if that changes you're not really losing too much work if you've if you've developed a pattern for that thing because there's a lot more work than than this than this than the padding or the color of the thing in the pat in the pattern library so the overall aesthetic can change and you're not really wasting too much time to just adjust those patterns in the pattern library but not everybody across the whole team knows that but you need to share things like that you need to get into alignment on things like that with the whole team so that people feel okay with the fact that we may have to tweak the general aesthetic of the site even though we've built most of the functionality and built patterns for the initial piece of functionality so so a lot of working together as a team just to accept the different way of working but it's working great the site is almost done and it's really been a success to work that way but we had to we had to reconcile the fact that we don't always have all the answers given to us at the start in life and doing complex things together we don't always have all the answers and that's okay so I'm gonna go to the next slide having most of the team waiting while a few people plan and design everything out is wasteful the team was ready to go we all wanted to get started it doesn't make sense to have a few people planning the whole thing out from beginning to end the trick is to figure out what's the minimal amount of planning and design to do to get started so the reality is is we can expect to have things to figure out as we go and we should do it together so design should be part of the team and we should be designing together and developing and making together we should do it together guessing right or making mistakes listening and correcting course this is how we work it's in how we work that lets us do more together better faster thank you so I left some time for any questions anybody might have KS Albrecht Sprint Day feedback thank you hi you you talked a little bit about prototyping have you ever or experimented with your teams designing and medium kind of like compiling the static design and the prototyping and medium together do you mean it's a develop I'm not sure I understand what do you mean by medium like in HTML and CSL so instead of like doing it and sketch or Zeppelin like kind of doing the designs and what the final medium might be yep yep yeah yeah that's super that that's super helpful and also I think it's really nice in the different tools that can let you get that CSS you know I think sketch lets you do that so that's really useful and then yeah just design just designing in that medium brings you that much further so if you have that skill that's that's definitely a plus hi um I'm a front end developer as well as our UX UI person and I know sometimes I can get caught in the trap of thinking that when I'm trying to design something I have to start from scratch like a brand new idea but I've also come to realize that there's a lot of value in looking at the things that have already existed to solve certain problems and looking at their successes and failures have you had experience with that I think that's the way to go I think looking to where you can reuse something that's already out there work as a community of designers to standardize on things I think you know the different frameworks that are out there Bootstrap goes a long way to that there are other ones but yeah and that's really the beautiful thing about about a pattern library is it changes the thinking from always doing a one-off or starting from scratch to here's what's in our library if you're going to have something new what collections of patterns are going to come together to assemble that new thing and if there's a new thing to create create it and add it to the library but yeah get away from the from the one-offs another thing I'll say about that is from a enterprise architecture point of view avoiding one-offs is avoiding risk because one-offs are new untested you don't know what's going to happen but you can build a library of tried and true design patterns that you can pull from and so if you're pulling from the community from something from something like Bootstrap or from your own tried and true pattern library that you built that that's the way to go yeah hi I'm interested in your case studies and what kind of discovery went into it beforehand I know to your your key point was too much planning is not a good thing but I'm wondering what kind of sense you had of the client's goals the target audiences and just what kind of content they wanted to highlight first and then also a frame did you have a framework of a project plan for the NTC project and the computational client like what did you have before you started that sprint the design sprint yep so might have to catch you I'll do the best I can right now but I might have to catch you later for some of the details on those I think for the computational cardiology I think it was mostly an agenda of each day what we were going to try to do each day and then that agenda evolved as the project progressed so that was really just that first day that was discovering who they were what they were trying to say and who they were trying to say it to for the Museum of Fine Arts we did that as part of backlog grooming so when so some of the backlog items would be different landing pages and site structure so there was some work along the way of here's the here's the site structure we think might make sense like our first best guess and then we've reviewed it with them we actually we did we did that site structure and we did like a strategy document where we took everything that they sent us and then we basically wrote our response as the site strategy and then we we had that strategy document and we had their existing site structure and we said here's the site structure that we make that we think makes sense according to our strategy so there was information from them and then we put together our response then we flew out there and for two days we went over it and refined it and changed it and did things and really got them on boarded to the to how we wanted to work together and so then they took our response and they worked on what they thought and gave us back their response and during that while we were waiting for their response on those things we worked on the design aesthetic that we that we were feeling would make sense after the visit so that was how that those initial pieces went there hey hi my name is Megan Davis I'm a project manager with the mass doc of state redesign project and we do work as a team in Agile but the smaller team that I manage of about 10 have not historically worked with Agile and so there's a lot of resistance I think to the process and like some discomfort with Agile and I'm wondering if you have any advice on how to bring along a team that it's not historically worked in Agile and may be resistant to kind of the change that it yeah I think I think I don't know if I highlighted enough in this talk but I I feel like really it's acknowledging what's hard about that you know I think there was a lot of stuff that I learned along the way that that I didn't wasn't really aware of that's really important to designers right I think I remember one retrospective it was pointed out to me that we were design was saying here's what we've come up with for how this looks and I would just say that looks good enough that's what we're going to launch and it came up in a retrospective that that they they need more feedback than that I was I was afraid that if I said well that that looks like the padding is a little too big I was afraid if I said that it was going to be back to the drawing board time and so I had to learn and acknowledge that there's something going on on with with design because they're on the hook for something bigger some you know some some bigger there's a bigger responsibility underlying that and so I think acknowledging it and finding a way so I had to find a way to to say that well I'm fine with launching like this but just you know and I think it looks I think this is going to be great for this first iteration that padding is a little bit off because sometimes you know I think if you say it that way and I don't know if this applies to you but I think if you say it that way then you might get a response back that you weren't expecting like oh we can change that but we're not going back to the drawing board that kind of thing another another example is was pointed out that you know oftentimes design puts their whole heart into you know the version of it that they're going that that they're going to deliver and they've thought it through they've really like here it is and if you iterate on that too much by the by the third or fourth time they're just like whatever I'll just put this wherever you want so it's really it's really in in I think communicating and acknowledging what's hard and just you know trying to figure out you know their their feelings are real so yeah bring them in and care and and you might learn something that you'll adapt how you're doing things come you know coming from why they're uncomfortable hey man preach into the choir about involving designers throughout the process coming more from the development side of things and you know you if you just kind of like have that phase and there's the divine design phase and then the design just gets handed to the developers and there's so many things that yeah come up in terms of the you know the actual you know real world right of what's going to happen on the site or on the platform yeah so how do you but how do you actually make that happen like what what are the like day to day ways that you integrate the designer and the developers like is it is it when you're doing stories or are there you know just practically how to operationalize that because I'd love to do that but I would like to have a good proposal for how to sure well so the first the answer that comes to mind I think has to do with that I'm often in the product owner role and I feel that I would take that responsibility on myself as a product owner to work with design and try to get something to a place where you could bring it to sprint planning so this is some version of what we want to do that we can actually build and I'm going to bring it to design and it's not the perfect version of what we're going to build so there's still some things to figure out but just get it to that point where where I want to get and sometimes you can get you can have a quick meeting with with the developer and they'll say they'll point some things out that you need to figure out you know this doesn't make sense this is there's a logical inconsistency with what you're trying to do or whatever but once you get it as soon as you get it to that point where you can start making it you bring it to development and so when it's at that point there's still going to be design things to figure out and and so the developers will have questions and so at that point they have to ask design and you're getting and then they're they're collaborating at that point Hey, how's it going? So I'm a front of developer I'm a former designer and I work with a small team about probably eight or nine people and usually what we do is to go back to what you were saying is we have probably like lunch and learns at the end of the month so technology involves a lot so I need to keep up with the speed of things and I educate the designers occasionally I work with very traditional print designers where things go out they get printed in the reel and you can't take it back because they got they they pushed out probably yeah 40,000 copies right most of our clients are universities so it's very important that things are like precise and designers are like oh no it's responsive that typography is changing sizes from 12 to 18 we can't do that yes so your iteration would happen before printing it yeah and the printing is that final that final iteration yeah so as as a front end developer I have to be sort of the catalyst to help the designers move forward so weekly at the end of the week lunch and learns or monthly lunch and learns is a good method thank you for that yeah so and there's other sessions starting but yep K.S. Albrecht kelly at lcm.io but yeah I'll be around all day thank you thank you thank you