Changing the way I start a project

Over the years I have refined the ways I go about not only building websites, but the planning of them.

How it used to be done

I used to present my clients with a list of features and the associated prices. Not all the features, of course, as I narrowed things down based on my conversations with them, but a pretty hefty list nonetheless. My clients then had to do a lot of sums, weighing up of one feature against another and still had lots of questions. I would guide them through the options so that they could finally make an informed choice for themselves.

How has it changed?

The real issue was that I was being hired to do something my clients weren’t good at or, in the most part, even interested in – they wanted me to tell them what was best!

I remembered that when Steve Jobs returned to Apple in the late ‘90s, one of the changes he made was to reduce their product line by 70%. This made it easier for people considering buying an Apple product:

1. Was the machine they were buying for professional or home use?
2. Was portability important? If so, take the laptop option. If not, the desktop machine would work better.

The choices that were important to the consumer were there, but the other, more technical decisions were made by Apple.

So any choices I give my clients are kept to things they care about: feedback on look-and-feel design, being a good example. The rest, they’re paying me to help them with.

Initial consultation

My role has become as consultative as it is technical. I start every project with a sit down (or a Skype if that’s not practical) over a good cup of coffee. We’ll talk about things like:

• Business goals
• Target market
• Existing marketing strategies
• Resources (both budget and who’ll be looking after the website and how often)
• Timescales

Following that, I spend about a day (sometimes longer, if the project is particularly complex) putting some documents together. These include a document summarising what work will be done, a project plan, prices, timescales, etc. and another more technical document detailing exactly how I recommend the website be built.

This gives the client a nice overview of the website they need in order to achieve their goals with the resources they have, as a technical reference point for anyone else who might be involved in the website in the future.

Better all-round

This approach saves a lot of time for everyone, allows my clients to leave all the technical stuff to someone who loves it, and focus on the things they’re most interested in.