Progressive reduction (PR)—the dynamic simplification of a user interface (UI) as users become familiar with it—has become a hot topic within the design community. After all, it could be an elegant solution for personalizing user experience at scale. But it’s not without its challenges. Let’s take a look at those challenges—and 5 ways to overcome them.
1. Implement progressive reduction within a framework
To many, progressive reduction seems too difficult to implement and maintain. That’s one of the primary reasons we don’t see many examples of it out in the wild. But implementing progressive reduction isn’t all that difficult
in and of itself—maintaining it’s the tricky part.
When many organizations try progressive reduction, they do it in an ad hoc fashion, which can create problems when you’re constantly iterating on an interface based on customer feedback. To sustainably design for progressive reduction, it’s better to build up a framework that accounts for it from the outset.
Generally speaking, you can save a significant amount of time when building and maintaining an application by using the right web application framework. Such frameworks provide the core functionality you see in most web applications, such as user session management, data persistence, and templating. With a framework like that in place, you’ll find it much easier to create a progressively reduced version of common interfaces.
2. Don’t change too much too quickly
Now, even if you incorporate progressive reduction into your application framework from the get-go, you’ll still run into the psychological phenomenon known as change aversion.
When a user becomes familiar with an interface, they often enjoy a feeling of mastery, of power. After all, they’ve learned to bend a piece of once-unfamiliar technology to their will. When you change that interface too quickly, you risk making people feel confused or inept. And nobody enjoys that.
Now, people aren’t fundamentally averse to change—in fact, they often love it. Don’t believe me? Just remember what “behavior design” leader BJ Fogg said: “If you’re thinking people don’t like to make changes to their behaviors, just watch a teenage girl get her first cell phone.”
When people display aversion to change, it’s usually because we (designers) did it wrong, by treating it like a band-aid.
More often than not, when big feature changes are made suddenly, the effort of re-learning how to use the application outweighs the benefits.
3. Make subtle changes for greater impact
To prevent creating change aversion in your users, design in a future-friendly way. Anticipate the features and interactions you want to design in the future so that when you do implement them, the change is so seamless as to be unnoticeable.
Many great designers have championed this method. Jared Spool once said, “Good design, when it’s done well, becomes invisible.” Dieter Rams said, “Good design is unobtrusive.” Clearly, designing for subtle change is a good idea.
But what does subtle change really look like? Think of raising a child or a puppy. Because you’re around them all the time, it’s difficult to perceive their growth, but before you know it, a year has flown by and they’re completely different.
In the realm of app design, think of Ramotion’s mockup of a tab bar where the icons shift over a period of weeks from a standard size with labels to become larger and label-less. As users spend time with the app, they begin to associate certain icons with certain functions, making explicit labels unnecessary.
Of course, this works for an iOS app, where a tab bar can only hold a maximum of 5 icons. In a large enterprise web app with 20 different navigation icons, this strategy may not make sense—context is king.
4. A/B test your progressive reductions
If you set up an app framework from the start, you can easily test varying degrees of progressive reduction and see which versions work without triggering change aversion.
This way, you can truly optimize the user experience by fine tuning it in accordance with customer feedback—without taking time to interview a large number of users. All of your insights are gained from the metrics gleaned from A/B testing, providing you with efficient and accurate results.
5. Progressive reduction versus progressive disclosure
If progressive reduction doesn’t prove right for your situation, try progressive disclosure (PD) instead. Essentially, progressive disclosure accomplishes the same thing as progressive reduction—a cleaner and more streamlined UI—but does it by placing advanced or rarely used elements on a secondary screen.
As you might imagine, progressive disclosure makes a lot of sense for advanced applications with many features and functions that might overwhelm the novice user. In this context, it makes more sense to start with a few features, then slowly reveal more.
As with all other user experience (UX) matters, we must keep our users in mind. It’s all too common for designers to design for the power user (aka, their ideal users). The problem with this approach is that, according to Joel Marsh, “Until someone registers for, or downloads, your product and spends some time with it, they cannot be a power user.” This means that you should prioritize initial and secondary features so you can guide novice users toward their eventual ascension to power user–dom.
Doing progressive reduction right
It’s easy to see why many people see progressive reduction as challenging to design for and implement, despite all of the positive things it can bring users. You just have to remember that it works best when you set it up within a framework from the outset. If you do that, your app should be fairly straightforward to implement and maintain.
Now, because progressive reduction hasn’t really been used much in the field, it’s still open to interpretation and evolution. Do you use progressive reduction in your web or mobile app? If so, we’d love to see it!
by Dan Birman
Dan's passion is for solving complex business problems through visually powerful and intellectually elegant design.
