Four Factors of Agile UX

By Luca Mascaro

Published: June 4, 2007

“Typically, the more time you have, the better the solution you are likely to devise, because you can metabolize more ideas and reflect at length on more user interface and interaction design issues.”

On a quiet spring morning, one of our clients—the director of a small firm with ten employees—called our office and wanted to see me the very same day to discuss a new project. When we met in the afternoon, he told me his firm needed a new Web site for the launch of their latest product, which they would promote—and, hopefully, sell—only on the Web. The site was to include communications tools for interacting with customers, Help, and a blog on which they’d announce new versions of the product.

Nothing strange so far. The firm meant to invest, as it had previously done, in user-centered design, online promotion, and development by my firm and two other partners. However, toward the end of the meeting, the director told me that everything must be online in three weeks’ time for a fair, and the whole site must be completed on a budget of less than $15,000.

Many firms and professionals who work internationally in user-centered design would not have taken up the challenge. In addition to the project’s limited budget, time is vital during the design phase. Typically, the more time you have, the better the solution you are likely to devise, because you can metabolize more ideas and reflect at length on more user interface and interaction design issues.

Unfortunately, though, the Southern European market comprises mainly small firms who use the Web to support their traditional businesses and, therefore, have neither the budget nor the time for ideally conceived projects. So I accepted the engagement—and my partners are still furious with me.

The site was online after three weeks. Though the project was not perfect, it turned out well. How did we manage this, considering that we followed all of the usual design phases? Our success was primarily the result of four factors that we were able to exploit and manage during the design project, which enabled us to make design decisions quickly and move on with great agility.

1—The best designer for a project is one who knows the product domain.

“You can more quickly understand a problem that you need to solve when you involve one or more users in defining the problem.”

To carefully weigh any design decision, you need to consider all of the goals, tasks, functions, information, and the context that should factor in the shaping of a Web site. On an ideal project, you could deliberate upon these elements for weeks. Neglecting some of them could lead to the wrong design decision, which would likely entail changes at a later stage of the project.

However, you can more quickly understand a problem that you need to solve when you involve one or more users in defining the problem, because the users already know the domain and the best way of working from past experience. Therefore, we requested that someone from our client's team—who had a better understanding of users’ needs—be present on our premises throughout the entire design stage. Thus, we were able ask him questions directly, at any time, and involve him in making decisions.

2—All activities in a UCD process are useful, but some more useful than others.

“On an agile project—when time is limited—it is, therefore, vital to know how to identify the activities on which to concentrate your efforts.”

In the process of user-centered design, many activities can help us reach a better understanding and enable us to achieve a more efficient design. Nevertheless, depending on the product you are designing, some of these activities matter more than others—at least as regards efficiently reaching usability goals. In our experience, performing just 30–40% of these activities substantially ensures the usability of 70–80% of the product, while the remaining activities merely add polish.

On an agile project—when time is limited—it is, therefore, vital to know how to identify the activities on which to concentrate your efforts. But such decisions are not obvious, because they are not based on objective information. You have to rely solely on the team’s experience. You reach decisions according to each member’s know-how.

3—Do fast paper prototyping, then quickly test your prototype on friends and relatives.

“You use the test results to help you choose from among several design solutions rather than to find usability problems.”

Running usability tests with users is always helpful, but if you must complete a project very quickly, you cannot aim at achieving the highest quality in all aspects of the product’s design. Most significantly, you do not have enough leeway to do in-depth preparation for usability tests. Usability tests thus become a means of helping you make design decisions rather than verifying the stability of a particular release. So you throw together a usability test on the spot, then you perform the test with whomever is available, because there is no time to select users from among those the site is targeted toward. Finally, you use the test results to help you choose from among several design solutions rather than to find usability problems.

Some people might object that targeted users and random users might use a site differently. This is true, but usability tests with any type of users usually reveal both mistakes and simpler, more elegant solutions.

4—The ability to explain a design efficiently is vital to the success of a project.

“One of the most important aspects of the work of designers do on a project is their ability to explain their choices and the reasoning that led to given design solutions.”

One of the most important aspects of the work of designers do on a project is their ability to explain their choices and the reasoning that led to given design solutions—both to their clients and to other member of a product team. Clear communication is vital to the smooth progress of a project, as even a single misunderstanding or communication glitch can lead to mistakes during implementation.

In the situation I’ve described, the only solution was to work in a single space with all of the members of the team, involving everyone at each stage of the design. Working in this way, everyone knew immediately how we’d arrived at each design decision, and they felt responsible for and committed to the goals of the project.

