Is it lazy or inconvenient not to distinguish between password reset use cases in the UI?

Question

I was recently asked to reset a password due to the fact that the security requirements for the website had been upgraded, and the users have been asked to change their passwords (for those that don't meet the current standards).

Although the user interface simply asked you to provide an email address (to verify that it is an active account) with a call-to-action to change the password, when the email link is sent to my inbox, it was in the format of a 'Forgotten Email' page that had the same flow as if you clicked on the 'Forgotten Email?' link commonly seen at the sign-in page.

Is it simply more convenient to use exactly the same process, or is it simply lazy design or development not to make this distinction as it clearly has some effect on the user experience? Is this a common practice and if so why?

Answer 1

Depending on which application or company asked you for a password reset it is usually a matter of convenience. When it comes to designing these kinds of flows, usually little priority is given, as it would be seen as an edge case. A case like this is not a primary feature of a website or app and is therefore treated with less urgency.

From a UX standpoint I would argue that when a case like this pops up, you should weigh in the following factors: security gain, possible loss (or gain) of trust, development effort. If possible loss (or gain) of trust is high, more effort should be put into designing this feature, even if it will cost a little more development effort. As a designer you should strive to create the most optimal solution, but also be smart on how it's implemented. So cases like these remain on the radar.

In this case it was probably seen as a quick solution, and other features had a higher priority. For many companies, edge cases like this are treated in a similar way, just because they are ad-hoc and pop up randomly and usually press on committed effort. Therefore, usually the quickest way forward is chosen. This usually leaves your app with a solution that works, but is sub-optimal. Even if the designer has made an effort to come up with a suitable solution, it usually doesn't make it. Not only that, it gets put at the bottom of the backlog, or disappears completely for it never to be implemented at all.

Answer 2

It sounds like what most likely happened is they did not want to do extra development to set up in place a different flow.

Now I consider there were two options, one to create a different flow and the second one to do some extra development.

But what would the benefits of a better flow be ? People are familiar with the forgot password flow, it is not a golden path that would possibly have user drop-off the flow so considering that the risk of confusing users is pretty low why would you have some extra dev ?

Yes it is a nice to have and it would be the correct way to do it but from a business standpoint it might simply not worth the effort.

Answer 3

Answers to your questions, IMO are;

• You cannot know if this is a common practice, as it probably depends upon company
• The same goes for the reason it is done that way
• It could be bad UX. Not sure how actually bad, but when user forgets password it is his "fault" and he needs to perform an action. Here user can interpret it is websites "fault" and therefore at least to expect nicely / custom design interface, so some effort from the website