Why Lazy Registration Sometimes Fails

This is the kind of UX design process article I like. No back slapping, no chest beating, just a good honest story.

Maybe I’m turning into a scratched record here, but dead ends and mistakes are inherent to a good design process. If this doesn’t happen to you in your work, you should stop and think for a moment. No mistakes means you’re not experimenting. It means you’re not exploring. No mistakes means you are doing very boring work. So if you’re sitting there smuggly thinking to yourself “this would never happen to me” then wake the hell up, it’s a bad sign.

One of the findings in particular struck a chord with me:

“Before even creating an account or logging in, users were immediately taken to the Home screen where they could start creating invoices, tracking time, logging expenses, and so forth — all within seconds of launching the app. No login or account creation required.”

When they took the prototype to usability testing they found:

“Beta testers expected to create an account or login immediately after the launching the app given the ubiquity of this paradigm.

Presented with just the Home screen, testers approached the app with hesitation and lots of unanswered questions. Where would their data be saved? To a new account? What if they already have an account? [...] Deferring account creation or login to an opportune time when its benefit is most relevant was novel, but ultimately just too radical.”

I came across the exact same finding a few years ago when working on a Job Board platform. We designed the job-seeker website to use lazy registration (aka “passive registration” or “progressive sign up”), so people didn’t need to register before they applied for a job or set up email alerts. This was so successful at boosting conversions that we decided to do the exact same thing with the recruiter job posting UI– this is the place where employers and recruiters post their job ad, categorise it in various ways and then pay. We took it to usability testing and it flunked with every single recruiter who tried it. Why? Because they didn’t like the idea of spending 15 minutes creating a job ad without the reassurance that it was definitely going to be saved somewhere safe. They far prefered the version of the app that required up-front registration.

It’s funny that for once, user research pointed towards the option that required substanially less development work. It’s also another nice little piece of evidence showing that you can’t just blindly copy and paste design patterns from one context to another and expect the success to be magically transfered. Context is key.

Edit: title revised for clarity (15-Dec-12)

2 comments