Less really is more...in time...
Progressive Reduction

Reading time: 2 minutes

In February 2013, LayerVault published a column titled Progressive Reductionbecause we’re not already up to our necks in progressive enhancement, mobile first design, responsive images, flat design and a myriad of different devices now including smart watches, smart tvs, refrigerators, and heads up displays in cars. Clearly we need another tangent to consider while designing. I jest, but sometimes it feels like designing even the simplest applications is becoming exponentially more complex by the day, and there’s good reason for that…it kind of is.

Years ago, usability wasn’t intergrated into the design process like it is in so many organizations today. It was more like a ‘nice to have’ that would get slapped on near the end of a project if at all, and often times what was considered a good user experience was whatever the programmer who was assigned to it considered good. Thankfully today, more and more companies recognize the impact user experience has on their bottom line, customer loyalty, and repeat business.

The fact that progressive reduction is even being considered by some is in and of itself a statement of how far user experience design has come. It’s an interesting proposition. What it boils down to is acknowledging that usability is a moving target. In other words, when I first attempt to use your application, I’m a beginner, and I might need some help. But after some time, I’ll graduate to a proficient user, and if I keep using it, I eventually move into that “power user” category, where I don’t need and probably don’t even want the same help and affordances you provided when I first began using your application.

Enter progressive reduction.


Ever land on a website for the first time that only used icons that you didn’t recognize for its navigation? On a desktop, a lot of times there will be a hover treatment that gives you a hint as to what each icon will do if you click on it. However, until something like Samsung’s Air View becomes ubiquitous across all touch devices, we shouldn’t rely on the hover effect to pop a tooltip. So what the theory behind progressive reduction says is we should provide text next to the nav icon that indicates what it does. And by tracking the user’s usage, once they reach a certain threshold of visits, we can then remove the hand holding and just provide them the icon without the text link. That’s just a simply example, but that’s the general gist of it – remove helpful affordances vital to beginners as they become more proficient to reduce unnecessary distractions and clutter.

The concept also takes into account power users who have been away for a certain amount of time in which the interface “rolls back” its affordances for the returning user until they’ve reacquainted themselves with the application again.

What do I think of it? I like it but…

Wherever possible, I always want to give the user control. Instead of automatically switching the UI from one given level of expertise to the next, I’d recommend that once a usage threshold has been met that we empower the user to switch from a beginner to a proficient user interface, or vice-versa. Let the user decide, remove the systematic determination.

My one big concern though is adding another level of code maintenance for IT to develop and maintain. At some point, the cost-benefit ratio may become too much to justify the features. I’d have to see it on a case by case basis to make that determination though.

Will this be as ubiquitous three years from now as responsive web design is today? Probably not, if for no other reason than despite increased awareness in usability heuristics, the idea of user experience design is still evolving and this may just be ahead of its time right now. However, with that said, I’m fascinated by the concept of progressive reduction, and I’d love to hear your thoughts on it and how you see it evolving into user experience design.

  • Duke3D

    Interesting article and a year later, I don’t see that the original concept has all that much traction in the website and web app world, in part because as you point out, it is yet another layer of complexity affecting maintainability.

    The sweet spot I see is not in responsive websites where once they are optimized to work well for the newbie user on a small screen, there isn’t much value to be gained by “moving the targets” just to have a bit more whitespace with the side effect of smaller touch zones; but instead in the frequently used web app that for the proficient user, could be squeezed into one screen instead of two or three screens to eliminate swiping and scrolling. But I also agree that the change should be offered to the user as they hit the proficiency scores so they may accept or reject the alternate UI element instead of just being surprised one day.

    Adobe’s alternate workspaces in most of their software is a good example of switching toolbars from labeled to icon with tooltip and with different layouts based not only on your familiarity with a tool set, but also to organize certain tools to be easier to reach based on the current task.

  • http://rhartzfeld.com Ryan Hartzfeld

    This is a very interesting train of thought. A question though: If you had enough available real estate in a layout to display the button labels for the first X visits, and it is apparent that the label enhances usability by reducing the cognitive processing time of the user, then why hide the label at all? The response that comes to mind for me is that the UI becomes sleeker and simpler, but only marginally. Is that margin really worth the extra development time, particularly for a team that is strapped for time or resources?

    • maccgizzle

      I totally agree with you Ryan in regards to the very simple example used to illustrate the concept. But what if it was a completely different layout design for power users vs. beginners that made both groups very happy? Or perhaps taking it a different direction, what if it was two very different layouts for different target users with different goals. Would it be worth letting users identify why they use your application or site and then altering the ui to accommodate said goals accordingly?

      • http://rhartzfeld.com Ryan Hartzfeld

        I see your point here. Definitely a valid option in a case like that. A general rule of thumb that I like to follow in cases where I am hiding data from the user is to provide a simple slide or fade animation when the change comes into effect. Seems to lend itself to better understanding.

  • Keith

    Interesting concepts presented. One concern I have with regards to “Let the user decide, remove the systematic determination” would be that the mechanism to allow a user to decide would likely have to be handled holistically (throughout the app, site or system). To recall the affordance’s signpost, prior to some prolonged time out, a maintenance feature might have to be introduced, adding complexity and effort. Alternately, if the signposts were dismissed as a one off, I could imagine it being cumbersome and a breech of context, pulling me from my focussed task.

    All said, I too believe in giving the customer / end user choices. However some decisions may be better handled as “design decisions,” removing the complexity of choice altogether.