Summary: If done right, big design shifts can have strategic value over tactical changes or little shifts. When updating or enhancing a UI, it is important to evaluate the true magnitude of your changes and whether those changes represent evolutionary or revolutionary design. Users get notoriously upset about needing to learn new designs, though not all design changes are equal. However, 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 that cause users to learn. Some key considerations exist when deciding whether to apply evolutionary or revolutionary design change.
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 dislike re-learning. Our ability to remember and recognize patterns is so refined we become annoyed at having to re-learn. Imagine learning to walk, tie your shoes, brush your teeth, or speak from the start daily. You stopped doing that at age three or so… (unless you are learning a foreign language now, in which case you get to see how this works firsthand).
One of the questions you need to understand is how you negatively impact user learning. Through Field Studies (contextual user research), you determine user expectations and needs up-front, which 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 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 user expectations, making it even more pleasant and supportive. The change did not force problem-solving but seamlessly introduced helpful change*. This is 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 will 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 a 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. You must minimize this ‘change-shock’ at all costs. Remember that all change is not equal. We are 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 confidently replied: “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.
First, determine if the changes your team proposed or just released are intended as evolutionary or revolutionary. Next, compare that to how users perceive them (if it’s live) 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:
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.”
Minimum Desirable Product
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 is 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.
Developers currently manage release schedules through Evolutionary design. However, this is done regardless of whether or not users want the features or upgrades being made to the new release. Often developers incrementally apply UX enhancements 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 feel the product is aging without improving or getting stale. So, big changes can aid in feeling freshness or renewed value. However, designers should prioritize minimizing stressed learning. 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. If you follow a proper user-centered design process, this should not happen.
Steps to manage interface change
- Get your UX strategy right. Use user research to vet the direction you ought to take: evolutionary or revolutionary design. Functional UX teams providing value should know the answer to this. UX strategy comes from being well-informed and clear about MDPs and taking a Desirability First (webinar) strategy.
- 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.
- Map your Current and Future State Journey Maps. Journey mapping comes out of user research. Most teams conduct current-state customer journeys. In addition, though, building out a “dream” state is valuable for finding the value creation points that help users adapt and adopt.
- 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 understand how bad the design is getting. Field studies will help you take a step back and understand the problem space, clearly define needs, issues, and opportunities, and change perceptions from your users’ point of view.
- 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 did with its big redesign. Whereas that is one strategy, there are others. If you are 90% certain users will benefit 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. Surprise, compel, and move your users 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)!”
Looking for more?
Join Frank Spillers’ UX Inner Circle: Get 1:1 mentoring and UX process tune-up advice and direction.
