I’m a big fan of minimalist design, so whenever I have the opportunity to reduce the information presented on a screen to just the bare essentials, I’m happy. With that in mind, I realize that certain patterns that we (designers) want users to execute require learned behaviors. For this, we often use labels, tooltips, etc. so that users know where to go and what to do. However, this can often lead to visual clutter, especially when we start looking at mobile screens or applications with a shit ton of icons.
According to the Nielsen Norman Group (NN/g), the best approach to solving this problem is to get the basic design right in the first place, then implement changes slowly and incrementally. Additionally, it’s much easier and more effective to front-load your user testing and design iteration prior to launch rather than just releasing your best guess. This way, you avoid mistreating and antagonizing your users by subjecting them to flawed designs, then making them suffer through the changes you inevitably have to make.
One of the best ways to implement the approach advocated by NN/g is through the use of a largely untapped method: Progressive Reduction (PR) – the idea that interfaces should be adapted over time as users become more acquainted with applications.
The Lowdown on the Background
To understand why progressive reduction is a good idea, you have to understand where it comes from. Its roots are in flat design, which arose out of a culture of reduction, where the goal was to remove all unnecessary embellishments in order to create an honest design.
The problem is that as designers, we spend so much time working on a design, that over time our bias trends toward the pro user. Consequently, we often want to design a UI that is cut down to a minimum and requires no handholding. However, we have to remember that the user’s bias changes over time. In order to solve for this problem, we can use PR to achieve the minimal UI that we love while retaining maximum usability for all users. Additionally, machine learning can be utilized so that frequently used features remain surfaced while unused controls can be better explained or (according to PR principles) hidden altogether.
How to Design for Progressive Reduction (PR)
The ideal way to implement PR is to start off with a minimal interface and build from there. However, if you’re starting from a large, complex product, you must first aim to reduce its complexity, redundancy, and feature bloat before attempting to implement PR. Otherwise, PR’s utility will be comparatively minimal. Regardless of what you start off with, once you have your base, identify the major features in your app that you want to reduce, and assign levels to these features.
Next, track your user’s usage. Ideally, this would be a combination of the total number of times a feature is used, as well as how often it is used within a certain time period. In other words, you should measure frequency of use and usage volume. The best thing to do from there is to create a proficiency profile for each user. With it, you’ll be able to tailor your app’s UI in order to reduce handholding (where appropriate) and generally get out of the way of your users.
One big thing to keep in mind is the concept of Experience Decay. Simply put, a user’s proficiency in a given product decays over time without usage. To account for this, steps must be taken to allow the UI to regress without usage (to stay aligned with the user’s knowledge regression). This can be easily accomplished by utilizing the level system you established earlier. If a user’s frequency of use and usage volume have gone down, then their UI should regress a level or two, depending on how far down their numbers have dropped. Regression is necessary to balance progression. Without it, you lose the ability to fully respond to dynamic changes in user behavior.
Be Aware of User Change and Attraction Patterns
One of the big concerns that people have about PR comes down to change. In an ideal world, all users would be change blind – they wouldn’t notice small changes in visual stimuli. Change blindness usually happens when users use an app frequently over time – their usage patterns become ingrained via muscle memory and automatic reflex. Consequently, small changes in UI go unnoticed. Because of this phenomenon, your experience decay protocol needs to be lengthy enough that users have the opportunity to become sufficiently familiar with your app in order to reduce any unwanted reaction to your well-intended changes.
However, many users tend to be change averse. While this is a potential pitfall of PR, there are various methods that can be employed to mitigate change aversion. To begin with, you should warn users about major changes before they happen. Once the changes are implemented, you should clearly communicate why you made those changes, as well as what value they add. For new users, a great way to accomplish this is through the implementation of some form of a walkthrough.
Most importantly, you should offer a feedback channel for your users and make sure to show users how you’re addressing their concerns as they are raised. There are a myriad of ways to set up a useful customer feedback channel, including personal emails, contact forms, surveys, usability testing, interviews, social listening, analytics, commenting, etc. For more detailed information about great ways to gather user feedback, have a look at this helpful article.
Implementing Progressive Reduction Isn’t That Hard
While some may disagree, I believe that PR’s benefits outweigh its disadvantages. The ability to easily create a highly customized UI for individual users in and of itself is amazing. When used properly, it gives businesses access to a much wider array of users than otherwise possible by maximizing usability for all users. This also gives designers an easy way to de-clutter their designs.
Now, after hearing all of this, you might be thinking to yourself, “Well, production reduction sounds like a good idea, but it seems like it would be difficult to implement.” Well, turns out it’s not actually that hard to implement. Layervault outlined how they implemented PR on their site in an excellent post. One thing to keep in mind is that while it isn’t difficult to implement PR, it is involved. This means that the ideal time to implement PR is from the outset of your design process (in order to maximize ease of implementation). However, this doesn’t mean that you can’t implement PR on a pre-existing product. You just need to spend time up front reducing and simplifying your product so that PR has room to be effective down the line.