How a brochure site grew into a page editor

At the start it was one of those projects where you feel you know exactly what is coming. A fast food brand with its own outlets needed a new website. Present the brand, show the menu, tell the customer where to find it. A brochure site, like many others.

I was on the project mainly as a frontend developer, and I took part in the planning too. The estimate was about three months, and nobody thought it bold. Half a year later we were handing over something that resembled the original brief from one side only.

That side was the one a visitor sees. Nothing dramatic happened there: the home page, the menu, the outlets, the campaigns. That is what was talked about at the start, what was drawn and what was estimated.

The other side a visitor never sees. It is where someone at the company adds a new product, swaps a campaign image or corrects the address of an outlet. The brief said nothing about it, and yet in the end more questions stood on it than on everything that shows.

What took longest to settle was neither the look nor the technology. It was what exactly the client should be able to change alone, without calling a developer.

Categories and products were clear from the start. But more questions came behind them, and each one opened another. Where can images be added? Who names the ingredients? Where do the names and addresses of the outlets come from? How does a campaign page tie into the rest of the site? What address should a category page have, and who decides it?

None of those questions was hard. What was hard was that there were many of them, that they came one after another, and that every answer changed something already agreed.

So the client’s administration was never planned. It grew during development, request by request. First it was about the client managing the content alone. Then about adding a new section to a page for a current offer. And then another one, with different data and a different look.

Nothing was set in advance: which sections would exist, which values they would take, or how they should look. The answers came gradually, as the client’s daily work brought them.

I cannot say exactly when the brochure site became a page editor.

It was not one moment and not one decision. It was a row of small steps, each of which made sense.

If I had to describe that site in one sentence today, I would not say a brochure site. I would say a tool in which the client puts together their own pages from sections.

Several pages were designed to their final form before it was clear what on them should be editable. Once that was clear, the client wanted them changed, and with good reason. The design captured a page in one state. The client needed a page that changes with every campaign.

So the finished design was opened again. And with it, what had already been built from it.

The project closed after about half a year, roughly twice the original estimate. The difference did not come from what the brief contained. It came from what the brief left out: content management, the sections the client puts together alone, and the design changes that followed from them.

The client was not at fault, and neither were we. The client wanted what every company that really uses its website wants: to change it without help. We estimated what was talked about. One question was missing from the first meeting:

Who will manage this site the day after launch, and what must they be able to change without us?

Today I would ask it first. Administration is a role like any other, with its own screens, rules and exceptions, and it belongs in the plan before the design is drawn. Whoever leaves it out estimates half the project.

This experience was one of the reasons Throughplan exists. It asks about the roles, and about what a brief leaves out, before there is an estimate. That the same gap shows up in an idea of your own, I found out later. I write about it in the article Why an app is always bigger than its brief.