Agile Design

Cross-functional teams, unlike silos, have all the people necessary to build a specific thing together. Let's look at an example. Imagine you're on a team that is supposed to build the onboarding flow for a new app that helps connect job applicants with jobs. You can't build the whole thing with just designers. Or with just engineers, for that matter. I mean, you probably could do it with just engineers, but it's a terrible idea.

A cross-functional team for this onboarding work might include a few engineers, perhaps some for the front end and some for the back end. Might include a designer, a researcher, a product owner or manager, maybe a content writer or a marketing person. In an ideal world, all of these folks would only work on this particular team. In the real world, where we actually live, sometimes folks are on a couple of different teams and some specialists may be brought in to consult. For example, if the team needed help from the legal department to explain some of the ramifications of a specific decision,

a cross-functional team would have a dedicated legal expert they could go to. But that legal expert might also work with lots of other teams. In agile environments, the cross-functional team generally sits together or if remote, has some sort of shared workspace. They all go to the required team meetings. They understand the goal of the team and the users. They're experts, or they soon become experts, on that onboarding flow. Contrast this to how it might be done in a siloed environment. In that case, you might have different people assigned to the team depending on need, which can seem really flexible.

Until you realize that you end up with five different designers working on the project all at different times and they all have to be brought up to speed and they don't really understand why the other designers made the decisions that they did. Same with the engineers. And do not get me started on legal. Silo teams tend to rely more on documentation that gets handed between groups. And this can lead to a waterfall project where project managers or product managers work on something for a while to create requirements, which they then hand off to designers who work on designs for a while

and then they pass the deliverables on to engineering, who immediately insists that none of this will work and demands to know why they weren't brought in earlier for consultation. You get it. By working in cross-functional teams instead, the people embedded on the project get comfortable with each other. They know how the team works and can make improvements to it. They come to deeply understand their particular users and their metrics. They actually bring engineering and even design and research into the decision making process early to avoid the scenario I described above.

A really hard part about agile design  for a lot of designers is this idea that we're going to put something out  into the world that isn't perfect. It's tempting to spend a lot of time tinkering with things, adding those little elements that we think will delight users. A lot of those things tend to get skipped on agile teams, and that can be really disheartening, frankly. The thing is, they're *not supposed to be skipped* on agile teams. It's kind of sad that they often are, but on good agile  teams that are constantly iterating and improving,

there's plenty of time to add those touches  and to perfect the design. The key is *not to do it too soon*, and again this can be tough. A lot of designers seem to have some sort of belief in the idea of good design as its own thing, like there's a cosmic governing panel that decides whether something is well designed that's totally independent of whether the product makes users happy or makes money for the company or makes the world a better place. And it's a tricky balance. I'm the first one to point out that if you release an incredibly crappy product,

you're not going to learn anything other than whether or not  people like to use crappy products. We're already pretty clear on that – they don't. On the other hand, if you spend months tweaking the fonts and obsessing over every single word or loading the product up with unnecessary features, you're very likely to waste a huge amount of time and money building things that nobody cares about but you. I really wish I had a simple system that would allow you to decide when you've hit *good enough* every single time. You know – a "Can I ship it yet? [] Yes [] No"; maybe someday we'll get that working.

Until then, I want to talk about cooking for a  minute. Stay with me; I promise it'll all come together. It might make you a little hungry, though. Let's say you're cooking dinner, and the first step in this brand-new recipe  you're trying out is to cut up some potatoes. Now, if you do a terrible job of it and hack them up  into uneven pieces, it's probably going to ruin the dish and make it inedible because half of the potatoes will be raw and half will be overcooked and mushy and the whole thing will be awful. If you're not much of a cook, the important thing to understand here is that things of wildly different sizes tend to cook at different rates.

And that ends up with some things being overdone and some things being underdone. So, instead of doing that, you take a little time, you use good knife skills and you cut the potatoes better. But now you have to decide how much  time you're going to spend on the potatoes.  Obviously, you could make them perfect, where  "perfect" means all exactly the same size and shape and weight, or cut into animal shapes or  trapezoids or whatever. Molecular gastronomists have almost certainly discovered the golden ratio of surface area to interior of potato,

