The Perfect Data Model, Gone to Hell (MI) Due to Bad Web Form Design

Dec 29, 2010   //   by Karen Lopez   //   Blog, Data, Data Modeling  //  7 Comments
Sample form rendered by Mozilla Firefox. (Clic...

Image via Wikipedia

I don’t normally work in the UX/UI design world, but I know enough from constantly filling out web forms that too many designs out there are destined for a special ring of data Hell.  If you’ve followed any of my web form rants on Twitter, you may have heard this before…but it should be repeated.  Seth Godin recently blogged about his frustrations with annoying web forms for data collection:

The problem with letting your web forms become annoying is that in terms of time spent interacting with your brand, they’re way up on the list. If someone is spending a minute or two or three or four cursing you out from their desk, it’s not going to be easily fixed with some clever advertising.

I realize that many web designers live in the US and hate the fact that they have to complicate their beautifully simple designs with all these weird non-US things like regions, postal codes, country lists, etc.  But if their organization does business with non-US customers or data, they need to realize that the design must support these wacky international requirements.  

One of my favourite resources for good web form design is a FREE eBook by Graham Rhind on names and addresses in web forms  Graham specializes in internationalization and address formats, so he is the go-to guy for these sorts of things.

It’s not just internationalization, though, that causes web form design to go all to Hell.

My pet peeve is referenced in Seth’s post: using drop downs to force a user to choose from a list of hundreds or thousands of values.  These are annoying because drop downs usually require acute mouse skills as well as waste time.  Developers love drop downs because they don’t have to do much data validation – if it’s in the list, it’s supposed to be good data.  However, optimizing a developer’s task isn’t always the the best for customers who have to use the form.   In fact, I’ve come to realize that the more we optimize development, the more we have to take from the end user.  It should not be that way, but I see it over and over again.

A typical frustration I’ll face is a form that collect address information.  It will have fields in the same order that we’d typically see a mailing label, something like:

  • Name
  • Address line one
  • Address line two
  • Apartment#
  • City
  • State
  • Other
  • ZIP
  • Country

…with State and Country being a drop down of all the US States and Country being a list from somewhere on the web of a list of countries.  There might be some magic in the country list that then causes the list of states to change based on the country select.  The problem is that as one fills out the fields from top to bottom, he hits the State field before the country field.  He has to jump down a few fields to find the right country, then jump back to the drop down.  If he is very fortunate, this change in country does not require a complete refresh of the form so his data might still be there…or it might not.

Or, the web designer might think that we foreigners should use the Other field to fill our foreign state or province.  They might also beef up their data quality be requiring a State in the drop down, even if it only contains US states.  We users won’t know until we try to submit the form.

When I use forms that require me to pick a US State, I usually go with OH or OR since they are “close” to my Province Code of ON.  Sometimes I pick Hell, Michigan because it’s just as good of a place as any if web form constraints force me to enter bad data.  I’ve always wondered, though, how that impacts analytics for that data.

My other peeve is when Birth Date must be filled in via a drop down.  First one must pick from a list of months, then a list of dates 1-31, then a list of Years going back to the ice age….or somewhere near my birth year.  There are much better ways for web designers to collect and validate data.  I’d love to see business management sit down and enter a couple hundred addresses into their web forms to decide whether the forms are “good enough”.

When users find annoying forms, they are more likely to enter bad data.  Don’t ask me how I know this…let’s just say that there are many records of me out there, happily describing my nice home in Michigan, where I celebrate my 13th birthday ever year, in my apartment number 0000, which also shares a ZIP code with a popular TV series from the 1990s

Love your data; don’t torment it in the hands of end users before it even gets to you.




Enhanced by Zemanta


  • Oh and while you are on these pet peeves, let me add a couple of things.

    Data format: There are many conventions for entering telephone numbers. Developers be nice and indicate the format you want it in. There are a few ways of entering dates. Give us a clue. If you are asking for year of birth, there is little point in the drop down starting this year. Choose a nice value, drop to there (in the middle of the list) and make it easy for us old folks.

    Hiding the login button. The trend seems to be that you are expected to be magically signed in. I have spent lots of time (WSJ are you listening) trying to find the sign-in.

    Use services to fill in data that can be filled without making the user do it. If you think ormalization, my guess is that there is an FD from post_code to city. Use normalization thinking (without necessarily fully normalizing the database) to use FDs (Functional Dependencies) tp discover candidate services for autofill.

  • […] This post was mentioned on Twitter by Karen Lopez. Karen Lopez said: The Perfect Data Model, Gone to Hell (MI) Due to Bad Web Form Design […]

  • Nice rant…I mean post. There are lots of things that bug me about forms and I read Seth’s post and yours and agree that business users and executives should be made to sit and fill out the forms multiple times to see how it actually works.

    Being in Canada with Postal Codes, I hate that websites don’t tell me if they want the space in the middle or not. Some do, some don’t and they generally don’t tell you. They should allow the user to enter it either way and then deal with it in the code. I recently filled out a form that did this and I knew because I didn’t enter the space, but when it showed it to me for validation of the address it had the space. I remember sitting here and going: “Huh. They actually had the form set up so they could take it either way…nice.” It’s a small thing, but when you add that to all the other things like phone number format, date formats, etc; filling out one web form can be annoying. Developers and businesses need to think about their forms from the user’s perspective and not just what is easier for them.

  • […] I have business users all the time tell me that they are 100% sure that they have no international data in their systems.  When we dive in to see what they actually have, they will find all kinds of "workarounds" that end users have done to wedge that data into their applications and database.  In fact, I’ve been guilty of that myself. […]

  • As a developer (and occasional data modeler, requirements analyst, architect, maintenance guy, etc), I wholeheartedly agree.

    To add another one to the list, if you’re asking for someone to enter information from a bill or other snail-mail form, show an example of where the data is located AND the format your electronic form will take. A banking site recently got some ‘affection’ from me because their sign-up form expected a different format for the account number then what they displayed on the paper bill and it too several guesses to make the form accept it.

    And another: My last name has a hyphen. Not only does this tend to uncover forms using rudimentary validation logic, it’s also uncovered a couple systems where restrictions from a backend system were thrust upon the wider world through the web portal because someone decided it was easier/cheaper to force the constraint on the end user than build the logic into the front-end system or systems integration.

    Despite living in the US, address forms are a special one for me. It is absolutely amazing the level of differences that one can find in data structure, expected use patterns, field order…I’ve used (and unfortunately helped implement) systems that would automatically look up state/province information from the postal code on one screen, but only allow 5-digit integer zip codes on another (good luck if you were in the 0nnnn set).

    And if we’re going to talk strictly interface issues for a moment, the standard keys for data entry on the web are the tab (next field) and enter (submit) and possibly space (check/uncheck). Anyone that spends a lot of time interacting with forms will be likely to use these, not the mouse. People who are not used to interacting with web forms will not have preformed, consistent habits. Choosing a non-standard set of keys and re-tasking the standard ones is guaranteed to trouble the experienced part of your user base (who should form the portion that require less support costs and training) and provide limited or no advantage to the inexperienced portion.

    Some habits I’ve picked up:
    – I tend to hit the submit button on forms right away if I don’t see any indicators for required fields
    – I enter my state code by hitting the N key to “shave and a hair cut” (NC is 5th alphabetically)

  • I think re months, states, and years it works well so long as you don’t have to actually scroll manually but simply type and it auto-scrolls.  One thing that really annoys me with this approach is where the programming is lazy in allowing one to only type the first character.  For example, as you start to type, say, “O” for “Ontario,” the focus goes to “Ohio.”  And, naturally enough, you go on to type the “n,” BUT the interface propels you to “Nebraska.”  I hate that.

  • […] guy doesn’t build UIs, but he does use them. And he doesn’t like some elements of them. I don’t normally work in the UX/UI design world, but I know enough from constantly filling out […]

Leave a comment

Subscribe via E-mail

Use the link below to receive posts via e-mail. Unsubscribe at any time. Subscribe to by Email