In this case, we did detailed design on paper—about half of the design—and the common parts of the design on a whiteboard. Doing so enabled all of the team members to contribute to and iteratively refine the design, because it was always before their eyes. Sharing the same space also enabled the project manager to quickly track each aspect of the project and thus to schedule design and implementation concurrently, which made it possible to finish the project within a few weeks.

Drawing lessons from my experience with this kind of agile approach, I can state that its advantage is certainly the ability to produce a satisfying result despite time and budget constraints—even though the result is not perfect and will certainly need refinement later on. Another advantage of this kind of project is that both our team and our client’s team got to know each other better and learned how to exploit each person’s know-how, improving the overall ability of the design team.

Thanks to Claude Almansi for translating this article.

8 Comments

These are some good tips, but it’s a mistake to assume that, because you did a project fast, it was somehow “agile UX.” There’s a difference between making smart, pragmatic compromises and true Agile development approaches.

I think it’s an unfortunate development that many people have learned just enough about Agile methods to decide, “Hey, now we can do projects in half the time.” Doing things fast and cheap is not the goal of Agile development.

I’m not sure that “agile” is the right term here, because in my opinion, iterations are critical components of any agile style of development. What you’ve described is half of the agile approach—close work between a multidisciplinary team, usually co-located. But the other half—frequent iterations with each iteration being functional and testable—is missing.

I think the topic of how UX fits into Agile development processes is an interesting one and not straightforward. This is a good start.

Thanks for the article, and I agree with the other two comments that this is really not an agile project. It’s just one that was done really quickly. I’m curious to hear from Luca about some of the details of the development or engineering side of the project. Was Luca’s firm just doing design or development as well? In either case, how did they work with the development staff, and how did Luca’s UCD activities relate to that process?

This article should be titled “My experience on a UX project worth of $15K in 3 weeks.” I felt this is more of what the author did with whatever resources—time, money, and people—were available to him for this project.

Therefore, one should take this information only in this context and shouldn’t generalize.

Hi all—The idea is not fast and cheap = agile. My experience was that, on a UCD project with a low budget and little time, the only approach that would work was an agile approach, with a light process that emphasized the four factors described in the article.

For Jeff—My company only designed the site. The engineering company worked in the same office with us for two weeks—day and night—using an extreme programming approach. The interesting thing was that the two processes converged many times during the project.

“Agile” UX is a bit of a stretch. Much like the Communist Manifesto, “Agile” anything all sounds great in the book, but in application, not so much—relative to design anyway).

Sure design is discussed within the context of true Agile development, but from my experience, design really doesn’t/can’t fit, because there’s generally “no time for it.”

To the author’s point, if you could work good design methodologies into Agile development practices, some of the points addressed here could be beneficial. However, the reason most firms will not tackle such an undertaking is because of the lack of time allowed—and maybe the budget too.

I agree with what another reader suggested. It sounds like here the author had a limited budget and limited time to get a project done. We’ve all been there, done that, but I don’t think that makes for “Agile UX.” And if you can make or made $15K in 3 weeks, good for you!

Good design takes time and that should never be considered a bad thing or a negative effect on scope. It should be viewed as a need, a value-add, and a vehicle to produce a product that users can and, more importantly, will use in the end. Cheap and quick to market only means so much if your design doesn’t ultimately meet users’ expectations. Design should be planned and budgeted for up front.

Luca, is it possible to tell us whether the product met users’ expectations? I think that could help people’s reactions to the article overall.

I’ve worked on projects requiring an Agile methodology, and none of them has thought of design as a bad thing or that it would have a negative effect on scope.

I would agree that, oftentimes, an Agile approach allows time only for focusing on the need-to-have features and functionality of a product over flash and glitter. But, to be honest, if you manage to get the need-to-have features and functionality in place, you’ve usually met the users’ expectations.

If a project is approached correctly, and the team working on the project are able to pull together to identify the problems and develop solutions, there should always be time for good design to happen, regardless of the time schedules or process used to bring a project to fruition.

If we use words to describe Luca’s process, concurrent, collaborative, overlapping, and co-located resources seem to fit. But as we now define agile methodologies, a recurring element is iteration of design and model/prototype—all of which are functional and testable in the context of the media used.

Fixation on the positive emotional implications of the word agile would be unfortunate. Labels must not segue into becoming icons—they are not unassailable. In my opinion, we are after methods that are, first, successful—defined in terms of reaching a stated goal—and then efficient—defined in terms of delivering reusable components and/or ideas, while using minimal amounts of current resources that themselves are immediately reusable or refreshable. Repeatability would seem to be the icing on the cake.

Best regards, Bill

Join the Discussion

Asterisks (*) indicate required information.