Website Registration as a Usability Anti-pattern

In software engineering, an anti-pattern (or antipattern) is a design pattern that appears obvious but is ineffective or far from optimal in practice. (Source: Wikipedia)

 

Whether the users are Software Developers or a sixty-two year old journalist I affectionately call ‘Dad’, users agree that Website Registration blows.  It’s a hurdle we must endure to get to our beloved internet content; or at least that’s been the status quo for a number of years.

Background

In a recent twitter conversation with @SQLServerCentrl, I complained to them about their registration requirements.  I hadregistered to see a certain article (it turned out not to help me, even though the search terms indicated it would); and I kept receiving their newsletter. As I was clicked on a link in one of their newsletters a few weeks later, I realized that I had forgotten what password combination I had used to register.  Then I realized that you can’t see any content on their site without registering.

I asked them about it, and their response was:

 

@gortok sorry to hear that, but the registration allows us to track stats. If you’re getting the newsletter, you should be registered


That doesn’t make any sense; doesn’t Google Analytics provide anonymous tracking?

That tête-à-tête ended with them pulling out the numbers card in Argumentum ad Populum style.


How many times have you, as a software developer, heard this refrain from your business analyst or marketing department: We need to be able to track users and collect information about them so we know who to market to. This refrain normally spawns a requirement (or two) that the end user must register in order to see content on the site.  All of the tie-wearers agree that that’s the only way to get all of this information, and so it is done.  If you develop software, and you let this happen, you have now commited the worst kind of design pattern, the Usability anti-pattern.  Jeff Atwood calls it a ‘barrier’, but it is so prevalent in websites that it can only be considered a design-pattern at this point, and an anti-pattern at that.

It’s an anti-pattern because while it’s easy to do, and it fulfills the business requirements, it gives users a bad taste in their mouths about your website.  When’s the last time Wal-mart required anything out of you other than walking into their store? 

There are reasons to ask a user to register on your website:

Common Reasons to ask for Website Registration

 

1. It’s the easiest way to track what you look at.

2. It’s our way of tailoring what we deliver to you.

3. We sell your information, we can’t sell it if you don’t give it.

4. We have ‘affiliates’ that we ‘share’ your information with to ‘better serve you’.

5. No reason given. Just a Privacy Policy written by a Lawyer (That gives me a warm-fuzzy).

 

If you look at all of these reasons (except #3); you’ll notice one thing they all have in common. They’re bogus. They don’t mean anything.  They’re simply excuses to get you to give them the benefit of the doubt.  When you go into a store to look at a product; does the store owner stop you at the door and force you to give him your name and address before entering? The answer is a resounding No.

What’s worse is that asking for personally identifiable information from a user now brings up legal issues, as this FAQ regarding registration from the Chicago Tribune website so aptly shows:

 

We specifically ask your birth year to assure compliance with our Privacy Policy concerning minors.

Solution

Wouldn’t a better idea be to not ask for personally identifiable information in the first place?

Besides selling your information or spamming you with emails, there is no reason for a website to retain any personal information about you.

Yet, we seem content to let this happen across our web-applications and websites. We force customers to give us some sort of information in return for viewing our content.  In the worst cases, you must log in every time you want to look at content (SQLServerCentral), and in the lesser cases, you only have to register and log in when you actually want to buy something.  At the good end of the spectrum, you have websites that set the bar low enough where this isn’t even an issue (Stack Overflow, Google, Amazon).

The harder (yet infinitely more usable) pattern is for a website to take one of three paths:

  1. No registration whatsoever.  Why would you want to register to read daily content, some of which you may never even care about?  What does registration get you? Nothing.  Registration is used simply to tie you as a user to what you look at.  Guess what? It’s the same information that can be found with Google Analytics. The only difference is, this information can’t be sold to a marketing company.
  2. Incremental registration after the user has poked around your site. A great example of this is buying something off of NewEgg or Amazon. You select the product, fill out your billing address, buy it, and then they ask you to fill out one or two more fields (usually just choosing a password), and that’s it.
  3. Registration for ‘advanced’ features or for continual participation. Stack Overflow uses this method.  As a Unregistered user, you can ask questions, browse the site, and you can even gain reputation. However, that reputation doesn’t persist across cookie deletion unless you register.

 

All of the methods I mention are widely used, and they’re all relatively easy to do. So why do businesses still ask for this information?

It’s easy, it’s cheap, and by the time you realize you’ve been hoodwinked, they’ve got your information, and you’re left with whatever they’ve seen fit to give you.  In most cases, you’ve gotten the short end of the stick.

 

Leave a Reply