UX matters, and the proof is piling up. A five-year study conducted by McKinsey revealed that design-driven companies pulled in 32% more revenue and 56% more shareholder returns. As a result, more companies are bringing UX designers aboard… only to find that UX seems to destroy their entire Agile process! Instead of working together as a team, designers and developers wage war with each other, and nothing gets done.

After much trial and error, we’ve learned to avoid this problem at Curtis. Here are four of our best peacemaking tactics.

1. Introduce the entire product team to User-Centered Design.

Steve Jobs said, “You have to start with the customer experience and work backwards to the technology.”

That’s User-Centered Design (UCD) in a nutshell.

Beginning as a vague notion, UCD has evolved over the years into a structured process by which UX designers research, design, prototype, test, and iterate on designs with end-users in mind. UCD is the heart of every great user experience, and fundamentally, it’s what UX designers do.

Unfortunately, if you ask many developers what UX designers do, they’ll say something like, “They draw squares and rectangles” or “They make pretty pictures.”

The first step to “winning” (a.k.a. not fighting) the war between developers and designers is aligning the entire team’s goals around the customer. So, as unorthodox as it might seem, UX experts should share the core concepts of UCD with developers! Giving developers a look behind the curtain does wonders to facilitate a unified, user-centered working relationship between different teams working on the same product.

2. Give UX a long runway in advance of the first Agile sprint.

This is really, really important.

UX must always work ahead of development, getting all the research, exploration, design and testing done before the first line of code is written. This is the only way to get a successful user-centered product.

Moving forward from there, UX can, in fact, operate within the Agile process. A good rule of thumb is to keep UX two sprints ahead of development. This way, if there does end up being a delay in the UX cycle, devs can work on other action items independently, without having to wait on UX. That’s what true agility looks like.

3. Include developers in early UX meetings.

For a designer, there’s nothing worse than finding out you’ve designed something that can’t be built. Including engineers from the outset is not a waste of their time: It helps ensure that designers are aware of relevant technical limitations as early as possible, saving everyone time in the future.

Another bigger-picture benefit of this hearkens back to our first point about introducing devs to the principles of User-Centered Design. During that long-runway UX phase, a profile of the end-user emerges, which is useful for developers to see and think about.

4. Make UX part of the Agile team.

This is most critical—and most often neglected—when it comes to release planning. During release planning meetings, get the UX team to estimate how long their tasks will take, just like everyone else. Also, throughout the development process, UXers should communicate using the same tools—in other words, don’t put UX tasks in Asana if you’re assigning dev tasks in JIRA. Overall, the more UX is treated as part of the development team and not as its own silo, the better the outcome will be.

Takeaways from this article:

You can have a dedicated UX team, a user-centered approach, and an Agile workflow. To accomplish this, unite developers’ and designers’ goals by introducing the whole team to UCD. Then, give UX a long runway in advance of the first sprint, include developers in early design meetings to save engineering time later, and treat UX as part of the Agile team, not its own silo. 

Congratulations! You’re on your way to making a great user experience, not war.

  • Share:

Leave a Comment

Your email address will not be published.

You may use these HTML tags and attributes: <a href=""> <abbr> <acronym> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Send a Mesage

Message sent!