May 31 2010
When it comes to getting an estimate or proposal for web design services, some folks will give you a rough number of web pages they think the site will be. I certainly understand why this is the case, and I can forgive most people who think of web development pricing this way. After all, in its early days the Web as the public knew it was just a bunch of static pages tied together by hyperlinks. But what I don't understand is why so many web designers/developers continue to feed the notion that the number of pages is an accurate way to price a web design project. Plainly put, it's an archaic way of determining costs in modern web design and development.
Although static sites are not as common as they used to be, they're still around. But even those can't be estimated based on page count alone. At least not if you expect a well-designed, well-developed site that's meant to do more than just sit there because "every business should have a website".
Information Architecture
Every site needs a solid foundation, which starts with Information Architecture (IA). IA is conducted in a variety of ways by different web design agencies but the goal is almost always the same: to determine the site's flow, page types and content. Some may say that this simply is overkill for most small websites and to be honest, they wouldn't be entirely wrong. We've launched a few sites without this initial phase and they've been decent sites. But when we put IA to work, our sites become that much more successful for a variety reasons. Such is the case even for smaller sites. The thing is, most people confuse site mapping and site maps with IA. They're not (necessarily) the same thing. Site maps are certainly part of IA but there is usually more to it than that and only gets more complicated and more critical the larger the site is in terms of not just pages, but features and functionality.
Design details
There's more to most websites than just the page layout or overall look and feel. Assuming that the creation of one or two Photoshop files for the design is enough is often a poor assumption.What about how the links and rollovers will work? If there's to be a drop down menu (I would hope not), a static mockup isn't going to address how that functions (i.e., what's the delay, how easy is it to get to sublinks, etc.).
And how about that contact form? What about styling on those blog comments? Should that Facebook icon change on hover? I could go on. As they say, the devil is in the details. And the details need to be accounted for when pricing a web project.
Iterative design/development process
Let's not forget client feedback, which is absolutely critical to the success of a project (not to mention a happy client). Going back and forth, improving on the initial prototype takes time that pricing by only the number of pages doesn't address. How many revision / iteration cycles are you going to go through before you require final sign off? The more cycles, the more time and should be priced accordingly.
The mighty dynamic website
Most websites are dynamic in some way or another these days. Be it a blog or or fully manageable website, there's no way you could account for all the different pages that a dynamic site might have. Sure, you could price according to the number of unique templates or page types but that doesn't cover other details I've already mentioned, including search functionality, custom back-end programming, etc.
The bottom line
When it comes down to it, pricing by the number of pages is about as modern as building a website with Microsoft FrontPage. It doesn't cover all the bases that a truly successful website will touch. And while scope creep is never a good thing, there's most definitely a fine line between it and adding a minor page here and there (that quite frankly, shouldn't - in most cases - be charged additonal for).
So the next time you see a web designer quoting a price for a range of pages, know that you may not be getting the best value for your money.