UX regression—that is, a step back in the quality or usability of an application or Web site’s user experience—can occur whenever a design diverts from an existing workflow because of a technology or design change. Some refer to this phenomenon as UX backlash. As designers and developers, we subject users to UX regression to some extent every time we embark on making a design change.
User Experience is a moving target. Just ask Google. Design experiments around their Search toolbar over the years have demonstrated both forward progress and regressive patterns in their search experience.
For example, in 2007, Google introduced universal search, integrating search results from a variety of sources such as Web, images, video, news, and maps. A tabbed navigation bar in the upper-left corner of the Google home page and search results pages allowed users to search for, then view results for each of these types of content. This navigation bar remained part of the user interface for about two and a half years.
Then in 2013, in an effort to accommodate their growing list of applications with an updated UX design, Google rolled out their app launcher, which consisted of an Apps grid icon at the right of the Google bar and a drop-down menu comprising a grid of application icons. The old toolbar appeared centered on the page below the Google bar. Figure 1 shows the Google bar and Apps grid circa 2013.
But neither of these design solutions addressed the awkwardness of scrolling to view search results. In fact, making these revisions to accommodate the Google menu meant the search results lost page real estate, as well as affordance on the page. Some might call this UX regression in the search experience, while others might focus on the usability issues, and a developer might call this technical debt. Google replaced this design after a few years, when the company went back to a docked, app drawer in 2014.
Google finally took on the scrolling issue by providing the persistent, pill-shaped toolbar, shown in Figure 2. A drop-down menu of Search suggestions appears when the user types a query, as shown in Figure 3. Thus, users don’t have to jump to another service without first scrolling up.
Today, Google’s search experience prioritizes the placement of search results by maintaining a docked app drawer at the right. The history of the Google search experience highlights the user workflow’s complex usability issues as the application architecture has evolved over the years.
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.
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.
Rachel is a User Experience Engineer at Rockwell Automation, the world’s largest creator of industrial-automation and information products, whose flagship brands Allen-Bradley and Rockwell Software have been recognized for their innovation and excellence. She leads interaction, performance design, and UX strategy initiatives for engineering and product teams. Rachel has spent the past decade creating, cultivating, and working in agile communities globally. She promotes collaborative engineering as a vehicle for increasing quality and productivity within teams. Read More