How to Succeed as a Designer on Agile Teams: Embrace Imperfection

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!