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.


4 Replies to “The mobile web splash screen antipattern”

  1. Yeah, you’re totally right! Lot’s of forums (phpbb) also have this wonderful plugin installed that presents the user with a confirm box, asking if they want to use the regular version or the web-obtimized version. That’s one annoying thing, but it also doesn’t remember your choice… If I once decided to use the regular version, it’s very likely I will make that same choice the next time, or else I will switch to the optimized version with the link provided at the top of the page.

    Anyway: splashpages are evil and should only be used for starting-up software on a non-mobile device. Like when you start Photoshop or Microsoft Word. I accept that I need to wait while the program loads and I don’t mind looking at some pretty picture whilst waiting.

  2. An App is a very permanent thing on a smart phone. I find myself Googling things very quickly in Safari and using mobile sites really speeds things up. If I am using Safari, I am clearly looking for information very quickly and in a temporary way (such as when you ‘find the nearest news agents’, you don’t want the app for the shop, you want a drink and you move on).

    In simple UI terms, modal dialogues should be used as seldom as possible. A decision between ‘yes’ or ‘no’ can be a UX killer. If you actually look at iOS you very rarely get Yes/No choices. In real life such choices work in conversation, but a smart phone is a different ballpark.

    In the end, if I wanted an App for that (really wanted, i.e., I would use it), I would get it from the App Store myself. Spend time working on that app and on your marketing, rather than annoying people and increasing your app conversions by 5%.

  3. There are yet lot many parameters to be unturned in this debate. Native vs. web app on Smartphones, each one has its own variety of advantages and conflicting disadvantages as well.

    Cross platform interoperability for Data intrinsic transactions, accessing/writing to Address book, fetching smartphones system parameter information and operating on it, etc these are few important aspects of any Mobile solution that need to be handled, probably a Native app handles it much better. If UX is the choice you can definitely choose between Web against a Native app, I agree with above article for same.

    However, cross platform tools which spins a universal build (web based build) for multiple mobile platforms may have certain amount of capabilities to reach Native layer interaction for the web based builds.


Comments are closed.