Anatomy of an Iteration

Where did the Office team at Microsoft get their inspiration and ideas for the last version of Microsoft Office?

I’ve been asking this question to different teams of developers every month, for the past 15 years. Every team comes back with the same list of sources, even though, over that period, there have been no less than six new versions of Office and tremendous advances in technology.

The answer is always ”from watching and listening to the customers and users of the previous versions of Office.“ In other words, the newest version can only exist because there were previous versions. Microsoft’s team has been iterating their designs, one after the other, to get to where they are today. And they’re still iterating.

Iterations are a key piece of any engineering effort. You take an idea, develop it into something, try it out, see how it works, and then start all over again. Microsoft, and every other software company, does this with every new version.

Of course, the release of the new version of Office isn’t the only iteration since the last version. The team has iterated hundreds, if not thousands, of times, using the same exact pattern. It’s just that they don’t show those iterations to the public (and only some iterations to the armies of alpha and beta testers).

And this is one of the great paradoxes of design management: The vast majority of iterations are never seen by anyone outside the team. So, it looks to the outside world that, when a great product comes out, that the team just sat down, thought it through, and built it, without any trial or errors. But nothing could be farther from the truth.

Dissecting A Successful Iteration

Iterations are key to successful design. They help reduce risk by letting us get all the bad ideas out of our system early, keeping only the best of the best.

Unfortunately, we’ve found that many teams don’t know how to iterate effectively. Good iteration is a deliberate activity, with four important stages: planning, implementing, measuring, and learning. The best teams focus on each stage appropriately, making sure they get the most out of it. While iterations can be very short, (we’ve seen teams that can iterate a dozen times in a single day,) the best teams don’t short change any of the stages.

If you’re familiar with Agile development, these stages will sound very familiar. That’s because there are parallels between the types of iteration we do when designing great user experiences and what developers do when building applications. The big difference between UX iterations and Agile iterations is that most Agile iterations focus on coding something, whereas UX iterations can have alternative deliverables, such as wireframes, or persona descriptions.

Interestingly, iteration didn’t originate in either the UX or Agile worlds—its origin goes back to the beginning of engineering practice, hundreds of years. And most interestingly, the stages are still the same today:

Stage #1: Planning

In the planning stage, we decide what we want to learn from this iteration and how we’ll make it happen. We’re not planning what the final design will be, only this iteration. Planning doesn’t have to be a complex process, but it is a necessary part of the conversation.

We go into the iteration with a specific problem in mind. It’s in the planning stage that we decide how we’ll try to tackle that problem and how we’ll tell if we’ve succeeded.(Because it’s easier to understand what to plan once you understand the other stages, we’ll come back to it a little later.)

Stage #2: Implementing

The implementing stage is the most famous part of the iteration. It’s where we create the prototype or deliverable we want to get feedback on.

What’s important to remember about the implementation is that we just want to build out those portions that we’re looking for feedback on. If our final design will have certain functionality, say print capabilities, that we’re not quite ready to look at, then we don’t have to build that portion.

In fact, we can get quite lean. For example, if we are only interested in how the data will show up on the screen, we can hard-code the data into the prototype, eliminating any need to implement a back-end database for this iteration. Conversely, if we’re only interested in whether the server can handle the transactions at a reasonable speed, we only need to write a program that stresses the transaction engine, ignoring the UI.

Stage #3: Measuring

Measuring is a critical stage of the iteration. It’s where we collect the data that will help us decide if our iteration is moving us forward, or if we have to rethink the way we solve our problem.

How we measure will depend on the information we’re trying to collect. If we want to see whether the user interface works for the user, we conduct a series of usability tests. If we want to see if a particular interaction sequence feels right, we just try it out ourselves. Measuring doesn’t have to be a complex process—it just needs to reflect what we’re trying to assess.

Stage #4: Learning

Learning is the final stage and one we often don’t pay enough attention to. In this stage, we take the data we collected during the measuring stage and identify the lessons we’ve learned.

Some lessons will be affirmative—they’ll tell us that the ideas we’ve generated achieved the goals we set out. Some lessons will be more constructive—telling us that we haven’t reached our objectives, but giving us ideas on what to do differently. Using what we’ve learned, we’ll then go back into the planning stage to decide what we want to get from the next iteration.

Revisiting the Planning Stage

Now that you’ve had a chance to see all the stages, let’s take a closer look at the planning stage. As I mentioned earlier, the planning stage is only about this iteration. We want to plan out exactly how we’ll implement and measure. We want to ensure we have the resources necessary to collect the data and to provide the time for identifying what we’ve learned.

Here’s an example plan: We’ll start by deciding what we want to learn in this iteration. Can we can come up with a checkout flow that makes sense with users using the point redemption process? We decide that we can do it with a paper prototype, starting with modifying the existing checkout process with the new functions. We’ll test it with a handful of shoppers, who we’ll recruit from other parts of the company, like the accounting department. We’ll give ourselves a half day to do the paper prototype and a half day to run our usability tests, wrapping it up with one hour debriefing meeting.

Best Practices for Successful Iterations

Over the years, we’ve learned some tricks to ensure we get the most out of our iterations:

First, you need to allocate as much time and effort to the Measuring and Learning stages as you do to the Planning and Implementing stages. If you find yourself taking two weeks to implement, but only give yourself a day for measuring, then something’s out of balance. It’s a common mistake for teams to short themselves on measuring, thereby not getting a chance to learn everything they should.

Second, look for techniques to shorten implementation. Make sure you’re only implementing functionality that is necessary for this iteration—leave the other functionality for future iterations, when it will matter. Also, look to prototyping techniques and deliverables that get you the answers you want quickly. We like paper prototyping because it’s very fast to get something a user can play with.

Explicitly looking at your process for iterating will give you a chance to refine your techniques, while helping you get the most out of your design process.