Flag

We stand with Ukraine and our team members from Ukraine. Here are ways you can help

Home ›› Business Value and ROI ›› 6 Key Questions to Guide International UX Research ›› Overhauling a UI Without Upsetting Current Users

Overhauling a UI Without Upsetting Current Users

by Scott Plewes
8 min read
Share this post on
Tweet
Share
Post
Share
Email
Print

Save

Avoid a user revolt against your product redesign by targeting the overall experience instead of just aesthetics.

Companies with successful software products often know that their user interfaces could be improved but hesitate to take action because major changes might upset their existing users. “Not only would a redesign cost me a small fortune,” one executive told Macadamian “but look at the backlash against Google and Facebook’s changes. I’m not willing to risk losing customers over design.”

Companies with successful software products often know that their user interfaces could be improved but hesitate to take action because major changes might upset their existing users. “Not only would a redesign cost me a small fortune,” one executive told Macadamian “but look at the backlash against Google and Facebook’s changes. I’m not willing to risk losing customers over design.”

Indeed, Google, Twitter, and Facebook caused quite a stir recently by making dramatic changes to their UIs. In less than 24 hours, hundreds of users formed a coalition against the new Gmail, with a mission to “urge Google to fix the horrid new Gmail interface and take us back to productivity.” And Facebook users began posting “If it Ain’t Broke, Don’t Fix It” banners to express their dissatisfaction.

But for every example of a redesign gone wrong, there is a success story of a company blasting ahead of its competitors by reinventing its product design. Salesforce.com’s dominance in the CRM market, for example, is largely attributable to its innovative design updates.

The risks associated with not updating a UI outweigh those associated with an update. But a successful redesign absolutely requires the right product management and UX techniques to evolve the product carefully and avoid a user revolt.

Consider Form and Function

Ninety percent of the value of an experience comes from how it works, not how it looks. Of course, it’s not that visual design is unimportant; it’s just not nearly enough.

This is the source of one of the major complaints about Gmail’s new interface. “Gmail’s new interface is form over function. Strange because the reason everyone went to Gmail was function” says one Twitter user. “Gmail’s new look is uncluttered, which is a good thing until you try to navigate and then, user beware.”

It is a myth among non-designers that the essence of a fantastic experience and a product’s success is its aesthetic value. Although UX pros recognize that visual appeal is just one part of the experience, even they sometimes spend disproportionate amounts of time on visual design, sacrificing other aspects of UX. The importance of good looks may be the initial draw to a product, and visual design can often be a very important factor in influencing purchasing decisions. However, for a product to be endorsed by the market, development needs to be focused on much more than just how the product looks. This is especially true in a world where information and opinions about products travel quickly and unpredictably via social media.

A redesigned UI that looks pretty but fails to deliver new value will not only disappoint new users but will also alienate existing, previously satisfied users, and the news of this failure will spread rapidly. Never make the mistake of thinking that a product’s aesthetic is the same as the product’s actual experience.

Redesign Based on Evidence

In order to make functional (not just aesthetic) improvements, product managers and design teams need to perform research with real-world users. Most people already agree with this in principle, but vary wildly in how well they execute on it.

One of the most common mistakes companies make is to implement UI changes based on what users say they want. Unfortunately, experience shows that what people say they will or won’t like doesn’t always match reality. Moreover, a user’s suggestion on how to solve a UI problem may be unworkable, unreasonable, or both.

While it’s important to solicit and listen to user feedback, users aren’t designers or usability experts so their complaints and suggestions should not be taken at face value. Don’t confuse a design suggestion with a design solution. To identify the real UI problems and solutions, careful UX research must take into account facts, not just opinions.

Two fundamental techniques that should be used in any major UI update are focus groups and usability testing.

Focus groups

Focus groups are a powerful exploratory technique that can provide rich information on the opinions and attitudes of the target audience regarding a new or existing product or idea.

They are best used in the early discovery and assessment stages of a design update project in order to:

  • get a feel for the range of opinions on different aspects of the interface
  • understand the reasons for change requests, new interface ideas, and underlying preferences
  • build a raw list of user requirements

This information can provide direction to a development team in the early stages of their work so they can prepare for, and even get an early start on, development in key areas in parallel with the design effort.

However, focus groups are not a good source of behavioral data. What people say they will do, compared to what they actually do, is notoriously unreliable for several reasons. First, what people say they will do (intent) and what they actually do (action or behavior) often vary because people can’t predict contextual factors that may alter their behavior in a given situation. This is why people like test drives and 30-day return policies.

Second, people are not fully aware of all of their behaviors. Some everyday actions are so commonplace that people sometimes forget they even do them. For instance, if you ask people something as simple as, “What features on a telephone do you use and approximately how often?” and compare the results to direct observation data on the same question, the results are usually staggeringly different.

That’s where observational techniques like usability testing come in.

Usability Testing

Usability testing is a technique to determine the effectiveness of a design by observing and assessing users as they walk through a predetermined series of tasks in the software. For example, if users consistently stumble during a particular part of the workflow, this is a strong indicator that the design is flawed.

Researchers usually follow-up each usability test session by interviewing the user and asking more qualitative questions about the experience. Usability metrics—such as the time it takes to complete a task, the number of errors, the number of clicks, the success rate, etc.—are collected along with ease of use ratings.

