In UX, Less Isn’t Always More

A lot of amazing work is being done in the UX space by Luke Wroblewski and others. There is a plethora of great advice about solving UX problems by simplifying forms, even reducing the number of fields down to just a single input. However, in this article I’m going to share a story about an instance I encountered where users actually were looking for a place to input their data, even though we didn’t want or need it.

Can You Reset My Password?

The problem arose when we released our new application. Shortly after launch, support starting getting requests from users to help reset their password. The users would complain that they never received their password reset email.

The form itself was extremely simple; a user is prompted to enter their user name and the system generates an email response with a secure link to complete the process.


Initially we started troubleshooting the form by looking for system errors, however we only found a properly working password reset form. Next we contacted support and asked them to try and collect some additional feedback from users who experienced this problem. Almost immediately we received an email from support containing a screen shot a user submitted, and that’s when we knew there was a problem.


We started logging all of the inputs each time a password reset was unsuccessful and we found that users were entering all sorts of things: email, first name, last name, full name, pretty much anything but their user name.

A Change of Plan

Using this information we decided to change the process. Instead of asking for a user name, we’ll ask for the email address.


Unfortunately, instead of fixing the problem we created a new one. The support tickets came in but this time the message was, “I forgot which email account I used to sign up”.

Knowing we could key off of both User Name or Email, we decided to include both fields on the form. We hoped this would give users the option to use either in case they couldn’t remember one or the other.


Once again, the support requests came in. Even with the addition of the email field, the user name field caused issues. We looked at the logs and saw the same pattern as before: first name, last name, or full name was consistently entered in the field.

A Fix is Found

Before resorting to a fix on the back-end, we tried one more change to the form. Since users seemed to want a place to enter their name, or were simply confused at what a user name was, we gave it to them. We added two dummy fields to the form, first name and last name. Neither field was collected or served a purpose other than to guide the user’s input. The only requirement was that either the email or user name were filled out.


The final form worked successfully, months went by and not a single support ticket came up regarding the password reset process.


Including first name and last name fields removed the confusion around what belonged in the user name field. In addition, there was no need to rewrite back-end code which would have been more time consuming than adding two fields.

There are no hard and fast rules in user experience design, so it’s important to keep an open mind. Frequently less is more and simpler is better, but in this case adding unnecessary steps actually improved the experience for our users.

