Make everything as simple as possible, but no simpler.
That’s one of my favorite Einstein quotes. Unfortunately, it seems to be ignored more often than not in the world of web development – to the detriment of a great many applications. There’s one realm in particular where I think we as developers (and designers) typically fail to apply this principle, and that is in the registration process. In my experience, application developers start from the assumption that they’ll have the typical user account, created by a registration process that (at a minimum) asks for an email address and a password. The problem with this is that many applications don’t actually need user accounts, much less one that requires a password. In the Cucumber world, there’s a practice referred to as ”popping the why stack.” This involves asking “why is this needed?” for any feature of the application – and repeating that question until you get to an answer that is directly tied to business value (maintaining or increasing revenue, or managing costs). If you can’t get to one of those values within five whys, your feature just isn’t that valuable, and should probably be put off for something that’s more closely tied to improving your business. As it turns out, many applications fail the why stack test for authentication. That’s why a site like Instapaper could successfully launch with significant functionality not tied to a login (though they’ve since succumbed to the standard approach, alas). I’d love to see more applications question the necessity of registering before allowing access to the end user; at the very least, this approach gives users a better idea of what a site provides to them, and it’s likely that they’ll see greater conversions as a result (the attrition effect of each step in the registration process is well-studied). Of course, some sites do legitimately need authenticated users – my argument isn’t that all sites should go account-free, but rather that we as developers (and user experience designers) should be mindful of the real requirements for each application we build. Let’s stop the cargo culting of user experience, just as we’ve tried to stop the cargo culting of development practices.