Graham Rhind, a noted expert on international data, has written an ebook on designing and implementing better web forms for better data quality.
This 76-page ebook is free for download and use, something I greatly appreciate. The fact that he has taken the time to document his experiences and recommendations, then provided this advice to the community reflects highly on his professionalism and desire to stamp out bad design.
I’ve blogged before (Belief versus Truth, Real world vs. “Business” Rules) about my frustrations in trying to do business with organizations who insist upon data rules that make no sense. Graham has, in this ebook, done a wonderful job describing the problems faced with poor web form design. However, I believe his work can be easily applied to other design decisions such as database design, UI design and even paper form design.
Contents list:
- Author’s note, acknowledgements and disclaimer
- About the author
- A state of denial and beyond frustration
- The solution
- Data quality and your form
- Knowledge
- Data storage
- Personal names
- Mailing address or street address?
- Dynamic data collection forms
- Data validation
- Rapid addressing
- Multilingual or unilingual? Languages
- Clarity
- Element layout and tab order
- Required fields
- Drop downs and other multiple-choice form elements
- Move the onus of formatting from your customer to your form: avoid overtaxing your customers
- Feedback – holding a dialogue with your customer
- Check your spelling!
- Test the form!
- An example
- The dynamic world – maintenance
- Dos and don’ts in your web form – a checklist
- Do
- Don’t
It is possible that many of the forms and data collection devices were forced down the path of bad design due to a poor or incorrect data model. I’ve reviewed plenty of models that require ZIP Codes with only digits, name fields that are only 25 characters long, or honorifics/titles that allow only Mr. or Mrs. as their valid choices.
I’ve also seen beautifully correct data models that are widely ignored by developers who produced odd, misleading, and dangerously incorrect form fields anyway. This is yet another example of why professional data management requires that resulting as-built artifacts be reviewed for compliance to the original design. All other professions have this requirement, yet somehow the data management profession seems to always skip this critical step.
I highly recommend that you immediately download Graham’s book, then start reviewing your models and modeling standards to ensure you aren’t making the same mistakes he demonstrates. I know I’m doing that today.
Go get it. Leave your comments here at InfoAdvisors.com about any additional items you’ve seen in bad data model or form design.
