I'm having a rather bitter affair with my client who also happens to be my boss at office. He is a completely non-technical dumb muggle in terms of application development. The frustrating thing is that he and his ego requires me to put a lot of extra effort in validating and strictly enforcing the user input to be of fixed formats.

For instance, telephone numbers should only be like 1234-123456-12 and people names should only contain alphabets and spaces and no other characters. Feels like the North Korean regime..

In terms of expert UX design, does an application really need to have such extensive unnecessary validations on it's forms? Is it ok to permit the user to enter anything he likes in the input fields? Except SQL injections and JavaScript snippets ofcourse. If so then what argument should I use to convince my client that these extra efforts are completely futile?

  • 2
    This article may be of interest to you: Falsehoods Programmers Believe About Names – JonW Apr 9 '13 at 8:26
  • 2
    It's also worth saying that if your site is used outside of the states phone numbers will follow different formats, as well as names contain accented characters, hyphens etc. If I tried to enter +44 1234 5678 and that is my legitimate phone number, or Harrington-smythé as my surname but it won't let me enter it or continue until it's entered in the 'correct' format I would give up on that site and sign up/purchase with a competitor – Steve Temple Apr 9 '13 at 10:43
  • 2
    A good input system should accommodate names like this :) – Pasha Apr 10 '13 at 0:21

Forcing someone to use a particular format for their data entry, where it doesn't change the actual information, is quite simply poor UX. There is no practical difference between the following phone numbers:

062 123 456 78
06 21 23 45 67 8

So don't try to force someone to use some data entry format that you have arbitrarily decided to use. Especially when there is no value for it.

Try to focus on data as information, not as formats, and you will have more people move ahead with your form. It's hard enough to get people to fill in forms, but every time you tell them that they have to use a different format than what they would prefer (for no good reason), you are simply giving them a (good) reason not to fill out your form.

|improve this answer|||||
  • 1
    Understood! You put it quite awesomely. But on the sidelines, what if the user enters words/alphabets in the phone number fields? How strict should I be to give the user a free hand? I'm not processing this info ahead, just storing in user's profile. Is it good UX design to give control to the user and permit one to, let's say, ruin one's own profile? – CobaltBabyBear Apr 9 '13 at 9:45
  • @AliHaideri It depends on the importance of the information. If the application requires a phone number to work correctly, then it might need to have more validation. – Kris Harper Apr 9 '13 at 13:04
  • @AliHaideri I always try to think about what would make sense if a person were talking to me. Saying "My phone number is 06 BD 123 456" wouldn't make sense, so I would reject that entry. However, you should allow symbols in phone numbers (like +-()) – JohnGB Apr 9 '13 at 15:47

Every time you tell you users they're doing something wrong and can't move forward, you're motivating them to quit. There is no real standard for phone number format, so don't force one on your user. Same goes for dates, names, etc. Form input should only be validated because it's wrong and you are unable to use the information without it being corrected. It's no good for UX, it's no good for conversion and people not filling in the form is no good for your client.

What you should be doing is letting the user of the form put in what makes sense to him. Then, if your client requires a certain format, transform the data you output to your client. Strip spaces and dashes from phonenumbers and put them back in where your client needs them. Same for dates: store the input as a real date and match your output format to your client's requirements.

And remember that your communication with the client is UX too. The client is probably not wrong, but is probably putting these requirements in for some reason he's not telling you. So find that out, don't get angry quite yet ;)

Then again... if he refuses to cooperate and insists on putting in counterproductive functional requirements instead of talking about the why of these requirements (been there, sucks), you cannot have a sustainable and sustained relationship with him. Build the thing, send the invoice, go do something constructive. (but don't tell anyone I said that)

|improve this answer|||||
  • On dates: There are multiple date formats used internationally, and it is not possible to determine the value of a date unless the user is required to enter it in a particular format. – Matt Apr 9 '13 at 13:31
  • True, but that doesn't mean the only way to handle this is with a validation error and it's still no reason to require a certain format (11/11/11 or 11-11-11). You could for instance, after the user entered a date, transform the input into a universally readable format (April 09, 2013) so that the user can check and correct your assumption. In many cases you can make a good guess about your target audience's preference for day-first or month-first. Help, don't hinder. – Koen Lageveen Apr 9 '13 at 13:40
  • The amount of code needed to parse an arbitrary incoming message into a valid date is substantial (google, i'm looking at you) and very error-prone. Add on script-injection measures and multiply this by every input field in your form and you have a huge javascript file. UX is great, but sometimes it's not plausible for the developer at hand. Treat all the UX guidelines as exactly that: guidelines, not laws. Accept the consequences for not following the guidelines and clearly describe them to your boss. – user1884155 Aug 6 '14 at 13:34

Looks like your main problem is communication with your boss. Unfortunately, you cannot ask other stakeholders to care about UX as much as you do, but everybody cares about UX a little bit (because everybody's experienced bad UX). You can build on that to get a more healthy process going.

My main advice would be to get to a place where you're mapping out issues rather than solutions, and to let the solutions come later.

In your case, the issue your boss cares about is data integrity. He wants all phonenumbers to be stored in the database in a consistent format. A fair requirement. You're worried about the UX of filling in a form with such strict rquirements. Since this directly affects conversion rates, it shouldn't be too difficult to make your boss care as well. The point is if you debate unvalidated forms versus strong validation, you're just creating bad blood and slightly missing the point.

If you think about just the problems for a while, you will start to see the solutions that address all of them instead of just one. For instance, you can write an input field with sections for the chunks of the phonenumber, so the user can't enter the number incorrectly. You can parse the user's entered data into a properly formatted phonenumber and show it back to them (to make sure they entered it correctly, perhaps using things like area codes to give additional feedback).

The point is that it's much easier to agree on what problems you have since there can be lots of them. Once you have to discuss the solution, things get frustrated, because you can choose only one.

|improve this answer|||||

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.