Usability testing is very different from beta testing. In beta testing, users will typically only report usability problems that make it very difficult for them to accomplish a task—in other words, things that are very clearly bugs. They typically won’t report that they found something challenging or unintuitive. People don’t always like to admit that they failed at something. Also, beta testers (or at least the ones who take time to report issues) are often fans of the product, and are therefore also power users. They may have already learned to work around or ignore usability issues.

Hopefully, by the time a product is in beta, most of the obvious usability issues will already have been solved because the most expensive time to fix a usability issue (or any bug for that matter) is after the product has been built.

Stop the Endless UI Debates

Despite access to quality user research, many projects still get mired in unproductive debate about design and implementation issues. To avoid this, take the development and design team back to the first principles of the product. When arguing over a particular feature or screen, stop to ensure the team is in agreement about the answers to the following questions:

  • Why will a user want to use this feature?
  • What will be their most common tasks?
  • Under what conditions, or in what contexts, will this feature be used?
  • Who are the primary users of this particular feature?

Taking just a bit of time to regroup and make sure everyone on the team knows the answers to these questions will forestall wasted debate and speed project completion. If you don’t, the same issues will inevitably come up again and again in the design and development process. Often when a team debates whether to include a certain feature, the true, underlying questions are, “Who are our primary users and what would they value?” If the team has considered these questions already, the answers to feature decisions will be clear, allowing the team to breeze through those discussions.

Integrating Redesign Feedback: Interpret and Prioritize

Even the best products won’t be perfect or universally loved; user complaints are a perennial and pervasive part of the design (and redesign) process. So when evaluating user complaints about the UI (there will always be some!) don’t react to them at face value or in a knee-jerk fashion that just closes the trouble ticket.

Experienced product managers and UX designers will take the time to gather qualitative and quantitative data from a variety of users to determine:

  • how frequently each design issue is occurring
  • the impact of an issue on a user
  • the relative importance of one issue over another

This data and analysis allows teams to make sense of all the user reactions so that they can swiftly address issues that will most affect their product (and ultimately their business) success and put aside all the red herrings.

How pervasive is the complaint?

Some complaints may identify a common user problem, but they could also simply be gripes from a very small but vocal group of users.

This is where quantitative data becomes very useful. When Google changed the Gmail UI, it added a pop-up bar in the corner of the screen that asked users for feedback on the new design.

Gmail Feedback Bar

This is an effective mechanism for determining how widespread design problems are, and as a bonus allows users a sense of control as they vent their frustrations in direct communication to the software maker.

However, this method can be costly as it requires staff to sort through the wide variety of comments. The quality of the data provided is also; users will often offer solutions rather than explaining the reason behind their frustration.

For more cost-effective and equally powerful data gathering, consider conducting a random survey of your targeted audience through user interviews or an ethnographic study. This provides the quality and quantity of feedback necessary to ascertain whether a given complaint is common and should be immediately addressed, or is a minor issue that should be lower on the priority list.

Consider the Consequences of not Making a Change

Jumping into a design update can be costly both during the design process and, worse, if the updated product causes user backlash. It’s tempting to take the conservative approach and maintain things the way they are, hoping to avoid hurting customer goodwill with a bad UI decision. But with products such as the iPad and SalesForce.com setting a new bar for software UX, companies are being forced to update their products’ UIs in order to meet rising consumer expectations. The risk of falling behind exceeds the risk of alienating existing users.

Fortunately, you can have your cake and eat it too. Proper product management and UX techniques can reliably produce UI updates that keep a product ahead of the curve without losing loyal users. It’s a discipline based on the fundamentals of good UX design: collecting, interpreting, and prioritizing user research. These are core competencies that companies planning to stay market winners must cultivate within their organizations.

post authorScott Plewes

Scott Plewes,

Scott Plewes is an expert in user experience design, user research, and incorporating the voice of the customer into product design. As Vice President of User Experience Design at Macadamian, Scott has almost 20 years of experience in the field of user interface design, working in both the public and private sector. Scott's experience design skills cover the spectrum from desktop, web, and mobile user interface design through to command line interface and telephony interface design.

Tweet
Share
Post
Share
Email
Print

Related Articles

What do Architecture, Computer Science, Agile, and Design Systems have in common?

Article by Kevin Muldoon
A Pattern Language
  • The article explores Christopher Alexander’s impact on diverse fields, from architecture to software development, introducing the concept of design patterns and their influence on methodologies like Agile and the evolution of Design Systems.
Share:A Pattern Language
7 min read

As consumers’ privacy concerns continue to grow, so should our attention to addressing privacy issues as user experience designers.

Article by Robert Stribley
Designing for Privacy in an Increasingly Public World
  • The article delves into the rising importance of addressing privacy concerns in user experience design, offering insights and best practices for designers and emphasizing the role of client cooperation in safeguarding user privacy.
Share:Designing for Privacy in an Increasingly Public World
9 min read

Navigating the Creative Landscape.

Article by Adri Mukund
Unveiling the Influence of Cognitive Biases on Design Decision-Making
  • The article explores the influence of cognitive biases on design decision-making, outlining various types of biases and offering strategies for mitigating their impact to foster inclusivity and objectivity in design processes.
Share:Unveiling the Influence of Cognitive Biases on Design Decision-Making
6 min read

Did you know UX Magazine hosts the most popular podcast about conversational AI?

Listen to Invisible Machines

This website uses cookies to ensure you get the best experience on our website. Check our privacy policy and