You can't send "forgotten password" links to a single account if you have the same e-mail address, unless the user specifies a unique username. But what happens if the user forgets the username as well? Then you need to reset password on all accounts associated with the e-mail address.
In my experience this happens for a number of reasons, some intentional and some unintentional.
Intentional reasons to trim whitespace:
Users often cut and paste passwords (yes, use of Notepad as a password manager really happens) and the paste operation for some clients adds a whitespace.
Phrase (multi word) passwords are ...
Interesting question. To answer it I think we have to understand what's frustrating to users and then provide some alternate ways of doing things.
Also remember, if you don't need the user to create an account then don't make them!
Users may find it frustrating to fill out a bunch of information in many different input fields. Especially ...
If you feel that people should have some control over their own information, then you should make it possible for them to delete that information from your system.
Since ecommerce sites (at least as I know in the US) have to deal with tax reporting, and in most systems if you delete an account then all reporting dealing with that account is deleted as well, ...
User would normally expect going back to the home page.
The solution to your problem can be a breadcrumb notion which would help user navigate back to the account dashboard instead of homepage.
Find out more about breadcrumb here
Here is a rough wire-frame for the concept explained above
Update: i have extended the answer and added some examples, i might further enhance the quality of the answer if i get feedback
Thought you'd never ask, here are some things to look at:
1. Does the user even need to create an account? Why?
Many product managers/designers fail to ask themselves this important question, it has become one of the largest ...
There are no security problems. If two people share an email account, and one of them has an account on your site, either of them can reset the password on the account (since they both have access to the place where the "forgot username" and "forgot password" emails get sent). Both people have the ability to take control of the account, and that's ...
I like to take informed decisions myself, so I recommend (1). If you keep me from deleting my account (to stop those annoying newsletters, for example), even if I am willing to lose money, I'd be really angry.
The really user-friendly offer (just to mention this :-) would be to offer to transfer my credit (to another store, to my bank). That's what I would ...
I'm sorry for the presumption since I know nothing about your use case, but I'll be the one to say it: don't force them to make an account. Just don't. Users can understand when making an account is necessary. If they expect to use your site without an account, then either you've confused them about what the site does or it's probably possible.
That strong ...
I would expect the logo to redirect to the root of the website.
Another way to look at the problem would be to "replace" the root of the website with the actual account-related content : see Twitter, for example.
After you log in, the home page displays your customized timeline; to the user, it's basically a different website.
Of course, that only works ...
Heavily utilize SSO services.
Add as much support for as many platforms as possible. Even though this is time consuming and compatibility issues increase as you increase the number you support, look at it like you are supporting more platforms (Android, iOS, Windows, Linux) because odds are the user will have one type of single sign on ...
How about just Username ?
Just see how many sites including Stack Exchange, Google, Facebook, Twitter, etc don't show any other kind of salutation. They just show the username, which is hyperlinked to suggest that further profile information can be viewed by navigating to this link.
I would go with the first Option "Warn the user that closing their account will forfeit their credit" but as you mentioned this might create frustration when it comes to real money, even its only cents.
You can reduce this frustration by donating the money to a charity, therefore you can reinforce your brand image also users don't feel like they are ...
It depends on the use case.
If a users wants to delete their account, but they can't, they might:
Create a new account
Abandon their account (never sign in again)
Pester your support with requests to remove their account
All three of these things are bad UX, and degrade the quality of a website. Specifically, in the case of Facebook, having orphaned or ...
In the UK at least, and possibly the whole of Europe there are very strict data protection laws, with some high fines against those that go against them.
The Information Commission Office have a set of data protection principles: https://ico.org.uk/for-organisations/guide-to-data-protection/data-protection-principles/
Personal data processed for ...
While the existing thoughts here are well, there are legal dimensions that may redefine everything you're thinking about — and complicating #1
Credits, in some states, are like gift cards. The value cannot expire and you cannot just drop it without giving the person a way to transfer it into a 'movable' form - like a physical card, voucher, etc.
If you ...
As you mention online purchases, the best is to let people checkout without needing to creating an account. They still have to fill out tons of details for their delivery, just ask them at the end if they want to create an account so they can check on their order easier.
Doing this, you ask it at the right time, when there is a benefit for the user.
I agree with Turch’s answer that allowing multiple user accounts per email address can be a good idea, but I don’t think that a 'less usable' 'special "Recover username"' feature is needed, and I don’t agree with Benny Skogberg’s reasoning that a password reset would require resetting all passwords.
Scenario: On Example.com, two accounts are registered with ...
First, I thought they try to prevent attackers from randomly guessing email addresses and checking whether they are registered or not. Imagine you know that Donald.Trump@yahoo.com is registered to, e.g., craigslist. This might be a great privacy issue in some cases.
This is precisely the reason why so many websites have implemented it that way and that's ...
If users find themselves trying to get to the Log In and Sign Up page by typing the URL in manually than they really must want to get there for some reason. I would first make sure that you have a log out button somewhere readily available on the app so that if they did log out they could proceed to that page. However, I think that you are doing it correctly ...
For administrator or testing mode, the testers usually want to be able to see the website as closely as possible to the user's point of view.
One way to do this is to just highlight the top nave bar a different color (like red or green) so that the tester knows the browser is in impersonation mode, but all everything else is the same so they are seeing ...
You don't want anyone knowing even that someone has an account.
If a malicious actor is searching for info on someone, it could be potentially damaging just knowing that someone even has an account / is a member of an organization.
Each piece of info is a betrayal of a users right to privacy.
To go further, let's say you have an organization or app that a ...
I have three main thoughts when it comes to your question.
1. Don't use the phrase "Upgrade Subscription"
To me, this phrase says: "increase cost of this service". While you may have a very worthy service for your users, that phrasing alone might deter potential upgraders.
Assuming you want to increase sales, emphasize features the ...
For me this would entirely depend on the context.
If your definition of "username" was a user's first and last name, then "welcome..." would be more polite than "logged in as..."; on the contrary, if your "username" was just something the user used to log in, "logged in as..." would make more sense than "welcome...", as otherwise you're welcoming the user's ...
Lots of apps rely simply on a Facebook log in. At this point it's become safe to assume that most people using your site or web app will be using Facebook, so if you're not concerned about users who don't want their account to your site linked to any of their other accounts, go ahead, just use Facebook log in.
However, you should keep in mind that most ...
Type of impersonation
Interesting question! how exactly this might look will depend on the aim of impersonation and the relationship between the impersonator and impersonated.
Few questions might be helpful in devising the right approach: For example, is the impersonation feature required for social networking product or for an enterprise solution? Is it ...
You have to balance how much you are interested in having their email confirmed. Until the user confirms the email the consequences could be:
Not using the app at all
Use only part of the app. Enough to be interesting but hide some features that will make the user want to confirm the email
No app features restriction. Probably not relevant for your case, ...
The logo normally navigates (and is expected to) to the highest level of the websites hierarchy.
Does the hierarchy of the account section depict the home page at the top or the account dashboard?
In general, the user will expect this to take them to the home page - it may be worth adding a notification to say something along the lines of 'are you sure you ...
The whole point of social logins is
to make it easier to log in
to ensure that users do NOT have to remember a lot of different username / passwords
to ensure that to avoid remember all those different ones, they would use the same ones on different sites creating a security risk for themselves
but most importantly: that they don't have to trust you to ...
Often times you need both.
The pop up sign in (or a drop in panel) is the smoothest experience for most use cases. It allows users to sign in without leaving their current path.
But you will also run into cases where you need to land users on a sign in page. In my experience, this should be the exception, not the standard.
One example of the exception path: