“Progressive Reduction” Could Mean Simpler, Friendlier Apps

Complex apps have a hard time within minimal design. But a new theory called progressive reduction might allow UI to expand and contract in complexity along with the user’s skill level.

“Progressive Reduction” Could Mean Simpler, Friendlier Apps

For more complex apps (think photo- and video-editing apps, or any app that has a content-creation focus) the FTUE is always going to be a little more challenging. That’s because typically these content-creation apps have a larger number of UI elements, advanced features, and a much steeper learning curve than other apps, which means it could be tricky to get new users to stick around.


Another problem with complex apps is that, due to their many UI elements, they usually run contrary to the current trend of flat, minimalistic app design. So how do you, as a developer, balance the need to offer users a myriad array of features, while trying to hide and flatten UI elements, while also trying to provide a good FTUE without having the user need to read a manual just to understand what to do? Progressive reduction could be the answer.

Progressive reduction is a term coined by Allan Grinshtein at LayerVault. Here’s how he describes it:

“The idea behind Progressive Reduction is simple: 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. As designers, the longer we live with a product, the greater our bias shifts towards the professional user. Alternatively, blindly applying basic usability heuristics results in a bias towards new users. The mistake isn’t biasing your UI towards one type of user, it’s failing to realize that your user’s bias is changing. How does one guide a new user from on-boarding, to low proficiency, to high proficiency? With progressive reduction, the UI adapts to the user’s proficiency.”

The easiest way to visualize progressive reduction is by imagining a button that has a shape (say, a rectangle) and inside that button is a text label that describes what the button does, and also an icon representing what the button does. For a first-time user, a clearly defined (rectangle shape) and labeled (text and icon) button is a good thing to see. In progressive reduction, however, once a user has reached a certain stage, the text label is removed from the button, with only the rectangular button’s shape and icon left behind. Once the user becomes even more advanced, the rectangle is removed from the button altogether, leaving only the icon, which could be reduced in size as well. The end result is a much flatter, minimalistic UI with no impact on the FTUE.


So as a developer, how do you implement progressive reduction in your apps? It’s as simple as creating a proficiency profile for each user:

“LayerVault creates a proficiency profile for every user. We do so by providing positive forces to get you into the right process, and when you’re an expert, we get out of your way. At the moment it’s limited, but you can imagine how useful having a report card for each user might be.”

Here’s the sample code to see how they implement the backend (in Rails and NodeJS):

View on GitHub

They then attach each class to the body element on each page:

View on GitHub

Now for the HTML:

View on GitHub

I haven’t seen a live example of a mobile app using progressive reduction (if you have, let me know), but I think it could be a brilliant answer to the FTUE challenges complex apps face on small screens.

Grinshtein is on to something here and if mobile developers can use progressive reduction in complex apps, they can make the app simple enough for the first-time user, with things like labeled buttons, but still get the sparser, minimalistic app later on that might be too complex when bringing a first-time user onboard. And the best thing about progressive reduction is that it would allow the developer to get rid of some of those god-awful chalkboard overlays or, worse, video introductions, they now commonly resort to for complex apps.


Why The First-Time User Experience Matters.

There are no second impressions in life or software. An FTUE can make or break any website or app; it’s what users will use to gauge whether your app or service is worth their precious time. If your FTUE is slow, cumbersome, or nonexistent, users may get quickly flustered and leave, never to return. Of course, there are ways to create user-friendly software that don’t require any kind of introduction at all–a black art we’ll cover in this story, too. For mere mortals, a first-time user experience should be fluid, responsive, intuitive, and more than anything, enticing.

As we scour sources and the Net for the best FTUE advice, we’ll use this story to track the best practices, advice, and even horror stories about the FTUE on web apps, native apps, mobile-specific apps, and hardware.


If You See A Splash Screen, The Developer Failed.

I own a health-tech startup that is currently in the process of prototyping our first piece of hardware and a companion app before we begin coding. For the last several weeks in our design meetings we’ve been talking about the first-time user experience for both.


While there’s been a lot of back and forth debate about this short, but highly important step, one thing almost everyone in the room agrees on is that if your app has a splash screen you’ve already failed.

For those not familiar with the terminology, a “splash screen” is a static image that appears every time a person opens an app. This screen is usually a solid color and carries the logo or brand of the app being opened. While I concede that a splash screen might be okay in the very first instance (with a caveat, see below) of the user opening the app, if it shows every time, you’ve got big identity problems.

