Agile Design Tip 1—Clear Goals Supported by Design Researchagile-design-research

In Some Thoughts on Design Research, Agile, and Traps Charles Lambdin stresses the importance of clearly defined goals. “Design Innovative software” is not a concrete goal; it’s a vague directive. Expand online clothing offerings, streamline the sales funnel, and clearly present all costs to customers are useful goals because they provide direction. They don’t tell the team how to design, but they serve as virtual guardrails to prevent the project from careening off the road.

Well-defined goals are necessary but not sufficient. These goals must be supported and refined by research: “The very point of design research, after all, is to determine what work the team should be doing in the first place.” Indeed, a thorough research effort can show the team specifically what to design and perhaps even how to approach the new design.

Agile Design Tip 2—Leading with UX Design

As explained in Why UX design is so important in agile software development, one straightforward approach is to allow UX designers to work one sprint ahead of the development team. The “UX advance team” can quickly gather user feedback to evaluate proposed product features. The underlying principle here is straightforward. It’s easier and cheaper to fix a problem at the design stage than during development and exponentially cheaper than addressing after product release.

Zach Watson Director of Content at DePalma concurs. Watson reminds us that “Agile wasn’t created with UX designers in mind. It was created for software developers. Consequently, Agile processes don’t leave much room for the user research phase of the UX process that designers rely on to inform their designs” (How to Build Better Collaboration Between Developers and Designers).

This reality usually means that UX designers are under pressure “expedite their process to conform to the deadlines set forth in the developers’ sprint plan.” The result is either a lower quality design due to this compressed time frame or a clash between designers and developers.

Neither is optimal, which is why the DePalma teams incorporate a sprint zero to allow designers to work ahead of developers.

Agile Design Tip 3—Re-thinking Up-front Design

In Designing in (and around) Agile Mike Kuechenmeister takes a different approach by advocating for as little up-front design as possible. The reason is that it takes considerable time to solve complex problems: “While incrementalism can be valuable, it often fails to get its arms around big issues. In fact, many problems are produced as a result of incrementalism.”

Instead, argues Kuechenmeister, the following should happen up front:

  • Ensure that the entire project team agrees on problem definition, scope, and requirements.
  • Don’t isolate design. Instead, gather the entire team and ideate together. This approach encourages a diversity of ideas. It also sets appropriate expectations because everyone is involved in design decisions.
  • Prototype quickly to prepare for usability testing and also to share concepts with leadership.

Kuechenmeister’s position is unconventional, and designers should not necessarily give up on leading with design. For certain projects, however, this approach is worth considering in order to keep design front and center.

Agile Design Tip 4—Going Through the Motions

agile-design-going-through-motions

The idea behind tips 3 and 4 is to urge developers to and product managers to allow sufficient time for user experience. In short, don’t make UX a checklist item. Make it part of the Agile process.

In What The Karate Kid Can Teach Us About Agile and UX, Agile guru Jeff Gothelf encourages developers and UX designers to go through the Agile motions together. Activities include daily standups, story gathering, and estimating.

Initially, a UX designer might not understand why she is going through this process sensing that these activities lie outsider her area of expertise: “As time wears on, the benefits start to manifest simply from the designer spending time with the team.”

Time spent with the team leads to camaraderie and, eventually, to trust: “Trust develops into transparency where the designer is now including developers in her process and developers are seeking out the designer as they code the experience.”

Gothelf realizes that trust takes time and requires the designers and developers to argue, fail, and eventually achieve success together: “Designing a schedule of ritual practices provides a framework for the team to start working together. Teams that go through this process begin to evolve beyond the textbook practices and evolve into high-functioning teams.“

Agile Design Tip 5—Joining UX and Quality Assurance (QA)

Naturally, QA teams review software near the end of the development cycle. It is not common for UX designers to participate in QA. In Why UX design is so important in agile software development Alejandra Rodriguez makes the case for joining UX and QA in the Agile Design process.

QA experts excel in finding errors and bugs in the code. They do not focus on interaction design issues. When UX designers work alongside QA, they are likely to catch usability issues that the team can correct prior to release.


About the Author

Eric Olive leads workshops focused on UX research, facilitation skills, and copywriting. He also writes about Agile UX and Agile Design.

Eric’s has spent the past 18 years conducting UX research for Fortune 500 companies in the finance, insurance, manufacturing, healthcare, education, and telecommunication sectors throughout the U.S. Eric’s UX career includes extensive work with Spanish-speaking users in the United States and Latin America.