It’s no secret that the agile development process has been hurtling through the development world for several years now, swatting aside the older, clunkier waterfall development method. To be fair, whether it was agile or something else, waterfall really had it coming, as its risk-averse, top down approach just can’t keep pace with the demands of today’s marketplace.
While similar changes are occurring in the design world, the agile design process should necessarily look and feel a little different than agile development; they are, after all, different disciplines. Let’s take a deeper look first at what agile development is, and then at a few great ways to adapt the process to the design world.
A Quick Primer on Agile Development
The Agile Manifesto emphasizes people and interactions over processes and tools. In practice, this means communicating frequently both within teams and with the customer, as well as doing things like daily scrum meetings so that the whole team can stay looped in on the activities of its members. This creates the consistent feedback loop that enables teams to adjust based on what customers, beta testers and the market is telling them, while also checking frequently to ensure their work is functional in the environment in which it will ultimately live.
More than anything, the agile process emphasizes the production of on-time and on-budget deliverables, not perfection, as products can always be tweaked down the road. This mostly takes the form of iterations, short, intense periods of production with smaller, more achievable goals that build in further iterations down the road.
So what steps can you take to adapt similar mentalities for a design setting? Let’s take a look.
Change Your Relationship With Your Clients
The traditional design process plays right into a common desire among designers to present only the most perfect products to clients. This begins in the proposal and research phase with overly elaborate PSD mockups and continues to the final approval phase. But for the most complex projects, it really doesn’t make sense to design for weeks if not months in the abstract, completely devoid of client input. As we know all too well, clients often gain a much clearer understanding of what they’re looking for as a site comes together. What’s more, market demand has a habit of changing quicker than designers can produce. This can be frustrating when working within a paradigm in which rerouting is both labor and time intensive.
Adopting an agile approach of looping clients into every phase of the process and producing a constant stream of deliverables can help fix this, as it allows clients to play around with designs as they go. It also allows them to gain a better understanding of just how the realized vision will operate in a real world context. The more regular the communication, the lower the chances of surprises arising down the road, the better a team can adjust to changing demands along the way, rather than having to retrace their steps.
In short: Make the customer a member of your team.
Frequently Compile Work Across Teams
In the development world, the integration of intra- and inter-team work is a crucial part of any project. This is all the more true as teams grow from the tens to the thousands at the largest organizations. But integration in the waterfall method occurs at infrequent intervals, making it all the more difficult for devs to find bugs in a massive amount of code. It also leads to a lot of backtracking and ship delays.
Not so with the agile method of continuous integration, which has devs integrating code on a once if not thrice daily basis. Continuous integration really takes the unwanted mystery out of integration, allowing devs to catch bugs as they arise and either fix them immediately or add them into the backlog for the next iteration of the project. It also fits in nicely with the agile concept of privileging interactions over processes, as devs across teams must communicate frequently to identify and fix these kinds of errors.
Designers can benefit from a similar mentality, whether that means doing a simple check-in with other team members on a daily basis, or communicating more frequently with devs to determine what’s technically possible to implement before heading down an exciting but tricky design route. Cross-team communication and compiling of work will also keep designers focused on designing when design is necessary, rather than overplanning or even implementing design work that doesn’t sync with what other teams are doing.
Test, Test, Test…All the Time
On a similar but crucially different note, frequent testing is an important part of keeping iterations on track. By “testing” I mean looking beyond integration to a design’s functionality both on a micro and a macro level by developing a problem solving point of view. In agile development, devs break bigger problems down into smaller ones that can be better addressed within the framework of rapid iterations. Testing of this work then allows them to identify problems to be addressed either immediately or in the next iteration. This keeps devs on track and on-time, preventing the kind of paralysis occurs when too much is approached at once.
In this way, frequent testing and a problem solving mentality can not only keep the design process on track, but fuel creativity as well, as it prevents designers from getting too caught up on the biggest problem of all: Knowing from the get go exactly how a site should look and feel. By focusing on smaller problems, designers can embrace a more emergent creative process, and discover their vision as they go.
All of that said, the value of zooming back up to the macro level can’t be ignored, or else designs will become too disjointed. As a nice balance between agile’s smaller problem solving focus and waterfall’s more holistic view, it’s worth devoting several iterations to solving problems in the context of the bigger picture, and also just taking in the view for consistency’s sake.
When you really think about it, agile design is simply the application of certain agile development principles to the design process. As each designer and design team is different, you’re best off picking the methods that work for you and adapting them as you go. That, after all, seems like the agile thing to do.