Chances are, you’ve heard about the myriad ways in which the agile development method is changing the face of software development. If you’ve worked in the design world, you may even have given agile a try yourself, or at least found yourself the victim of an overeager manager who wanted to “shake things up” and “think outside the Waterfall box.”
The agile method is, indeed, an effective and schema-breaking approach, one that’s far more relevant in today’s cash-strapped, fast-paced work environment than more traditional, slow-moving, risk averse, top down production strategies, which often fall behind the market. But, while related, software development isn’t web design, and the agile method isn’t necessarily a solid template that should be applied to the design process. Instead, it’s better to take the wider agile philosophy to heart and apply the method’s core principles strategically and use a proper agile project management tool to go with it.
Let’s take a look at just what agile is, why it might be good for designers, and how to adapt it accordingly.
What is Agile?
Agile is a reactive rather than predictive development method. The manifesto states four main values:
1. Individuals and interactions over processes and tools: While the agile method does employ various techniques, e.g. scrums, processes and tools are a means for creating more frequent interaction between team members and customers, not an end in themselves.
2. Working software over comprehensive documentation: While agile does require some planning, there is more of a “dive in and get it done” mentality in order to ship a Minimum Viable Product (MVP). This reduces the amount of documentation from planning to post-ship analysis.
3. Customer collaboration over contract negotiation: With agile, the goal is to get things done quickly. For that, customers need to be on board and in frequent communication with the development team, not negotiating terms.
4. Responding to change over following a plan: There are few “straight paths” in agile. Work occurs in a series of iterations so that the team, clients, and beta users can test various elements of the MVP as it’s developed, and change course if necessary.
Why Agile is Good for Designers
While at first it may feel weird and even upsetting for designers to nix the upfront, static PSD, the agile method can really big a boon for the creative process. On the simplest level, it can get designers out of that pixel-level perfectionism that can delay delivery of projects for months, bring projects in over budget, and even impede the original brainstorming process.
The agile method also allows designers to gain a continuous look at just how users interact with designs. This may lead to more low-level frustrations when, say, a whole day’s work needs to be re-envisioned, but it also prevents even bigger redesigns down the line when a client doesn’t like a finished product that may have taken months to develop. In the right situations, where communication is productive, agile can even lead to more creativity as both the designer and the client discover the true heart of the project as they go.
Lastly, agile design will help designer work seamlessly with developers also using the method, promoting collaboration rather than silo-induced isolation.
Let’s take a look at a few agile techniques and see how they apply to the design world.
Technique 1: Frequent Iterations
While still essential, the information gathering, site mapping, wireframing phase in agile design should be seriously reduced, as should, really, every other phase of the design process. Instead, the design team should set goals for an MVP right up front, and then work toward achieving that MVP via a series of 1 to 2 week iterations. This means breaking tasks up into a series of smaller deliverables and tasks, placed into the categories of backlog, in-process, in review, and in production, so that the both team members and the client can constantly re-evaluate and re-prioritize. It also may be helpful for designers to focus on developing personas that can inform the ad hoc design experience.
In order to really embrace this new process, it’s important to adopt the attitude of welcoming changed requirements, and being ready to set new goals, as long as they bring you closer to your MVP. You’ll also likely to do better if you forget static PSD mockups in lieu of sketches and easily changeable mockups. Overall, it’s best to start working with products from day one, something web designers will be better able to do if they work in browser.
Technique 2: Continuous Integration
One of the biggest pitfalls of the waterfall method is that a team could very well reach the end of a development cycle only to find that many moving parts don’t fit together. This can still be a problem even with agile’s many iterations, as there’s no top level plan to tie it all together. In fact, the more frequent a team’s iterations, the more important it is to do continuous integration. In the development world, this means integrating, running and testing code once a day, to make sure everything is aligning. Continuous integration is obviously important to do both on the design team itself, but it’s also a chance for designers who may be developing a greater sense of a project’s overall direction to guide the project’s holistic vision.
Technique 3: Constant Interaction with Clients
Agile design, just like the agile method at large, really can’t work without constant interaction with clients. Yes, I know, this might seem nightmarish to consider outside of any but those dream clients, who come equipped with a clear vision of what they want. But in many ways, agile is much more appropriate for the average or even difficult client, who can’t make a decision. With agile design, you’re bringing the client onto the team to test and re-prioritize right along with you, allowing designers to gain a much better sense of just what clients are looking for through interaction than the clients may even have themselves.
However, it’s important that someone on the team act as the point of contact, so that designers can focus on their work. What’s more, there should still be clear leadership from the design team so the customer doesn’t yo-yo too much, or else the final product will be disjointed.
Takeaway
Despite its many strengths, the traditional waterfall method just won’t work in today’s market, and it has the added detriment of playing into designer perfectionist tendencies. If the highest principle in the agile method is to “ship all the time,” why wouldn’t agile design benefit both customers and designers alike? Communicate well, build well, ship well, and take your design up to the next level.
Note: all images designed by Luke.
“also likely to do better if you forget static PSD mockups in lieu of sketches and easily changeable mockups”…*GASP! FAINT!* I would be lying if I said this statement didn’t just give me heart palpitations. I am a design control freak, they’re gonna have to pull my PSDs out of my cold dead hands! 😀 My biggest fear is that the agile design method is going to create a lot of “cooks in the kitchen” problem. Hold onto your lug nuts designers! This could get ugly…. really, your designs could get really ugly. 😀
Leigh, I, myself am afraid sometimes of my design becoming ‘ugly’ after the initial draft…
If we can take in what our client wants, and justify our design as to how it suits their needs, it’s possible to have a result both you and the client are happy with.
Unless a client is being particular and telling you to use a green>yellow gradient on the navigation bar, you have all the potential in the world to make every design a great design!
Indeed, with this approach most clients have a hard time understanding that preliminary sketch != final design, usually if I provided a more polished mockup they better understand the direction because sketches leave a lot more room for interpretation. But that might also be because I’m not Don Draper? 🙂
PS: I’m not saying Agile is bad, I like the idea but maybe if it is kept inside the company and the client sees more iterations but still far from rough sketches.
Really love this article.
I’m a firm believer in seeing the client as a collaborator more than anything else (especially not a nuisance).
All too often designers have a subconscious notion that we’re designing to make ourselves happy and not actually for THE CLIENT. We are here to make others happy.
Great tips, thank you!
Great article! Congratulations. From the strategic design perspective, what you say has even more impact. Learning to be reactive without losing quality is the challenge of our times.
Love the underlying philosophy, and have used many elements of agile in our interactive design process for years (when it fits with client/project needs). The challenge with any approach that embraces shifting requirements is managing the budget and schedule! In software development, you are developing the product itself, the success of which relies on its “greatness” to compete in the market. While the same is arguably true for design work, client projects are typically focused on a scope and budget…we’re not doing R&D, developing ownable IP.
I actually prefer constant interaction with the clients, because like Alex said it’s difficult for the client to see the end result in a sketch. So I think it saves time in the long run to have them along for the ride, so they don’t get a big surprise at the end of the project!
Yes, rush crap out so you can do it over (and over and over ) till, like Krusty the Clown sez, “it’s not just good, it’s good enough”. Why bother to think about stuff when it’s only gonna be around for 15 seconds anyway. And when will those silly architects stop wasting all that time with those finicky blueprints and just start throwing those buildings up – the Donald can’t be kept waiting.
Sorry–
Stopped reading when you said “web design is not software design.” Wrong. Can’t wait for the day when you jump on the next bandwagon, when it trumpets correctly that web design is software design.
This is a really good article. Discussing Agile Principles in relationship to design shows a strong correlation to how a successful design team has always worked — when it is really built right, don’t you think?
Having the designers interact with the client continually with current versions of the concepts does help the client & designers figure out what the client really wants. (Helps us not have to be psychic).
And, having a point person on the design team act as the point of contact with the client & a clear leader on the team helps give the customer the successful final product.
I think Agile means being strick, it works if some company paying the amount necessary for the designer, and it is only supports in USA and European country. In those country where people pay less for designer, Agile won’t work instead they would run away from the job.
Agile is actually pretty good if you’re more into GTD kind of thinking rather than being perfectionist.
Good post btw 🙂