How to be a good client…
While developing websites we have been trying to develop some good habits and more importantly serve our clients to the best of our abilities. However as with any industry where budgets, time constraints and differing aesthetic and technical values collide there can always be room for improvement in the client-developer/designer relationship. So with that in mind I decided to compile a list of do’s and don’t for clients – I shall write one for developers and designers too… in the interest of balance of course!
Do…
…research in the area of the market you’re aiming your site or application at. I tend to recommend this especially for e-commerce sites or websites that are designed to be more than just brochures. I can get alarmed by clients that think they know a lot about web technology because it usually means that I have to temper their expectations to fit with their budgets. I tend to be more frightened of a client that doesn’t quite know what they want – this spells disaster for the the client and possible hell for any developer/designer. You can have a great site but if it has no clear purpose and no solid business plan backing it up someone’s going to be disappointed in the end.
The client will think they got a bum deal from the web company and said company ultimately has to look back and reflect on whether their work meets the standard of their portfolio. So in short research your competitors, potential partners, developers and designers. Make sure you have compiled a sizeable amount of information including aesthetic details and whatever technical information you want to gather perhaps draw mock-ups of interfaces or put together a mood-board be sure you have a clear idea of what you site will do and who you think its for at the outset. If you don’t have the time to do it yourself many self respecting development firm will go through a “scoping” phase with you to find out your requirements – I always try to convince clients that a short period of research and/or application prototyping can help to throw a light on issue or potential problems
…know what you want … see above! Knowing what you want is only half the battle. Hopefully once you’ve established the basics you will move forward with your designer and developer to signing off on a scope/requirements document. Be aware that once you sign off and put you money in escrow or pay a deposit there is no going back. If you want to change any part of a web scope during the build phase you could be in for delays and possible run-ins with the build team.
…avoid “scope creep”. You can avoid this by building in review periods so for example we like to recommend a review after the Design + Wireframe, Alpha and Beta as well as at the end of the testing phase, to check functionality is as per the requirements document. If you wish to change things or talk about additional features you may be able to persuade a developer who has been keeping good track of his time. there may be time in the development schedule for that lovely new jQuery menu that you saw. Ian Broom over at Weboo is very careful to build in extra development time into his quotes so that should there be any “scope creep”
…pay attention to the design because you definitely don’t want to have to go through this process twice. Just as with the basic features and aim of the site you must decide upon a design that appeals not only to you but more importantly to your target audience. You may get it perfect first time but more often then not you will always be thinking of ways to improve it. Perhaps the user interface needs tweaking, perhaps some elements are a few pixels out of place. Remember that all of these issues can and should be solved by your development team but don’t get too frustrated if you’re not happy. All websites evolve over time and if you use a good content management system you have effectively given yourself an easier time when it comes to the point where you need to redesign your site.
…test, test and test again. If you draw up a set of user scenarios to try to anticipate how your users will interact with your site or application you will have a set of testing parameters that you can use at every phase of the project. Keep it minimal at first and then expand the tests scenarios with variations to see if your site throws up any bugs, glitches or annoying tendencies. Don’t leave to us poor developers to think of all the possible bugs – get feedback from a select group of testers. Perhaps you could ask friends, family or business associates you trust. Scenarios can help during wireframe and scoping to help determine what the core functionality should be. Poll Daddy is a free survey service that allows you to create polls and surveys easily so that you can see if your site is getting the desired results.
Don’t…
…get “locked-in”… There are many lazy developers out there who will recommend only one type of system or something completely custom coded with poor documentation and messy code. Be sure that you see a demonstration of what they recommend before you opt for it. Make sure they use open source technology if you go for a custom coded option e.g. if your developers code in PHP rather than say .NET this is usually better (the are many open source programming languages and CMS frameworks). Make sure that a full listing of the code and documentation around it is available so that you can easily pass work onto another developer if you need changes in the future.
An example of bad systems analysis is the London Stock Exchange – programmed by Microsoft and Accenture using C# and .NET technologies with expensively licensed Microsoft SQL servers. After launch the system slowed down and then crashed on the day Freddie Mac and Fanny Mae were taken over by the US government losing billions. This meant that the LSE had to entirely replace a £65 Million investment using Linux the Open Source alternative which should have been recommended in the first place given that it already runs rough 60% of the net. See this article for more info.
…forget your users because ultimately they are who your are doing this for so re-read the Do’s!
…forget that your are a user too! Whether the site is merely a simple portfolio or brochure or perhaps its a huge web application you are probably going to be the one that manages it or else someone else you’ve hired will be. If its difficult to use, hard to change, and has an unintuitive interface you will make life very difficult for yourself in the future and ultimately expensive. Choose the right CMS based on the needs and skills of your administrators as well as your requirements. Squiz.net has one of the most powerful CMS’s around and because of its scale and complexity they offer comprehensive training on all areas of it but it comes at a price so you’ll want to make sure whoever you train is likely to stay with your company given the large investment. We offer a similar training service for those systems we recommend whether it be Google Apps, Analytics, MailChimp or Wordpress and we keep a documentation area online separate from the site from which all admins can access teaching materials like videos and wiki guides. If your developer doesn’t talk about documentation, support or training then ask otherwise you could be paying for simple updates or massive changes unnecessarily.
…worry if you’ve done you research well and your developer has used the right tools. Your site should be fit for launch and ready for any future updates, upgrades and changes. And remember perfection is impossible only evolution so just make sure your site/application/design/business model can evolve over time to cope with changes in the market and in technology. A good site is never finished when it launches just like a good business can never stop moving.
I’ll post more to expand on certain points I’ve made here but this is just a starting point for clients. I’ll post a developer/designer version drawing from the wisdom of others as well as some of our own here at Second Variety. Thanks for reading and I hope this helps to build a good relationship with you development and design team. If you think I’ve missed anything please leave a comment and I’ll add it!
Tags: client relations, do, don't, how to
