The Golden Rule of Web Design Implementation, Part 1

Hi folks! Today’s post was so full of awesome that I had to split it in two. This is part one, about views. Part two is about development.

Estimating is hard, and I hate doing it. But I have a trick.

Specifically, I’m going to talk about how to estimate the implementation of a web front-end project. Maybe it’s a UI refresh for an existing web site, maybe it’s a new take on e-commerce, maybe it’s one of those new-fangled web-apps… it doesn’t matter. As long as you’re implementing a relatively well-spec’d-out design, this rule will work every time.

Oh, and the technology doesn’t matter either. It can be HTML/CSS, with or without JavaScript. It can be Flex, it can be JSP or ASP or anything else. As long as you’re not doing any significant back-end work, this truth still holds.

This is really important so I’m going to write it in a really big font:

The time it takes to implement a web design will always average out to one view per day.

So if the design has 16 views, the implementation will take 16 days.

There are two interesting facets to this rule. Today we’re going to talk about the first one, the significance of the term “view”.

Views != Pages

This is an important distinction: it’s not about pages anymore. We’re past that. We have bigger monitors, and that means we can have more elaborate pages. In fact, we often put several views on the same page, just because we can.

Imagine you have a page in a standard two-column layout. The main content is one view, that’s obvious. What about the sidebar? These days, if it’s anything other than nav, it’s probably also an independent view. Even the main content can be more than one view, if it separates logically and especially if part of it will be re-used on another page.

Of course, not all views are created equal. Maybe the sidebar view in our example is a lot less work than the main content view. That’s bound to happen, and it’s fine. The rule states that this will average out, and believe me, it will. For every super-easy “only took an hour and a half” view you find, you’ll get stuck with one that takes nearly twice as long as it should because you hit some silly browser compatibility issue.

Get used to thinking in terms of views.

There’s another reason for looking at the design in terms of views: That’s how implementation works. You start with the overall page architecture, build out a grid or column structure, and then tackle each distinct view one at a time. The developer’s standard divide-and-conquer approach.

Doesn’t it make sense to estimate the same way? By considering the design in terms of views at scheduling time, you’re estimating the same chunks you’ll be implementing. This will lead to more accurate estimates.

It will also make your estimates easier to defend if they seem too high. Write out a list of all the views in the design, and say “this is a breakdown of the implementation in one-day chunks”. If there are 12 chunks, that’s 12 days. You don’t even have to use the term “view”.

By throwing away the pages metaphor and instead thinking in terms of views, you’ll get better estimates that are more accurate and easier to track, and easier to explain to others.

There’s still more to learn!

We’ve only looked at the first interesting corollary from the Golden Rule. In part two, we dig even further to reveal the secrets of development.