
Don't Make Visitors Make Accounts - benburwell
https://www.benburwell.com/posts/your-website-is-not-special-dont-make-visitors-make-accounts/
======
timr
Actually, most of this advice is too general to be good. Your website _is_
special, and you should think through all of these questions rather than just
taking a blog post's advice at face value.

Maybe you don't display it as an "account", but I can't think of a single
commercial website where you shouldn't at least be taking an email address as
part of the transaction. Yeah, users _love to complain about registration_ ,
but I can tell you from direct experience that they love to complain _even
more loudly_ when they have a problem, and you can't find a history of their
transaction because they never gave you a way to identify them -- I can
_guarantee_ that they never printed out your transaction record. Account-less
purchases will have their way with you. Don't do it.

As for the rest of it, maybe it makes sense for you to provide OAuth options;
maybe it doesn't. It really depends on the domain. Likewise, maybe it makes
sense to offer "traditional" login, or maybe it doesn't (Tinder seems to be
doing okay). The password advice is good.

Developers are this unique audience of people who have -- well, let's say
"highly evolved" \-- expectations about how web businesses "should" work. Most
normal people don't share their expectations, so don't make assumptions
without direct validation from your target audience.

~~~
hawkeyedan
For a project I'm working on right now our team decided to simply eschew user
accounts even though it's a site that is built around user generated content
and comments. Everything is done by entering your email address (which the
site doesn't surface) and then clicking a confirm link we send via email.

So far,our testers love it. It seems to have gotten them quickly past the user
dread. It also means your first participation in our site can happen by
submitting one form and confirming one email. That's somewhere between two and
five steps shorter than had we required account setup. While it adds an extra
step to subsequent interaction, email confirmation, we feel like it's a good
trade off for them. After all, going through a password reset when you come
back to the site is an easy way to lose people.

And for us, it eliminated a lot of development headaches. When a user first
participates in the site we assign them a randomly generated username. And
they can change it to whatever they like ... They just fill put the change my
username form and confirm by email.

Obviously, if we wanted to save credit card info or something like that we
might need to modify this approach for PCI compliance, but I believe a
fundamentally similar workflow could be employed even then.

~~~
tokenizerrr
I'm not sure I understand, you're saying that you are sending an email for
every login? It surprises me that your testers seem to love that, it seems
very obnoxious to me. I also don't quite understand:

> After all, going through a password reset when you come back to the site is
> an easy way to lose people

Most password reset forms I've seen just ask the user for their email, send
them a link and ask them for a new password. This is nearly the same flow as
your regular login flow, if I understand correctly?

~~~
tracker1
I'm guessing there is a long (week or two) session cookie that they only need
to re-confirm their email after a few weeks of not being on the site... maybe
as a secondary token/cookie to re-entering their email, if it matches the
second token, they're in...

It'd be similar to 2fa, but without the first factor (a password).... I work
on a similar site, where each real interaction is a financial transaction...
since there's no real need to login after that transaction, there's no
password, they're buying a product, and that is delivered via email... no need
for the hassle of creating an account to login with... an account is made with
a random password under the covers, but it's never really needed.

------
JonathonW
> Use a slow, secure hash function like SHA-256. Don't use MD5!

Don't use a single round of _any_ hash function, including SHA-256.

You shouldn't try to roll your own crypto, and you shouldn't try to roll your
own password verification either. Use bcrypt and you'll get salting and you'll
get a multi-round hashing process that has the ability to easily scale up in
complexity as computing power continues to increase.

~~~
benburwell
I actually just updated the article to reflect this. bcrypt is a much better
solution than what I originally proposed. Thanks!

~~~
TheSwordsman
I gotta ask, how many systems/websites have you actually maintained in a
production environment?

I like people offering help to others, but I read your article before you
updated this... and I immediately wrote you off because of that.

It's great to offer advice, but can't seem to find any indication of what your
experience is.

------
getdavidhiggins
Some of us have been online for decades, and have seen our fair share of
walled gardened apps with a login screen hiding the app. We are sort of used
to registering, but we are also sick to the teeth of having to register too.
The problem can lie in the micro copy too; you often see "10 seconds to
register" or, "one click login". It is rarely that - it usually entails a
frightful tale of password management, making the password match the
requirements of the app (alphanumeric and maximum 8 characters nonsense),
alongside a11y issues, PIA (Personally identifiable information) issues, and a
slew of other barriers to entry.

Very much something that has gone un-noticed by developers for a long time, is
that login systems are an obstacle and something to be avoided if we can.
Login systems can not be solved with Single Sign On (SSO) / OpenID systems
either. (Not all of us have FB/Google accounts, and never presume so) Every
developer is scrambling to find a solution for the 'login problem', and
completely overlook how login systems complicate things for their users. A lot
of login systems suffer from Not Invented Here™ syndrome. Often online forms
are a sort of 'mystery meat' where users don't know what to expect there. I
once saw an account registration form asking to include an emoji character in
my password, for example.

~~~
yarou
Biometrics may alleviate some of these issues, but you have a lot of
compliance/regulatory headaches to worry about. Not to mention privacy issues.

------
throwawaymsft
My favorite model is letting people use the app from the first visit, stored
in a cookie.

"Want to save your work? Create an account."

Creating an account can use FB/Google, or local login.

First demonstrate value, and people will gladly save their work.

~~~
lhh
Do you happen to have examples off hand of sites that do this well? Thinking
about implementing something like this for my current project

~~~
throwawaymsft
Khan Academy used to let you watch videos, do questions, and collect points.
Then you would sign in to claim them.

Their new homepage looks to push you to sign up first though. There is still a
link to "Unclaimed points > Sign up to claim your points" in the top nav.

------
jacquesm
I never use websites that require me to have an account somewhere else. Either
have no account at all (especially if you don't need one, that's just
friction) or set up a minimal password system as an option next to FB/G/TW or
whatever else is in fashion as external authorization provider.

------
onan_barbarian
Seriously. Our local burrito chain has a loyalty program where you get a
little card, and so on, but you have a _password_. Right, because I really
want to remember a Burrito Password.

~~~
arthurcolle
I wonder how many people's passwords for that are 'burrito'

~~~
andyjdavis
I would guess most are either "burrito", "password", "1234" or similar with
the remainder being forgotten by the person who set it the instant they
entered it. I am curious what percentage have a reasonably strong password
that they can actually remember for their burrito account.

------
bbx
This reminds me of the $300 million button:
[http://www.uie.com/articles/three_hund_million_button](http://www.uie.com/articles/three_hund_million_button)

They significantly increased their revenue by simply allowing customers to
purchase without having to create account.

------
fishnchips
By having you create an account I get your email. By getting your email I can
start retargeting you for advertising purposes and perhaps even you will tick
the box allowing me to send you spam. This is called customer retention.

------
riteshpatel
As a platform that sells tickets to events
([https://www.theticketfairy.com/](https://www.theticketfairy.com/)), I feel
that I should make a counterargument to not making users create an account.

Our checkout process requires no existing account, so you click on the buy
button, enter your name, email address and billing info, and you create a
password at the end, after which you DO have an account. We feel that this is
much better UX than most other ticketing sites that send you to registration
forms before you can continue the checkout.

We used to receive many, many support requests from people who'd lost the
email containing their tickets. We then added order history and the ability to
download their tickets by logging into their accounts and this resulted in a
massive drop in support emails.

Another key point is that most people realise they've lost the ticket email
only a few hours before the event is about to start, so we get very panicky
last-minute emails from people freaking out that they're not going to be able
to get in. Just giving people the option to log into an account and retrieve
their tickets not only dramatically reduces our workload but also provides
them with peace of mind.

We're adding 3rd-party login shortly (primarily Facebook) but will keep
email/password as an option. However, even with 3rd-party login, we'll still
need to confirm the email address as most people are used to email as their
delivery method.

Saying all this, most of the advice in the article is valid and we follow many
of the points. Our username is the email address and we enforce HTTPS on all
pages (with HSTS headers).

~~~
jordanpg
> support requests from people who'd lost the email containing their tickets

"Losing email" is a problem completely distinct from the UX question. Since
"losing email" is more-or-less impossible in year 2015, it isn't a reason to
force people to make accounts. There are other ways to deal with this problem.

~~~
andyjdavis
>Since "losing email" is more-or-less impossible in year 2015

Actually losing email is basically impossible but non-technical people still
do it all the time. What they mean is that they can't find the email they are
after. "I am not good at searching" is indistinguishable from "the email is
gone".

~~~
riteshpatel
Exactly, or their phone only syncs emails back a week/month and they bought
the ticket months before the event. Loads of scenarios where this can happen
when you run a consumer-facing ecommerce platform

------
rfrey
This can go too far in the other direction too.

My latest project was a sunglasses/eyewear design site, where people could
design their own glasses (I had a tech stack on the backend to make the
glasses in my studio - the company is an experiment in mass customization).

I went to great lengths to allow people to use the software without creating
an account. In the end, I probably spent two weeks trying to get it to work
properly with all the edge cases - saving the anonymous design when they do
finally create an account, locking out certain features that required
identity, appropriate warning dialogs when work was going to be lost, etc.

And I still had edge cases. I burned two or three weeks trying to accommodate
account-averse people, then had to spend another two days yanking it. That
effort was based on my personal distaste at having ten billion website
accounts, a distaste probably widely shared here on HN and likely nowhere
else.

(This isn't an argument with Ben's points - his example use cases clearly
don't need accounts.)

------
xnull1guest
I agree with the author that in the short game not providing your own accounts
is attractive. However in the long game it doesn't look so good. Unfortunately
there are problems with using federated auth everywhere.

* It's a single place for a compromise to occur - the devastation of a serious identity provider hack completely upends the security of huge swaths of the internet in a single shot

* Breaks in fedauth protocols and implementations, similarly, presents a large auth crisis for the entire Web

* It's a single place for legal or extralegal pressure for governments to access services and data on behalf of everyone

* It creates market friction. If federated login had been around in large numbers when Myspace was the big social platform we'd still be using Myspace for the sheer reason we need it to vouch for our identity. It makes the big fedauth players 'too important to fail'

One should consider options carefully and determine whether a good user
experience can be offered without further centralizing the Web.

------
kazinator
> _One of my pet peeves in website usability design is forcing people to
> create unnecessary accounts._

This has been a pet peeve of a vast number of web surfers for over 15 years
now.

In the early days, this pet peeve created a backlash in the form of a custom.
The custom went like this:

1\. When confronted with an annoying site asking you to log in or register,
first try the account name "cypherpunk" with the password "cypherpunk".

2\. If that works, great.

3\. If there is no such account, then create one, for the benefit of future
visitors who participate in the custom. There are variations on this:
pluralizing to "cypherpunks" and possibly using the "cipher" spelling.

~~~
kazinator
.. and speaking of which, who is the dickhead who created a cypherpunk account
on HN, but with a nonstandard password? Or changed it to a nonstandard one?

Please atone for your evil ways and fix it to "cypherpunk".

Thx.

------
kevinflo
I felt oddly vindicated when he mentioned Ticketfly specifically... It irked
me too that they don't allow guest checkout, so in making
[http://showboarder.com](http://showboarder.com) I put in the extra
thought/effort to make it an option.

That said, having implemented this I can see why many services don't. It's an
entire other case to consider when thinking about security, user experience,
etc. and for many it could definitely be more trouble than it's worth. It's
just a question of values if you make it a priority or not.

~~~
hawkeyedan
I'd suggest that the guest use case is the most important one and that account
generation/creation/etc is for most sites the use case that should come
second.

------
jinushaun
1\. I do not want to log in with Facebook or Google 2\. I use a password
manager so creating new accounts is cheap and easy.

~~~
vonklaus
Agree or disagree with the post, you are a sample size of 1. If you said on
your site, these were the patterns you see, then sure maybe it is in line with
a macro-trend. If n=1 the data is usually not very helpful.

~~~
fishnchips
Samples of size one can invalidate scientific theories.

------
minimaxir
This advice is too generic. There are many, _many_ applications where a
persistent identity is required. What would happen if Hacker News had
completely anonymous users? :P

A ticketing startup is a good example of a startup which could be used without
a dedicated user account. But that's the minority.

~~~
stegosaurus
I would say that in my experience, account creation at online retailers (even
Amazon) is very rarely something I've found useful for myself. It may well
benefit the company.

I don't want my card details to be saved, and typing in my address and card
number take less than a minute anyway. Newsletters almost universally go to
spam because I'm not a landowner who has the disposable income to just buy
arbitrary things that are advertised to me.

I think generally developers are aware of this, but they're chasing the few
that do respond to such tactics.

~~~
mattmanser
Most people aren't you actually, contrary to your very misplaced belief.

Just think of the huge number of people have kindles with 1 click buy.

The 'few' indeed.

~~~
Gracana
The advice isn't "don't have accounts," its "don't make visitors make
accounts." Having an option is good... if you don't plan on coming back or
you're worried about your security, you don't have to store anything on their
servers. If you're a frequent customer and you want the convenience, you can
make an account.

------
Frozenlock
> Always allow your users to close their account. This should remove all
> information about them from your service to the extent possible without
> disrupting the integrity of other information.

I think this would be much better if it answered the question "Why?"

~~~
vonklaus
This is pretty obvious from the user perspective and from the site runners
perspective, something you do not want. Obviously a user who closes their
account want to make aure their information is safegaurded and no longer used.
This is especially salient now that Facebook own user data like pictures and
can profit not only from information, buy sellig photos and other user-
contributed things as assets to be used for commercial purposes.

From the site owners perspective, they want the data. Maybe they sell it, or
maybe they want to provide a nice user experience. Welcome back user, here is
all of your information, we kept it for you so it is not lost. Thanks for
rejoining.

In the end, it really depends on what kind of site and what kind of users you
have. Sites will prob not choose to delete all the information they have, much
to some of their users dismay.

------
mbrock
Why not let users complete their transaction with only an email and payment
info — and then send an optional account confirmation link along with their
receipt?

------
fr0styMatt2
The worst thing about having to register an account on damn near everything is
the security implications. I lost track of the number of unique passwords that
are stored in my LastPass a long time ago. Seriously, the number is absolutely
ridiculous to the point that trying to manage those accounts manually and in a
secure fashion is, I'd argue, too much of an unnecessary burden on people.

------
tempestn
"My bank limits passwords to 14 characters..."

I chuckled at that, since _my_ bank limits passwords to exactly 6 alphanumeric
characters.

~~~
aikah
for me its 6 numeric characters.

------
another-dave
" If you do have password requirements, show them to the user before they try
to make a password. "

& again as help text when they're logging in.

Constantly have to reset passwords on obscure sites because I don't remember
that I've been forced to use, e.g. no symbols. No use just telling me that on
sign-up & expecting me to remember 6 months later.

------
dsjoerg
If you want your readers to follow your advice, tell them _why_ they should,
and not simply _what_ to do.

See what I did there?

Are readers of this piece supposed to follow the advice, like sheep, simply
because they are told to? Or because they will get more usage? Or because it
will make the world a better place? Or some other reason? We can only guess.

------
dzhiurgis
> My bank limits passwords to 14 characters, which is rather absurd.

Similar with Paypal.

What's most frustrating, when you login it lets to enter as long password as
you want. Which is when it leaves you wondering why your password does not
work.

------
jobposter1234
In addition to the other threads, the fact is businesses need contact
information to make money. Upsells, deal emails, etc., are all a critical part
of their revenue streams.

So removing this would cost them a great deal of money.

~~~
lazyjones
> _fact is businesses need contact information to make money. Upsells, deal
> emails, etc.,_

Fortunately, there are plenty of exceptions to this rule. For example, price
comparison websites (I built, ran and sold one) need nothing of the sort, it's
just a mediocre marketing tool (your users are much better at recommending
your product than you are!).

------
z3t4
Most people will actually endure a sign-up process. We are so used to it. But
you should stop asking for an e-mail address! Or make it optional.

~~~
tracker1
Unfortunately account recovery requires a secondary means of contact... I'm
much more likely to give a new site my email address than a credit card
number, phone number or other piece of personally identifying information.

------
TheSwordsman
Who is BenBurwell, and why do I trust his advice?

------
nosferatus
"don't invent your own crypto" I laughed hard.

------
sam_lowry_
My website _is_ special.

------
rendall
Don't tell me what to do!

