Below a certain size a website is a set of pages somebody designed. Above it, the pages are generated by people across the organization from a system of components and content types, and the design work is really the definition of that system. Buying an enterprise site as a set of page designs produces something beautiful on launch day that decays as soon as teams start creating pages the system never anticipated.
The content model is the most consequential decision
What types of content exist, what fields each has, how they relate and how they are reused across channels determines what the site can do for years. Get it wrong and every future requirement becomes a custom template. Insist that the content model is a named deliverable, reviewed by the people who will actually author, before any visual design is signed off.
Buy a design system with documentation and governance
Components, states, accessibility behavior, usage rules and a working code implementation, not a file of screens. Also agree who owns it after launch, how a new component is proposed and approved, and where it lives. Design systems without governance fracture within a year as each team adds its own variants.
Migration is where enterprise rebuilds lose value
Large estates carry thousands of URLs, much of the traffic on pages nobody remembers, and search visibility accumulated over years. Require a full inventory, a decision per URL, a redirect map and a post-launch monitoring period as contracted deliverables. More enterprise rebuilds are damaged here than by any design choice.
Accessibility, performance and privacy are acceptance criteria
Put a named accessibility standard, a performance budget measured on real devices, and the privacy and tag governance rules into the acceptance criteria rather than the aspiration section. Anything not tested at acceptance will be discovered later by a regulator, a customer or a slow quarter of search traffic.
Questions people ask about enterprise website design
How long does an enterprise site take?
Typically several months to a year depending on the estate, and the schedule is usually dominated by content and governance rather than design or build. Plan the content work first; projects that leave it until after the design is approved are the ones that slip.
Should we replatform at the same time?
Combining a redesign, a replatform and a content migration into one project multiplies the risk. Where possible, sequence them. Where the platform is genuinely the constraint, do that first and redesign afterwards on a stable foundation.
Who should own the site after launch?
A named internal product owner with a budget, not a project team that disbands. Enterprise sites decay because nobody owns the system after the launch party, and the second year's small decisions are what determine whether the investment lasts.
How do we keep the design system alive?
Fund it as a product with a small permanent team or a named owner, require new components to go through a defined review, and audit the live site periodically for variants that bypassed it. Without that, every team ships its own button within eighteen months.