Design Iteration

Your constantly-updated definition of Design Iteration and collection of videos and articles. Be a conversation starter: Share this page and inspire others!

352 shares

What is Design Iteration?

Great designs don't just appear overnight – they take time to get right. UX designers and, in fact, all other kinds of designer know that they don't get one try to make a product the best it can be, it takes many iterations to get the product the way that it best suits the user. Iterative design processes are used across all design disciplines to produce results that count. A UX designer should ensure that they understand how iteration works and how to best use it in their own work.

Show Hide video transcript

00:00:00 --> 00:00:31

Great agile teams commit to iterating on features. Now, it's interesting. When we did a bunch of research on agile teams back in 2019 and 2020, we found one of the biggest complaints people had was that their teams never went back and improved things that they'd already built. They would ship something, move it to the Done column and then never look at it again. Sometimes, they didn't even look at metrics to see if anybody was even *using* the feature.
00:00:31 --> 00:01:00

The really unfortunate thing was that teams often shipped small or stripped-down versions of features just to get them out the door and then they *still* never went back and approved them. Obviously, this led to absolute nightmare products full of half-finished things that were inconsistent and didn't really make sense as a whole product. The thing is, that's one of the least agile things you can do. The whole point of lightweight methodologies is that we're constantly getting things in front of users, getting feedback and improving them.
00:01:00 --> 00:01:32

Do we sometimes ship things to people that aren't quite perfect? Yeah – all the time. But we do it with the understanding that we're shipping it in order to learn something, and once we learn something, we're going to go back and improve the product based on what we learned, and then we'll do it again... and then we'll do it again. That is iteration, and it's pretty much the core of agile. Great teams learn from their users and keep improving their product by iterating on features. They don't just keep churning out new half-baked features like they're some kind of widget factory.
00:01:32 --> 00:01:41

So, teams that are truly committed to agile methodologies should be iterating and improving their user experience and their codebase *constantly*.

Learn More about Design Iteration

Iteration is a common theme in both design thinking and agile methodologies.

For more practical insights on how to incorporate iteration while working on agile teams, take the course, Agile Methods in UX Design.

Learn more about the iterative, non-linear design thinking methodology in the course, Design Thinking: The Ultimate Guide.

Agile Methods for UX Design

Closes in

days

booked

Get Weekly Design Insights

Join 316,081 designers who get useful UX / UI Design tips from our newsletter.

Literature on Design Iteration

Here's the entire UX literature on Design Iteration by the Interaction Design Foundation, collated in one place:

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

An agile team values shipping working software in order to gain customer feedback and respond to it. This emphasis on shipping working software, combined with short timelines to ship it in, often only a week or two, puts excessive pressure on designers to deliver designs to engineers in unrealistic time frames. How can a designer survive, let alone succeed in such a team? The key lies in a shift in mindset — to embrace imperfection. Let’s see why.

One of the biggest challenges facing UX designers in agile teams is time. If you feel that it is unrealistic to deliver polished designs within a week, then you’re right! It may not be possible to churn out pixel-perfect mockups at speed, all the time. And it is this expectation that often burns out designers. But it needn’t be this way. Agile teams function in a fundamentally different way than a design agency, and so, as a designer, you must adapt your work accordingly. This doesn’t mean skipping research or getting burned out in handing over polished assets. It’s somewhere in between — letting go of “perfection,” especially when it comes to mockups and functional prototypes.

Every professional strives to put their best foot forward, and designers are no exception. However, agile teams are not great places to be perfectionists, partly because there isn’t much time for it, but mostly because we rarely know what makes something perfect. And, what designers think of as “perfect” is almost never the same as what a user would consider “perfect.”

Instead of aiming for some nebulous version of a perfect design, aim for getting things good enough to learn from and iterate.

In this video, Laura Klein uses the analogy of a familiar household activity to explain how you can train yourself to think in terms of good enough, instead of “perfect.”

Show Hide video transcript

00:00:00 --> 00:00:33

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,
00:00:33 --> 00:01:02

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,
00:01:02 --> 00:01:31

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.
00:01:31 --> 00:02:03

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.
00:02:03 --> 00:02:35

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,
00:02:35 --> 00:03:00

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.
00:03:00 --> 00:03:33

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?
00:03:33 --> 00:04:01

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!
00:04:01 --> 00:04:30

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
00:04:30 --> 00:05:03

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.
00:05:03 --> 00:05:30

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?
00:05:30 --> 00:06:01

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*.
00:06:01 --> 00:06:09

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!

