Finding common ground between UX design and Agile development has its challenges. But with the right processes and culture in place, you can combine the two to great effect.
I know because Agile UX is the foundation of how we develop products at DePalma. Our process combines the best of Agile and human-centered design to develop highly usable digital products.
By definition, Agile UX is an attempt to blend the practices of human-centered design with the process of Agile software development.
Superficially, Agile and UX design may seem like kindred spirits.
Both employ iterative workflows that source feedback from user and stakeholders and allow for changes in direction based on that feedback.
Closer inspection reveals obvious divides in the two ways of working.
UX design uses documentation like wireframes and personas that Agile may deem redundant. Agile's focus on simplicity and shipping releases doesn't leave much room for user research.
This means UX design gets put on the backburner in favor of finishing the sprint on time.
Of course, this puts the entire product at risk. If the user experience isn’t designed correctly, then it doesn’t matter how well the code works.
Origins of Agile
To understand where product development is today, it’s helpful to recall where it’s been.
Long ago, in the 1990s, the project management world was held in the cold grip of Waterfall project management. Work could only move forward once one particular team finished their contribution, and everyone else has to wait idly until their turn came.
Building software took years. Developers couldn’t adjust to changes in the market, so products were often outdated on arrival.
A visualization of the process resembles a waterfall, and so the management technique got its name.
Then one day the Agile Manifesto was published, and a new philosophy arose to save us all.
Agile prioritized, well, agility, and it equipped developers with a set of principles to respond to changes in the market.
The overarching idea was to eliminate bureaucracy and empower the developers to deliver more quickly and efficiently.
Practically, this means breaking work into smaller, specific portions and distributing it across cross-functional teams. In order to facilitate speed, an allotment of work is to be done in sprints, or specific chunks of time.
Feedback from customers is gathered early and often. Unnecessary tasks are eliminated. Here's a visual:
And it worked. The dark ages were over. Agile revolutionized how software products were developed, and in a relatively short period of time it’s become the dominant project management methodology.
Photo and research courtesy of NN Group.
A competition of philosophies
Unfortunately for UX designers, Agile was contrived by developers for developers. It’s a methodology for optimizing the workflow of that particular group, namely by granting them the ability to quickly respond to changes in project requirements.
As a result, Agile often leaves little room for the human-centered processes practiced by UX designers.
Working in a rigidly Agile environment can rob UX practitioners of the time they need to research, create, and validate their experience design. In the worst cases, designers regress to creating visuals without any substantial data from the end-users.
To overcome these challenges, designers must address the organizational factors that limit their ability to be human-centered. Here are the most common:
A lack of buy-in
If designers don’t have the backing of their development colleagues or executive leadership, then carving out additional time for research is a steep hill to climb.
This scenario isn’t uncommon. User experience design is rapidly growing in prominence, but it’s still widely misunderstood among business and engineering stakeholders.
Thankfully, a rapidly growing body of research supports the ROI of following a human-centered process.
In our experience, citing evidence and showing examples is the most effective way to convince someone of the value of the human-centered design process.
That’s why we’ve catalogued the most prominent research here.
Skipping qualitative research
Building a sense of cognitive empathy with users is cornerstone of any UX designers process.
For most projects this requires qualitative research to establish the context in which people use the product, the challenges the face, and viable ideas for solutions. This research is also referred to as "generative" because it generates ideas for design.
Too often, developers and business stakeholders view qualitative research with suspicion. Instead, they prefer to think in quantitative terms.
The curse of being too data driven is that you sacrifice being user-centered. Qualitative research is the genesis of the optimal solutions for your audience. If you skip it, then you run the risk of delivering a sub-optimal design.
The keys to an Agile UX process
Despite the differences between Agile and UX design, it is possible to merge the two. Our product development process at DePalma relies on our ability to coordinate experience design with development, so we’ve managed to uncover a few tricks of the trade.
Here are three critical factors in our process:
When using a Scrum approach to Agile, it’s common practice to number the sprints in a project. Sprint Zero is technically a sprint devoted to planning.
During this 2-6 week timeframe, we break the work down into user stories for developers to create a backlog of work. Sprint Zero is also the time when we let the UX designers work on their first sprint before the developers start to do their work.
Here's a visualization of the work:
Agile technically dictates that cross-functional teams should work on the same part of the project simultaneously, so this approach is controversial in some circles.
Still, we’ve found that the only way to consistently produce high caliber, evidence-based designs is to let the UX team work a sprint ahead of the developers. It just works better.
For Agile UX to work, both the Agile and UX teams have to be flexible.
It’s all too common for developers to fall into a dogmatic view of Agile and resist any deviation from a narrow set of processes, rituals, and ceremonies. Of course, this approach just replaces Waterfall with another rigid set of project management guidelines.
Agile is fundamentally about pragmatism, and it should allow for leeway in its processes where something as critical as UX design is concerned.
Equally, experience designers must be prepared to amend their process when the scope or requirements of the project call for it.
For example, instead of creating full-fledged personas, designers can expedite their work and settle for lightweight proto-personas. This documentation requires far less time and resources, and in the right circumstances, can still deliver user-centered designs.
Finally, both teams must communicate with one another on an ongoing basis.
Misunderstanding is the origin of most disagreements, so we make a point to include development stakeholders in any meetings where feedback is given on the design. If time permits, we’ll even include developers in usability testing research.
What’s more, if a particular design isn’t feasible from a development perspective, our technical experts are able to clarify that constraint early in the design process.
By building communication directly into the process, we build a shared of the importance of user research and give everyone ownership in the success of the experience design.
Bringing Agile and UX together isn’t easy. It takes work. But if you can create an environment where everyone commits to open communication and flexibility, then you can build a process that harnesses the best of both worlds.