Web design/development has always been seen as a service, obviously due to the way it's delivered. It takes units of time to deliver a set of qualifications that should be met, rather than producing a physical product that is then delivered. The way it normally works is you talk with a client, they have a set of goals/requirements they need met (whether it's a database being built, a design, or a widget), and you try to deliver them.
This is no different than when you go to a restaurant. You go in, look at the menu (~development services), check out the prices (~rates). You normally learn about the restaurant from a friend (~contact/colleague), and decide ahead of time whether or not you want to eat (~work with) at the restaurant.
So you go in, look over the menu, order your food, wait for it to arrive, and then eat it. Straight forward enough. The difference comes in with the reception of the food (~service/work). If you're in a restaurant, you're paying for the service of them preparing the food, not for the actual cost. You don't go in, order a salad, and they charge you how much the food costs; they charge you for the preparation of the food, and the delivery of it.
So if you go in, eat up your meal, but don't enjoy the taste or experience, what do you do? Do you walk out without paying the bill? No, you don't. The reason you don't is because there is an established trust and relationship between a restaurant patron and the restaurant. When you enter the establishment, and order something from the menu, you are now contracted to pay for the food, regardless of whether or not you enjoyed it.
The reason for this post and analogy is because of how web development services are received. When I develop a design, widget, database schema, PRD, or whatever, I have now started work. We have a contract in place (whether formal or informal) that states/infers that my work warrants monies. I deliver my work to you, and whether or not you are satisfied, you pay me for my time. If you aren't satisfied, you don't return, but you pay promptly without complaint about the services. You don't negotiate, you don't haggle, you pay.
It's in my best interest to perform the best way possible; I don't want you leaving the restaurant (mixing analogy terms now...) thinking the food was terrible, and the service was awful. I want you leaving happy and I want you telling everyone how great your experience was. But if it wasn't; if you weren't happy with the food or the service, you don't just leave or try and argue with the restaurant owner/chef. You can choose not to leave a tip, and choose to go and tell anyone who will listen how terrible the experience was, but you do not leave without paying, and you do not delay your payment.
Web development is based on trust, just like a restaurant business. Your patrons approach you to enjoy your services, you perform those services, and they pay you. It's as simple as that. Clients need to understand that they do not have the luxury of debating and argueing with the services after the fact.
If you go into a restaurant, before you order your food, you can do the following:
- Ask the waiter how good the food is (subjective, obviously)
- Check what the specials are
- Read the menu, see if there is anything you like
- Talk to friends and ask how good the food was, the service was, and how expensive it was
All this being done, you now have a clear idea whether you want to exchange their services/food for your money. Web development should be the same.
The reason's why it's not received with the same level of trust as a restaurant is beyond me, and perhaps due for another post, but for now, I think I've made a descent enough case towards the problems with clients and their perceptions of web development services (especially the paying part).