Agile is here to stay. The economic difficulties of the past months have finally put waterfall out of its misery; now more than ever, long requirements phases and vaporous up-front documentation aren’t acceptable. Software must be visible and valuable from the start.
Article Continues Below
For many designers, Agile is already a fact of life (and for those less accustomed, some recommended reading follows at the foot of this article). We are reaching the point where we must either acclimatize or risk being bypassed. The good news is that Agile does allow us to still do the things we hold dear—research, develop a vision, and test and improve our designs—we just need new techniques. Now is the time to get real, and prove design can adapt, if we want to stay relevant in these increasingly unreal times.
Time, research, and ideation have historically been designers’ comfort zones. They suit our natural aptitude for vision and intuition, and allow us to carefully synthesize nebulous things like “brand” and “user behavior” into objects developers love: specifications, sitemaps, layouts, and graphics.
Agile, on the other hand, aims to deliver software quickly and handle change smoothly. The two systems rely on subtly contrasting ideologies: reactive versus predictive, accommodating change versus pre-empting it. Despite these differences, a lot of the Agile Manifesto is fundamentally relevant to designers. Interactions above processes. Collaboration above negotiation. Feedback. Simplicity. All music to our ears.
While designers and developers look at the world from different viewpoints, the Agile philosophy is, at heart, flexible enough to sustain the approaches and views of both professions. There are still ways to fit quality design work into an Agile world.
Given that Agile says “working software is the primary measure of progress,” there’s little room for detailed research. While Agile projects can function without any recourse to users (substituting hunches and “user-scented design”), the output is usually poor. The operation may succeed, but the patient dies.
Proxy users can suffice if team members are sufficiently similar to the audience. Designers should use their expertise to make the call, recognize the inherent bias, and accommodate it. This situation is rare, however, and most projects will benefit from research, lest they quickly build momentum in the wrong direction. The iteration zero is deservedly becoming an accepted way of buying time, but some teams are extending this idea with an additional mid-project iteration zero, in which no user stories are delivered. Instead, developers can tidy up code and plan next steps, while designers can revisit the vision and check that brand, aesthetics, and experience are coherent across the site so far.
Since research must be lightweight, it must also be less meticulous. Fortunately, even one or two short sessions per iteration can suffice. A good approach is to recruit using personal networks (friends of friends, Twitter) and hold short dual-purpose sessions: research for future stories, and guerrilla usability testing for completed stories. If reaching genuine users is impossible, all is not lost. Marketing teams often sit on mountains of demographic data, server logs can help expose search terms, and so on. It’s crude, but even this hacked-together research can help designers fill in the gaps.
These approaches clearly aren’t suited to research-critical projects which, by necessity, require up-front research phases. Some teams try to sidestep this by using satellite researchers outside the Agile cycle to drip-feed research findings when available. However, results appear mixed and useful details can be lost in the gap. For all but the largest projects, designers can gain great insight by doing the research themselves.
Agile iterations are planned to create a steady development velocity, but designers don’t always benefit from the same uniformity of workload. Therefore it can be worth exposing estimates for design too. Accuracy can be tricky, but even a ballpark estimate can help reduce rushed design and reinforce that design is as critical to the project as development.
“Best practice” suggests that designers should research iteration n+2, design iteration n+1, support iteration n and review iteration n-1. This is sound advice but should not be taken too literally: some stories will take longer to design than these arbitrary timeboxes. Designers should use their intuition and experience to flag up potentially complex stories in advance, giving themselves increased lead time. It’s bending the Agile rules, but should be encouraged if the product benefits.
Lack of coherent vision is a common weakness of Agile projects. This stems both from Agile’s modular nature and, to an extent, its inherent power balance. Product owners, for all their strengths, sometimes lack the tactics to appreciate the big picture. Unchecked, this can lead to vague, volatile requirements based on strategic whim, and products faithful to company daydreams, not customer reality. A telltale symptom of this malaise is the “horizon effect,” whereby potential problems are pushed repeatedly from view into future iterations, and the designer is unsure whether the solution works as a holistic whole until it is complete.
Fortunately, we can learn from other fields. Filmmakers operate in a similarly agile fashion, filming scenes in an order dictated purely by logistics. To ensure vision, coherence, and narrative continuity they employ specialists: directors and script supervisors. On the web, designers can play a similar role, but must volunteer and adapt it for themselves. This means getting involved in writing user stories and trying to guide product owners away from over-hasty solutions.
There’s still little time to explicitly explore product vision, but we can get close by chaining user stories together into entire user journeys where possible, and designing those chained stories together. We can then review and test them as whole journeys too. This approach reveals a lot about a user’s overall experience and warns us of holes caused by the horizon effect.
Agile is deliberately light on documentation. Great—more time to spend on thinking and designing. Given this bias, static page comps and wireframes are a dead end. They’re simply too rigid for Agile, particularly now that the page is no longer the atomic unit of the web. Instead, we can favor “interactions over processes” by starting with conversations, not templates, and choosing interactive prototypes over static wireframes.
User experience (UX) designers have a host of options for deliverables. Lo-fi sketches and paper prototypes are ideal mechanisms for sharing design ideas and exploring discussion points, yet they are still surprisingly rare in practice. By sketching lots, quickly, and often, UX designers can rapidly iterate on their work, while building up a paper library of components, buttons, navigation elements, dropdowns, and so on.
Prototyping in HTML or with tools like Axure and iRise can be a good alternative. While all have learning curves, they avoid the ambiguity of sketches (and the paper cuts). They’re also flexible enough for changing requirements, but consistent enough to test entire interactive user journeys.
Visual designers still need to create high-quality graphics so they can’t stray far from Photoshop or Fireworks for the end product. However, they too should be involved in early prototype iteration with UX colleagues. Pushing proposed solutions out early and often can be an alien concept to some, but it is central to the Agile philosophy. To save time, it can be wise to design only one example of each content type—one form, one search results page, and so on. With sufficient communication, the prototype can double as the spec.
We are told that the modern org chart is hyperlinked, but in many companies design is still a single point of decision. Designers must let go of perfection to produce rapid, iterative work: “90% right” solutions are par for the course for Agile. This can be counterintuitive, but for better or worse, Agile prioritizes the timeline over virtuosity. Certainly it makes designing to impress other designers harder. No great loss.
There comes a point at which compromises become too great, however. In the words of Alan Cooper, “there is no large group of people out there waiting in a breathless delirium to purchase your lousy product.” Best-to-market usually beats first-to-market, and designers naturally work well as quality custodians, lobbying sponsors for extra resources where required to do the product justice.
There can be a temptation when designing quickly to fall back on easy stereotypes and clichés. Drawing on the diversity of others’ creative skills can help. Designers should therefore become comfortable as facilitators, not dictators. That’s not to say design should become a democracy—specialist knowledge is as necessary as ever—but by working together, designers can foster this shared ownership of the design, and also boost the credibility of their own skills. This approach also demands literacy: the best Agile designers, project managers, developers and business owners all have a good understanding of each others’ disciplines.
While many designers are keen to adapt to the Agile world, few believe the Agile community is meeting them halfway. Agile is successful to the extent that, for some, it is dogma: an inviolable best practice in software development. However, Agile is no more “best practice” than Python, usability testing, or microformats. It’s just a tool: sometimes appropriate, sometimes not. To this end we see the emergence of post-Agilism, which tries to retain a lower-case-a agile mindset but deprecates elements not suited to the project.
Regardless of the label, it’s time for the Agile and design communities to agree on our common future. We need each other, but also need to dismount from our high horses and jump from our ivory towers. After all, we have the same goal: giving our clients and users the best we can.
Recommended reading#section9
Finally, the IxDA and Agile Usability lists frequently discuss the issue of Agile design.