Here’s why: If I open an app and each time need to be reminded in the first few seconds of the name of the app I’m using, that means the app is designed so horribly that I can’t tell just by looking at its interface what app I’m in. And if the user can’t tell from the UI what app they’re in, then you’ve got problems that an image with your logo popping up won’t solve.


But let’s say the UI is good enough where even if I wasn’t the one to tap the app’s icon on my homescreen–where someone just handed me an iPhone with the app already opened–that it’s easy enough for me to tell what app I’m in. If this is the case (as it should be with all apps) then what is the purpose of having that splash screen at all? There is none. Splash screens are ego. They’re shouting “Look at my cool logo again and again and again!” And that’s all they are.

Think I’m being too harsh? Android and iOS developer Cyril Mottier calls splash screens just plain evil. But he does state one reasonable case to use one:

“A splash screen can be used to make resources available before an application starts. Personally I think it is not necessary in 98% of the cases. It may be useful for applications actively relying on heavy resources such as Google Earth, Sky Map, or games but this is not applicable to simple utility applications such as feed readers, social network apps, news readers, etc. You should not require a network connection at startup nor do heavy computations.”

You have a chance to treat every session your users launch as a new “ first time user experience.” And you can do it by just getting on with it and letting them accomplish the task they opened the app for. When I launch an app, I want to be brought into it and start using it as fast as I can. I don’t want to stare at your brilliant logo.


And no, splash screens aren’t a newbie mistake. Some popular apps (I’m looking at you Yelp, Netflix, and LinkedIn) use splash screens, and it’s baffling to me why they do. I mean, even Apple explicitly states developers should avoid splash screens:

“Avoid displaying an About window or a splash screen. In general, try to avoid providing any type of startup experience that prevents people from using your app immediately.”

The above mentioned apps all have a great FTUE and generally distinctive UIs, so I can tell what app I’m in immediately when the app loads. This makes their splash screens nothing but branding ego. As a user, I don’t need to sear their logos into my brain again and again. Now take a good look at your app and ask yourself whether your users really love your logo as much as you do.

What can web application designers learn from the onboarding process of video games? That’s a question I found on Quora that was asked in 2010 and to this day it still only has one answer–but it’s a good one, especially if you’re a developer of a website where an active community is essential (think any type of website that relies on user-edited wikis or thriving message boards).


Here’s what Dave Snider, designer at video game news and culture site GiantBomb had to say:

At GiantBomb, we launched a Quest system (essentially badging with multi-part goals and an XP system) that provides a similar experience [as in RGP games] and for the most part it’s been one of the more important things we’ve ever added to the site. We run new quest sets every week and even set a community goal (if 3000 members finish this quest by X, we’ll award X) that help organize users as a team. Here are a few examples of the impact of quests on our site.

1. By far, the hardest thing we ask users to do is contribute to the wiki. Some parts of the wiki, like adding release date information around games, is extremely boring to fill-in. By adding quests with high goals (contribute 50 new release entries) we were able to see contributions improve 1000%. While this spike is always highest the week the quest is launched, it stays continually higher over the period since quests are always attainable.

2. We once had 6000 users watch a combined 60 mins of video over the course of one week around a certain game in order to complete a quest. Our members assumed it must be ad related, but we just wanted to focus on our great coverage of that game that week. For a site that puts out so much content every day, sometimes it’s hard to find the really good stuff. Quests help us make sure they see us at our best.

3. Large community sites often don’t have trouble getting contributed content, but instead have a larger problem of trying to float the quality content to the top. Look at YouTube and its thousands of worthless comments. We use quests to force our members to go out and rank their peers reviews. Doing so drastically changed the chance you were going to find a quality user review while browsing the site. That benefit is self-replicating in that seeing quality reviews on a site makes you want to contribute your own, possibly better one.

Right now we have a total of 195 quests that ask for a variety of goals to be hit. About half of them are created with the above situations in mind, that is… how can we harness our members passion into helping us organize the data they so rabidly create? They’re also a lot of fun, I get caught up in them all the time and keeping ahead of the game is just part of our human nature.

“If you see a UI walkthrough, they blew it.” So says UI designer Max Rudberg (echoing Steve Jobs’ famous quip about the stylus). Rudberg made the comments in reference to the “trend of ‘gesture driven’ apps with a flat UI.” These “novelty apps” like Clear, Rise, and Solar, though hip right now, are so minimalist in their style that they risk putting off users because there’re no clear (excuse the pun) sign of how they work. That means many minimalist app devs are forced to turn to UI walkthroughs to enhance the FTUE–something Rudberg thinks is a no-no. So what’s the alternative? Be clever, says Rudberg. One example he gives is of the iOS lock screen so many of us are familiar with–and itself a very minimalist part of iOS’s UI:

