Reining in UX Regression

Designs That Answer Questions

As the Google Search example illustrates, making UX design changes in striving for product differentiation as an application evolves can sometimes lead to usability issues. Adding complexity to user workflows can spiral into further problems—in our example, workflows for information research or cross-application navigation. In the case of Google Search, user issues such as the following might have resulted from UX regression:

• mental strain that negatively influenced users’ perception of the search experience
• user mistakes and misunderstandings about an application or service offering
• abandoning a task to find answers elsewhere—sometimes on a competing channel

The design of the primary user workflow should allow a user to complete a task—not necessarily searching for information—without requiring additional steps or workarounds in the user interface. Users want a highly integrated user interface that brings together related information and functionality in the same context. But this complexity makes it all too easy for a design to diverge, causing UX regression.

When Does UX Regression Happen?

It’s worth considering a possible parallel between UX maturity and UX regression. Many companies’ products experience UX regression because its avoidance depends on product features remaining inert. Google is a prime example. When the Google menu appeared on the home page, the company was already a decade old, and they didn’t have the design leadership they have today. Companies might experience UX regression as a consequence of changes to their UX process that result from executive directives—for example, when spinning up a new UX team or going through an agile transformation. Such situations often result in changes to the UX process. When product teams add new members who have never done certain UX activities before, that can reduce the team’s overall awareness of those activities, as well of the existing user workflows.

Depending on the UX maturity level within an agile-development context, User Experience may have no clearly defined role. In such a case, the development team is often responsible for design decisions, regardless of whether they possess the necessary design skills. For example, when a UX professional conducts an expert review, it might not be part of the agile-development process or get the documentation or consideration it deserves.

For instance, consider a UX workshop in which a product team’s task is to create a test plan for a new feature. If the team doesn’t provide a complete solution, workshop participants might return to their desks and implement ideas that might or might not solve the problem. So the team either makes design decisions that are based on minimal design activities, runs the risk of guessing what users needs, or fails to make the necessary changes at all. Without casting blame on whoever makes the final decisions, the lack of a viable test plan often results in the creation of a design concept with little to no user validation that would have allowed the team understand its usability. This can result in an inferior user experience.

When Should UX Get Involved?

Let’s dig deeper into the struggle to fit a UX process—comprising research, ideation, prototyping, and usability testing—into agile sprints, which in many organizations last only two or three weeks. To overcome this issue, UX designers typically work a sprint or two ahead of agile-development teams. The problem with this approach is that the development team might expect designers to complete their designs by the time a sprint begins. Or concurrent usability testing may be necessary to assess the usability of a design iteration. Development teams sometimes view UX activities as roadblocks, even though it might not be feasible to complete designs within a week.

Jeff Gothelf introduced Lean UX methods in his book Lean UX, in an attempt to solve potential problems by moving UX design into the ideation or discovery phase and helping product teams to define a problem and integrate design perspectives into a vision for its solution. While it can be tempting to try to do all of your UX research up front, that might not be realistic.

UX regression can also occur when a product manager or other stakeholders change requirements in a way that is out of line with product usability. Avoiding UX regression demands following the UX process to realign the user workflow through usability testing.

These scenarios conjure the wisdom of Aristotle: “For it is an advantage to advance to that which is more knowable.” In essence, the more we think we know something, the more we need to learn or relearn.

Agile UX serves as a model for raising a product team’s UX-maturity level by embedding a UX designer on a product team. A cross-functional product team’s design decisions then maintain a focus on the user.

Leadership Support

Design and product leadership need to understand and deal with the problem of UX regression. Exacerbating this problem, UX-maturity levels sometimes decline during agile transformations, so you’ll need a plan to address any gaps that occur in UX practice. UX regression is more likely to occur if a company uses agile practices and tools without adopting an agile mentality—which basically requires maintaining full communication and transparency between team members, while keeping a common goal in mind. An agile development process should create full transparency across all team members, including managers.

Have you experienced UX regression? How long did it take your team to address this issue and realign the user experience? Please share your stories about UX regression in the comments.