and I am sure that they would love to tell you all about it.  But the more time you spend carving your potatoes into identically sized polygons or whatever, the  less time you have for cooking the rest of the meal. And, frankly, having the potatoes perfect  doesn't contribute that much to the overall meal. The end result of perfect potatoes might not  be *noticeable* to the person eating the meal, and even if they did notice, it wouldn't increase their enjoyment of the meal enough to justify the time it took you to do it.

Nobody wants perfect potatoes  at midnight. They want good potatoes at 7pm. Remember, your goal isn't to make a perfect potato,  whatever that means; your goal is to *make dinner* – preferably a dinner that people enjoy eating. And what even is a perfect potato, anyway? Maybe you get them all the exact same size but they're still  too big, so they take too long to cook, and what you should have done was make them 20% smaller so that  they came out at the same time as the rest of the meal. Or maybe what makes a potato perfect depends  on who's eating it. I mean, if you're ever cooking it for me, just make mine sweet potatoes and just  go ahead and fry them, OK?

So, what's the solution? *Satisficing and iteration*. What is satisficing?  That doesn't sound like a word. Satisficing is a decision-making process that aims for *adequate or good enough*. What makes the potatoes good enough to eat and enjoy but doesn't take so much time that you never get them on the table and you don't have to take a bunch of expensive cooking lessons just to get them right? By the way, before you get mad at me and say, "We shouldn't just be going for good enough!" – *yes*, we should!

That's what *good enough* means! As long as we're not defining good enough as "barely edible" – we're just defining it as something we can make that people will enjoy eating. In agile design, we're also often saying that good enough is something that people will be able to use to *solve a problem* and that we can *learn something from*. What we want to learn is: *What would make the thing even better?* Because on agile teams and, honestly,  when cooking potatoes, we get to *iterate*. I mean, no, you're hopefully not going to just keep  throwing out the potatoes and doing them over and

over and over again before ever serving them, but  the neat thing about dinner is that a lot of us eat it every night. We can try these potatoes  tomorrow or next week or whenever we feel like it. Maybe we wouldn't try out a brand-new recipe  if our boss was coming over for dinner, but you could practice making  potatoes as often as you want. Same with a lot of the kinds of products  that we build using agile technologies. We get to make things and share them with subsets  of users in safe environments and get feedback   and then make them better. And the cool thing is  when we iterate like this we actually start to develop an idea of what *better* means.

Let's say the first time that we make the potatoes we cut them roughly the same size, but we try not to stress too  much about them being a little off. This lets you get the potatoes on the table so that you or your  family or whoever you are cooking them for can try them. Maybe the potatoes would be better if you cut them a little smaller. Maybe the dish needs twice as many potatoes. Maybe you decide to substitute  cauliflower potatoes like a terrible person who hates food. Maybe the problem isn't the potatoes at all – it's the spices; they're all wrong; you didn't see that coming, did you?

You'll have a much better  idea of what *better* means once you've shipped the meal and gotten feedback about what people liked  and hated and what they left on the plate and why. This is why I say there's nothing wrong with aiming for good enough, especially on the first few versions of something. Good enough doesn't mean gross and inedible, and it doesn't mean too broken or bad to learn from. It definitely doesn't mean we're never improving on it. It means we're getting something out that is *good enough to get feedback on and then we can improve it over time*.

Besides, spending less time obsessing  about the potatoes lets you spend time   on more important things like the fact that you  should have just made dessert and ordered a pizza!

A really hard part about agile design  for a lot of designers is this idea that we're going to put something out  into the world that isn't perfect. It's tempting to spend a lot of time tinkering with things, adding those little elements that we think will delight users. A lot of those things tend to get skipped on agile teams, and that can be really disheartening, frankly. The thing is, they're *not supposed to be skipped* on agile teams. It's kind of sad that they often are, but on good agile  teams that are constantly iterating and improving,

there's plenty of time to add those touches  and to perfect the design. The key is *not to do it too soon*, and again this can be tough. A lot of designers seem to have some sort of belief in the idea of good design as its own thing, like there's a cosmic governing panel that decides whether something is well designed that's totally independent of whether the product makes users happy or makes money for the company or makes the world a better place. And it's a tricky balance. I'm the first one to point out that if you release an incredibly crappy product,

you're not going to learn anything other than whether or not  people like to use crappy products. We're already pretty clear on that – they don't. On the other hand, if you spend months tweaking the fonts and obsessing over every single word or loading the product up with unnecessary features, you're very likely to waste a huge amount of time and money building things that nobody cares about but you. I really wish I had a simple system that would allow you to decide when you've hit *good enough* every single time. You know – a "Can I ship it yet? [] Yes [] No"; maybe someday we'll get that working.

Until then, I want to talk about cooking for a  minute. Stay with me; I promise it'll all come together. It might make you a little hungry, though. Let's say you're cooking dinner, and the first step in this brand-new recipe  you're trying out is to cut up some potatoes. Now, if you do a terrible job of it and hack them up  into uneven pieces, it's probably going to ruin the dish and make it inedible because half of the potatoes will be raw and half will be overcooked and mushy and the whole thing will be awful. If you're not much of a cook, the important thing to understand here is that things of wildly different sizes tend to cook at different rates.

And that ends up with some things being overdone and some things being underdone. So, instead of doing that, you take a little time, you use good knife skills and you cut the potatoes better. But now you have to decide how much  time you're going to spend on the potatoes.  Obviously, you could make them perfect, where  "perfect" means all exactly the same size and shape and weight, or cut into animal shapes or  trapezoids or whatever. Molecular gastronomists have almost certainly discovered the golden ratio of surface area to interior of potato,

and I am sure that they would love to tell you all about it.  But the more time you spend carving your potatoes into identically sized polygons or whatever, the  less time you have for cooking the rest of the meal. And, frankly, having the potatoes perfect  doesn't contribute that much to the overall meal. The end result of perfect potatoes might not  be *noticeable* to the person eating the meal, and even if they did notice, it wouldn't increase their enjoyment of the meal enough to justify the time it took you to do it.

Nobody wants perfect potatoes  at midnight. They want good potatoes at 7pm. Remember, your goal isn't to make a perfect potato,  whatever that means; your goal is to *make dinner* – preferably a dinner that people enjoy eating. And what even is a perfect potato, anyway? Maybe you get them all the exact same size but they're still  too big, so they take too long to cook, and what you should have done was make them 20% smaller so that  they came out at the same time as the rest of the meal. Or maybe what makes a potato perfect depends  on who's eating it. I mean, if you're ever cooking it for me, just make mine sweet potatoes and just  go ahead and fry them, OK?

So, what's the solution? *Satisficing and iteration*. What is satisficing?  That doesn't sound like a word. Satisficing is a decision-making process that aims for *adequate or good enough*. What makes the potatoes good enough to eat and enjoy but doesn't take so much time that you never get them on the table and you don't have to take a bunch of expensive cooking lessons just to get them right? By the way, before you get mad at me and say, "We shouldn't just be going for good enough!" – *yes*, we should!

That's what *good enough* means! As long as we're not defining good enough as "barely edible" – we're just defining it as something we can make that people will enjoy eating. In agile design, we're also often saying that good enough is something that people will be able to use to *solve a problem* and that we can *learn something from*. What we want to learn is: *What would make the thing even better?* Because on agile teams and, honestly,  when cooking potatoes, we get to *iterate*. I mean, no, you're hopefully not going to just keep  throwing out the potatoes and doing them over and

over and over again before ever serving them, but  the neat thing about dinner is that a lot of us eat it every night. We can try these potatoes  tomorrow or next week or whenever we feel like it. Maybe we wouldn't try out a brand-new recipe  if our boss was coming over for dinner, but you could practice making  potatoes as often as you want. Same with a lot of the kinds of products  that we build using agile technologies. We get to make things and share them with subsets  of users in safe environments and get feedback   and then make them better. And the cool thing is  when we iterate like this we actually start to develop an idea of what *better* means.

