Let Them Pee: Avoiding the Sign-Up/Sign-In Mobile Antipattern

Posted by

This is an excerpt from the upcoming Android Design Patterns: Interaction Design Solutions for Developers (Wiley, 2013) by Greg Nudelman

Anything that slows down customers or gets in their way after they download your app is a bad thing. That includes sign-up/sign-in forms that show up even before potential customers can figure out if the app is actually worth using.

It’s a simple UX equation

This antipattern seems to be going away more and more as companies are beginning to figure out the following simple UX equation:

Long sign-up form before you can use the app = Delete app

However, a fair number of apps still force customers to sign up, sign in, or perform some other useless action before they can use the app.


The application SitOrSquat is a brilliant little piece of social engineering software that enables people to find bathrooms on the go, when they gotta go. Obviously, the basic use case implies a, shall we say, certain sense of urgency. This urgency is all but unfelt by the company that acquired the app, Procter and Gamble (P&G), as it would appear for the express purposes of marketing the Charmin brand of toilet paper. (It’s truly a match made in heaven—but I digress.)

Not content with the business of simply “Squeezing the Charmin” (that is, simple advertising), P&G executives decided for some unfathomable reason to force people to sign up for the app in multiple ways. First, as you can see in Figure 1, the app forces the customer (who is urgently looking for a place to relieve himself, let’s not forget) to use the awkward picker control to select his birthday to allegedly find out if he has been “potty trained.” This requirement would be torture on a normal day, but—I think you’ll agree—it’s excruciating when you really gotta go.

Registration Torture
Figure 1: Registration Torture: Sign Up/Sign In antipattern in SitOrSquat app.

But the fun does not stop there—if (and only if) the customer manages to use the picker to select the month and year of his birth correctly (how exactly does the app know it’s correct?), he then sees the EULA (Figure 2), which, as discussed in the previous article, End User License Agreement (EULA) Presentation (Boxes and Arrows January 2nd, 2013), is an antipattern all to itself.

EULA on a mobile device
Figure 2: Reading the EULA while wanting to pee should be an Olympic sport.

SitOrSquat’s EULA is long, complex, and written in such tiny font that reading it while waiting to go to the bathroom should be considered an Olympic sport, to be performed only once every four years. Assuming the customer gets through the EULA, P&G presents yet another sign-up screen, offering the user the option to sign in with Facebook, as shown in Figure 3.

Sharing bathroom habits
Figure 3: Finally! Sharing my bathroom habits on Facebook has never been easier!

I guess no one told the P&G execs that the Twitter message “pooping” is actually a prank. They must have legitimately thought that they could transfer some sort of social engineering information about the person’s bathroom habits to “achieve and maintain synergistic Facebook connectivity.” I would have to struggle hard to find monumental absurdities from social networking experiments that are equal to this. I can’t imagine that anyone thinks “Finally! Sharing my bathroom habits on Facebook has never been easier!”

Assuming that the user is a legitimate customer looking to use the bathroom for its intended purpose, and not a coprophiliac Facebook exhibitionist, we may hope that he will naturally dismiss the Facebook sign-in screen and come to the next jewel: the Tutorial, shown in Figure 4.

Tutorial is a sub-par Welcome experience pattern. Here it is another impediment to progress.
Figure 4: Tutorial is a sub-par Welcome experience pattern. Here it is another impediment to progress.

SitOrSquat tutorial is an extra screen that provides very little value, other than impeding the use of the app for its intended purpose. (If you need a tutorial, I recommend a much more effective contextual Watermark pattern, which I discuss in Chapter 5 of the Android Design Patterns book.)

50 Taps and 7 Screens of Antipatterns

Note that the entire app outside of registration consists of basically four screens (if you count the functionality to add bathrooms!). However, if you include all the sign-up antipattern screens (including my initial failure to prove that my potty training certificate is up to date, as referred to in Figure 1), it takes seven screens of the “preliminary” garbage before the content you are looking for finally shows up (refer to Figure 5). If you count the number of taps necessary to enter my birthday, that becomes almost 50 taps!

The Glory of 50 taps needed to get through the Sign Up/Sign In antipattern in SitOrSquat app.
Figure 5: The Glory of 50 taps needed to get through the Sign Up/Sign In antipattern in SitOrSquat app.

One of my favorite UX people, Tamara Adlin (who coauthored The Persona Lifecycle: Keeping People in Mind During Product Design with John Pruitt) wrote brilliantly: “For Heaven’s Sakes, Let Them Pee.” I believe that never before has this line been so appropriate. In the absurd pursuit of social media “exposure” coupled with endless sign-up screens, with heavy-handed “lawyering up,” P&G executives completely lost sight of the primary use case: letting their customer SitOrSquat.

Long sign-up screens detract from the key mobile use case: quick, simple information access on the go. Overly invasive sign-up/sign-in screens presented up front and without due cause will cause your customers to delete the app.

There is no reason to force anyone to register for anything

