Don't make customers hunt for the Sign In button on your website(blog.stunning.co) |
Don't make customers hunt for the Sign In button on your website(blog.stunning.co) |
Ooft.
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?
Insurance (in my experience at least) seems like this astonishing scam where they collect premiums for years and then as soon as you try to collect on a claim they refuse to pay and cancel your policy.
This makes it very clear that 1: fitbit wants me to use the app, and 2: fitbit wants to sell me stuff more than they want to help me.
I've peeked into the dev tools to see how Tailwind is used there. And since I'm advocating against using Tailwind, this page seems to be a perfect example what problems it brings to the table. Plenty of elements had to use custom classes to randomly overwrite some Tailwind classes here and there (like .display-3 and .main-headline) or completely avoiding Tailwind, like for the #recovered-revenue-main.
It just shows that Tailwind did not solve issues it was claiming to solve, at least in this project. And I guess it must be a pain to maintain this project since PR reviewer and other coworkers now have to know Tailwind by heart to figure out quickly what really got overwritten and why.
I know it is a blog but still it's part of the website and as a customer I should be able to access "Sign In" with one click from any page, right?
1. The website timed them out.
2. They pressed “log out.”
3. They/their browser deleted their cookies.
4. They are on a different device.
5. They are in private/incognito mode in a new tab or window (say after clicking a link to confirm their email address at signup).
To the extent the solution works at all it only works for (1) and (2).
SaaS websites, don't make visitors hunt for what the hell the service does.
It's somehow hard for many SaaS websites to clearly explain what their service does. I often have to dig into multiple pages to figure out what the service does.
https://www.miscbeef.com/birdcrab
(blatant self-promotion)
There’s a business service site I have to log into once a month who’ve hidden the login behind a drop down and it’s really annoying!
This is why you should avoid making a SPA unless you know what you're doing, if you're going to use one at least put a spinner or something so it's clear the site's doing something.
The site doesn't have much traffic right now and is running entirely on serverless lambda, it's likely you arrived while it was idle and had to wait for it to wake up...
> at least put a spinner or something so it's clear the site's doing something
def should improve the loading state for when it hasn't woken up yet.
Back in the day it was the other way around. Sign in was primary and sign up was secondary (often accompanied by something like "don't have an account? Sign up"). You just know some busybody UX person saw that and argued this was bad for new members. Well now you've just screwed it up in the opposite direction. Well done.
Why do companies like Twilio make me put my email in first and hit the arrow before i can even type in my password? (it confuses me and the password manager) and adds at least 5 seconds to the login process.
I ask... why?
Because of lazy UX implementations of SSO.
You'll see logins like Google, where this is common. If you submit an email that has an SSO authentication associated with it, they can redirect you to the right auth form.
However, for everyone that's not an SSO login this is a worse experience.
I don't agree with it personally, I think it reflects an organization where marketing is prioritised over customer happiness.
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)
Who in the world came up with this?
But nothing can beat MS Teams "Close" document preview button, which once clicked, uncovers chat "Call" button. Add some laggy nature of Teams and you call the entire channel/chat just by trying to close an opened document with too many clicks.
If I'm signing in, there's a good chance there is no cookie saying I have ever signed in.
- 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 with an extra mouse click sucks if you are using a password manager. Doubly so on mobile where using password managers involve a bit of fiddly interactions. Having to do this twice sucks. If you do this, at least have one of the fields in the dom tree but hidden so that it gets filled with one click via your password manager.
- Not making the login form password manager friendly my not sticking to conventions for field names for this.
- Defocusing input fields in the middle of typing login information
I guess i'm in the minority these days but I like to keep strong passwords in my head.
This usually happens due to some side effect of the login page being absolutely fucking massive and not fully loading or executing before I start to fill in the form, then one of three things usually happens in order of frequency:
1. cookie banner blocks input and defocuses
2. it defocuses for no apparent reason (I suspect MVC "rendering")
3. it "helpfully" re-focuses on the first input element
Only login I regularly use that does not suffer from this problem (or any others!), is HN:
https://news.ycombinator.com/login is 1.07KB
Causes only one secondary HTTP request to favicon at 7.66KB which doesn't interfere with the page in any way.
I use Surfing Keys, a vim-like plugin for browsers. When inputs defocus unexpectedly while I'm typing all of the navigation shortcuts kick in and it's like "roll a d100 to see which random negative consequence you get." Usually I at least lose the page that I'm on and I have to start the form over.
Browser url-bars are shooketh...
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 patterns here but I think password managers should get a bit smarter and work with this trend.
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.
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 the username as they type, and lock the password field if its not needed.
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.
I think they mostly do this so SSO customers do not accidentally enter their company password on the site every time.
I like this more than other sites where I have to find the right button between different login options (sign in with google, sign in with facebook, sign in with sso, ...) and then have to type the company name ... whatever might be the choice the admins did there that time ...
I also think that approach was initially created by Yahoo! So they could shown the user's avatar on the password page to prove authority. Not sure whether that still is a thing somewhere, considering that a recent trend is not to verify whether an account exists ...
Signup is a big thing with lots of stakeholders and interest. User acquisition is an easy metric to track for business health. Everyone wants to push not-logged-in users to sign up.
Ownership of logging in was much less clear. It's not a full time job for a person or team in the same way customer acquisition is. So you put some buttons/links on the page, but then there's no single owner of them to get pissed off when other teams start moving their shit around.
(The other aspect here is that the website was a declining platform compared to the apps, where a not-logged-in user is much more captive and there's a more obvious single "login or signup" landing page point. On the web most media sites, at least, try to provide SOME sort of preview/partially functional experience version of the logged-in view, which wasn't designed with a prominent "SIGN IN" button in mind.)
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/Attributes...
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 existing account, so you go along with the new account thing and use another email address.
Before you know it, you have 5 different accounts and don't remember which ones you use for which servers.
Yes, there is a "use existing account" link, but it's not prominent, the "What should everyone call you?" textbox with the big "Continue" button are the only psychologically viable option unless you've already gone through the whole process of involuntarily creating many accounts.
And if you do this to people just because their cookie went stale, then is this really a customer that you want to remind that they don't use your service enough? A customer that is happy paying the bill every month but doesn't use a ton of resources?
It reeks of really bad optimization of metrics: do everything possible to increase conversions, at any cost to the rest of the business. That sort of desperation is not good for retention.
I don’t get it either, this is why I stopped reading the LA Times (I should probably cancel my subscription). On the other hand, I can’t remember the last time I logged into NYTimes, it just works (that’s why I read it daily).
At this point, I just naturally assume that newspaper websites are unusable. They certainly give ad-blockers a workout. Once you get through all the cruft candy I especially like the paywalls with the several second delays.
Some of this I suspect may be related to browser privacy settings these days, as the "Remember me" checkbox to avoid hitting 2FA for my bank accounts basically no longer works for me either these days? Some 3rd party cookie collateral damage?
Password manager makes it pretty painless anyway, though.
I don’t understand the problem, if people want to try or sign-up for your service they’ll locate the signup button. That’s a one time problem. A hidden login button just annoys existing customers.
My feeling is that this is down to testing without privacy in mind. Your site might be fine, but others aren’t so a minority of users will clear cookies at the end of each browser session. That’s not a senario most will test for or experience.
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 between new and existing users.
https://mixergy.com/paul-graham-design/
Kind of along those lines.
While they say "Don't make customers hunt for the Sign In button...", they've implemented "Sometimes make customers hunt for the Sign In button..." which is arguably worse. It's good that someone else has identified this as a problem (it's annoyed me for a while) I just don't think this solution knocks it out of the park.
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 they stop doing these dark patterns.
Rather than find a more in depth/better designed solution, it's easier just to remove the "sign in" button and any "confusion" that might cause for users who would otherwise complete the sign up workflow. If their A/B testing indicates that removing the button improves sign up rates, that's exactly what they'll do.
It's super-annoying and short-sighted - not to mention lazy - but this kind of micro/over-optimisation of behaviour on the web has been de rigeur for at least a decade now.
A better approach would be to try to understand why "confusion" around sign up/sign in is happening - i.e., what's the real reason having both buttons/links on a page decreases sign up rate? Root cause the issue and you can fix the real problem in a way that probably doesn't annoy your customers. That's effort though and most customers probably don't care enough to complain about the annoyance of hunting around for a sign in button or link.
I’m not sure why a site would recommend making an extra click easier when it’s not necessary at all. If someone has ever logged into your site, they should get a login page so they don’t have to do some extra tap. This is triply true if your site is frustratingly slow to load.
Also:
Support password managers. Your damned custom login page BS might be cute in design but sucks for usability. If your site doesn’t work reasonably well with a password manager I won’t come back. US Bank lost my business this way recently.
Related: Have sane password requirements and limits. If my password manager gives you a 32 character password, don’t bitch because it doesn’t contain a number or uppercase character. It’s 32 characters long and unguessable, that should be enough. Also... if you fail because there is an underscore or ampersand, you’ve failed.
Why have two very different options with almost the same label?
And with the overwhelming complexity of current front end web tech, it seems there's not much time left to put into thoughtful user experience.
Nowadays a large chunk of online services’ objective is more to “engage” you and sign you up to some bullshit newsletter or sales call rather than actually provide you a service that you’d be happy to pay for. Marketing has become the primary objective, with “deliver value to the user” a neglected side-effect.
This would be the same as excusing falling bridges and crashing planes on whoever's money speaking louder.
If the people who actually _build_ anything – the actual developers, engineers, etc. – don't build things up to standard or can't manage executive expectations, there's no hope; we'll live in a capitalocracy ruled by MBAs.
People building things need to care about the crap they ship because they'll have to use it too. There's way too many people in the industry not caring, just happy to collect a paycheck.
I keep my windows in a grid and I end up just making my window wider because it’s easier than using their god forsaken hamburger menu.
The login button is just hard to find on the homepage.
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...
It seems loyalty is for suckers these days. It used to be that long time customers and employees got rewarded. Now they are being punished and exploited.
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 down on mobile, is that design really hard to find the sign in link -- specifically on desktop?
Interestingly enough Stripe has only a sign in button in their nav bar https://stripe.com/ for non-logged in potential customers. I just checked with an incognito window. I guess they determined users who sign up mostly come from the main area of their home page or through another page reached from their nav menu (products, use cases, etc.), not so much from a sign up button near the sign in button.
You can get to "Sign In" by clicking the burger menu and scroll sufficiently far down, or by searching. You can't find it by simply searching on the front page, or by just clicking the burger menu. I guess that's what people mean by "having to go hunting for the sign in button".
Interesting, I don't see that here. I wonder if they're A / B testing layouts and my IP is locked into a specific choice.
If I open the page in Chrome or Firefox I see both buttons side by side and then if I slowly make the window smaller (starting at 2560 width btw), it eventually gets to the point where both buttons disappear inside of the hamburger menu when the buttons get too close to the left nav. The sign up button is never visible on its own.
Which browser do you use?
Why, github, why?!
Prioritize features (ideally based on studying user behavior), and make those features present and accessible. Hide the rest, if necessary, behind some menu system or toggle.
The minimalism trend (perhaps a reaction to the early amazingly busy Amazon UI?) has gone too far. One great (bad) example of this is Parabol.co. We use it at my company, and it provides just the right set of features we need. But for providing a relatively small feature set, it seems to go out of its way to make it difficult to know how to use those features. I only mention them because they are a good example of this, but there are countless other services that have user hostile (or frustrating) interfaces.
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.
Ideally there was one single email address field and a combined sign up / sign in button that either took you to the password or new account creation dialog. If you're concerned about privacy implications, do realize that user signup forms leak the very same information.
The end result feels slightly off. Like I can't say what should be happening, but what is actually happening feels not quite right.
I'll avoid Slack as much as possible unless they fix this evil UX.
The reason it happened is b/c I use email aliases for stuff I sign up for, and sometimes I forget them...
It's otherwise very hard to convey that you care about existing customers so this seems like a no-brainer.
Perhaps these are similar symptoms.
precisely
(sorry for the !!!'s. but this one really gets my goat)
In many cases the homepage login forms took years to come back, after we got to a point where virtually every site was all-HTTPS on all pages. In some cases they never did.
Why seldom used? Because you stay logged in for a long time.
Is UX bull on this issue? Maybe, but if you are logged in for a long time, and then you come to log in when you've been logged out, it might be that you accept the lousy experience on this issue because you actually want to use the site... all that said I wouldn't care if the UX research suggested it was a good move. I wouldn't do it (on anything I owned, I would just argue against it if asked to implement it)
99% of sites don't have so many features and sections that they'd need to omit some of them from the landing page. But for some reason they think replacing UI elements with screen-filling fancy animations and a lot of empty space inbetween is somehow a good thing. I never saw any upside in this.
I have a short attention span and am easily distracted, and modern UI trends are catastrophic from my perspective. I don't care about a fancy "hero area", just give me a menu bar that stays in the same place and gets me anywhere I need.
Azure Active Directory does not make it easy to do this, with the way you have to explicitly whitelist post-back URLs, or else you get the dreaded login.microsoft.com 401 page of death, where you have to parse out information buried in the query-string to determine why you didn't get redirected properly (usually it is a trailing slash on the URL... %2F)
Anyway my name is remembered on my company SSO form, and I never sign in as someone else.
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.
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"...
Especially given that I have some insider knowledge on how large publishers translate tech books and the way they do it is, in one word, awful.
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.
The problem is when you have a bunch of enterprise customers and you're not sure which custom login to use, and you dont want to list all your clients.
Ideally, this is solved by the client company telling its employees to use an internal link that authenticates and redirects. Though I'm sure not all clients are capable of this, and still want to use SSO. In that case, I think my solution is much nicer than requiring a two step login.
I was able to directly link this page however, which I bookmarked:
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 website operator you can mitigate this. Have separate pages for SSO/non-SSO, dynamically hide the password field if the username is associated with an SSO provider, or just ignore the password field and have a subtitle along the lines of "leave password empty for SSO accounts".
It seems rather straightforward to me, from their example, to de-emphasize the "Sign Up" button and prioritize the "Sign In" button for someone who already has an account.
1. Less likely to abandon your service than prospective users
2. by far less likely to even see your landing page, since they’re usually already logged in.
In this specific context, your existing users are the less important ones.
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 any suggestions you have for password managers to improve here though. I can't think of anything short of a .well-defined login route.
> 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.
(Just don't forget to donate, if you have the means.)