Let's say the first time that we make the potatoes we cut them roughly the same size, but we try not to stress too  much about them being a little off. This lets you get the potatoes on the table so that you or your  family or whoever you are cooking them for can try them. Maybe the potatoes would be better if you cut them a little smaller. Maybe the dish needs twice as many potatoes. Maybe you decide to substitute  cauliflower potatoes like a terrible person who hates food. Maybe the problem isn't the potatoes at all – it's the spices; they're all wrong; you didn't see that coming, did you?

You'll have a much better  idea of what *better* means once you've shipped the meal and gotten feedback about what people liked  and hated and what they left on the plate and why. This is why I say there's nothing wrong with aiming for good enough, especially on the first few versions of something. Good enough doesn't mean gross and inedible, and it doesn't mean too broken or bad to learn from. It definitely doesn't mean we're never improving on it. It means we're getting something out that is *good enough to get feedback on and then we can improve it over time*.

Besides, spending less time obsessing  about the potatoes lets you spend time   on more important things like the fact that you  should have just made dessert and ordered a pizza!

In this video, we'll teach you how to use  Google's design sprint process to create great design faster. In an age of tight resources, companies  are more reluctant than ever to commit  to big design projects without a thorough  understanding of their chances of success. Google has developed a method to make the design process fast and still offer valuable insight. The process developed by  Google Ventures is called a *design sprint*.

It focuses on getting insights into *critical  business questions* within a very short timeframe – just five days. The process is based on *design thinking*, so it attempts to gain those insights via *rapid design*, *prototype development* and *user testing*. The design sprint is a five-phase process. Each phase takes approximately one day or eight  hours to perform. So, a sprint can be done in five days. The five phases of Google's design sprint are *understand*,

*sketch*, *decide*, *prototype* and *validate*. The design sprint is a *linear process*, but you  are strongly encouraged to *make revisions* based on your first sprint and then *reiterate the prototype and validate phases*. You can also move further back to earlier phases and reiterate from there. In the following, we'll look at each step in more detail, but let's start by taking  a quick look at how to plan a design sprint. To ensure that the design sprint will be  successful, some *planning ahead* is required.

Before the sprint begins, here are some things you should consider. You should *write a brief* to state the sprint's goal and bring everyone on the same page. You might also need to collect or *conduct user research* to get insights that can inform the work you do during the sprint. *Consider who should be on the sprint team.* Google's sprint process is designed to be run by teams rather than individuals. That means getting everyone together and ensuring  that they're all aiming in the same direction. The ideal team would include representatives from  all relevant functions and at all levels in the organization.

You could also invite external people –  for instance, a representative user or stakeholder. You need a *suitable space* for the  sprint, typically somewhere bright, quiet, with lots of wall space and enough room  for people to move about will be suitable. You have to *gather supplies* for the sketching  and prototyping phases. Typically, you need office supplies like Post-its, blank sheets of paper, color markers, tape, and so on. Finally, you should choose a good *icebreaker exercise* to kick off your design sprint.

Some members of your team might not have worked together before, so it's good to start off with an activity to warm people up. Now, let's take a look at each stage in the  execution of the actual sprint. In the understand session, your goal is to *create shared knowledge* about the business problem you're working on. You bring everyone together and unpack all of your  team's knowledge about the problem.

*Lightning talks*, where knowledge experts use 10 to 15 minutes to share their knowledge about the problem, is an important part of the understand session. Typical topics for a lightning talk are *business goals*, *insights from user research*, an *overview of competitive products*, *technical opportunities*, and so on. As part of the lightning talk, it can be a good idea to have a presentation by someone from senior management outlining why the problem  you're working on is important to the business. Other typical activities of the understand phase are demonstrations of solutions that are already available,

a detailed walkthrough of any proposed  solution, creating user journeys and performing user research. In the understand session, it's also  a good idea to be *clear on the metrics of success*. And remember, your metrics should be  useful and not pulled out of thin air. When you do the understand session, it's  important to involve the whole team. Don't let an individual or group dominate the  proceedings. The idea is to ensure everyone is on the same page, and the only way to do that  is if everyone is heard from.