Just tapping on the camera icon makes the screen jump, briefly revealing the camera UI behind the lock screen. This combined with the ridges above and below the camera tells the user to slide the lock screen up. Before this behavior the camera was activated by a mystery meat action; double tap the home button and a camera button would appear to the right of the Slide to unlock well. There was no way to find it unless you knew that double tapping the home button was possible in this screen.

Rudberg gives some great examples of other apps that use “progressive disclosure with slight visual cues and subtle animations” to help convey usage to a first-time user.


A more hands on approach can be found in games which often deals very well with progressive disclosure, revealing game mechanics as you move further into a game. In Pudding Monsters, if you sit idly by when facing a new scenario, an animated hand will appear and make a sliding motion. It’s inherent in humans to mimic actions we see and it immediately becomes clear how to proceed.

And then there’s his own app, Filibaba Meals, which shows users vegetarian meals and how to make them. Since the iPhone’s screen offers limited real estate, he chooses to keep the recipes in a pull-out “drawer” that hides to the left of the screen while a user views photos and descriptions of the meal on screen. Instead of doing a UI walkthrough on the app’s first launch, he uses progressive disclosure to tell the user they can perform another action:

To do so effectively we have the ingredients in a separate layer to the left of the description. To make it obvious that there is something more to the left of the current screen, there is a subtle animation that moves a piece of paper into the left part of the screen each time you pick a recipe. It’s subtle enough not to get annoying over time, but still serves as a UI hint the first time. We allow both tapping the piece of paper, as well as a horizontal swipe anywhere on the screen to move to the ingredients view.

From a user perspective, apps that use the “progressive disclosure” method with subtle animations feel more engaging. No one likes having to go into an app’s settings and select “view help overlays” if they need help using it. Progressive disclosures with animations make me feel as if the app is a partner that’s helping guide my journey as I learn to use it.

A vital part of on-boarding a new user is collecting information from them. While it’s fine to let people begin using your app willy-nilly, you might regret not having at least grabbed their email address or social handle later, when it’s time to announce new features or collect feedback. But how do you do that without encumbering the first-time app experience?

One way is to begin collecting user information before the product has launched. Poncho, a new weather reporting site coming out of Betaworks here in New York, uses a fun little demo of their experience to lure people into signing up for the beta.

Potential Poncho users are first presented with some beautiful weather animations; then they see subtle indications that they can scroll down. When they do, a simple, visually pleasing explanation moves to the foreground. Entrepreneur-in-residence Paul Murphy implies that he put some energy into this process, in his introductory email to the Openbeta email list:

Poncho is initially only available in NYC. We’ll quickly roll out additional cities in the coming weeks (so please, sign up if you’re not in NYC so we know which cities to launch next). The signup process is intentionally fun, so give it a try through the Openbeta VIP link.

Here is the explanation screen, below.

A staple of the FTUE for many developers is showing a new user around their app the first time they launch it: Also known as a “UI walkthrough.” Tapity founder Jeremy Olson, who makes the popular app Languages (among others), contends that the walkthrough approach isn’t good at teaching users how to use the app’s “mystery meat.” Why? He says there are several reasons:

  • No context. The user barely knows what the app does and yet they are bombarded with instructions to swipe hither and thither to do this and that. Because there is no context, the gestures themselves seem much more complicated than they actually are and folks are easily overwhelmed.
  • Memory management. While users may, by some miracle, remember all the gestures you described in the walkthrough, think about users who come back to your app after a month of non-usage. Unless your gestures are extremely intuitive, mapping to real world metaphors (like iBooks page swiping), your app may be a complete mystery to them. That’s not good.
  • Impatience. Impulse downloaders want to cut to the chase. They want to evaluate your app in a few seconds to see if it is worth their while. We learned from Steve Krug that users don’t analyze websites, they muddle through. The same applies to apps. Many users will skip the tutorial because they don’t want to learn about the app, they just want to try it.
  • Confusion. If not done properly, users will often mistake the walkthrough screenshots as the actual app and will try to tap them, getting frustrated when nothing responds. I learned this the hard way by doing usability testing on an app I worked on. Almost every user tried to interact with the walkthrough screenshots (and I thought I had already taken adequate precautions against that).

So what are the alternatives to UI walkthroughs? Olson says “coach mark” overlays work better, but still they do not do a good job of solving the problem:

Not a fan. You might say that this provides more context but I think it’s overwhelming and only provides superficial context.

The best option, Olson says, is to teach a first-time user how to use your app by making functions of the app obvious through the placement and labeling of controls. If more help is needed, he says, use visual queues that suggest to the user what actions to perform.

