Answer 21 of 50
How User Habits and Mental Models Should Limit Design Innovation
Break a user habit only when the benefit to users clearly exceeds what it costs them to relearn, and test that before launch. Habits limit innovation because people bring them from everywhere else: Nielsen Norman Group’s Jakob’s Law states that “Users spend most of their time on websites other than yours.” They arrive expecting your site to work like those. That expectation should constrain change where people depend on familiar patterns, and leave room for it elsewhere.
What a mental model is
Nielsen Norman Group’s article on mental models, Megan Chan’s 2024 update of a 2010 article by Jakob Nielsen, defines one this way: “A mental model is what the user believes about the system (web, application, or other kind of product) at hand.” The same article notes that mental models “help the user predict how a system will work”, which is why a design that matches them feels effortless and one that contradicts them makes people stop and think.
The article also states that a mental model is based on belief, not facts. Users carry beliefs about where navigation lives, what a link looks like, and how a form responds, whether or not those beliefs match your design.
The learning-cost arithmetic
A new pattern costs users time and attention before it saves them anything. For example, imagine a navigation pattern that saves two seconds per task but takes two minutes to learn. The break-even point is the learning time divided by the time saved per task: 120 seconds divided by 2 seconds is 60 tasks. A frequent user passes that point quickly; someone who visits twice a year never does.
Time is not the only cost. During the transition, plan for the possibility of more errors, more support questions, and some visitors who leave instead of learning. Before you ship, decide what drop in task success you will accept and for how long; that number is a team decision, not a published standard, and writing it down in advance ties the evaluation to what the change was supposed to achieve.
When breaking a habit is justified
Breaking a convention is justified when:
- The convention is outdated. A pattern designed for desktop mouse use may not work on touch screens; a pattern designed before accessibility was considered may exclude people.
- The convention does not fit the domain. A pattern from consumer shopping may be wrong for clinical software or a professional tool.
- Testing shows a better alternative. If your own research shows a new pattern outperforms the familiar one for your users, the evidence outweighs habit.
- There is no convention yet. A product with no direct predecessor can borrow patterns from adjacent tools users already know, such as calendars, email, or file managers, and innovate where nothing familiar applies.
Where a site can afford creativity at all, by layer and by risk, is covered in balancing convention and creativity. This page is about the moment you change something people already know how to use.
How to change a habit without losing people
Incremental change lets users adjust step by step. A revolutionary change asks them to relearn at once, so it needs a benefit they can see quickly. Either way, reduce the cost of the transition:
| Tactic | What it does | Watch for |
|---|---|---|
| Beta with willing users | Tests the change on people who opted in and will report problems | Opt-in users may be more tolerant than everyone else |
| Gradual rollout | Exposes a growing share of users while you watch task metrics | Metrics need a baseline from before the change |
| Optional classic mode | Lets people keep the old pattern for a set period | Maintaining two versions costs effort, so set an end date |
| Guidance in context | Explains the new pattern at the moment it appears | Guidance that stays after people learn becomes clutter |
Snapchat’s 2018 redesign shows what happens when a large audience rejects a change. BGR reported on February 21, 2018 that a Change.org petition against the redesign had gathered 1.2 million signatures. Snap’s published response kept the new design and announced “tabs in Friends and Discover, which will make it easier to find the Stories that you want” instead. One reading of the case: if you keep a major change, address the specific task users say it broke, here finding Stories, rather than defending the change in general.
Market position changes how much patience you get
How much relearning users will accept depends partly on who you are to them:
- A category leader can shift expectations, because people have strong reasons to keep using it.
- A follower or new entrant can get less patience: users who are still evaluating a product compare it with what they know and may leave rather than learn.
- A product with loyal users can ask more of them, though loyal users can also be the loudest critics of a change, as the Snapchat petition suggests.
Familiarity, not birth year
Prior exposure shapes mental models. People differ in how familiar they are with touch gestures and app conventions, and age is a rough proxy for that at best. Segment by observed familiarity in your own research: ask which apps participants use every day, and watch whether they try a swipe or look for a button. Design for the familiarity you observe, not for assumptions about a generation.
Test the change against real expectations
Card sorting, tree testing, and interviews show how users think about your domain before you design. Usability tests show where a new pattern makes people hesitate or ask what something means. Once the change is live for part of your audience, compare task success, time on task, and errors with the baseline, and use an A/B test when you have the traffic to detect the difference; how to run one properly is covered in how A/B testing should guide web design decisions. How to measure learnability itself, with first-time and repeat tasks, is part of core principles of intuitive interface design.
Write down why you deviated
Every deviation from convention should complete the sentence “We did this differently because…” with something concrete: faster task completion, better accessibility, or a function the product cannot offer otherwise. “Because we wanted to be creative” does not justify a cost that users pay. The written reason helps later: when someone questions the choice, or the product changes, the team can judge whether the reason still holds.
Questions teams ask
Our competitors are all conventional. Isn’t a novel interface a competitive advantage?
Only if it helps users reach their goals more easily. People choose products that work for them; looking different is not an advantage on its own. Compete on outcomes, and put distinctiveness into brand expression and content, where it does not stand between users and their tasks.
We tested an innovation, users struggled, and we still believe it is better long-term. Should we ship it?
Find out what kind of struggle it was. A learning curve shows up as errors in the first session that fall in the second; deep confusion persists. If it is a learning curve and your users are frequent enough to reach the break-even point, ship with guidance, a gradual rollout, or an optional classic mode. If confusion persists, redesign before launch.
Before you change something users already know how to do, calculate the break-even point, decide what drop in task success you will accept and for how long, roll out to willing users first with a way back to the old pattern, and keep the change only if the numbers recover.