By Frank Spillers

paper airplanes moving in same direction but one moves in a different direction

 Summary: Big design shifts can have strategic value over tactical changes or little shifts if done right. When updating or enhancing a UI, it is important to evaluate the true magnitude of your changes. Users get notoriously upset at having to learn new designs, though not all design changes are equal. Adjusting your UI 'change-shock' so users can adapt and adopt easily is critical. Managing interface change can help lower the risks and mitigate user adoption. 

Evolutionary or Revolutionary design changes?

Evolutionary changes make tactical improvements, feature by feature. Revolutionary changes blow everything away and change the Interaction design paradigm from the ground up. Both cause changes which cause users to learn. 

How much learning do your users need to do? 

The enemy of change for users is having to learn new interfaces. Humans are near perfect in this regard, we don't like to re-learn because our ability to remember and recognize patterns is so refined, it annoys us having to re-learn. Imagine having to learn to walk, tie your shoes, brush your teeth, or speak from the start every day. You stopped doing that at age 3 or so... (unless you are learning a foreign language now, in which case you get to see how this works first hand).

One of the questions you need to understand is how you are impacting user learning negatively. Conducting Field Studies (contextual user research) will help you determine user expectations and needs up-front, which can be used to guide a re-design or plan a new design. Usability testing and Accessibility testing can be used on live products or changes that are being rolled out incrementally. 

So the key question to figure out is how whether your forced re-learning (UI change) is bad for users or good for users. Let me explain...

If your UI change is bad for users it means that users are forced to change their expectations and assumptions, searching, browsing, navigating, thinking more. If the small incremental changes (typical in Agile releases) add to this "cognitive load" (more thinking)...they can burden the user. 

If your UI change is good for users it means the changes met or exceeded expectations, make it even more pleasant and supportive. The change did not force problem-solving but seamlessly introduced helpful change*. The equivalent of buying and installing a key rack in your home so you remember your keys every morning. You have to hang them up every day, but you never lose them now. 

*Change is like stress, it can be annoying and turn you off, or it can be helpful and guide you. Not all stress is bad, not all change is bad. 

Are you perceiving the change or are your users?

Many teams I work with and train make the mistake of seeing UI changes from their internal point of view. Here's a typical contrast in thinking: Developer: "This update is going to be very helpful to users". User: "This change/feature does nothing for me and is annoying to learn". Senior management and stakeholders think: "These UI changes are going to be major (or relatively minor) for our users". Instead, users think: "Why is the design changing again?; The change seems so trivial (or huge, it scares me)". 

Most users have change phobia when it comes to UI updates. Even announcing changes or the "new beta" can cause assumptions of effort and pain in re-learning. This 'change-shock' needs to be minimized at all costs. Remember that all change is not equal, we're looking for *helpful change*. 

Here is a story from one of my UX Trainings that illustrates the point:

A moment of panic came over me when testing a new B2B web application with users at a major bank in London...the (very senior) user said: "Why the hell are you redesigning it again? You better NOT MAKE ME LEARN it all over again!". He then breezed through six tasks in less than ten minutes (compared to 30 minutes on the old design). When we finished, I asked if the new design would cause him to waste time learning it, he replied confidently: "NO, not this one!". Whew! Negative change impact minimized. Note: This testing occurred after a round of user interviews/ observations as well as rapid prototyping. Risk-managing in this way can lead to the desired outcome of a user reacting in the way illustrated in the story. 

First, you need to determine if the changes your team proposed or just released are intended as evolutionary or revolutionary. Next, that needs to be compared to how users perceive them (if it's live) or, or expect them to support their needs (if it's being designed).  

When your big bang is peanuts for the circus elephants 

Without doing proper day-in-the-life studies with users (i.e. developing personas without research), you can miss out on what users really need. Worse, users might perceive your changes as trivial (eg visual design enhancements, or "making it pretty" without considering workflow or task flow). Getting the wrong feature set or set of changes right can also prevent upgrade or deeper adoption of an existing tool---in both B2C and B2B scenarios.

Another story from one of my UX Trainings that illustrates the point:

Example: A user said: "The designs this company produces seem to be evolutionary, not revolutionary". He explained, "They tend to do small updates that don't really make a substantial difference or change the core problems with the interface...if I am going to spend my money on upgrading, I want something more revolutionary than evolutionary".

It is important to note that The Lean Startup approach (book title and standard in IT today) MVP approach excludes an important step that can help determine the need for evolutionary or revolutionary UI change. MVP leaves out user needs discovery which is part of the ISO and industry-standard Human-centered Design methodology and is critical in UX Strategy work. Many teams following the MVP product development approach, lose track of what's minimally desirable for users

Definition: Minimum Desirable Product (MDP) is a Lean UX approach to guiding product and engineering priorities by bringing in what is of the highest value and priority for users. This is based on problems users are trying to solve, real pain points and of course, perceived user needs and desires. 

Evolutionary design is currently used to manage release schedules regardless of whether users want the features or upgrades being made to the new release. UX enhancements are often applied incrementally without making fundamental improvements to desirability (how well users' needs and expectations are served). Instead, the latest versions (Sprint releases) ought to focus on what matters most for users (MDP's) with strategic improvements aimed at making a bigger difference in the product experience. Big differences combine high value to users with minimal learning

So aligning with evidence-based user needs (seeing, hearing, and feeling user stories/struggles) is vital to managing all change and UX success. Guessing is not good enough for a quality UX process. 

Another problem we have noticed with the evolutionary approach is that users might not notice the updates (often they do not) and if updates are so frequent and last years, for example, users can get the feeling the product is aging without improving or getting stale. So big changes can aid in the feeling of freshness or renewed value. However, as stressed learning must be minimized as a priority. Sometimes waiting for substantive change is optimal. 

Many organizations avoid revolutionary design for fear of unleashing too much change on users and creating a backlash. This should not happen if a proper user-centered design process is followed. 

Steps to managing interface change

  1. Get your UX strategy right. Use user research to vet the direction you ought to take: evolutionary or revolutionary? Teams that have functional UX teams providing value ought to know the answer to this. UX strategy comes from being well informed and clear about MDP's and taking a Desirability First (webinar) strategy. 
  2. Focus on following Mental Models to Conceptual Models. Mental models are what customers need from a familiarity and expectation point of view. Conceptual models are the new containers (UI patterns and flows) that cater to user comfort zones, based on properly created personas with distinction.
  3. Map your Current and Future State Journey Maps. Journey mapping comes out of user research. Most teams conduct current state customer journeys. However, building out a "dream" state can be valuable for finding the value creation points that help users adapt and adopt. 
  4. Get real, in-depth user input. This depends on how much you know about your current design from your users' perspective. Usability testing (having users walk through your design) is a great way to gain an understanding of how bad the design is getting. Field studies will help you take a step back and understand the problem space, clearly defining needs, issues, and opportunities as well as change perceptions from your user's point of view.
  5. Assess the value and priority of release features for how much impact & value they offer users. You can wait for things to get really bad as Amazon.com did with its big redesign. That's one strategy. There are others. If you are 90% certain users will benefit hands down from feature updates, then release them. Look for paradigm shifts you can make that will cause anticipated changes to increase conversion, loyalty, or the perception that your company is leading in the market. Users should be surprised, compelled, and moved by a redesign-- in a good way. As one of our client's users who saw a redesigned product prototype said, "I would CRY if I could use that! (in a good way)". 

Best Regards,

Frank Spillers, Chief Experience Officer @ Experience Dynamics

Looking for more?

Join Frank Spillers' UX Inner Circle: Get 1:1 mentoring and UX process tune-up advice and direction. 

(Express your Early Access interest here)