Forms?

There’s one thing I’m seeing more and more of – and that’s bad practice on forms. For example, a client of mine decided that on their registration form they would have over 20 fields. They had no excuse for it – they really only needed 3 or 4... But they got greedy, and now no-one fills in their form. Simple. So in the past week, I’ve put some effort into finding resources on forms, the technologies, and best practices etc. Just so I have some ammo next time I argue with project managers/clients!

Step 1 - Objective
What does the user want? What do they expect? Do we really need so many fields? What’s the real objective of this form? All these questions are imperative to designing and producing a form that will actually get users typing. So often I have clients who want 10-15 input fields, when all they need is two or three. So it’s a case of asking WHY before even thinking about design.

I’ve been listening to Ryan Singer – a designer at 37Signals, the creators of Basecamp, Highrise etc. These guys obviously pay close attention to their users needs and requirements, and pay a lot of consideration to their processes before any IA/design/development work starts. I think what’s impressed me is that a registration form, or transaction process doesn’t always HAVE to be the same. Just because your competitors have name, email, date of birth, first cat’s name – doesn’t mean you have to as well!

Check out:
This book

Step 2 – Language
I don’t mean French and English (although translations will play a part in the design process, label positions for example) - I mean the way you speak to your users. Having them signup with your company, or buy a product is a privilege you are being granted with - not the other way around! So make it easy, use your copy to guide the user through the process. Start with easy, no brainer questions, like Name or Email... get your user invested in this process. Most importantly for me, and this is something we often consider an after thought – is how we approach errors. If I spend 10 minutes completing a form to be told “NO – YOU’VE MADE AN ERROR” - I’m going to be pretty pissed. I’d never say that to someone’s face, who’s sitting beside me completing a paper form – so why do we do it on the web? So consider how you notify your users of an incorrect field – and ask them politely to return and amend.

Step 3 – Design
So I’m calling it step 3, for argument’s sake – but there are obviously loads of architecture considerations which should be undertaken beforehand. Let’s be honest here, designing a form should be quite an easy process if the aforementioned steps are done correctly. A clear and clean use of language, clever consideration and use of technology and a healthy portion of CSS will ensure that your form is easy to navigate – and friendly to use. Forms, above all, require the designer to work with their front and backend developers – so do that, if you can.

Check out:
www.rosenfeldmedia.com/books/webforms/
www.smashingmagazine.com/2006/11/11/css-based-forms-modern-solutions/

Step 4 - Development
Standard and technically ‘simple’ forms are a thing of the past. That’s arguably a shame for the developer – but great news for the user. New developments on the web mean we can use AJAX for things like checking the validity of usernames, emails or postcodes. Doing this means our users don’t have to click submit to see they’ve made a mistake (see above). But, above all – we can use technology to reduce clicks. A fantastic example of this is PayPal;

When you purchase something on PayPal requiring a credit card, you are presented with a seemingly standard e-com form, but with one difference. There are pictures of the supported card types (AMEX, Master Card, Visa etc) - but no indication of anything clickable. You are they invited to enter your long number, and from that, the form indicates to you what card you’re using (seeing as the starting integer indicates the card type).

It’s simple, it’s straight forward – and it reduces our clicks by at least one. Which is never a bad thing!

Check out:
www.shauninman.com/archive/2007/09/10/styling_file_inputs_with_css_and_the_dom

Most of this information is taken from the FOWD presentation of Ryan Singer. Watch and listen