Becoming an Agile Company

How to Involve the Development Team in the UX Design Process

“Regarding your question about how to get Development involved in the UX design process, you may have to start gradually,” continues Christian. “Often, this comes down to how to involve developers in activities for a sprint when they’re not going to implement the design until another two or three cycles later. If you have succeeded in getting buy-in to a dual-track agile model, the best way to do this is to break down the developer time spent on this sprint into two separate categories:

1. The time developers spent reviewing design demos or research results from the UX design team’s current sprint, which will be coming to development in two or three sprints. This is a good time for developers to provide guidance on whether the design solutions are feasible, which will help reduce rework later on. This effort should take maybe 10% of developers’ time during a given sprint.
2. The time spent doing development for the developers’ current sprint, which includes back-end work, but also the development of the solutions the UX design team provided two or three development sprints ago. The developers will probably have questions about issues that they didn’t think of before—perhaps because they weren’t fully engaged because they weren’t coding. This will probably take the majority of their time—about 90%.

“For UX design, the above percentages are flipped: they will spend 90% of their design sprint doing design and research and 10% clarifying developer issues regarding design work they did two or three sprints ago.

“Admittedly, doing this doesn’t actually involve the development team much—we got only 10% of their attention. But you can increase this percentage a bit over time, by either:

1. Showing how having developers participate in UX design and research improves the overall quality of the solutions you jointly build—if this is true.
2. Showing that this collaboration reduces rework later on.

“Neither of these is easy to show because you need to gather the stats. Plus, I feel that dual-track agile just doesn’t allow for a ton of overlapping, simultaneous work by developers and UX designers.”

“There’s a difference between simply becoming more agile and using an agile project-management methodology such as SCRUM or XP,” says Jordan. “Generally, if the Development team isn’t involved in the UX design process, it’s not really an agile project. I’m guessing the Development team might be resisting the shorter develop-and-launch cycle because they aren’t involved in the UX design process.

“Keep in mind that the goal of an agile process isn’t necessarily to launch, but to demo at the end of each sprint. You don’t want to end up releasing partially complete work.

“Many organizations structure supposedly agile projects as mini-waterfall projects. These involve discrete User Experience, Design, and Development phases during each sprint. This often leads to the Development team being told what to do instead of their being included in the definition of what the team can accomplish.

“For instance, let’s say you’re on a two-week sprint schedule, and the UX Design team uses the first week to design and the Development team uses the second week to develop a demo. If the Development team isn’t involved from the beginning, they’ll have to wait until the designs are complete before they can start building a demo. In contrast, if Development is involved from the beginning, they can start building out the broad strokes while the UX team is defining the design details. Keep in mind that UX design needs to be as agile as development. In many cases, UX design implies a technical solution without sufficient thought. For instance, it may not make much of a UX impact whether a design uses a modal window or an off-canvas drawer. However, this choice may have significant technical impact.”

The Lean Alternative

“An alternative to agile—dual-track or classic—that may work is to instead adopt a Lean method of working, in which a cross-functional team focuses on the most important question for a given sprint and expends a minimum of effort to answer it satisfactorily,” continues Christian. “When this is done correctly, such a cross-functional team will spend many of their Lean sprints creating concepts or prototypes and testing them with users rather than developing code that leads to a release. This is the most efficient way of answering the most important questions. Later on, when there is more certainty, a lot more coding happens, and the UX Design team may be either working tactically on that solution or getting ahead of the game by doing up-front research for future Lean sprints.”

Developer-Centric Companies

“By the way, the reason you and other readers have this question and encounter this problem is because most companies are developer centric, which can lead to the widespread and sometimes thoughtless implementation of a developer-centric process such as agile,” concludes Christian. “This happens because developers are the largest headcount cost, so companies believe they need to optimize these resources more than any others. In reality, however, they are missing the fact that most of what gets developed must go through the UX design team, which is typically much smaller—from six to 33 times smaller. Adopting a process that makes UX design less efficient tightens the bottleneck further and has the unintended consequence of making many team members even less customer centered.”

“Why is the Development team the one we always worry about being put upon with so much work?” asks Steven. “I have never worked anywhere that User Experience wasn’t outnumbered by Development at least 50:1. No, I’m not kidding. I went back and looked at headcount charts. I’ve been at places that were closer to 200:1.

“So I have to say to any developer who thinks his or her life is hard, spend a day in our shoes, working every part of a project, talking to every constituent team, and doing that on five projects at once.

“It is not the job of User Experience to make anyone’s life easier except the user. Ideally, we are actually judged on those results—and at a few places I have worked, we were, with things like a quarterly SUS (System Usability Scale) being the guide.

“But back to the specifics of the development process, it’s not clear to me why developers wouldn’t want to be involved in the design process. And not just the UX design process, but the whole concept of product design. Far too many implementations of agile force developers to produce code on Day 1. What happened to planning, software design, or even iteration?

“Without these, Development teams get stressed out in the same way you might imagine a construction crew becoming stressed if they were given a pile of lumber, some hammers and nails, and a photo of the front of a house to build. If the foreman were to say, “No, don’t think about it, or talk, or stake out the site, just start building!” Things would go poorly and require a lot of rework, resulting in slipped schedules, unhappy customers, and more stress.

“Resistance to shorter cycles on agile teams results from these sorts of bad process decisions—for example, from management insisting that Development complete entire features in each iteration. From the false assumption that faster iterations are not just a different cadence, but literally faster—so if something takes four weeks today, switching to two-week iterations will make everyone go twice as fast!

“So there’s only so much the UX team can do about much of the development process. But you can try to explain the cost/benefit tradeoff of developers being involved in design up front. If developers plan, design, and use spikes properly to investigate effort and build proofs of concept, when they get to writing the final code, it will be better and it will soon become easier to estimate.

“All of this should sound familiar to most UX professionals. We do our work because we believe in better outcomes through knowledge, planning, and consideration. This applies at every level of the development process.”