Welcome to Designer Confidential: a new advice column where we’ll share practical advice on solving your toughest challenges. We want to help you tackle your biggest obstacles as a manager, like transforming your organization, creating a better-connected workflow between designers and developers, building a great team, and much more. You can submit your questions via this form, email us at email@example.com, or tweet at us at @InVisionApp. This is our first installment, so keep your eyes peeled for the next one!
In an Agile-driven project, how does a UX professional fit in where time is scarce and product development is usually started right away?
UXer working on their Agility
Your question is one we often hear from designers, as Agile is central to the digital transformation process at companies around the world. Agile is a methodology that helps organizations (especially engineering organizations) work faster. Problems arise, though, when Agile teams move fast but in the wrong direction.
Speed on the wrong trajectory can result in entropy, wasted time, and a poor user experience.
Designers often want to slow the process down: to talk to customers, understand the problem more thoroughly, and design a full solution. There is a virtue in these intentions, but the time invested can feel like a vice if it compromises the team’s ability to ship on time.
We need to find a balance, to bring together trajectory (understanding the customer and the problem we’re trying to solve) and speed (building things as fast as possible to meet business needs).
Want more post like this in your inbox? Sign up for our weekly email digest.
We’ve talked to a few people about this problem, including developer Brad Frost and designer Dan Mall who invited us to challenge our assumptions about how design should work.
Dan Mall, co-founder of SuperFriendly, said, “When it comes to Agile, the first step is designers figuring out how to work smaller, rather than how to work holistically and broadly. If designers can work smaller now, they can work at the same pace and the same cadence as the developer counterparts and that makes for an even playing field.”
We also talked with Josh Seiden who co-authored Lean UX and Sense and Respond with Jeff Gothelf. Not only has he written extensively on this subject, he also consults and speaks regularly on how design and Agile should work together. He said,
“In an eight-week research study, you should be planning on saying at the end of every sprint, I’m going to share the work in progress. I’m going to deliver some value to my team. ‘Hey, we did two interviews this week. Here are the themes that came out of the interview that’s valuable.’ Even if it’s not finished research or conclusions…a team will get value from that without having to wait for eight weeks to learn what you’ve been doing.”
“Everyone in an Agile team needs to spend time with customers to create a shared understanding of the problems you’re trying to solve together.”
Jeff Gothelf has published some rules for how UX should integrate with Agile worth noting here. Here are the key takeaways:
- Every Agile team needs at least one designer. I’m an advocate for two designers per team as, when you’re a solo designer, it’s easy for the values of design to be overpowered by engineering.
- Everyone in an Agile team needs to spend time with customers to create a shared understanding of the problems you’re trying to solve together. Jared Spool’s rule of thumb is great: everyone should spend a minimum of two hours with customers every six weeks. Jeff adds, “The more the team can learn together, the less time is spent sharing and debating the learning and more time spent deciding what to do about the things we’ve learned.”
- Jeff recommends creating just one backlog of work that contains development, research, design, and QA work all in one place to be prioritized and shared. In his experience, if design work is in a separate backlog it will get ignored.
Jeff’s also taken the time to diagram out the workflow he’s found to be most effective in aligning design and engineering in Agile teams (Fig 1).
Marty Cagan, founder of the Silicon Valley Product Group (SVPG), has been advocating a similar but slightly different approach called Dual-Track Agile. In this methodology, there is a discovery track (learn about the problems) and a delivery track (build the solution). It reminds me of the classic double diamond.
One key benefit of a Dual-Track Agile approach is that it helps the team test hypotheses and define design details before the development begins, which cuts down on wasted time building the wrong things. This approach maps well to the way designers tend to think. Designers want to understand our users and the problems before we start designing. Some have also pointed out that Dual-Track Agile can be an effective way to make space for innovation in a system that’s so focused on iteration.
We hope this helps get you on the right track for finding better ways to fold design into fast-paced Agile workflows. It’s not impossible, but I acknowledge that it’s hard! I’ll leave you with these action items to point you in the right direction:
- Do your homework. Research these models so you can speak about them intelligently with your colleagues.
- Make a friend. Build closer relationships with your colleagues in engineering with whom you can explore ways to refine your process. This not only makes space for design, but also will improve the quality of your work.
- Buddy up. If you’re the only designer on your team feeling like a stranger in a strange land, take note from the Slack design team who practice paired design. Identify a designer you can work with a few hours a week to get feedback, get unstuck, and get the comradery you need.
Wishing you the best as you dial in your team’s approach to Agile. There’s a place for you and your fellow designers in the workflow!