Once everyone is on the same page, it's time to split the team up and get them to start working on solutions. Sketch day is an *individual effort*. Everyone is tasked with coming up with a detailed solution to the problem. It's a good idea to do this on paper for two reasons. First, it's quick and it takes no time  to make changes. Second, everybody is able to sketch so they can participate even if they don't know any wireframing tools.

For particularly complex, large-scale problem solving, you might want to break up the problem into *manageable chunks* and assign people a chunk rather than the whole problem. The aim of sketch day is to get as many ideas down as possible. If your team is large and you generate a ton of ideas, you might want to allocate an hour at the end of the day to quickly *reduce the number of ideas* to a more manageable number before you go into the third day of the sprint. As you might expect, decide day is all about  *making a decision* about which idea

you're going to take to the prototype phase. But there's more to decide day than making a decision. It's also about working out how your solutions  might conflict with your objectives and abilities. You can start the day by quickly  listing any assumptions that you are making about things like budget, users, technology capacity and business drivers. Then it's time to review each idea and look at  the conflicts that it generates. You should have an objective in mind during your review.

Would you be looking to take a single great idea forward to prototyping? Or are you going to pick, say, a top  5 and take those forward? You should be looking to constantly *refine* your list and remove ideas that simply aren't feasible early in the process. The entire team takes part in the decision process  by participating in discussions and through voting for ideas. Once you have an idea or ideas you  want to prototype, the last part of decide day is to *create some storyboards for your ideas*.

The storyboard should show each interaction with the user in a step-by-step process, and they'll be your specification for your prototype. You might also want to define a *user story*  or two to help beef up the specification. As the title implies, on prototype day you have  a single day to *create a prototype* that your users can test on the final day. First of all, storyboard what you're going to build if you haven't already done that. To build a prototype, you can use any tool of your choice.

Just pick one that you master enough for  rapid prototyping. The important thing is, don't attempt to learn a new tool on this day. Just use *whatever you're most comfortable with*. Finally, remember to *leverage the whole team*. Assign tasks and get everyone building or helping with something. Prototyping isn't just for the engineers.  Get people to document, write, review, plan a user test – any activity that contributes towards your end goal.

On day 5, you *validate your idea*. The most important part of the validation  is to bring in a group of your end users to test your prototype. It's important that the entire team gets to *observe the users interact with the product* either directly  or through watching recordings of your test. A *cognitive walkthrough* or *brief usability  test* are great tools to use in this phase. Other good activities to validate your design –  to bring in experts and management stakeholders to review your idea.

Everyone on the team should make  notes and record what they feel they've learned. You want to take these notes and  summarize them at the end of the day. This should help you decide if  anything needs iterating and improving. At the end of the final day, take some time with  the whole team to reflect on your experience. As Google puts it, there can be three possible  outcomes to a sprint: an *efficient failure* – perhaps your ideas didn't work so well, but you learned a lot in the process

and saved your team a lot of time from going down the wrong path; a *flawed success* – perhaps some ideas worked nicely, while others didn't: this gives you insights on what  can be improved and what you could work on next; finally, an *epic win* – the ideas your team had have  shown great promise and seem to work really well. You're ready to move into a more serious  implementation phase. Either way, you can only win! Whether it's by avoiding failure, learning where more work needs to be put in

or generating a killer design, you can only emerge from the design *wiser and more experienced*. The added bonus is that the time you've sacrificed  for this is relatively *short*. Though this is a tried-and-tested method by Google, it's also a relatively new concept adapted from Agile methods. It might take a few tries within your organization  to keep the sprint to five days. That's OK. You can work towards delivering faster sprints as  you get more practice. Google design sprints should help you take a process that currently takes months and make it lean and efficient. 

It's not a substitute for all design processes,  especially not for very complex products, but it's one that lets you ideate and test  ideas incredibly fast. A highly productive design team working in sprints is more likely to add business value and be recognized for their work within the larger organization. Finally, we encourage you to take a look at Google's Design Sprint Kit to get more ideas and tools for how to run your own design sprint.

