iPhone prototype: Sign up/in

Roles: Information Architect, Researcher, Visual Designer

This was a fun project — one of the few that was totally in my hands from start to finish. I even got to do some visual design!

The goal was to fix three main problems:

  1. Our oauth authentication flow was confusing. It appeared at first glance that the only way to create an account was to provide an email address and set a password. On its own, this would’ve been fine, but it required the user to exit the app and click a link sent to their email. As any product manager knows, exiting the app on first use leads to poor conversion (I rolled my eyes, too, but the data confirms it). So, somewhere down the line, it was decided that we should intercept anyone trying to sign in using an email provider that supported oauth — basically, if someone entered “john_smith_41234321@aol.com” in the email field when signing up, the app would offer an “authenticate with aol” screen directly afterward. But rather than completing the oauth flow, many people backed out entirely, not realizing that they had a choice — the standard verification email flow was offered on the next screen.
  2. A popular opinion among members of the product team held that some users were downloading the app without having a solid grasp of what it did, mainly due to the number of accounts abandoned directly after signup.

The solution to the first problem was to redesign our signup/signin flow from the beginning, starting with the splash screen. Rather than intercepting oauth-enabled users, we decided to give them a more familiar choice; i.e., the “sign in with google/yahoo/facebook” options that appear all over the web and in other apps. Turns out, this isn’t as simple as it sounds. The most elegant solution from an information architecture standpoint would be to display all the signup/in options on a single screen and not force the user to go through multiple steps. So, that was the first thing I tested:

signup1You can click the image at the left to go through an interactive version. This is the same prototype I used for user testing. The Google and Facebook oauth options work, the Yahoo one doesn’t (though it would, of course, on the production version). If you try out the email option, the prototype requires 5 characters in the email field and 1 in the password field.

If you know anything about oauth, you know that there’s not really any distinction between signing up with it and signing in with it. What we found, interestingly, was that this still isn’t clear to many users. Common syntax on the web is “sign in with [oauth provider],” but in our tests, users signing up for the first time seemed to expect the oauth options to show up under the “sign up” header as well as the “sign in” header.

Leaving aside the additional problem of the too-verbose “sign up with your email” button, this was unexpected and left us scratching our heads — we couldn’t very well have the same oauth buttons in two places on the same screen! That would be foolishness!

So, in the end, we realized that the two-button splash screen was the way to go. People want to see two options at the beginning: sign up and sign in. Then they’re mentally prepared to deal with the next step of the flow. We already had the first step, so the only other thing to do was add the oauth options to the next step. Version 2 (shown below) delivered much more promising results.signup2

You might notice that this prototype does something weird — namely, after signing up with one of the oauth options, it asks you to set a password! If you want the (long, complicated) backstory here, I’m happy to discuss; suffice it to say that it was somewhat of a compromise.

With the signup flow solved, it was time to move on to the second problem. We knew from previous research on our webapp that people who took the time to view our promo video (not that many people, alas) had a pretty good idea what TripIt did. So, we decided that the logical thing to do would be to try to distill that content down so it was consumable quickly on a mobile device. This took the form of a swipeable brochure accessible from the splash screen. I tried a number of methods to introduce the brochure, and ended up using iOS’s nifty page curl transition. A second or so after the splash screen displays, a corner of the background peels away to reveal a teaser.

As for the actual brochure content… I’m not an illustrator; I’m definitely more a UX guy than a visual designer. That said, I think I did a pretty good job with this. I was trying to mimic the style of airline safety cards, with a dash of some of the same splashiness in our promo video. I ended up taking pictures and then tracing over them. It’s important to note that there’s always a clear action item: inside the brochure, it’s “sign up,” obrochureutside the brochure it’s sign in or sign up. Check it out in the last prototype.

The result: largely successful! We’ve observed significantly fewer users backing out of the signup flow and significantly fewer abandoned accounts after successful signins. Our last round of usability testing, however, illustrated the need for some sort of post-signin tutorial. But that’s another project…