We are a custom web development company, and as such, we are constantly building new websites and new user interfaces for clients that have not been done before. That's the whole point of our existence - it is custom, not prefab.
The problem arises when clients ask us to build something and so we go through all of our motions of documenting, wireframing, recurring meetings, development, testing, etc. We do our best to make sure that what we are building is what was promised and quoted. We also try to make sure it will be easy to use. But inevitably, something that we built one way could arguably have been implemented in a different way. The original way it was built is not wrong, and is certainly usable. But now, after the site is built and everyone is using it and the client is starting to get some feedback it has now become apparent that if we had only implemented that feature differently it would be better.
This is very common and happens all the time. How many times has Yahoo or YouTube changed functionality on their sites to make things easier or more streamlined for users? Of course this is all par for the course in the world of custom web development.
And so it always strikes me as odd when a client comes back to us and says this: "The functionality you built should have been implemented differently and therefore it should be considered in-scope (i.e. free), since it was built wrong initially through your own short sightedness." Ok it doesn't exactly happen in those specific words, but you get the idea. We built something that didn't exist previously, and now that the client is actually using it, they have different ideas about how things should work than they did initially.
When this happens we grudgingly proceed down the path of meeting with the client and showing them the wireframes and the initial documentation that the client signed off on, and explaining that if they wanted it to work differently they should have said so much earlier in the process. This is usually met with something like "well you're the experts, I can't be expected to anticipate what problems users will have."
Let me try to put this in terms that perhaps will be more familiar to people. If I hire a contractor to build me a custom house. I meet with the architect and get everything laid out and designed how I want it, and I sign off on everything before construction begins. I make regular visits during construction and do my walk throughs and confirm that everything is going as planned. After the house is built, I move in and realize that the window in the family room is in a bad spot because it faces south and the glare from the sun makes the TV hard to see. The window needs to be moved, obviously! So I go back to the architect and the carpenters and tell them that obviously that window is not in a good spot since the glare from the sun makes the TV hard to watch, and obviously I can't move the TV since the couch I have is a sectional and obviously it can't go anywhere else. So it is very obvious that the window needs to be moved, and I'm not an architect, so how was I supposed to know we would have this problem, so the window need to be moved and I shouldn't have to pay for it. Yeah right, I'd like to see anyone pull that one off and get that window moved for free.
This is the point I am making. With custom web development, we actually do anticipate many things and build as much as we can so that it is intuitive and user friendly. But those things go unnoticed, it's only the specific features that appear to function "wrong" that stick out and make clients think it should be changed for free.
Custom web development is not cheap, you need healthy budgets in order to build something that will be successful, and something that you can afford to change around after users start using the site and you get some real world feedback. Honestly, a custom web development budget should include room for usability testing, focus groups, test marketing, soft launches and reworks. But more often than not these things are not included in the budget and clients expect the web developers to anticipate these things and build something that won't need to be changed.
Before I get flamed for not using an Agile methodology, let me just say that we give our clients a choice between Agile and Waterfall. The problem is that Agile costs more, and the clients that I am specifically talking about in this article (the ones who want free changes after launch) are not usually willing to pay for Agile. They want a fixed price up front with a fixed scope so that they know exactly what they are paying for.
I don't really have a solid conclusion here. Most of it is just venting, but a small part of me hopes that this is read by someone who will treat their web development endeavors more carefully, and budget appropriately.
No comments:
Post a Comment