I’ve been involved in an interesting discussion that stemmed from an article written by Marcus Lillington from the guys over at Headscape: ‘Does Agile methodology lead to poor interface design’. It’s a debate that crops up quite often, especially from designers working in companies that have, or are trying to adopt Agile but were previously delivering the creative process akin to something ridged like Waterfall.
Here are a few complaints I’ve heard:
“Agile doesn’t value visual design within the process so design isn’t given enough time”
“Agile doesn’t enable you to consider the whole character of the design”
The problems I hear often have little to do with Agile and more to do with an implementation or (mis)interpretation of Agile. Quite often it’s because Agile has been introduced or driven by the technology requirements of the business and the adoption has not been considered company-wide. Those stuck on the outside are left without a clear understanding of how they fit in. Additionally, Agile is too often treated as a process that focuses on technology and not as a set of values as it should.
If we follow this manual and pick from this menu of tools then we’re Agile
There’s nothing that tells us how design should be accommodated within an Agile project, but stripped back to it’s core, there’s a set of four Agile values that can, and should, be applied to the creative process:
– Individuals and interactions over processes and tools
– Working software over comprehensive documentation
– Customer collaboration over contract negotiation
– Responding to change over following a plan
Which designer on Earth would question adopting any of these values?
Agile can help
Agile can help us focus on the desires and emotions of our target audience as much as it can help us to deliver technology. We can learn about our customers, building up a deeper understanding of them by having quick feedback loops that test our designs on real people, with working software. All of this lovely feedback is invaluable information for a designer to embrace within further iterations, refining the design so that it aligns with the users as we discover more about them.
On the other hand, if design doesn’t take into account the type of person that the software is being created for, then the design has failed. For example, a design that fulfils a function but doesn’t strike a chord with the intended audience, so much so that it puts them off using what’s been created, is as much of a failure as something that looks great (to them) but doesn’t perform the functions the user needs – we’ve created the wrong thing either way.
I would recommend thinking about design as something that’s testable: akin to an acceptance criteria. Make design a conversation of the user story, as opposed to a veneer that’s applied in some different way. Make designers accountable for the quality assurance of the user story by embedding them within the production workflow alongside developers, UX’ers and frontend’ers. As Mike Cottmeyer points out, you’re not really Agile unless you have a cross-functional team, so figure out a way of involving designers throughout the production process as part of your team.
Make design a conversation of the user story as opposed to a veneer that’s applied in some different way.
When it comes down to it, design can succeed or fail within Agile the same way as it can using Waterfall or anything else; in the end, it’s how you choose to embrace the Agile values within your organisation that will determine if you get the right results. I’ll finish off by reiterating that Agile doesn’t tell you how to design and therefore can’t really be blamed if design doesn’t work out. Think how to make Agile relevant to your designers as well as your developers and above all, take this with you and hold it close:
‘Individuals and interactions over processes and tools’