Live data from Hacker News

Don't make customers hunt for the Sign In button on your website

blog.stunning.co

111–120 of 213 posts

Re: Don't make customers hunt for the Sign In button on your website

#111
post #38

Earlier quoted context omitted.

Yeah, what ever happened to Create account/Register and Log in? Why have two very different options with almost the same label?

Heh, there was a time when Microsoft’s Polish translators (who I’m mildly convinced are robots in disguise) decided “Sign in” should be translated as „Zarejestruj”. Which is what everyone else called the “new account” button. They managed to fix it since then to a much more reasonable and much less confusing „Zaloguj się”.

>who I’m mildly convinced are robots in disguise

I think Windows translators are real humans, because quality is much better than whatever Bing Translator spits out (seriously, who thought it was good idea to automatically redirect to Bing-translated MSDN pages), but translated completely without any context. For example, task manager now have RAM "Form factor" translated as "Współczynnik postaci"...

Re: Don't make customers hunt for the Sign In button on your website

#112
post #110

This drives me nuts. It feels the same as the insurance company's phone menu asking if you're interested in purchasing a policy or submitting a claim, where the former choice get you an instant human being and the latter a 45 minute wait. In other words, it signals that you're more interested in signing up new customers than serving your current customers.

I'm working on switching insurances this month. 18+ months of being unable to pay online.

If they don't want my money and competitors are cheaper why am I debugging their website to get passed all of their JS errors?

Re: Don't make customers hunt for the Sign In button on your website

#113
post #76

I'm surprised so many folks are saying DigitalOcean is bad at this in the comments. Their home page on a desktop has 2 equally sized sign in and sign up buttons in the top right. The sign up button is filled and the sign in button is outlined. In mobile view it's pretty bad, they still show both buttons side by side but they're buried under a hundred miles of product links. Besides the buttons being pushed so far dow…

I actually thought of DigitalOcean first when I saw the title of the article. I somehow always end up clicking sign up instead of sign in.

Re: Don't make customers hunt for the Sign In button on your website

#114
I am a UIUX product designer, and this was left intentional.

The idea is that benefit of having a better CTA for SIGNUP far outweighs the friction/cost for the obscure SIGNIN.

Existing Users can also be trained and conditioned to look for the sign in. They will not get away since they are existing customer (SaaS).

However, once a prospective new lead bounces out, most likely they will not convert anymore (counting remarkerting aside)

Re: Don't make customers hunt for the Sign In button on your website

#116
post #95

A couple of frequent mistakes with signin which are usually caused by junior product owners/ux persons not reflecting on what they are doing and blindly copying what they believe is the way to do things. - Having confusing language and poor differentiation between the sign in and sign up form. Symptom, users start filling in the wrong form only to realize their mistake. - Separating the password from the email field…

> Separating the password from the email field with an extra mouse click I think they mostly do this so SSO customers do not accidentally enter their company password on the site every time.

This is always still annoying since you type in your email, then get sent off to your SSO page - and they can never be bothered to post your email over, so now you have to enter it again.

Re: Don't make customers hunt for the Sign In button on your website

#117
post #47

Earlier quoted context omitted.

That's to support single sign-on. It checks whether to show the in-house sign-in page or to redirect.

This one is a significant failure of our entire industry. We've somehow accepted that degrading user experience because of an implementation detail is good instead of working together to hide that implementation detail by implementing the necessary browser functionality. We already have technologies such as Kerberos that are supported in every browser and seem like they would solve this problem. In any case, as a web…

It's not obvious to me that it's an improvement to have an extra textbox that goes away moments after you type in your email address (possibly after you've tabbed into it to start typing) or an extra textbox that just stays there unused.

Re: Don't make customers hunt for the Sign In button on your website

#118

Earlier quoted context omitted.

> Separating the password from the email field with an extra mouse click sucks if you are using a password manager. If I understand correctly, the reason behind this pattern is SSO. Most websites are gaining SSO capabilities. Before asking for your email/user, they don't really now if you're gonna login using password, or you should be redirected to an IdentityProvider. I'd be happy to know if there are better patter…

Honestly asking, what's wrong with "Password (Leave empty if you're using {Name of SSO}): ____"? If you are going to tell that may confuse users, I think not having a password field is already confusing the other half, while also not being password-manager-friendly.

Seems like password managers should be able to handle the password being entered on the next page when there's no input on the current page.
Post reply on HN