Clients are always asking me for registration forms. From course registrations to downloads and online newsletters, getting an interested party to get in touch is the instant call for a form on a webpage.

The catch to all of this is that, over the years, not one client has been able to articulate what that form is going to do for them in literal terms, also known as “when I click Submit, what happens next?”.

Hint: the answer is not “um, stuff?”

Top questions to ask when “I need a form on my website” comes out of a client’s mouth:

1. What information do you want to collect? (Tell me the fields in the form)
2. How much of that information is mandatory vs. optional? (Which form items do I flag as required? What error checking is needed?)
3. What happens when a user clicks Submit?
   • Who receives the information? (People or person)
   • How is the information saved? (Flatfile, database, email)
   • The user receives what feedback? (Assuming success – confirmation message on the same page, a thank-you page, a pop-up)
   • When is there additional follow up? (Are you contacting the user yourself once you’ve processed their info? Does the system send an email immediately?)
4. What services are you using with this form? (Paypal, ConstantContact, [insert your service here])

And then there’s my favourite question: “when do you want this live?” (Inevitably the answer is “this afternoon!” – but that’s a topic for another day).

One “simple” form turned into a big production in the end: when the user submits the form, a link to a product download is emailed to the user, the information from the form is recorded into a database, and a notification email is sent to one of a list of contacts. I should have asked little details like “what are you doing with this information once it’s in the database?” because later additions included :

• “how do I know when they filled out the form?” – add a date column to the database
• “how do I get the e-news registrants into my mailing list?” – the e-news option should really be feeding a different database table entirely
• “Add new registration dates!” – gee, wouldn’t this form populating from a database table populated by another form that the client uses to manage events be convenient?

It’s a snowball gathering speed downhill.

Conclusion: unless you want to be like me, cursing your retroactive short-sightedness as you edit a form for the 16th time, ask a lot of questions when your client says “I need a form on my website!”

They’ll appreciate it in the long term, but you might want to bring bribes to smooth that interview process in the short term.

Or maybe I should just create a form to let them select their options…