We played with gestures a lot when developing Languages. Going for that minimal, gesture-based approach definitely helped us get rid of unnecessary UI baggage but at the end of the day we decided that functions like search were so important that we needed a button (in this case a search field) to make the function obvious. We then used a folding animation and other cues to let the user know they can also conveniently swipe the entire screen to switch between searching and browsing.

As a developer you aren’t going to like to hear these numbers. According to a Localytics study from 2011, 26% of apps are only opened once, 13% are opened twice, 9% are opened three times…and the downward curve continues (only 2% of apps are opened 10 times). While Localytics stops short of saying this, we can presume that at least some of the drop-off owes to poor initial user experiences.

Matter of fact, for apps requiring a sign-up process, developer Luke Wroblewski notes that popular app Everyme only saw a 25% completion rate of their FTUE–and ended up only retaining 5% of their users through their on-boarding process. If your software relies on gathering a lot of data from your users so it’s (eventually) useful to them, Wroblewski recommends a gradual engagement approach instead of a collect-as-much-data-as-you-can-and-then-dump-them-into-the-app approach.

That’s exactly what he did for his app Polar:

“Gradual engagement is the process of moving a user through an application or service–actually engaging with it, and seeing its benefits. With gradual engagement, new users are not just presented with a registration form and then dropped off a cliff. Instead, registration is either postponed, or handled behind the scenes and the first time experience is focused on giving people an understanding of how they can use a service and why they should care to.

This is the approach we took with our mobile app, Polar. Polar is all about sharing and collecting opinions. So out the gates, that’s what we allow anyone opening the app for the first time to do: vote instantly on the polls they see. 87% of people who download the app do.

Here’s how it works. When a new or logged out user opens Polar, they are presented with a list of polls to vote on. We hold on to all their votes so if they ever create a username and profile page, all their votes will carry over. Commenting or creating a poll requires an account and the dreaded sign-up form. But we’ve made a lot of design decisions to make that process as fast and painless as possible. Massimo Pascotto recently wrote an article about the design of our sign-up screen if you’re interested in more. With gradual engagement we can communicate what our mobile apps do and why people should care by actually allowing people to interact with them right away. We can capitalize on all the hard work it takes to get a download instead of turning 75% of our potential audience away with sign-up requirements. 85% of the over 3.5 million votes on Polar have from signed-in users. But another 15% came from people voting without an account. And we’re happy to give them a voice as well. No sign-up form required.”

As a writer, this advice hits home for me: Tell stories in your FTUE, don’t give instructions. Dropbox engages users who might not be familiar with the cloud at all with a short video and a story book, instead of making potential users read through paragraphs of information on what cloud storage can do for them.

As Jordan Koschei writes on The Industry:

Users are likely brought to the site by a recommendation from a friend or publication, but the real Dropbox experience starts on the homepage. They are presented with a friendly and easy-to-follow video, which explains the service in a manner both techies and non-techies will appreciate. Underneath the video is a single call-to-action encouraging users to download Dropbox — to avoid presenting the user with unnecessary choice, it detects their operating system and serves the correct version of the application. If the video isn’t enough, or if users want to learn more, the site offers the friendliest product tour I’ve ever seen. The five-page “book” is a quick read, easily understood and filled with quirky illustrations. Even the least computer-literate user should have no trouble understanding and downloading the program.

But as Koschei notes, Dropbox doesn’t stop with storytelling to engage users. It also relies on another very human trait: the giving of rewards.

[After sign-up] The real magic happens once the user has already installed Dropbox and signed up for an account. In order to better explain the service and provide the user with authentic, personal use cases, the Get Started page includes a list of tasks essential to the Dropbox experience. The tasks include items like “Install Dropbox on other computers you use” and “Share a folder with friends and colleagues” — fundamental activities which might not be obvious when explained in a video or tour. To incentivize completion of the list, Dropbox offers users an additional 250 MB of storage for finishing the tasks.

This solution is much more elegant than simply forcing users to sit through instructions. For one thing, it offers them a choice; nobody is forced to go through the steps, but most people will anyway in order to gain the reward. Furthermore, the reward is intrinsically linked to the product — it isn’t a tangential incentive like a badge, but rather more of the product itself. Rewarding appropriate use of a product with more of the same product is simple and elegant.

Stay Tuned As Coverage Continues!

[Image: Flickr user Mark Probst]


About the author

Michael Grothaus is a novelist, journalist, and former screenwriter. His debut novel EPIPHANY JONES is out now from Orenda Books. You can read more about him at