Making agile the friend of experience design

By Rob Gillham 17 Sep 2013

How best to fit user experience design activities into software development has long been a challenge.

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:

  1. Faced with mounting constraints, the UX team abandons user research in favour of immediate production of screen designs – with the shape of the solution dictated to them by developers and business analysts. Instead of driving the solution, the designers have become the slaves of the process by which it is built.
  2. Working outside the development plan in an attempt to remain independent, the UX team delivers unfeasible designs – and too late in the development process for them to stand a chance of being built (this is arguably worse than 1, as by removing themselves from the mainstream of the project, the UX team is distancing themselves from the production team).

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:

  1. Individuals and interactions over processes and tools – Interaction designers generally love collaborative environments. Co-location of teams is an important part of the Agile approach, but with many development teams now located offshore, this is routinely and conveniently ignored.
  2. Working software over comprehensive documentation – Software documentation rarely describes the solution accurately and goes out of date quicker than anyone can update it. Despite this, many stakeholders are instinctively in favour of this ‘Big Design Upfront’ tendency. This demands a fully documented UI early on, making the design vulnerable to the inevitable changes that will be required later on. Conversely, low-documentation Agile environments less wasteful of effort and more responsive to late-breaking user insight.
  3. Customer collaboration over contract negotiation – Agile teams are supposed to contain a customer representative. In reality, clients are reluctant for spare people from their business to support development. This is a false economy as they are invaluable, particularly for helping decide priorities when trade-offs between UX design and speed of coding are required.
  4. Responding to change over following a plan – I consider this to be one of the most important Agile concepts for UX. Traditional ‘Big Design Up Front’ demands adherence to untested hypotheses. Like user-centred design however, Agile emphasises continued reflection and improvement to deliver solutions of value. Sadly, in practice this often ends up as little more than arbitrary scope-cutting as soon a solution appears technically difficult to accomplish.

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

  • Identifying business objectives, design principles and desired outcomes for users are more important at this stage than specifying UI solutions. They provide a basis for decision making later on – and more likely to survive necessary changes to the development framework.

2Do not over-specify UI design early on:

  • Don’t waste time on inappropriately detailed work, as inevitably this will need changing the moment you begin work with developers.

3. Make UX an Agile activity:

  • Make the game work for you – insist on the developers and stakeholders play by the agreed rules: co-location, daily scrum meetings and regular reviews – if you’re going to do Agile, do it properly

4. ‘Adequate and real’ is better than ‘Great but imagined’

  • Remember that like UX people, developers are quality-focussed people driven to create great stuff. Agile practices are simply pragmatic measures which allow them to deliver working software on-time and on-budget
  • Above all, remember that a solid idea that gets built is better than an impossible dream which never reaches the market.

What do you think?