The mobile web splash screen antipattern

Brad Frost’s tweet yesterday reminded me that this is a request I have been presented with, and argued against, on every mobile web project I have been involved with:

First-time visitors to the mobile website should see a splash screen inviting them to download our App. They should also have an option that allows them to proceed to the mobile website.

This is symptomatic of another bad, but regrettably common practice: building your native app before you build your mobile website.

The impulse to put a splash screen in place is driven by a variety of factors and assumptions, not all of them correct (and not all of them openly acknowledged):

• The native app has a prettier UI than the website. Users like pretty. Therefore it will drive more engagement, and more conversions.
• The native app goes on a user’s home screen, therefore they will see it regularly, and use it more often than the web.
• A user might prefer a native app, and they might not know that we have one.
• If we get lots of downloads, we will rank highly in the App Store, which is good for marketing and will lead to even more downloads.
• We just spent a lot of money building a native app! If someone just uses the website instead, then all that money and effort was wasted!

Here are the counter-arguments:

• It’s a barrier to user engagement. A user has to click through the splash screen to get to where they were trying to go in the first place. If you know about purchase or marketing funnels, you know that every screen is another step in the funnel. You never gain users as you step through the funnel, you only ever lose them. The splash screen is a valuable opportunity for you to lose customers.
• The idea that someone who goes to the effort of downloading your app will become a more engaged user is questionable. You should also consider the possibility that they will get distracted or just give up during the process of a) being redirected to the App Store, b) reading the app description, c) acquiring the app, d) downloading & installing the app, e) launching the app, f) figuring out how to navigate your app to get to the point you led them away from in the first place.
• The request is usually to provide a splash screen for first-time users. If there is any category of users who should never be presented with an extra hurdle it’s first-time users. If they are visiting your site for the first time, then they almost by definition don’t know enough about your product or service to decide whether they want to carry on using it, or download an app for it. In the desktop web world, you may have come across sites that show a popup asking you to take part in a survey about the site. How do I know if I want to do that before I have experienced the site itself?
• It’s disrespectful. If a user has arrived at your website using a web browser, very likely by following a link from another website, then maybe they were trying to use their web browser to use your website. Extend your users the courtesy of considering that they might actually know what they’re doing. Putting up a splash screen is like McDonalds putting a bouncer on the door, and telling customers who just parked their car and want to enter the restaurant that they should use the drive-through instead.

Basically, a mobile splash screen, no matter how pretty your designer has made it, is annoying and needy. You are placing your own desires above your user’s. Don’t do it.

“But how will people find out about our wonderful native app then?!” I hear you cry. There may indeed be cases where users can do things in your native app that they can’t do on your website. (Push notifications, for example.) Some people prefer to use apps than websites. For frequent-use, highly-interactive services, a native app may be a faster, lower-friction option than a website. Fortunately there are plenty of less intrusive ways to let your web customers know about it:

• Show a notification bar at the top of the page. You can leave it visible until a user dismisses it, or until they have viewed N pages, or some other criterion. But it shouldn’t obscure the page, or require explicit action before the user can carry on interacting with the page.
• The page footer, traditionally a place people look for additional information, can carry a link to the native app.
• If your site involves some kind of sign up process, you can tell people about your app options at the end of the sign-up process, or in a welcome email. Signed-up users have indicated a clear level of engagement with your product or service; this is a good time to entice them further. Read Jared Spool’s 2002 article about “Seducible Moments.”
• If your site carries advertising, consider injecting ads for your own native app into your ad stream.

But above all, don’t rely on a native app to be the only way a user with a small-screen device can interact with your business. You’ll literally be turning away customers.