Progressive Reduction: just another buzzword?

by Adrian Zumbrunnen / Aug 2, 2013

Today I stumbled upon a tweet from Jeffrey Zeldman about Progressive Reduction. I was so intrigued by the sound of the term that I couldn’t resist digging a little deeper. Let’s see what this term is all about and discuss it’s pros and cons.

It all started when LayerVaults` Allan wrote a post explaining the concept of Progressive Reduction as follows:

Usability is a moving target. A user’s understanding of your application improves over time and your application’s interface should adapt to your user.

While I understand and agree with the basic idea, I’m not convinced that it’s flawless and feel we should perhaps be a little more skeptical about such approaches even if they sound incredibly nice (Read my recent post about  design trends).

The concept is definitely effective in a perfect world where you have very accurate and up-to-date knowledge of your users’ ever changing proficiency. You can then intelligently adapt the UI allowing people to achieve their goals faster and more efficiently.

Unfortunately though… We don’t live in a perfect world.

The idea of Progressive Reduction holds the potential of bringing a whole new level of complexity to development and user testing. First, how will users react to those changes? If the change is too big, users might get confused. If the change is insignificant – why even bother? Or picture the situation when you want to teach a friend how to use an application, but it looks different on his device because he’s in another stage of progress, wouldn’t that feel strange?

Let’s have a look what LayerVault did:

progressive reduction
LayerVaults implementation of Progressive Reduction

At first glance, their approach looks like a nice UX optimization. But, in practice, does it offer enough value that you should incorporate it in your project?

Progressive Disclosure VS Progressive Reduction

It was a few years ago that another “progressive” word made its appearance. That word was Progressive Disclosure. The idea of the latter is to minimize an interface to it’s core parts and then reveal further relevant content as soon as the user requests it.

progressive disclosure
Mac OS X example of Progressive Disclosure

As you can see the concept works out perfectly because it can dramatically reduce UI clutter without any significant drawback. I’m not so sure about Progressive Reduction though.

Jef Raskin, best known for his work at the Macintosh Project at Apple, describes the problems of invisible UI elements in his Book “The Humane Interface”. He claims that the user should always be in control of an application. When a user interface suddenly changes, will this still be the case? Can he undo it? Will there be a control panel for it which eventually increases the complexity of the application after all? What happens if the user doesn’t use the application for a while? At which time exactly will you show the reduced version? Questions upon questions…

The Fact: We are creatures of habit

It’s not a secret that we are creatures of habit. Habits build the foundation of user experience; they define the way we use applications and increase efficiency. Raskin even argues that we should deliberately take advantage of the human trait of habit development and further argues:

An interface is humane if it is responsive to human needs and considerate of human frailties.

An interface should be responsive to human needs. Is Progressive Reduction a move towards more responsive interfaces? Possibly. Simon Raess, founder of Ginetta Web / Design and former Product Designer at Google pointed me towards two interesting phenomena we can bring in to assess this concept in a more scientific & psychological perspective. These concepts go with the name Change Blindness and Change Aversion.

Change Blindness & Change Aversion

Change Blindness can be described as a psychological phenomenon that occurs when a change in a visual stimulus goes unnoticed by the observer (wikipedia). In theory that would mean that an unsubstantial change on an interface will not be consciously noticed by most users. The longer people use an application the more patterns evolve which end up in muscle memory and automatic reflexes. Could this be an indication that Progressive Reduction could work after all? Time will tell.

While the theory of Change Blindness relates to users who do not take notice of changes, Change Aversion could be considered as pretty much the opposite. Aaron Sedley, UX Researcher at Google defines it as follows :

Change Aversion is the negative short-term reaction to changes in a product or service. It’s entirely natural, but it can be avoided — or at least mitigated.

In his blog he shares some ideas on reducing Change Aversion and emphasizes that Change Aversion can in fact be mitigated. Among others you should clearly communicate the nature and value of the changes as well as offer the possibility of going back. To enable all this, you still need to embed this functionality somewhere, and that’s the actual problem.


While some of the disadvantages mentioned can be solved by paying close attention to the concept of Change Aversion, there are still a lot of questions that remain to be answered. Does the advantage of a less cluttered UI justify the sudden change of it with all the possible risks involved? Eventually only user testing will help us to better understand the impact on the final user experience.  One thing is for sure though, if such UX concepts are not used by paying close attention to details it can quickly do more harm than good.

I believe that we should aim at building applications & websites that focus on the essence from the very beginning which should make such concepts obsolete. There is actually a famous saying from a guy who might not have been a user experience designer but who sure knew what he was talking about:

Keep things as simple as possible. But not simpler.

That guy was Albert Einstein.

So what’s your take on this? Do you have a project where you make use of this in the near future? Do you see some cases where it can bring significant advantages?  Let me know, have a good one!

Let's talk

I'm thrilled to hear about your thoughts. Let's talk on Twitter or leave a comment.

Christian Zumbrunnen

First reason for me to mainly stay away from Progressive Reduction would just be because it’s adding a technically complexity I’d prefer to avoid. Not for philosophical reasons: “keep things as simple as possible, but not simpler” but for practical ability.
Second the argument that it’s impossible to teach someone on an application when it’s looking and/or behaving differently on his device is an relevant example.
I think “responsive design” is a good thing but should mainly be responsive to the device (like screen size) and not the user. While it’s a clever idea to “respond” to the proficiency of the user, I agree that’s not so clever to design a “moving target”. It might be better, to offer different modes of UIs for all users to choose from.
I personally also don’t like “personalized” content (except maybe for ads, but probably not even then) as it gives me the feel that I might miss something that someone else gets and I don’t. (With ads it rather gives me the feeling of being monitored.)
So let’s go for “progressive simplicity”.

Michael Havard

I think there is a balance point here. As with all things, moderation. If you are going to use progressive reduction, do so for apps where it makes sense; Those apps that are used very frequently by their users. At the same time allow a path backward or forward through the progression. I’m thinking about what happens for infrequent users, or users who hand their phones off for others to use, or users who’ve just switched phones or re-installed apps and want to regain their preferred experience.

For instance gmail allows adjusting the display density between comfortable, cozy, and compact. If an app with progressive reduction could offer similar preferences in an easy to switch way, that could be one way to alleviate at least some concerns with the technique.

Another technique might be to encourage the user to make the decision. Instead of just switching based on number of click-throughs or a count of days used, pop a message informing the user of the options available to them and let them choose their comfort level. This removes the element of surprise and helps the user feel empowered.

Of course adding all these capabilities means more complexity in the code base. There has to be a pay off somewhere if we’re going to add dev time, qa time, and maintenance cost. So progressive reduction needs to show some sort of lift. Either users use the app more, make more purchases, need less support, have higher conversions, something to justify the cost of implementation. That’s the real challenge is showing the monetary value of the strategy.


thanks for the thoughts. good points with the gmail comparison. And just as you said, I agree that there should be a pay off somewhere. If it just results in higher complexity in the code base without significant advantages, it’s questionable whether it really makes sense.


Changes always meant something. In user interfaces, changes could be an upgrade, or a consequence of an action taken by the user or an event made by the system. And changes must noticeable and understandood by the user, and sometimes he needs a time to learn again and get used to the new paradigm. Adding another possible reason to evaluate the cause of the change and evaluate what it implies, doesnt make his life any easier.
Progressive reduction could be a good approach to solve a particular situation or scenario, but, for me, not a recurrent solution. And must always be explicit, like those new headers that are reduced after some scrolling. Great article Adrian!

Mats Svensson

“Usability is a moving target”
…but sometimes it doesn’t move around enough on its own and we get bored, so lets strap roller-skates on its feet.

Christian Krammer

For my taste this adds way too much complexity to the development process. There’s still so much to think about for a website so why add yet another level? A better approach would be to find a good compromise so that an interface is not too complicated for beginners but also not too annoying for pros.

Tech Writer This Week for September 5, 2013 | TechWhirl

[…] The merits of progressive reduction […]

Lucas VB

It is a very tricky subject. I think the use of “Change Aversion” techniques is very good, but it doesn’t solve it all.

I think what is really important is the familiarity the user have with the interface. For Example, nobody needs to teach anyone how to use a doorknob to open a door, maybe a baby who is learning how to interact with the world, but even a baby can learn how to do it by observation.

If you think about the generation z babies, the touchscreen interface will be as familiar to them as a doorknob, designing touchscreen interaction for them is going to be a piece of cake. It’s all about Habit, as you said.

That’s why the progressive disclosure works, because when the user get really comfortable with the interface, you simplify it in a way that just make sense.

Imagine if the first iPhone was launched with all the features it have today (app store, don’t disturb mode, push notifications, etc), maybe it would be as well succeeded as it was.

I think maybe the progressive reduction have to be studied to understand if is a performance enhancer, but if it is, maybe the best way to implement it is using the change blindness, using homeopathic doses of ‘progressive reduction’ until the user be used to use this kind of interface.

Hope my toughs help the discussion.

King Regards,
Lucas VB.


You make some really good points. I don’t know that progressive reduction works in all cases. I mean what happens when you have a new user that’s never used the interface before and then has no idea what the simplified icons (or whatever elements that have been reduced) means?

Your suggestions for handling Progressive Aversion are right on. Case in point: Evernote’s recent major UI changes without any sort of announcement, explanation or way to revert back. It upset a lot of people including myself as they took away functionality that most of us were very used to using in our workflows and had no intention of giving up.

At least they listened and added some of it back, but we have yet to see if other changes will be reverted or not. Hopefully they learned from the experience.


Complexity of coding and design appear to be the primary reasons for rejecting this concept, and they may be valid to the extent they increase the price of the application beyond what the market will bear.

In any case, Progressive Reduction doesn’t have to be a jarring and confusing automatic change. I can think of two fairly user-friendly ways to implement it.

One is to provide preferences/settings that accomplish various aspects of reduction, and to apprise or remind the user of those at whatever evolutionary point you would have chosen to automate the reductive change.

Another is to provide alternative means of invoking application functions, such as keyboard shortcuts, so the user can choose when (if ever) to reduce functionwise, and to accompany their use with visually reductive changes in the interface (perhaps again controlled by preferences/settings).

Ricardo Zea

Why fix it if it’s not broken?

Progressive Reduction is a highly questionable UX practice in my eyes, at least for the most part.

It certainly violates one of the, if not THEE, most important principles of Web Development: Write[Build] once, run anywhere.

However, the core concept is 100% right: Enhance the user experience.

The procedure is what kills the idea.


@nano: Thanks so much for your insights. I totally agree! (y)

Benjamin D. Bloom

Does anyone else remember text-based interfaces that allowed you to change your prompt level? I remember three basic levels:

Full menus: (R)eply (D)elete (F)orward (H)elp

Partial prompting:
R | D | F| H

and no prompting:

Aren’t we talking about doing the same thing for a GUI? Maybe the addition is of some intelligence that make an attempt to determine when a user is ready for reduced visual queues?


@benjamin that’s a really cool comparision! you got a point there.


@clarient makes sense. especially as the user stay in control which is one of Jef Raskins fundamental principles of usability. I think that progressive reduction is intended to automate this process though. And that’s why it’s so delicate.


@lucasvb be careful, progressive disclosure is a whole different thing than progressive reduction. I agree with the example of the iPhone. But that’s also because companies start learning from their users at the same time. It’s very important to note that the proficiency of the creator of an interface and its users actually improves at the same time.

Frederik Krautwald

Even with user testing, you cannot please all.

Lucas VB

@adrian I agree with you, what I meant is that understanding the progressive disclosure theory may justify the use of the progressive reduction processes. But I’m not sure of course, it’s just a guess. :)

Erich Senft

This could make some websites very frustrating to navigate. Human beings are very much creatures of habit, and time is often of the essence. Not everyone would appreciate having to figure out how to deal with a site afresh, every time they visit. JMHO.


Seems to me that the success of Progressive reduction is built on the principal that all users are operating at the same level. Thats fine for certain projects, but this theory has to be very delicately applied on broad user projects.

Would an animated disclosure of elements (on hover, display title etc.) not be a more suitable solution to an overcluttered interface?

Andrew Corway

This is a great article. Echoes my sentiment.

Designers, specifically UX designers, must always remember that design is HOW THINGS WORK in our field. This applies to the CODE as much as it does the VISUAL DESIGN. Having a decay features means your developers have to maintain three different UIs at the expense of marginal gains IF ANY to usability. Those poor developers at LayerVault now have a codebase that’s 3x as robust! Egads.

If the first iteration of the design that utilizes icons AND labels helps users navigate easily then why change it?

Now to their credit, I think the exploration of something like this because it is… well.. really cool. And LayerVault should be commended. It may even be working for these (release metrics please!). But ultimately it seems a bit too clever for its own good.