The worst web projects are not the ones with bad designers. They are the ones where nobody established what the site was for until the third round of revisions.
Collaborative web design is a working method rather than a philosophy: the people who understand the business and the people who build the site make the structural decisions together, early, before anything is visual. It is unglamorous, and it prevents most of the expensive problems.
Collaborative Web Design: Align Goals and User Journeys
1. What usually goes wrong without it
A brief arrives describing pages. Someone designs those pages. Halfway through, it emerges that the sales team needs something the structure cannot accommodate, or that the content nobody assigned an owner to does not exist.
Revisions follow. They are treated as design problems, but they are almost always decision problems surfacing late. By this point the cost of changing direction has risen sharply, so the site launches as a compromise nobody chose.
The fix is not more revision rounds. It is making the structural decisions while they are still cheap.
2. Start with the decisions, not the pages
A first session should answer questions that have nothing to do with layout:
- What must someone be able to do here that they cannot do elsewhere?
- Who are the two or three audiences, and what does each arrive wanting?
- What is the single most valuable action, and what currently stops people taking it?
- Which content already exists, which needs writing, and who is writing it?
- What must this site do in two years that it does not need to do now?
That last question prevents a surprising amount of rebuilding. So does the content one, because unassigned content is the most common cause of a delayed launch.
3. Bring evidence, not opinions
Design meetings drift toward preference when nobody has brought data. Three sources usually settle arguments faster than discussion does.
Your analytics show where people currently leave and what they search for. Your support and sales teams know which questions come up repeatedly, and those questions are usually the missing content. And watching five people attempt a real task on the current site will surface more than a month of internal debate.
Five sessions tend to reveal the same three problems, which is enough to act on. This is the cheapest research available and the most commonly skipped. The GOV.UK Service Manual’s user research guidance is a practical starting point for teams doing this for the first time.
4. Prototype before you polish
Test the structure before anyone chooses a typeface. A rough clickable outline answers questions that no amount of discussion will: can people find the thing, does the navigation make sense to someone who does not work here, is the journey shorter than the one it replaces.
Changes at this stage are cheap. The same change after visual design and build is expensive and increasingly likely to be refused on budget grounds.
Keep the prototype ugly on purpose. Polished mockups invite feedback on colour when you need feedback on structure.
5. Decide the constraints together
Two constraints belong in the room from the start, not bolted on later.
Accessibility should be a requirement in the brief. Working towards WCAG 2.1 Level AA covers keyboard operation, contrast, focus visibility and clear error messaging, and building it in costs a fraction of retrofitting it.
page weight should have a budget. Agreeing a ceiling before design begins changes the conversation from “can we make this load acceptably” to “is this worth what it costs”. Reducing unnecessary data and processing supports both a faster experience and lower estimated digital carbon, though environmental figures remain modelled rather than directly measured.
Both are easier to agree on at the start, when they are principles, than in the final week when they are obstacles.
Who needs to be in the room
Fewer people than you think, and different ones than usually attend.
You need someone who can make a decision without escalating, someone who genuinely understands the customer, and whoever will own the content afterwards. That third person is routinely left out and is the one most likely to be affected.
You do not need everyone with an opinion. Wide consultation is useful for gathering input and poor for making decisions. Separate the two explicitly.
Our sustainable web design work is structured this way: decisions and constraints first, visual design once the structure holds.