Four Factors of Agile UX
Published: June 4, 2007
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.
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.
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.
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—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.