Questions to ask a client before beginning a website

Question

I am aware of this question which deals with the technical aspects of website construction, but I was unable to find any place with suggestions on knowledge you must obtain from a client before undergoing a project. As someone who freelances on the side, I think this could be incredibly useful.

What important questions must one ask the client (and require an answer to) before undergoing a website? or, in other words, What must you know about the project before starting it?

This can range from "When do I get paid?" to "How many pages will the site be?". I believe this is relevant to programming because you must know how to communicate with your client to get all the information necessary before you can begin programming. If not, downstream changes can put a serious delay on the project from things not hashed out beforehand.

Thanks!

PS I plan on maintaining this question with an aggregation of the top voted answers (and hopefully you will all help too! :)

Answer 1

I think the most important question is what is your budget?

Answer 2

• Requirements. In writing. Everything that they ask.
• Performance - how fast the site is expected to respond
• Capacity - how many users to handle (in a day, hour, etc)
• Scalability - how fast the user base will grow
• Usability - what browsers to support, what kind of users: tech savvy, kids, etc
• Deployment - hosting, what server OS, server limitations, virtualization
• Support - what is expected of you to support it for next year
• Ownership - who owns the end result, selling, leasing, partnership
• Internationalization - if there's an intent to support multiple languages

Edit: added Internationalization

Answer 3

• How should we handle discovered requirements? i.e. something that was not stated as a requirement but really is a requirement.
• Which requirements are really desirements and not strictly necessary?

Answer 4

I'll add:

• Release Management and Prioritization. A scheduling of releases and their content. Possibly a prioritization of macro features.
• Mockup definition. Using a mockup tool I'd design in the first phase of the project all the screens of the application. I'll ask customer to accept/reject these mockups and I'll ask them to use as guideline of the application

Answer 5

On the UI Side, for a big project I'll split the job into multiple parts. First, prior to even taking the job, I'll document the requirements, audience, and technical limitations. Once I've gone back and forth with the client to get things right, I'll quote (and bill) a design phase (not technical) where I'll do nothing but wireframe the UI and document the site's structure/flow/navigation patterns. Upon completion, I'll final bill that phase, hand it off to the client, and bid (with documentation) to begin the application development phase.

Sure, this allows the client to leave me before I get the chance to do the big $$$ work, but it's never happened--clients appreciate the communication and believe it or not in 10 years of work I've never been involved in a dispute about scope creep.

There's a non-technical side to this argument. Ask them offbeat questions to find out their personality...it's as important as the technical requirements. Through these questions, find out their level of detail, organization, knowledge of the web, personal preferences, etc. Are they high-maintenance....don't ask them that one directly! If I get a hint that I have a potentially "challenging" client, I always bill hourly so I don't lose my shorts doing tech support.

Documenting the timeline is important, especially if you're moonlighting. If you're freelancing, you can't be doing re-writes when your 9-5 expects you to be writing code for them!

If you're doing websites, get SEO in writing so the expectation is clear. I've had a client hold up payment because Google didn't pickup their site for a few weeks...even though SEO was never part of the deal. Document not only what you will do, but what will be additional. From a marketing point of view, nothing is impossible...it just costs more.

Finally, have a good support/warranty and honor it. My personal policy is that I'll fix any bug in my code (excludes errors from CMS entered html) at no cost to the client for two years. Sure, it's made a little bit of extra work, but I'm also turning away work based solely on referrals--so it must be working.