Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
How to collect web design requirements from customer?
- Thread starter zqlpzq
- Start date
- Sort by reaction score
Sit down and talk to them, in person, if possible.
If not, conference call web WebConference, and you take lots of notes. Remember one important fact, don't get overly technical as that's expected of you, never of them.
Start with:
1) Ask for all branding materials (graphics, PDF with logo, marketing literature)
2) Ask for results of any surveys, usability studies or interviews they may have conducted to determine the direction of their web site
3) Ask for a summary of basic expectations (no matter how vague) - never critique it, just accept it and say thank you and keep it as your high level view of what you plan on doing in the future, your "prime commandment". If the client has a detailed listing, the gods are in your favor and use it (see "use cases" below).
You then meet with then again after you do the following:
1) Create a few scenarios describing from a user's perspective what they want to do, and how to accomplish it (referred to as "goal based") and discuss.
Example: You are traveling to Seattle for your job next week and you want to check on the amount you can be reimbursed for meals and other expenses.
It could be a phrase, sentence or even a parapgraph but the key is for you extract your own technical requirements/design considerations based on these short but sweet client scenarios. 10-30 of them is common on a typical job.
2) Discuss each scenario you've created with the client, and create "use cases". Instead of being short and summary, all this means is expand a scenario to include all the details of how users will interact with the site to accomplish that scenario.
Your list of use cases really is the "requirements", i.e. the fundamentals of how the site will function from a user's perspective. Do not discuss design, interface or layout in a use case. Just focus on the sequence of interactions between the user and the web site.
Once you've got that written down, you have your requirements.
Next steps include:
Content inventory
Identification of information auditors (content providers)
Hardware inventory, development platform
Prototyping
and so on...
-jim
If not, conference call web WebConference, and you take lots of notes. Remember one important fact, don't get overly technical as that's expected of you, never of them.
Start with:
1) Ask for all branding materials (graphics, PDF with logo, marketing literature)
2) Ask for results of any surveys, usability studies or interviews they may have conducted to determine the direction of their web site
3) Ask for a summary of basic expectations (no matter how vague) - never critique it, just accept it and say thank you and keep it as your high level view of what you plan on doing in the future, your "prime commandment". If the client has a detailed listing, the gods are in your favor and use it (see "use cases" below).
You then meet with then again after you do the following:
1) Create a few scenarios describing from a user's perspective what they want to do, and how to accomplish it (referred to as "goal based") and discuss.
Example: You are traveling to Seattle for your job next week and you want to check on the amount you can be reimbursed for meals and other expenses.
It could be a phrase, sentence or even a parapgraph but the key is for you extract your own technical requirements/design considerations based on these short but sweet client scenarios. 10-30 of them is common on a typical job.
2) Discuss each scenario you've created with the client, and create "use cases". Instead of being short and summary, all this means is expand a scenario to include all the details of how users will interact with the site to accomplish that scenario.
Your list of use cases really is the "requirements", i.e. the fundamentals of how the site will function from a user's perspective. Do not discuss design, interface or layout in a use case. Just focus on the sequence of interactions between the user and the web site.
Once you've got that written down, you have your requirements.
Next steps include:
Content inventory
Identification of information auditors (content providers)
Hardware inventory, development platform
Prototyping
and so on...
-jim
I have been struggling with the same thing since my workflow has increased.
As SirWeb said, I find ideally you need to have a face to face with people. Especially people who may not be very web literate. There are a lot of things you need to explain to them, and I find they just don't always take it in if you are talking to them face to face. I have had clients who know exactly what they want, are computer literate, and can do all communications through email. But more frequently it's the direct opposite. And using only email to communicate with those clients ends up costing me time and aggravating me.
I spent a day visiting other design sites, and reading various blog articles related to how a client should prepare for web design work. I rewrote these into a simplified 'checklist' type article for the client that I give them before we agree to any estimates/timelines etc. All of the items SirWeb mentioned are in that document.
I also did a ton of research on 'terms of service' documents as well. I noticed a lot of people make sure to mention the clients responsibility for supplying information, and how it can/will affect the time/cost estimates of a site. I give them this after the consultation, and after they decide they want to use my services. They get the document before I start the actual work.
A lot of people I deal with just aren't that internet savvy and still like to see hard copy documents. I find supplying them with the documents I mentioned above really helps get the point across.
I am NO expert yet by any means. But this just what I have learned in a short time. Preparation is such a key element. For both the designer and the client. And if you don't get a handle on it, it WILL end up costing you money and time.
As SirWeb said, I find ideally you need to have a face to face with people. Especially people who may not be very web literate. There are a lot of things you need to explain to them, and I find they just don't always take it in if you are talking to them face to face. I have had clients who know exactly what they want, are computer literate, and can do all communications through email. But more frequently it's the direct opposite. And using only email to communicate with those clients ends up costing me time and aggravating me.
I spent a day visiting other design sites, and reading various blog articles related to how a client should prepare for web design work. I rewrote these into a simplified 'checklist' type article for the client that I give them before we agree to any estimates/timelines etc. All of the items SirWeb mentioned are in that document.
I also did a ton of research on 'terms of service' documents as well. I noticed a lot of people make sure to mention the clients responsibility for supplying information, and how it can/will affect the time/cost estimates of a site. I give them this after the consultation, and after they decide they want to use my services. They get the document before I start the actual work.
A lot of people I deal with just aren't that internet savvy and still like to see hard copy documents. I find supplying them with the documents I mentioned above really helps get the point across.
I am NO expert yet by any means. But this just what I have learned in a short time. Preparation is such a key element. For both the designer and the client. And if you don't get a handle on it, it WILL end up costing you money and time.
Just from the poor grammar and little to go on from the OP, i will assume that nothing said here will actually sink in.
It seems like whats been said so far applies to people who know what they are doing in terms of business and web.
And from what the OP has said that cant apply to them.
More than likely, though I wish the OP would chime in, this is just a typical "I wanna make web pages, help me to do it" instead of the atypical "Ive got a big client coming up, how do I get them to let me do my best work?"
It seems like whats been said so far applies to people who know what they are doing in terms of business and web.
And from what the OP has said that cant apply to them.
More than likely, though I wish the OP would chime in, this is just a typical "I wanna make web pages, help me to do it" instead of the atypical "Ive got a big client coming up, how do I get them to let me do my best work?"
He's apparently Italian, so you shouldn't let his grammar affect your judgment.
Couldn't agree more... For some reason, people think that this stuff is easy. Take a few classes at night or read a few books and you've got a whole new career in just a few months!
The problem with computers is that there's no capital costs. You can build a program and spend nothing on it other than your time. If it appears to work, then you start selling it. Who cares if it's actually engineered to scale well, or has good i18n or accessibility characteristics, whether it's been unit tested or has maintainable source code?
I wonder if there are financial forums somewhere where somebody posts: "I wanna be a fixed income analyst for a big bank. I'm taking an accounting class at church on wednesday nights. What else do I need to do?"
No, this is not easy and the advice I offered is for professionals in the business, and notice everything I said had nothing to do with actual design aspects and not even development. That's up to the OP to figure out on his own, the major point I am making is it helps to have a process in order to figure such things out. I explained that process.
As to assumptions, remember the old (I think, "Bad News Bears") movie? The coach writes on the chalkboard, "Assume" and explains to the group, "You know what happens when you assume, don't you? You either make an ASS out of U or ME." Careful, folks.
-jim
As to assumptions, remember the old (I think, "Bad News Bears") movie? The coach writes on the chalkboard, "Assume" and explains to the group, "You know what happens when you assume, don't you? You either make an ASS out of U or ME." Careful, folks.
-jim
Who didn't notice? lol
But seriously... Doesn't mean that the advice given isn't any less useful to those who actually do want to know
But seriously... Doesn't mean that the advice given isn't any less useful to those who actually do want to know