OK, here's a scenario: You're a designer on a product that connects job hunters with great new careers. Your team is currently working on a new screen that will let applicants search by categories. Your job is to figure out what the  categories should be. Well, obviously the easiest way to figure this out is with some research. There are a bunch of different sorts of research that you could do; you could do *quantitative*, for example; you could do some *analysis* maybe of the search terms that people are already typing in

and see if there are any obvious categories; you could also do some *competitive research*, maybe check out some other sites and see if there are any common terms; or, of course, you could do the gold standard  and actually *observe some users searching for jobs*. But here's the problem: Those all *take time*. And the engineer who was assigned to the user story wants the answer from you so that they can finish  before the end of the *sprint*, which is on Friday. But you were just designing a story; how are *you* supposed to solve this problem?

It turns out this happens quite a lot on agile  teams and it can be *extremely frustrating*. The thing is, this is indicative of a very common  anti-pattern often called "feeding the beast". In this instance – in *all* instances – the engineers are the beast. There are a few ways to handle this. The first requires that stories be treated differently. Researchers and designers could work on their stories *ahead* of engineering, and by the time engineering gets them, the acceptance criteria are all set. In other words, you'd get this story a few weeks early, get to go do your various forms of research,

come up with a good solution, and then the story would go to the engineers. That's fine. And it's what happens on a lot of teams who are what we call "agile-ish". But it's not particularly cross-functional or collaborative. Another way of approaching it is to actually involve the engineer you're working with on making the decisions. For example, maybe they can help do some data analysis on the search terms while you do some competitive analysis on the competitors' types. You could both work together to observe some real users. Meanwhile, the engineer could do a bit of exploration to see if there are any technical reasons why certain types of categories would be

easier or harder to implement than others. You would be shocked at how often there are weird technical constraints that you do  not find out about until an engineer sees a story, which means it's really much better to get them involved as soon as possible. Of course, this may mean it takes you a little bit longer than a single sprint to get the whole story done; although, again, that can depend on how fast you are or how big the feature is or how long your sprints are. On the upside, you know that any design  will be technically feasible because you're involving the engineering team  in the decision-making process.

You also know that the engineer implementing the story  actually understands the user needs and goals. Depending on the design, it may drastically reduce  the number of deliverables you need to create. I mean, if you've already done co-design exercises  and sketched out ideas with somebody, you often don't also need a designer to create pixel-perfect mockups to show them exactly how something works. Will this kind of group research work in every single instance? No; sadly not. It depends on a lot of things, not least the willingness of the engineers to be involved in the research.

On some teams, engineers could get penalized if they spent too much time on a story. So, this sort of research would end up being bad for their careers. This is incredibly unfortunate, and if your team is like this, it's honestly worth trying to get it changed because the benefits of doing research together strongly outweigh the slight negatives of maybe moving a bit slower in some cases. In fact, often doing research and design  like this can end up making a team move faster in the long run simply because there's  less miscommunication among team members and less need for complex deliverables to be passed  around.

Of course, doing research together doesn't necessarily mean that everybody on a team does all research all together all the time; you're still doing larger, more open-ended studies that take a longer time. And if you've got one researcher and designer and several engineers and a product manager, you're not all going to go to all of the sessions together – that would be a little overwhelming. But be sure to *include* various members of the engineering and product teams and even marketing or sales or customer service or anybody else who has an impact on product decisions *when you're doing your research*. Not everybody will go to every research  session, but having people on your team

watch your customer experience first-hand can  really help your team be much more agile by giving everybody the context that they need to make  better decisions about whatever they're working on. Of course, this does tend to work best with smaller  teams, but then that's true whenever you're using agile methodologies. They're all designed around this idea of a truly cross-functional, collaborative, reasonably sized product team that is at least partially autonomous and can make actual decisions about what to build and how to self-organize.

If that doesn't describe your team, team research is going to be harder; although it's still not impossible, it just takes some work.