Virtually all Agile developments project will eventually meet the user experience design process. It’s inevitable. Unless you’re working on something that will run unseen by anyone — some middleware, perhaps, or an application that integrates data flow between two existing systems — someone has to interact with the software being designed and built. Even the most compelling UX design will literally do nothing without code to perform functions, manipulate data, and connect with other systems.
However, when UX and Agile practitioners meet, we’ve found that there is almost always a communication challenge. These two disciplines use similar terms but in different ways. Without some new techniques of working together, the result will disappoint everyone involved: designers, developers, and users.
Semantics are critical in business. When different groups use a term in common but in different ways, the result affects smooth management of the organization. A classic example is the misunderstandings that occur over a single term like inventory.
How can anyone misunderstand that? You’d be surprised. The warehouse sees inventory as boxes on the shelf. Supply chain management might include inbound material that hasn’t yet arrived. Purchasing looks at the value of the most recent acquisitions, while finance uses an average value, or maybe a first in/first out approach. All of them use the term inventory, and yet they all treat it differently.
When it comes to UX and Agile, the same is true with respect to one of the most basic terms: iteration. Ask designers and Agile developers how they work and they’ll say they start with talking to the client and then, step by step, they use a process of working and then refining what they do. Eventually, they have a finished project.
With recent trends to bring UX and Agile development into a more joined-up collaboration, we’ve noticed that both disciplines approach the practice of iteration differently. In Agile, iteration typically means the time-boxed allocation of time to developing the next set of software features that represent a future software release.
Designers, whether creating interfaces, scarves, cars, or illustrations, approach iterations differently. Designers often create multiple complete concepts at the start of a project, not small increments. The more approaches the designers consider, the more options they have to solve the problem of how the user will interact with the product in question.
A great example is that of Apple’s chief industrial designer, Jonathan Ive. When working on a final school project, he built 100 models rather than the six that other students did. Ive has spoken of his team bringing a product design for review by the late Steve Jobs, who told them to go back and start over.
Having to toss what seemed finished and then start over isn’t restricted to the famously fussy Apple. Interface usability expert Jakob Nielsen has described an online white pages system that had settled on a general concept and gone through 14 iterations, only to be scrapped and completely reworked.
For Agile developers, iterations are opportunities to build new increments of software built on top of previously delivered functionality. Design iterations however can be ether improvements on existing work — or they can be someone declaring a previous approach to be rubbish and starting over. That’s because a design doesn’t always lend itself to growing in steady increments. For Agile software projects to be successful, we’ve found that it’s important to understand this fundamental difference between the way in which both developers and designers talk and think.
In my last article I reviewed the basic concepts of LeanUX and how both designers and Agile practitioners are finding new ways to collaborate and satisfy the requirements of both disciplines. The emerging insights from this movement demonstrate that designers will need to learn new ways to deliver designs incrementally while Agile practitioners will need to better accommodate the less predictable nature of human centered design. This new, sometimes awkward “mash-up” of disciplines is both inevitable and critical for those serious about innovating software and services that have customers begging for more.