When deciding whether to force the customer to perform an action, consider this: If this were a web app, would you force the customer to do this? If you have Internet connection, you can save everything the customer does and connect it back to his device using a simple session token and a guest account. And even if you don’t (for example, while riding in a subway, using airplane mode, and so on), today’s smartphones have plenty of on-board storage you can use for later syncing with your servers when the mobile network eventually becomes available.

This means there is simply no reason to force anyone to register for anything, other than if they want to share the data from their phone with other devices. As a general rule, rather than forcing registration upon download or at the first opportunity, it is much better to allow the customer to save a piece of information locally on the phone without requiring that he log in. Wait until the customer asks for something that requires registration, such as sharing the information with another device or accessing information already saved in his account; at that point completing the registration makes perfect sense.

For example, imagine how absurd the Amazon.com shopping experience would be if the app asked you for your home address, billing address, and credit card upfront—before allowing you to see a single item for sale! Yet entering the home address (where would you like to have the items shipped?) and credit card (how would you like to pay for this?) makes perfect sense during the checkout, after the customer selects a few items and indicates she would like to complete the purchase.

Finally, remember that “Forms suck,” as brilliantly quipped by Luke Wroblewski in his book Web Form Design (Rosenfeld Media, 2008). Only ask for what you strictly need to proceed to the next step and omit extraneous information. (Effective mobile data entry controls and forms is a huge topic to which I devote chapters 10-12 of my upcoming Android Design Patterns book (Wiley March 11, 2013), now available on Amazon.com).


  1. And just in time after-St. Patrick’s Day, too…

    My new book, “Android Design Patterns: Interaction Solutions for Developers” (Wiley 2013) met with great success at it’s inaugural release workshop at SXSW and is now available for immediate download or delivery on Amazon.com: http://bit.ly/droidpatterns and fine book retailers everywhere.


  2. Great post but would you consider “there is no reason to force anyone to register for anything” as the default approach?

    If so, how does this apply to apps like Uber which have an arguably better experience if you provide billing information prior to the purchase?

    How would you suggest handling registering & billing info in an app like Uber?

  3. Hi Greg,

    > “there is no reason to force anyone to register for anything” as the default approach?


    But there are always exceptions.

    I am not as familiar with Uber, but if registration is the key to the experience, and the customer knows the trade-off, then up-front registration can be a great strategy to get commitment. Facebook is a great example of that — can’t get anything unless you register and pull in at least 1 friend.

    However, too many companies think if up-front registration good for Facebook, then it must be good for them. Exposing the fallacy of this thinking is what the article is all about. Toilet habits aside, most people will engage with your company’s social media and even register to get premium content, products, discounts. *Just not up-front.* It has to make sense in the context of the overall experience. But often doesn’t. Be sure to consider sing-in/sign-up carefully, and remove obstacles to customer engagement.

  4. This sounds like a standard onboarding issue: if you can make people *want* to register rather than *force* them to register, they probably will. A fair few ticketing site (rail is a great example), will remind you at the end that if you log in you’ll get extra benefits. The best sites let you register straight after a transaction and retroactively auto-add the details to the site (not perhaps the best for using toilets, but certainly useful for other important mobile tasks).

  5. Great post, and I agree whole-heartedly. If I had to guess, I’d say the age gate up front has to do with COPPA laws, which regulate how marketers can avertise to kids under the age of 13. If that’s the case, I think the solution would have to be to figure out a way to make sure the app provides useful non-marketing content before requiring the user to sign up/sign in.

  6. Yes Vicky — great point. I was once on a checkout flow design project for a very large e-tailer. That’s exactly the solution we implemented and saw a very nice jump in completion rate (and revenue). As I recall Jared Spool had a similar experience he called the “300 million dollar button”.

    Hi Simon, you mean they really *weren’t* looking for my potty-training licence? 🙂 It’s very hard to reliably verify the age of mobile netizens. Having to enter a birthday on the mobile device is one way P&G chose to proceed. In the words of a Crusader from the Indiana Jones movie, “They have chosen poorly.”

    Another way would be to present a simple checkbox:

    Please check the box if you are 13 or over: [ ]

    With a single tap, or a simple wooden cup “You have chosen wisely”. This brings to mind another project, where the company saw a double-digit improvement in completion rate from doing this one simple change.


  7. Great stuff Greg. It’s outrageous that this app would place these requirements on its users, given the context of use. PS. Bonus points for your post title 😉


  8. Hey Greg! Thanks for the mention, and great article! I just reposted Let Them Pee in its full glory on my corporateunderpants blog in case anyone is interested. An oldie but a goodie!

  9. The story around SitOrSquat and P&G is a bit forced, true but forced. First, because if someone finds and wants to use the app, they’ll probably install it long before they really need it. Second, because if you really are in an emergency situation, you’ll probably just google “public toilet around [my location]” rather than looking for and installing an app that provides this information.

  10. Interesting, logical and entirely sensible but… in my experience more often than not these requirements are put in place by the compliance and legal departments. This is especially so in the case of large corporates like P&G. Case in point is the utterly pointless (for the user) age gating you have to pass to use any alcohol related app. There’s no way to check the age of the user is their actual age but by forcing the user to enter their age (true or false) they shift potential liability away from themselves and back onto the consumer.

    With this specific app there seems less need for this but lawyers tend to see things in very black and white terms and apply a one size fits all policy pretty remorselessly due in part no doubt because there’s not time to look into each individual product and adjust their legal policies around the requirements of the app and user.

  11. I think the other thing to bear in mind is the user journey – at which point does it become necessary to ask for information from the user? If the questions are asked at logical points, and the user understands the validity of it, then it becomes less painful. And also, limiting input fields is key on mobile. Provide shortcuts where possible. For example, Paypal is much easier than having to input long card numbers and so forth.

    I recently worked on an FMCG mobile first site where users are required by law to input lots of data, which is then validated against the Voters Register. Huge hurdle. The solution was to create a novel, shareable experience, so that the perceived payoff was slightly higher than the pain of inputting. The form was also optimised to combine fields (e.g. first and last name).

    The barrier always have to be weighed up against emotive triggers and hedonic factors and force us to think more creatively. Even then, there is the risk of low uptake because of data collection.

  12. Sweet article, sometimes I come across these issues and ideas start to sparkle in my mind, better to write them down and share with people/developers

  13. Great post everyone! Thank you — keep em coming!
    Tamara — it’s my pleasure — “Let Them Pee” is in my book as well. What can I say, I’m a huge fan! 🙂

    Crystal — I really like your blog posting on COPPA. However, one point to add: it’s up to UX people to make product managers aware of the drawbacks of using various methods: like 10-30% drop off in registration rate.

    And as you said, let’s all keep firmly in mind that anyone with half a brain can lie about their age, especially if app allows multiple registration attempts, as SitOrSquat certainly does, providing a helpful error: “You are not yet of potty-trained age”. Pretty obvious how to fix that, don’t you think? If first time does not work, the 12-year old “kid” will just add a few more years and try again and succeed. That pretty much proves to anyone that this COPPA UI requirement is BS. Personally, I favor a simple “By clicking the Continue button you agree that …” approach if you can help your lawyers to be sensible.

    Why oh why, if that approach is good enough for eBay, why does SitOrSquat need extra that junk? Surely going to the bathroom is something less involved than buying and selling online?


    Ultimately, ** there is no law on the books about which UI components to use to determine age requirements.** There is quite a bit of flexibility (partly because mobile is still new and no “standard” is available) so THE POWER TO IMPROVE EXPERIENCE IS IN YOUR HANDS. Don’t take crappy experience for granted — question authority! And if you need some ammunition, get my new book: Android Design Patterns: Interaction Design Solutions for Developers http://www.androiddesignbook.com/android-design-patterns-interaction-design-solutions-for-developers/


  14. Oh and right in this venue, here’s Kidzeter’s sign up form, COPPA-Cabaña compliant:


    See P&G — no need to charge customers attention tax to use the restroom: a simple 2-radio buttons group does the job nicely. I especially like the straight-forward explanation that avoids lawyer-speak, just like Southwest Airlines.

    Good work, Kidzeter! – Greg

  15. Unfortunately, well reasoned arguments about obvious improvements to user flows can’t overcome the legal arm of a company like P&G. The lawyers have final approval, period. Their job is to avoid lawsuits and if you believe their reasoning is flawed, consider the quite unreasonable lawsuits brought against their employer on a regular basis. They error on the side of caution because they believe the opportunity cost of a poor user experience is less than the cost of a lost legal battle from an opportunistic litigator.

    I worked briefly on the iOS version of Sit or Squat and worked on a number of projects for P&G. Believe me, everyone involved agreed that the upfront process was flawed and would turn people away. It wasn’t a lack of awareness that led to that process.

    It isn’t sufficient to point to some other implementation that is less restrictive and say, “see someone else did it this way, so you can too”. I’ve never heard of Kidzeter. Next to P&G they’re non-existent. Who’s going to sue them with expectation of a big payout?

    I often ranted about the restrictions legal issues placed on my work, but I also understand it’s more complicated than people realize and simply being right isn’t enough to change things.

  16. Flickr.
    I was at someone’s blog and I clicked on a photo that linked to Flickr so that I could see the rest of their photos.
    Up pops a popup, “You should use our app”.
    I install the app, then go back to the page in Chrome.
    I click on the link from their blog again and it starts the Flickr app.
    The app then asks me to login.
    I click cancel, I just want to see the photos and hope it will be a better experience than the website, they recommended it to me after all.
    The app closes and end up looking at the photos in Chrome.
    Thanks for wasting my time Flickr.

  17. Great post!

    I’ve always thought of registration as an outcome, rather than a prerequisite, on ANY platform.

    Capture what you can when it makes sense and only ask users to fill in the blanks when necessary for them to attain a goal, product or service…

    Any excuses by the business or marketing to do otherwise means they don’t value ux and only see users as dollar signs…

Comments are closed.