On a large web project there is a phase in which a lot is discussed and nothing works yet. From the outside it reads as slowness. From the inside, it is the stretch where changing your mind costs minutes.
In our project management tool there is a task with an unglamorous title: “Wireframes for inner sections”, the grey-box outlines of each screen before it is designed. It belongs to the e-commerce platform of a large institution, a project that combines a product catalogue, an online shop, registration of professional customers, document validation, invoicing and integrations with the ERP, other corporate platforms and the email tool.
That task gathered 174 comments over a good number of weeks: 85 from us and 89 from the client, a conversation split almost evenly. In the years the project has been running, only two tasks have more: the content templates task, which was its natural continuation, and the content migration task.
This article explains what was decided in that thread and what work surrounds it. For confidentiality we do not identify the client or show their deliverables; the figures come from the project management tool.
The phase that gets cut the most
Information architecture is the discipline that decides what content a website has, how it is grouped, what it is called, how people reach it and what each user can do on each screen. Together with UX (user experience) and UI (the visual interface), it makes up the phase in which a project is conceptualised before it is built.
It is also the phase most likely to be cut. “We already know what we want”, “let’s do something like X’s website”, “we’ll adjust the wireframes as we go”. It makes sense: it is the part of the project where nothing is working yet. On large projects, cutting it is expensive.
What came before the first wireframe
When that thread started, we had been conceptualising the project with the client for some time. No wireframe is drawn from a blank page.
Four pieces of prior work
Conceptualisation is a project within the project, with its own deliverables that the client reviews and validates.
An initial questionnaire and four working-group meetings with the different teams involved, because each one uses the website differently and needs different things.
A content tree and plan, versioned and reviewed by the client several times, backed by a benchmark of reference platforms.
Five definition sessions: how a product and its variants are created, how a customer registers and is verified, how they buy (one product, several or a bundle), how the financial and marketing side is managed, and which systems everything integrates with.
Prices and discounts, registration fields and attributes of each product type, filled in with the client.
Without all that, the wireframe would have been an exercise in aesthetics. With all that, it was the first time the client saw their business turned into screens.
What was decided in those 174 comments
Six decisions made in the thread
The thread has almost no comments of the "move this button a bit to the left" kind. What it has are business and product decisions, made when changing them cost minutes.
The client had many product types and wanted to tell them apart. Our recommendation was the usual one in large e-commerce sites: few templates, so users learn a single way to browse and buy. The debate was long and very good. It ended in a middle ground: fewer templates, but respecting the hierarchy between product types that was strategic for the client.
We prepared extra screens so the client could test registration with real users. Result: the order of the form's field groups had to change. In a prototype that means dragging a few boxes. On a live site it means touching forms, validations and emails.
Can a user change their email? And their profile type? What happens when someone deletes their account? In Drupal these questions have serious implications. We answered them with the wireframe in front of us, before promising anything, and the client decided knowing the cost of each option.
Address autocomplete and certain modal windows were consciously moved to a second phase, with an agreed interim solution. Knowing how to leave things out is also design, and it is what lets you reach a launch date.
To decide how to show each product's variants, the client analysed how many they usually have active at the same time. The component was designed for that case, not for the pretty example.
Even the menu label was discussed: the catalogue's name or "Explore"? In information architecture, what things are called determines whether users find them.
A thread like this only holds up if the conversation is open and nobody is afraid to disagree, neither the client nor us.
A comment on a wireframe costs a few minutes. The same change on a live site costs days of development, testing and deployment, and sometimes a data migration. The UX phase is the only point in the project when getting things wrong is cheap.
The UX phase is the only point in the project when getting things wrong is cheap.
From wireframe to functional spec
A validated wireframe is not yet a project ready for development. What was agreed in that thread was carried over into three functional documents: modules, navigation and templates, and processes. They describe what each component does, what it shows depending on product type and user type, and how each flow is chained together. They went through several rounds of comments until their final version, in parallel with the graphic proposal and a web style guide that fixes the interface.
That set lets the development team work without guessing and lets anyone, years later, know why a screen works the way it does.
Why it weighs more the bigger the project
On a small corporate website, an architecture mistake gets fixed in an afternoon. On a platform with a shop, registration, invoicing, integrations and several user types, every badly solved screen multiplies: it affects forms, permissions, transactional emails, admin dashboard reports and the client’s internal processes.
If we had to choose where a project like this is won or lost, we would say in the first months. That is why we defend this phase when the temptation to cut it comes.
What to check before moving to development
If you have a project of this size ahead of you, with us or with another team, these questions will tell you whether the definition phase has done its job.
Five questions about the definition phase
They apply to any team and any platform.
Have management, marketing, operations and technology seen the same thing and decided on the same thing before budget is spent on code?
Have the technical limits, the odd cases and the requirements that "were taken for granted" already come up in a meeting, or will they come up during testing?
Has every decision been checked against how people browse and buy, against sector references and, when needed, against a real test?
Will development be estimated against a closed functional spec? Without one, estimates are wishes.
When the project grows in later phases, is the architecture designed to absorb it?
Those 174 comments say that the client and we took the project seriously before writing a single line of code. When development arrived, we already knew what had to be built.