The Take Away

Teams that can learn from user feedback and iterate on features tend to stress less about making a product “perfect” before it gets released. They know that, as long as it’s good enough, solves a user problem, and can be learned from, they can go back and make it better later.

Unfortunately, a lot of teams that call themselves agile don’t ever go back and iterate, which makes this a tricky thing to implement. Work with your team to find out what “good enough” means for any given feature and then commit to going back and improving it once you have a better idea of what “perfect” looks like. You may still never make it perfect, but at least you won’t waste a lot of time adding things that make the product worse!

Images

Learn more about Design Iteration

Take a deep dive into Design Iteration with our course Agile Methods for UX Design .

Agile, in one form or another, has taken over the software development world and is poised to move into almost every other industry. The problem is that a lot of teams and organizations that call themselves “agile” don’t seem to have much in common with each other. This can be extremely confusing to a new team member, especially if you’ve previously worked on an “agile” team that had an entirely different definition of “agility”!

Since the release of the Agile Manifesto in 2001, agile methodologies have become almost unrecognizable in many organizations, even as they have become wildly popular.

To understand the real-world challenges and best practices to work under the constraints of agile teams, we spoke with hundreds of professionals with experience working in agile environments. This research led us to create Agile Methods for UX Design.

In this course, we aim to show you what true agility is and how closely agile methodologies can map to design. You will learn both the theory and the real-world implementation of agile, its different flavors, and how you can work with different versions of agile teams.

You will learn about the key principles of agile, examples of teams that perform all the agile “rituals” but aren’t actually agile, and examples of teams that skip the rituals but actually embody the spirit.

You’ll learn about agile-specific techniques for research and design, such as designing smaller things, practicing continuous discovery, refactoring designs, and iterating.

You will also walk away with practical advice for working better with your team and improving processes at your company so that you can get some of the benefits of real agility.

This course is aimed at people who already know how to design or research (or who want to work with designers and researchers) but who want to learn how to operate better within a specific environment. There are lots of tools designers use within an agile environment that are no different from tools they’d use anywhere else, and we won’t be covering how to use those tools generally, but we will talk about how agile deliverables can differ from those you’d find in a more traditional UX team.

Your course instructor is product management and user experience design expert, Laura Klein. Laura is the author of Build Better Products and UX for Lean Startups and the co-host of the podcast What is Wrong with UX?

With over 20 years of experience in tech, Laura specializes in helping companies innovate responsibly and improve their product development process, and she especially enjoys working with lean startups and agile development teams.

In this course, you will also hear from industry experts Teresa Torres (Product Discovery Coach at Product Talk), Janna Bastow (CEO and Co-founder of ProdPad) and Adam Thomas (product management strategist and consultant).

All open-source articles on Design Iteration

Stage 4 in the Design Thinking Process: Prototype

One of the best ways to gain insights in a Design Thinking process is to carry out some form of prototyping. This method

1.3k shares
4 years ago

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

An agile team values shipping working software in order to gain customer feedback and respond to it. This emphasis on sh

546 shares
11 mths ago

How to Get Meaningful Design Feedback from Your Clients

Meaningful design feedback is essential to the collaborative and iterative design process, and it’s equally important fo

626 shares
3 years ago

The Journey of the UX Design Process in VR

VR’s design process isn’t that far off from a typical user-centered design approach. It’s all about continuous discovery

475 shares
2 mths ago

Open Access—Link to us!

We believe in Open Access and the democratization of knowledge. Unfortunately, world-class educational materials such as this page are normally hidden behind paywalls or in expensive textbooks.

If you want this to change, , link to us, or join us to help us democratize design knowledge!

Design Iteration

What is Design Iteration?

Learn More about Design Iteration

Literature on Design Iteration

Learn more about Design Iteration

All open-source articles on Design Iteration

Stage 4 in the Design Thinking Process: Prototype

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

How to Get Meaningful Design Feedback from Your Clients

The Journey of the UX Design Process in VR

Open Access—Link to us!

Popular related searches

Filters

Privacy Settings

Security

Enhanced Functionality

Referral Program

Error Reporting

Analytics Storage

Google

Advertising Storage

Personalization Storage

Advertising Personalization

User Data

Meta Pixel

Meta CAPI

LinkedIn Insights

LinkedIn CAPI

Google Ads Tag

Share Knowledge, Get Respect!

Cite according to academic standards

New to UX Design? We're Giving You a Free eBook!