Live data from Hacker News

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

blog.stunning.co

81–90 of 213 posts

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

#81

This is so common nowadays that for many sites I have the direct login page bookmarked. It indirectly implies that once you sign-up, the company stops caring about you. At-least for me.

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.

While that may be the case (I'd also argue that the front page should be a welcoming place for existing users), showing me that you value your existing users is a great marketing move.

It's otherwise very hard to convey that you care about existing customers so this seems like a no-brainer.

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

#83

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 This is useful if you support authentication methods other than password > - Not making the login form password manager friendly my not sticking to conventions for field names for this Instead of relying on heuristics based on field names, it's also possible to annotate the field with the autocomplete attribute https://developer.mozilla.org/en-US/docs/Web/HTML/Attribut…

You can still separate them and have a hidden password field for a password manager to bypass the other page or pass it through to the next page.

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

#85

Github hid their sign-in button and added annoying animations. Why, github, why?!

This pisses the hell out of me becuase, due to my privacy settings, I end up on their homepage a lot. Evidence just for records: https://imgur.com/a/HfF9vUJ

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

#86

Discord is bad at this. When you receive an invitation to a server, you're presented with a textbox that reads "What should everyone call you?" and you're unknowingly creating a new account. Then you're asked your birth date and then for your email. You type your email and it's already used, obviously. By this point you don't want to go through the whole process of deleting your browser history to log into your exist…

I think I have 4 discord accounts for that reason

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

#87

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 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…

Most websites I've used where this is a thing, definitely don't do this. All the projects where I dealt with PMs / designers insisting on this they would not even had a clue about what SSO was or how it impacts their UX. There are plenty of websites out there with sane login flows.

Passwords work off well publicized naming conventions. That's why they work on the vast majority of websites. The problem is junior developers not knowing that is a thing getting creative with naming things. No-one on such projects even thinks about testing this or pointing out to their PMs that this does not work. 9 out of 10 times you'd get the response to "please fix that". Because why would you not.

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

#88

Earlier quoted context omitted.

The same Vanguard that could have millions of dollars of investments in your account? What’s the appropriate time out?

I don't think the criticism is the logout time, it's the fact that you have to hunt for the button. The logout time only exasperates the problem.

[deleted]

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

#89
post #5

This is becoming more and more common with major sites, and it’s really bloody annoying. Some are putting “Sign In” behind some tiny dropdown in the nav, not just grayed out or small but invisible unless you hunt for it. They know exactly why they’re doing though, and I think OP is preaching to the converted. Those doing this don’t need a tutorial explaining how not to do it, they need to lose money (users) until the…

I don't understand. Why is it to their advantage to have their users struggle to log in?

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

#90

Earlier quoted context omitted.

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.

I don't think making the user read instructions is the solution. Most (myself included) will begin typing before they finish reading. The current trend to only show the password box after the username is provided doesn't have to be bad for password managers. I use loads of sites that do this (so they can support SSO) and they just use hidden form fields so the password managers know what to do. I'd be curious to hear…

The Oreilly learning platform does this. Email and password field on the same page and a message under the email field

> Using Single Sign-on (SSO)? Simply enter your company email address and click sign in.

Seems simple enough to me as a user, not sure how most people interact with it though or how many companies A/B test these things.

Post reply on HN