Has your organization made the move to agile development? If so, you’re in good company. A recent HP study found that two-thirds of all organizations now use agile methodologies.
While agile has undoubtedly proven effective for many organizations, some product teams are still noticing gaps in their application development. One of the most common questions we hear is where to fit the UI and UX process into their development lifecycles. The agile approach doesn’t traditionally include UI/UX design work or QA testing in the development process, instead placing them in separate stages of the product lifecycle.
We recently hosted a webinar on The Risks of Separating UI/UX from your Development Cycle. The audience responded with a number of great questions for Logi’s product management team:
Q: How do you integrate design into the agile process?
A: That’s going to depend on the type of project. But, for example, at Logi we’ve integrated UI/UX directly into the sprint process of our dev teams. What that really means is that every time we plan a sprint, one (at least) specific UI/UX-focused story is incorporated directly into the sprint process. And often, many other sub-task stories will also have UI/UX components. So UI/UX is treated just like any other piece of development.
The result, typically, is that several UI/UX stories are a part of each sprint—though each story may not be fully related to that sprint. It’s common for us to be working two to three planned sprints ahead with UI/UX stories. That makes planning incredibly important, but it also helps assure that no critical UI/UX balls are dropped.
Q: Does it really make sense to have a dedicated UX person for each sprint team?
A: Absolutely. Design, after all, plays a part in virtually every development decision made during the product development process. It’s not just about engineers churning out code in isolation. And the ultimate goal is to create the optimum user experience for customers.
Q: What about situations where a client must approve a design before development? What are the risks in separating design in this scenario?
A: That’s a fairly common scenario, and it doesn’t have to present any unique risks to the project. Think of that type of separation as prototyping. And if you’re doing prototyping as part of an overall development sprint—even if the goal is to develop some designs to be approved for future use—there’s no reason for prototyping to present special problems. Also, for a completely new product effort, the prototyping process helps ensure that you’re on the right track early in the development phase.
It is important, however, that focus be placed upon maintaining design consistency when some separation is introduced into the process.
Q: Do you attach designers to multiple teams?
A: Sometimes, depending upon the flow of work versus resources available. It’s important, of course, to assure that designers aren’t stretched so thin that they’re unable to give proper attention to each project they’re assigned.
Q: You referred to a sprint team in the presentation. Are there any other teams outside of the sprint team?
A: Generally speaking, no. Since we’re running an agile model, everything is incorporated into the sprint process. It could be argued, though, that our product management organization is not directly a part of the sprint team. But they are involved in the overall planning process, story development, and final reviews.
Q: Does the UI designer work on sprints in advance? How much in advance?
A: This typically depends on the amount of new development in progress or in the queue. As noted above, we’ll frequently have UI stories mapped out one or two, sometimes even three sprints in advance. And sometimes, UI stories are part of the development work occurring within the same sprint—particularly if certain subtasks require UI input (work or reviews) to assure that designs conform to project standards.