Freelance web design - how do you estimate hours?

July 7, 2009 1:01 PM

Freelance web designers - what factors do you use to estimate the number of hours you'll spend on a project? I'm looking for examples of reasonable rough estimates (based on scope).

I have some freelance web projects coming up, and I need to estimate hours to determine a rough project budget. I've found lots of great Metafilter threads on rates, but the archives haven't turned up many sources to help me figure out how many hours I should budget.

I realize that this is highly personal and depends on a million things, from the developer's experience to site scope and how particular the client is. I haven't done a great deal of web work yet, and what I have done has been either small + simple (done in a weekend or two) or huge and sprawling over months and multiple revisions. There's also a pretty steep learning curve with this stuff, so time spent on past projects where I had to figure things out from scratch won't necessarily equate to future projects where I have more experience under my belt.

So, I'm hoping to get a ballpark idea of what other designers estimate, then adjust from there.

- What information do you need from the client at the outset to estimate how long a project will take?
- Is number of pages a good starting point? If so, how long would a 10-page site take versus a 100-page site?
- Or, do you estimate differently based on programming language? (ie, using PHP might mean more upfront coding, but time spent is less tied to page count).
- Or, does it make sense to split time based on project phases, allotting hours for initial planning, creating sample layouts, coding, and testing separately? If so, what are general guidelines for time spent in each phase? What are the most logical phases to include?

(If it helps: I am an experienced graphic designer, so things come pretty naturally on the design end, but I'm new to web work. I am pretty solid in XHTML/CSS and can do basic stuff in PHP/MySQL/Wordpress/Flash)

posted by Fifi Firefox to computers & internet (7 comments total)

My extensive experience in a previous life spent managing such projects and teams of people can be summed up as this: (1) Break it all down as much as possible, and ask each team member how much time their small-size pieces will take; (2) compare these estimates with their previous projects and adjust accordingly, usually upward; (3) total the estimated hours.

And then (4) double the estimated hours.
posted by rokusan at 1:21 PM on July 7

double the estimated hours

This. I was taught to call it a "safety factor" but I've always thought of it as a "necessary and inevitable factor." It can and will help you keep your sanity as you're tracking down those niggling bugs.
posted by ThatRandomGuy at 1:49 PM on July 7

i would say triple your estimate, even if you think it's already high :)
posted by jacobsee at 2:34 PM on July 7 [1 favorite]

Generally you are going to get some sort of basic spec for work. This will generally be a very rough functional spec. In the past I have added detail to these in order to make my initial quote and used these as underlying assumptions for the fee estimate.

I go two ways on the estimation front. Some say that getting overly granular actually makes your estimation less precise (more room for error). But writing down everything you need to do is a very valuable exercise.

So usually I'd do something like:
Design Phase -
* IA Doc (1)
* Front Page Design (2 designs)
* Story Page Design (2 designs)
etc.

But I still just estimate for the total design phase. Right now do the best you can, you can't get better at this without doing it so just take your best swing and be prepared to vastly overbid and likely also screw yourself a bit. It comes with the territory.

After you have come to relative terms on the job in general and your fee then it behooves you greatly to do a detailed statement of work. This is where you specifically detail what you are going to do and what you will get paid to do it and is the real underlying contract. Consult an attorney fluent in these matters and see if they have some good boilerplate. Changes to the SOW should require change orders and re-estimation. The SOW saves your ass when the client goes off the rails.

Number of pages is silly, unless you're doing each page by hand with a different design - Number of Types of Pages makes sense. You may want to get familiar with a PHP based CMS like Drupal for complex sites and my personal fave for simple sites FrogCMS (Actually I use the RoR app its based on.

Language shouldn't matter, your client should expect you to be fluent in whatever technology you are using so assume fluency - you can pad for learning curve in your estimate but you should be eating any learning you're doing unless its some off the wall technology.

It absolutely makes sense to estimate based on phases. Frequently design and development phases are broken out separately. Again this saves your ass a bit because it gives you bail out points if the deal goes south.
posted by bitdamaged at 2:35 PM on July 7

Oh what also may help is don't estimate in hours - most people are piss poor at this, estimate in days or even weeks.
posted by bitdamaged at 2:37 PM on July 7

I prefer to go with a set cost rather than hours, especially when things have to be learned which add to your skill-set which can be applied to future projects. You still need a rough estimate in your mind of how long it will take versus how much pay you're looking for though. However something like a 'minimum cost/timeframe, but not to exceed' contract is more agreeable than '$x cost/hr and it'll be done when it's done', the client has no idea how much it's going to cost in the end. Include a maintenance clause in case they want further work done or bugs fixed.
posted by hungrysquirrels at 2:45 PM on July 7

I break it down into two phases: Design and development.

Design: basic concept layouts, look/feel sort of thing. Specify the number of concepts you will show them. This is more or less a flat fee.

Development: This part scales depending on the size/complexity of the project. Assume you will be receiving finalized content. Specify exactly what it is you will be doing for said price.

In my estimates, I put down costs but it's really based on a time estimate and hourly rate. The time estimate is based on the set of assumptions I lay down, but should specs change mid-way or if they are really revision-happy, there is wording that says "This is an estimate and not a quote. Stuff not covered in the estimate will be charged at the rate of $N/hour. I will notify you if changes in spec will cause me to exceed the estimate by 10%. "

As for timelines, I write down something like this:

July 1 : client submits finalized content to me
July 7 : I submit design concepts for consideration
July 8 - 15 : Revision cycle
July 16 : Approve design concept, begin development
July 17 - whenever : Develop website (pad this liberally)
etc...

..because if you just say something like "I'll have it done by August 1" the client may not factor in their involvement in the process. Content might get revised, or the people with approval authority might be unavailable, and so on. It's rough, but it outlines what is expected of them to ensure a certain delivery date. And then they are less likely to be all WHERE'S MY WEBSITE come August 2 if things haven't gone as smoothly as you'd thought.
posted by emeiji at 6:29 PM on July 7