The heart of User Centered Design (UCD) is to listen to users. By "listen" I don't mean just hearing their words but using all the methods of observation to understand what users want from a product. I need to see what users are doing with a product, their body language, the context of use, prior knowledge, cultural and social issues, along with many other factors. I use what I learn from users to continuously improve the product until I balance the needs of the business with the needs of the users. Iterative Design is a method of repeated pairings of observation and product refinements to discover and eliminate issues. In this article I am going to focus on how I use Iterative Design to make products better.

Derived from the standard UCD process here at Infragistics, I use a Lean UX philosophy, which focuses on fast results rather than meticulous adherence to protocol. The process is broken down into four quick steps: Plan, Run, Review and Change.

1. Plan what questions to ask
2. Run the study - interview participants
3. Review the results and learn the issues
4. Change the product to address the issues found - return to step 1

Some clients get the false impression that Iterative Design is a slow, costly and a marginally effective process. In my practice I have used this model with 100% success. I have never found it to be a waste of time or resources when executed correctly. Once a base design is established through analysis and design iterations, the fine-tuning begins where I found it very powerful and efficient to execute short and focused iterations with test participations. Typically, I run a study with three participants in the morning, make changes to the application that afternoon, and then run three more participants the next morning. In the time span of less than 2 days, most issues are resolved - not all, but most issues. Depending on the results of our findings, more iteration cycles may be required.

Iterative design can be done at any time during the development process, ideally, it occurs during the design phase before developers have begun building the application or web site. In the design phase, it is less expensive to make changes and the design possibilities are broad. Ideas are tested quickly and changes are made rapidly. Once in the building stage, iteration is used to resolve issues that come up because of unforeseen technical limitations or other issues that only show up once a prototype is built. In the prototype I want to verify that the interface is usable and provides the user experience we are looking for.

I have written a lot about the process in general, but doing it is really simple.

The process

Plan

Planning is the first step. This can be complicated (if you let it) or as easy as you like. I basically go for easy every time! So here is the planning process:

• Determine the question you'd like answers to.
• Decide how much knowledge of the domain the test participants need to know.
• Work out how to recruit the users you want to talk to.

Determining the questions

I like to look at the areas the design team had trouble with. Where did we have a tough time with the process flow? I look at the connecting points in the application, the transitions from one process flow to another. If we had to compromise to make something "fit" I want to be sure our compromises worked. I also like some general questions about the interface. Can the user describe what the application is about at first glance? Are the buttons, links, grids, in other words - are all the components working as expected? Are the results from operations as expected? Is the user interested in using the application? Does it seem cool? Stupid? Boring?

Once we know what we want to ask, the next thing is determine how we are going to get our answers. Here is where you need good insights into how someone uses your product. I use scenarios drawn from use cases or from subject matter experts that are realistic and commonplace, I am not looking to test edge cases. I want situations that most people will encounter; if I can get it right for 80% of the users I can be sure I hit most users' sweet spot.

Knowledge of the domain

Some applications are so industry or company specific that you need participants that have a great deal of domain experience. These types of people are sometimes hard to find, so I am very careful about going down that path. Most times you don't need experts in a domain to get the answers you're looking for. Is there some way to remove the complexity? Can you supply the background information needed so that anyone can answer the posed question? If there is no way getting around using people with the necessary background, then be prepared for additional effort in finding users to interview.

How to recruit

If you don't need users with domain knowledge (my favorite) then I just start walking around the office and see who's free. If you don't have enough people around then you'll need a more sophisticated plan. If you are working for a client, you can ask them to rustle up some people on their end. Maybe some clients would be interested in participating? You can put ads in newspapers, use trade magazines, Craig's List or other web based advertising. When working on websites, I sometimes put a request right on the home page asking people if they would like to help make the site better, you'd be surprised how many people respond! Being interviewed to help make a product better is not painful-it's fun. Most people enjoy the process and are usually quite interested in having a voice in a products development.

Run the study

All the planning is done and now I am ready to talk to our users. After capturing some basic information about their background and experience with the software in general, I ask them to do some tasks with our software. We run through the tasks while asking them to "think aloud" - to go through the task while giving a running narration of what they are thinking, kind of like the play-by-play a sports announcer does.

I take notes on everything the user does, what they say, and how they say it. I like to have screen captures or wireframes of the question area in the program so that I can jot down notes directly on the screen captures. There are many ways to capture the information from videotape to screen capturing programs, you can get very elaborate here if you want to. Please remember, this is not a quantitative study, we are no trying to prove anything here with statistics. We are looking for problem areas, once you see a few users stumbling over the same spot you will know you need to make some changes. That being said, I usually just use written notes on screen shots to draw my conclusions.

How the user holds their body, breathing, and general demeanor. 

Review your results

I like to review my notes right after the last user leaves, while everything is still fresh in my mind. If other people helped conduct interviews, now is the time to compare notes. Review them for common themes. Try to determine what impact the issues will have on the product and how hard or easy the changes can be made. Get the team together and present your findings. What are the next steps? I think it's pretty simple: do nothing (there are no big issues - you're done) or make changes to the product.

Change the product

Revise or create new wireframes, revise the visual designs or tweak the code, whatever you're testing.    Review the changes with your team and confirm you've addressed the issues raised. The next step is to return to the Plan stage, this time it will be very easy. Just update your questions to address the new issues found, make any course corrections you may have found in your procedures and run the study. The cycle continues until no significant issues are raised.

So to sum up, this easy to follow iterative design process can be used in just about every situation. Sure, there are times when more elaborative systems need to be put in place but for many projects with limited time and extremely tight budgets any iterative design is better than no iterations at all.