Incorporating UX into Agile Development
‘How to UX your Agile’ — the topic that has launched a thousand Medium posts — is worth discussing because it continues to be a major pain point for product teams. In the following, I’ll discuss tips on how UX designers can vibe with the pace of sprint cycles on top of succeeding in organizations with varying levels of UX maturity.
These tactics are based on my experience in manufacturing environments. Engineering organizations tend to be late adopters of Agile methods and have low tolerance for ambiguity due to detailed requirements related to safety and compliance. However, this ‘newness’ to Agile has presented opportunities to help shape our development process to be more inclusive of UX.
So far, these approaches have gone over well:
- Convince teams to take UX debt seriously;
- Stay involved throughout the product lifecyle;
- Manage relationships with stakeholders;
- Educate while delivering; and
- Advocate for UX priority in product backlogs.
Taking UX Debt Seriously
Agile’s emphasis on speed incurs UX debt. What is UX debt? UX debt in a sense is much like technical debt, it includes features, user stories or enhancements that are de-prioritized in favor of velocity. UX debt accumulates over time (much like compound interest, hence the analogy) and the longer it goes unaddressed, the more the user experience loses its integrity. Refactoring post-production is costly and frustrates both the dev team the users impacted by a half-baked product; as not every organization has the resources to support continuous delivery. Alternatively, if teams never get around to addressing the debt at all, users could get used to the bad designs and learning new patterns could be disruptive. Organizations may even lose customers, market share and talent because products become difficult to maintain and use.
So, other than emphasis on speed, why does UX debt occur? The Nielsen Norman Group provides a list of debt-causing scenarios, however, I’ve seen it happen most often in efforts that involve acquiring or merging other products without a change management plan. In other words, rolling existing solutions into new products, and haphazardly sundowning others. Working with legacy code and delayed refactoring plays a role too. Sometimes UX debt isn’t known at the outset, as it may be later identified by stakeholders, customer service feedback, surveys, and analytics. Now that we’ve defined UX debt and its implications, you may be be wondering how to reduce it.
Staying Involved throughout the Product Lifecycle
One way to reduce costs associated with UX debt (or poorly implemented UI) is for UX to stay involved from ideation to deployment and subsequent iterations after. Seems like a no-brainer, but, ha, it is not. Depending on the design culture of your organization, this can be standard practice or a relentless, soul-sucking, uphill battle. If you’re in an organization with low UX maturity, the key to design presence is gumption. UX designers need to just jump in. Ideally, over time, UX will gain organizational trust and each new project kickoff will go a little smoother.
On tactical level, one way for UX stay involved is to engage developers. By doing so, UX designers can learn about feasibility and constraints early in the process. Understanding the tech stack or IDE where the product will reside is also helpful; because basic knowledge of the development process creates empathy. UX will then be better equipped to understand why some solutions are more involved than others. In my experience, annotating wireframes with product backlog item numbers helps devs know where I’m coming from. If devs want to know the rationale for a pattern, IA or interaction on screen, they can view the associated user story in the in the Scrum docs.
In Agile teams that value UX (and allocate points accordingly); designers typically work a sprint ahead of dev teams. As Catalina Manea points out, sometimes this staggering creates the expectation that the designs are supposed to be complete by dev hand-off — when designs aren’t complete, UX is considered a roadblock. The pressure to deliver leaves little time to validate conceptual approaches and test wireframes. Socialize the idea that testing is intrinsically part of the design process, not an added line item on an SOW. A small amount of testing no matter how informal (like guerilla testing) is still better than nothing. Knowing who engage is important, which leads us to another component for success in a product lifecycle: relationship management.
Relationship Management
One of the key factors in ensuring the success of UX efforts in Agile teams is having a solid relationship with the product manager. In Agile, the product manager represents the customer and is often held accountable for the success or failure of a product. (Sidenote: I used to be confused about the difference between a product owner and a product manager until I read Melissa Perri’s take: “Product owner is a role you play on a Scrum team. Product manager is the job.”)
Since the product manager is a proxy for the customer, it’s really important that UX supports him or her when defining user stories and grooming the backlog. UX can facilitate by contributing product backlog items and ensuring end-user representation via design validation. Sometimes the business will require something that undermines end-user expectations, and it’s UX’s role to discuss these issues with the product manager.
When it comes to cross-functional teams; it’s also important for UX to engage stakeholders and executive sponsors, especially if the product manager does not take an active role in this coordination. I’ve seen really well-executed products get killed because an influential stakeholder was taken by surprise. No one likes surprises. One way to mitigate is to work with the product manager on a RACI matrix. A RACI is basically a spreadsheet listing stakeholders or teams and an agreed-upon level of involvement: responsible, accountable, consulted or informed. A RACI helps UX and product manager cover their bases, but also safeguards the process from becoming a design-by-committee situation. Now that we’ve discussed how to get involved with the product lifecycle, what do we do once we’re in? We demonstrate value to product teams.
Educating while Delivering
For teams new to Agile (or new to UX methods, for that matter) it’s helpful to take the show-and-tell approach when discussing deliverables associated with UX services. For example, I don’t just explain what a deliverable is without an example (some people don’t know what a wireframe is, and that’s ok) nor do I discuss a deliverable related to product team efforts, without first providing context. The goal is to show that UX design is a methodology and discipline with standards. It’s not me, just making stuff up. Sometimes I still come across teams that view design as ornamentation — something that’s slapped on at the end of the process — and I view that as my responsibility to educate otherwise. Beyond an individual level, UX teams in organizations can host lunch and learns and design thinking workshops to set expectations of UX services well before a request comes through.
Another way to add value is to track the successes or learning opportunities that resulted from specific design decisions. Leveraging analytics, user testing or working with the business to define product KPIs make compelling arguments to take design strategy seriously. However, in Agile, it’s important not to get too overzealous with design rationale, because direction can change quickly. Moreover, don’t create documentation for the sake of documentation or process for the sake of process — keep the focus on the shared conceptual model of the product and the shared strategy to meet business and customer needs.
Maintaining UX Priority in Product Backlogs
So now that your Agile team is committed to:
- taking UX debt seriously;
- involving UX throughout the product lifecycle;
- and knows what to expect from UX in terms of communication and deliverables …
Then what? On a practical level, how do we ensure that end-user advocacy and design best-practices actually make their way into the product? If there’s one thing I want you take away from this caffeine-fueled missive, it’s this: do everything you can to keep UX efforts high priority in product backlogs. Why? UX-related stories are often forgotten when the pressure to fix things diminishes as devs get shuffled onto new priorities. The Nielsen Norman Group suggests using the same dimensions (ranking system) for UX items as all other items in the backlog; with the exception of assigning higher priority to fixing existing features rather than introduce new features (because if something doesn’t work, then it shouldn’t exist).
The NNG also suggests either adding UX stories directly to the backlog or qualifying them first in a spreadsheet so the team isn’t inundated with new stories related to UX debt. I personally, don’t recommend putting that information it in a spreadsheet first — because it’s too easy to disregard a stray document not within an IDE/PM platform.
Another approach is to rank UX debt-related stories (or general UX product backlog items) based on highest impact/value and lowest effort (a priority matrix) — this approach requires input from the dev lead. Other factors for success include dedicating a specific amount of story points for UX debt each sprint; routinely sharing how the progress was made; and ensuring that stakeholders and sponsors show up to retrospectives (so that the people who have the power to change things can see outcomes).
Regardless of where your organization is with Agile adoption or UX maturity, the single most important thing you can do is advocate for the people who will be impacted by your product. This is especially important in enterprise UX, where users may not have a choice in the matter.
How to fit the UX value-add within organizational frameworks and development methodologies is an ongoing conversation that I’m sure will launch another 1,000 posts in this coming year as well. However, these discussions are what makes UX challenging — and unbelievably fun.
For further reading:
