Live data from Hacker News

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

blog.stunning.co

161–170 of 213 posts

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

#161
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ę”.

Translators for the Dutch version of Windows 10 are definitely robots. For example, in the save webpage dialog of Edge, they translated “Webpage, complete” to “Webpagina, voltooid”. Voltooid means completed, as in a completed task. The correct translation would have been “Webpagina (volledig)”.

Similar errors are often found throughout programs new with Windows 10 and sentence structures are directly copied from English. I have never found a single error in Windows XP/7.

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

#162

Semi-related: The trend of the not having a log in button and only a sign up button, requiring multiple clicks just to login. I get that less friction for a new user is better being the thinking but I truly hate having to go through multiple pages just to sign in. What happened to having sign in/sign up being on the same page? Seems the simple and easy, as well as lowest friction way of splitting the difference betwe…

I save the login page link in my password manager. Problem solved.

Other people still had the problem, even after you did that. Problem not solved?

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

#163
I just decided to stop pursuing a home loan with a company because of a few anti patterns like this. The first was there was actually no “log in” button whatsoever. You have to click “create an account”, and _then_ there’s a log in link.

The second, more fatal anti pattern is not allowing paste in the password field. There’s simply no way I’m going to memorize random 30-digit password for your website. (I had to use dev tools to actually paste the password). Even though the APR was good we moved on.

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

#164
post #20

For https://sqwok.im , I explicitly placed the login/signup prominently at top right for all users on mobile and desktop because I want it to be clearly visible always. I could see some value in detecting whether the user has already created an account and highlighting the "login" portion like the author has. There’s a business service site I have to log into once a month who’ve hidden the login behind a drop down an…

No login link, just a series of grey lines, even after I enable javascript. Ah, I see you require that I accept cookies just to to view your front-page ...

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

#165
This kind of thing really bothers me - it's like a symbol for how little they care about existing users.

I feel like there should be some specific name for this kind of thing - design patterns that target new users and suck for existing users. Honeymoon feature?

'First hit is always free' feature? Maybe just 'First hit'? I'm bad at naming.

---

"As they approached the city they could see enormous walls surrounding it. Jonathan noticed a guard standing near the entrance to the city. The guard was shouting, “Sign Up! Sign Up! Sign Up!” and then more quietly, “or Log In.”"

https://zalberico.com/essay/2020/07/14/the-serfs-of-facebook...

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

#166
post #71

Earlier quoted context omitted.

It implies that because it’s literally true. Not a complete loss of care, but it makes sense to hide the sign in button because users who are already signed up are already invested, and less likely to abandon the service. The front pages main job is to grow the company by attracting new users, and a sign in button for users who aren’t going anywhere anyways gets in the way of that.

Inconveniencing either current or prospective customers never ‘makes sense’. It’s not like you have a fixed amount of inconvenience you have to distribute.

You have a fixed amount of screen real estate on the landing page. Distributing it to your most important users for that page (prospective users) does make sense to me.

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

#169

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…

They could just check if the username needs to be redirected, and if they do then ignore the password. It wouldn't be that hard. The only downside is the user submitting a password they dont need to, but if you're using js you could post the username first and only post the password if needed. That would be the same exact process, except from the users perspective it would be seamless. You could even have it check th…

I could see a lot of large companies that integrate with other B2B sites recoil in horror with a UI that encourages employees to enter their corporate email address and a password. Many employees would use their corporate passwords.

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

#170

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…

They could just check if the username needs to be redirected, and if they do then ignore the password. It wouldn't be that hard. The only downside is the user submitting a password they dont need to, but if you're using js you could post the username first and only post the password if needed. That would be the same exact process, except from the users perspective it would be seamless. You could even have it check th…

this is exactly the sort of thought process that leads to terrible login flows. yes, it's technically possible, and it works for you.

but the login flow is one area of your product that needs to work for everybody. There's plenty of features that can be tailored to a power-user workflow because they're the only people that will see it, but the sign-in flow is not one of those. any confusing UI in your sign-in flow is going to confuse your least-confident users. and asking people using Facebook Sign-in to enter a password when they haven't ever set a password for your site is extremely confusing. all just to save a couple keystrokes for the most-technically-competent users.

Post reply on HN