Header image courtesy of Floriana


  • Pingback: Dew Drop – April 16, 2015 (#1994) | Morning Dew()

  • This is an interesting case study, and a great reminder that the most important user data to design around is your own application’s user data.

    • burkeholland

      Also a good reminder to measure measure measure your application and put some telemetry on that sucker. I think too many times things like this go unaddressed because there is no visibility into what is happening after the application gets deployed. In this case, the support system caught the UX issue. In other cases, users just wouldn’t use the app and you would be left wondering why adoption was so low.

  • habix

    imo that’s a poor aproach. Just because the users are sheeps in this case, it doesn’t mean you need a sheppard.. A simple “this username is not valid.. click here if you forgot username” is much better. Reset password by name/last name is ridicolous, unless you got a system with 10 users. You can’t measure UX on users that don’t read the messages.

    • brtdesign

      and if they forgot username – what information is used to reset that? The email address was mentioned in the article as being problematic…

      Preventing mistakes is better than relying on validation messages to correct them IMO.

      Users don’t always read the messaging – thats all part of the game – and being a shepard is entirely appropriate in this instance.

      • habix

        That is supporting lazynes and root of more mistakes to come when entering other data..
        Why use ‘username’ as login info in the first place then? Use email.. and we have 0 problems and a nice UX. You can still have backup systems (2nd email, sms reset, secret question, personal verification, etc) to complicate it a bit more, just for users that lost access to their original email.

        We had to remove all automatisation from UI on one of our ERP project, because users didn’t even think anymore what they are entering..

    • William H

      You must measure UX on users that don’t read messages. A user is a user regardless.

      • habix

        You have user that don’t read red, bolded, possibly pop-ed up ‘user not found’, after they requested something (password reset in this case), but expect him to go with the complicated “solution” suggested here?

        Just because this team eliminated the support tickets doesn’t mean the user experience is now better. The only thing important in password reset (at least for me and probably many more) is speed of getting it over with.. the less time it takes for me to regain login, the better..

        Having to fill a form that looks more like a registration page can’t be a solution (even if you have to enter only 1 data our of 4 – you still have to read the instructions).

        You can take whole buss of grandmas and grandpas to find out that both iphone ux and android ux is useless.. or you can ask the users and get a totally different opinion.

        Measuring UX is not putting a log on a button click event and calculating succes vs faliure.

        • remotesynth

          You make a lot of assumptions in your criticisms. The biggest is that you are personally representative of the user base of this application and therefore your own preferences are reflective of the user base. To me, the point of this post was about not boxing yourself in with rules and being willing to go where the needs of the users take you regardless of whether you personally think they are “doing it wrong.”

        • William H

          I don’t necessarily ‘expect’ this solution to be the appropriate solution as I don’t have all the data. I do agree that the elimination of support tickets doesn’t always equal a solution and could be an indication of a newly created problem. If the typical user model for this specific application doesn’t read red bolded text, then they are the model the UX should be designed around and inherently measured against.

    • Ruben Dröge

      Security 101, you do not show anyone messages about whether a user name is correct or not.

      • habix

        1998 security 101… and even if you have all 4 textboxes they can type it all wrong, as remember the userbase in this article doesn’t read at all.. the whole concept of webpages is: get a response for a given request.. if you don’t read what the respond is….

        • Ruben Dröge

          It might be an old way of thinking about security but old does not equal bad, see discussion in

          And to get back to the UX piece here, merging User Name to Username /might/ be a game changer as well.
          It’s all perception…

          • habix

            Exactly.. I already posted the suggestion to merge the fields. Also the validation message can be generic: “you typed something wrong”.. or if you’re even more pessimistic “you should recieve email within 5 mins, else you typed something wrong”

          • Ruben Dröge

            I could live with that 🙂

  • habix

    “The final form worked successfully, months went by and not a single support ticket came up regarding the password reset process.” – thats not same as UX. If I clicked reset password and you would show me the last creen, my first thought would be “no, I don’t want to create new user”; clicked back thinking I miss-clicked. Then I would click reset again… my 2nd thought would be “they want me to enter all this data, just to reset the pwd?”. In the end I wouldn’t read the text, I would enter all the data, thinking this UX was one of the worst.

  • It is a good idea to improve the password reset UX, because it is often more used than we think.
    The final form is definitely better than the other ones.

    However my first impression is: damn I have to fill all thoses fields? I don’t even remember all of them!
    I know, I’m wrong because it is clearly written in the description: “Enter your user name or email”.
    See that little 2-letters words “or”, nope missed it!
    It easy to skip the description, most people I know (tech or non-tech) do that!
    And I’m afraid some people can be scared with such form.

    You have to consider the sad case where the user doesn’t even call support and prefer to leave to service or create another account.
    One of the last blog entries on the Scott Hanselman talks about that:

    An idea might be to try multiple screens with limited choice on each, examples:
    – do you remember the associated email -> yes/no -> 2nd screen
    – type your email + link “I don’t remember my email”
    – …
    So that you maximize ways to recover your account, and the user is not scared/lost.
    A state diagram is usually helpful to describe possible screens.

    You also have to think about the security issues involved with too many ways to recover an account.
    It might leak data such as which account is registered on the platform.
    A first response is to finish the form with a message “an email has been sent” whether that’s true or not, without specifying it of course.
    It’s not perfect and it’s always related to other security practices and platform specificities. Also a good place to show support contact infos (tchat, phone, email).

  • vb_guy

    Overkill. Should simply provide messages when/if they enter invalid data.
    “Invalid Email Address”… “Email/User Name not found”.. etc

  • Rebecca Riley

    I’m not sure I agree with this. Sure you got the result of zero tickets, but I don’t think it’s the best experience. Now a user has to process 4 fields instead of 1 (a heavier cognitive load) – and you’re wasting the user’s time by having them input data which isn’t relevant at all and it isn’t very clear that you don’t have to input all those fields. That isn’t a better experience for your user, it’s a better experience for your support team.

    I’d also like to know what percentage of users used the form successfully compared to ones that didn’t. In other words, was the first or second form used more successfully than it wasn’t? If that was the case, then you’re making the experience worse for most users instead of better with more unnecessary fields.

    Instead, why not have some form validation setup where a username can’t contain “@” signs or can’t have certain patterns like “” to prevent entering an email? And then, like a few others suggested, having an option where you don’t remember your username. Or change usernames to accept emails or usernames since you already have the emails on file. If they don’t know what to put, then they’re probably looking around for a help link so I don’t believe that they won’t read or see an “I forgot” or “I don’t know” option.

    Mailchimp has a pretty great login form, helpful notifications for username recovery, “I forgot” links, a link to “Trouble logging in” document, and an option to reset via email or mobile phone (and it’s hard to believe they wouldn’t know which number they used). It has 2 options for recovery and one or two fields (for phone) for input max. To me, that is a much better experience.