Blog – The Architect’s Log

Odds are this has probably happened to you before: You painstakingly fill out an online order form and it malfunctions in some way. Maybe you hit the “submit” button and nothing happens or you get a “file not found” 404 error. Maybe you’re trying to enter a message on a contact form and the text box isn’t big enough to accept your answer. Worse yet, maybe you submit your information, nothing happens, and you’re left to wonder if the information even made it to it’s destination.

Once any kind of web form has been created, it needs to be thoroughly tested before released to web site visitors. We do a good deal of testing on the development end, but it’s a good idea for you to conduct testing as well, from the user end. Here’s how:

1. Attempt to submit the form before completing any information.
   The form should respond by preventing submission and assisting the user with the completion process.
   
   
2. Test each field individually.
   Did all the field validations work? For example, if a field is noted as “required”, were you able to submit the form without supplying this information? Were you able to submit a piece of information in the wrong format? (Ex: an email address formatted without the ‘@’ symbol, a phone number that is missing digits, etc.) Are field character or selection limitations in place and sufficient?
   
   
3. Review the user instructions.
   Are the form instructions clear? To they give enough instruction to reduce the possibility that the user will encounter an error message?
   
   
4. Review error messages.
   Do the error messages correctly describe the problem? Is there enough information to assist the user in correcting the problem?
   
   
5. If present, does the CAPTCHA work?
   A common type of CAPTCHA requires that the user type the letters of a distorted image that appear on the screen, before a form is submitted.
   
   
6. Does the form function without the use of Javascript?
   If Javascript is turned off in the browser, there should be a secondary mechanism to handle form validation.
   
   
7. Review the “Thank You” page.
   Were all fields collected as planned? Were provisions made for handling blank fields? Does the language on this page properly confirm submission? Is the language sufficient to indicate any “next steps” for the user? Is the language consistent with company branding?
   
   
8. Test response emails.
   Review any email messages sent to the user and/or the administrator after form completion. Did messages arrive at their intended destinations? Were all the fields properly displayed?
   
   
9. Test the database.
   If response information was sent to a database, did it arrive properly? Are provision in place to reject incorrect or malicious data?
   
   
10. Test logic and conditionals.
    Were all calculations correctly executed? Were any special rules (if this, do that) correctly applied?
    
    

Be sure to consider (and handle) the following possibilities:

1. Incorrectly formatted or fake email addresses.
2. Misspellings and misinformation.
3. Submitting information to early in the process.
4. Abandoning a process before completion. (Either on purpose or by error of their browser/computer/internet connection.)
5. Incorrect data types. (Supplying a date in the format 7-1-07 when the format 2007-07-01 is needed.)
6. Errors in imported, submitted, or stored data.
7. Other silly and random user mistakes.
8. Form spam.

Things Netdrafter does to minimize the possibility of user error:

• Print directions to assist the user.
• Require specific web form fields.
• Validate web form fields before accepting the information.
• Provide form field examples.
• Use consistent and intuitive program logic and flow.
• Follow our own form design best practices.

Also see:
Netdrafter’s 6 Tips for Effective Web Forms

Trackback URI » Comments RSS