Making agile the friend of experience design
17 Sep 2013
17 Sep 2013
In many projects, mismatches between UX and development practices can present a real barrier to the timely delivery of quality software.
Although the answer is not always obvious, paradoxically it’s not difficult to fathom the causes: proper user-centred design insists on iterative engagement with users. The fact that this supposedly time-consuming activity isn’t planned into most software development processes creates tension. Add the race against the clock to deliver working code that characterises most software projects, and you have an apparently intractable challenge.
The latest software development paradigm, Agile, is one of the most pressing topics for the UX community currently. Put simply, if UX is to create positive outcomes for complex software projects, then engagement with approaches like Agile is a necessity.
A measure of how problematic the issue remains is that many UX conferences now have entire sessions devoted to the subject of how practitioners and developers can collaborate on Agile projects. At UXPA 2013 in Washington DC recently I heard other attendees share familiar ‘software project’ war stories about ridiculously aggressive timelines, technology solutions that were advanced too quickly to accommodate improvements and user insight-driven changes snuffed out by apparently inflexible developers.
What I find slightly disappointing about the current level of debate within the UX community is that as practitioners we are supposed to be experts at getting inside the heads of customers. We try to see the world through their eyes – and then design solutions that make sense from that perspective. Why then, as a field have we not applied these skills to properly comprehend the pressures and constraints which inform the practices of software developers?
In my experience, when UX teams working within development environments get into difficulty it is usually because they have committed one of the following two errors, both of which impact on user-centred design outcomes:
In both the scenarios above, there is a failure on the UX designers’ part to engage with the development framework in which they must work.
As I mentioned, Agile is the latest development approach that UX people are grappling with. It’s not my intention here to discuss Agile’s overall merits as a tool for rapid, cost-effective delivery of software (previous blog posts have commented on Agile’s pros and cons from a UX perspective). What is indisputable is that Agile is a reality the user experience community cannot get away from. So, how can user-centred design be safeguarded within an Agile approach?
I feel increasingly that the answer lies in applying Agile’s own best practices: comparing notes with others in the UX community, it does seem a great deal of what passes for ‘Agile’ development is nothing of the sort. Many practitioners I spoke to described similar experiences of ‘pseudo’-Agile formats, where the only ‘Agile’ aspect of the process was that everyone was expected to work crazy hours to deliver the solution to a ludicrously optimistic deadline.
It’s certainly my experience that development teams and stakeholders frequently do not want to abide by the rules of the game they themselves have chosen. That is a pity, as properly observed, these best practices can create an environment that is conducive to good user-centred design.
To illustrate the point, consider that the Agile Manifesto‘s four key principles:
All of these factors can add up to projects which are only superficially ‘Agile’. Project stakeholders appear to have a fast-moving and iterative production process, but in reality much of the fundamental Agile philosophy is not being observed.
Here then, are my big 4 suggestions for making Agile the friend of UX design:
1. Identify ‘Big Ideas’, not Big Design, upfront
2. Do not over-specify UI design early on:
3. Make UX an Agile activity:
4. ‘Adequate and real’ is better than ‘Great but imagined’