Why hierarchical Salesforce campaigns create more marketing value
From Website Replacement to a Sustainable Digital System
Many organisations we work with are not struggling because they cannot update their website. They are struggling because their website has become increasingly difficult to change.
The organisation has evolved since the site was built. Services and programs have changed, new audiences have emerged, priorities have shifted and the story the organisation wants to tell is no longer quite the story the website was designed to tell. Yet seemingly straightforward changes can become surprisingly difficult. There is nowhere obvious to put something new, navigation is already crowded, the same information exists across multiple pages, and changing one part of the story creates consequences somewhere else.
Eventually the website starts influencing the organisation rather than supporting it. Teams hesitate to restructure content, reconsider journeys or refresh the brand because they know that doing so may trigger significant design and development effort. The organisation can edit the website, but it cannot easily reframe it.
Much of this comes from how websites have traditionally been created. A familiar agency process is to define a sitemap, create wireframes, produce visual mock-ups, configure a CMS or page builder, populate the pages, test them and launch. There is nothing inherently wrong with that approach, and it can produce very good websites. Its limitation is that the website itself becomes the thing being designed and built. Content, navigation, presentation and technology become progressively intertwined around the experience required for that particular launch.
A sustainable digital project starts from a different objective. We still need to launch an excellent website, but we also want to establish a digital system capable of accommodating the organisation that website will need to become.
That changes the flow of the project:
Take Stock → Know Your Audience → Atomic Design → Content Modelling → Content Planning → Content Pooling → Experience Design → Site Building
The sequence progressively separates and then reconnects the things that traditional website projects often bind together: audiences, content, structure, presentation and experience. In practice the stages overlap and later learning will cause us to revisit earlier decisions, but there is still value in understanding the logical sequence and what each stage contributes.
And the bonus with this approach is that the early work extends well beyond the website. Take Stock and Know Your Audience are focused on digital engagement rather than simply web engagement, so the understanding we develop about audiences, interests and engagement life stages can also inform social engagement, direct email marketing, campaigns, CRM journeys and other digital channels. The website may be the immediate project, but the thinking behind it helps strengthen the organisation’s broader digital engagement.
1. Take Stock
The first step is to understand what already exists before deciding what the new website should become.
That means taking stock of the existing websites, content, navigation, technology, integrations, forms, search, analytics, SEO and security, as well as the broader digital environment around them. We want to understand what is working, what is creating friction, what has become difficult to maintain and where the existing environment is limiting the organisation.
Importantly, this is not simply an exercise in finding problems. An ageing website can still contain years of valuable organisational thinking, useful content, established stakeholder journeys and functionality that continues to serve its purpose. Replacing the technology does not mean everything built on it should automatically be replaced.
The content estate deserves particular attention. Over time, websites accumulate pages, duplicated information, outdated material and structures that made sense when they were created but may no longer reflect the organisation. Taking stock allows us to identify what should be retained, what can be rationalised or consolidated and what no longer needs to move forward.
We also need to understand the wider systems with which the website interacts. CRM, marketing platforms, payments, forms, identity, search and other services may all form part of the digital experience even though they sit outside the website itself. Understanding those dependencies early helps prevent the new site from simply recreating existing integration and operational problems on a newer platform.
The objective is not to redesign anything yet. It is to establish a reliable starting point: what we have, what remains valuable, what needs to change and what constraints or opportunities the existing environment creates. A sustainable digital project should rarely begin with a blank canvas. It should begin with a clear understanding of what is already there.
2. Know Your Audience
Once we understand the existing digital estate, the next step is to understand the people the digital system needs to serve.
Rather than developing a large collection of traditional personas, we use a deliberately constrained three-dimensional audience model. It considers people across three dimensions: archetype, interest and engagement life stage.
Archetypes describe the broad type of relationship a person has with the organisation. Interests describe what they are interested in or trying to achieve. Engagement life stages recognise that the needs of someone discovering an organisation for the first time can be very different from those of someone already participating, supporting or maintaining a long-term relationship.
We deliberately keep each dimension small, typically to three or four meaningful categories. Archetype × Interest creates our engagement matrix, giving us a manageable set of audience combinations rather than dozens of personas. Each cell in that matrix is then considered across the engagement life stages to understand how that audience’s needs, motivations, messages, calls to action and experiences may change as their relationship with the organisation develops.
The model gives the rest of the project a practical lens for decision-making. We can ask which archetypes a piece of content serves, which interests it addresses and at what engagement stage it becomes relevant. That thinking will later inform content modelling, navigation, journeys, search, personalisation and experience design.
The value of the model comes from keeping it usable. We want enough variation to expose genuinely different audience needs without creating so many audience definitions that every decision becomes an exercise in managing theoretical personas.
By the end of this stage, we have not designed the website. We have established a manageable model of who may be engaging with us, what they are interested in and where they are in their relationship with the organisation.
3. Atomic Design
With the existing environment understood and a practical audience model established, we can begin exploring how the organisation’s brand might translate into a contemporary digital experience.
We typically start with an exaggerated visual interpretation of a homepage. At this point, it is not intended to be the final homepage or even a page that will necessarily be built. It is a creative device that allows us to explore the digital expression of the brand more freely and make ideas tangible enough for stakeholders to respond to them.
The design deliberately pushes further than a conservative first draft might. It explores typography, colour, imagery, spacing, movement, hierarchy, calls to action, content treatments and interaction ideas together in one rich visual composition. This is often much easier for stakeholders to respond to than discussing individual design elements in isolation.
We then take that interpretation through a small number of feedback loops( usually two – its easy to find yourself in analysis paralysis here). The objective is not to perfect the homepage. It is to establish enough confidence in the visual direction to understand the design language that sits underneath it.
Once that direction has emerged, we explode the design into its atomic parts.
Typography, colours, spacing, buttons, cards, links, controls, imagery treatments and other foundational elements become atoms. Those combine into increasingly useful components and patterns such as cards, navigation elements, content treatments, calls to action and form elements. What began as a deliberately expressive visual concept starts becoming a structured and reusable Atomic Design system.
This is an important distinction from designing a homepage and then proceeding page by page through the rest of the website. The initial homepage exploration is being used to discover the system, not define the site.
Nor is the Atomic Design system considered finished at this point. It establishes the initial visual vocabulary and enough reusable structure for the next stages of the project. As real content and audience experiences are designed later, those atoms, components and patterns will be tested, refined, polished and extended.
By the end of this stage, we have moved from an expressive interpretation of what the digital brand could feel like to the beginnings of a reusable system that can consistently express that brand across the experiences we design next.
4. Content Modelling
By this point, we already know considerably more about the shape of the future digital system than we did at the beginning.
Taking stock has shown us what content exists, how the current site is structured, what performs well and where duplication or structural problems have accumulated. Knowing our audiences has given us a model for who needs that information, what they are interested in and how those needs change across their engagement life stages. Atomic Design has started making the future experience tangible and has helped expose the different ways information may need to be presented.
Together, those stages begin to shape three closely related things: the navigation systems, the SEO and discoverability framing, and the content model underneath them.
Content Modelling is where we bring that emerging understanding together and give it structure.
Rather than beginning with a sitemap and treating the page as the fundamental unit of the website, we identify what the organisation’s information actually represents. Programs, services, people, locations, events, stories, campaigns and resources become meaningful content types with their own attributes and relationships.
A program, for example, might have a name, description, audience, location, dates, eligibility, cost, related people, events, stories and calls to action. Those attributes belong to the program itself rather than to whichever page happens to present it.
At the same time, we begin giving clearer form to how people will find and navigate that information. Some pathways will be hierarchical, some will be driven by audience or interest, and others will emerge through search, related content and relationships between content types. The navigation system therefore begins to reflect both what the organisation needs to communicate and how its audiences are likely to look for it.
SEO and broader discoverability are part of the same thinking rather than something applied at the end of the project. Understanding how audiences describe their needs, what they search for and how the organisation’s information should be grouped helps shape content types, naming, hierarchy, metadata and the relationships between information. The structure needs to make sense to people, search engines and increasingly AI-driven discovery systems.
The audience model developed earlier becomes particularly useful here. Content can be associated with relevant archetypes, interests and engagement life stages without being permanently embedded inside a page designed for one particular audience. That creates the foundations for different navigation pathways, related content, search, future personalisation and experiences that can change as the organisation evolves.
The objective is not to turn every paragraph into a database field. We structure information where doing so creates genuine value through reuse, relationships, consistency, search, filtering or future flexibility, while leaving editorial content appropriately flexible.
By the end of Content Modelling, the future site is beginning to have a recognisable structure. We understand the major types of content, how they relate, the emerging navigation systems through which audiences will discover them, and the SEO and discoverability framework that helps connect audience needs with organisational information.
5. Content Planning
Content Modelling gives us the structure of the system: the types of content we expect to manage, their important attributes, how they relate to one another and the emerging navigation and discoverability structures around them.
The next step is to develop a Content Plan: what do we currently expect to fill that model with?
The Content Plan is not intended to be a perfect or literal specification of the finished website. Like any useful plan, it gives us direction, establishes expectations and provides something tangible to work towards while accepting that our understanding will continue to develop as the project progresses.
If we have established Programs, People, Locations, Stories, Events or Resources as content types, we begin identifying the actual programs, people, locations, stories, events and resources we expect the new system to contain. Alongside those content pools, we identify the broader pages and experiences we currently expect to need: major landing pages, audience pathways, organisational content, campaigns and other parts of the emerging site.
This gives us an increasingly complete picture of the future website without requiring every page to have been written or designed. It allows us to test whether the content model is sufficiently complete, whether the emerging navigation makes sense and whether the needs identified through our audience model have somewhere to be addressed.
It also creates practical expectations around content. We can identify what already exists and can be reframed, what should be consolidated, where genuine gaps exist and where materially new content may eventually be required. This allows content effort to be understood and managed rather than discovered unexpectedly during design or build.
The Content Plan also gives us enough structure to begin establishing the complete site. Placeholder pages can be created for the experiences we expect to build, even though their final content and presentation have not yet been determined. This allows navigation, hierarchy, URLs and relationships to begin taking shape around a representation of the whole site rather than only the content that has already been completed.
Those placeholders are deliberately provisional. Some will become substantial standalone pages. Others will become highly assembled experiences drawing from multiple content pools. Some may merge, disappear or change purpose as the project develops.
That is why this is a plan rather than a specification. Its purpose is not to predict the finished website perfectly. It is to give the project enough direction and shared expectation to move confidently into the next stage.
6. Content Pooling
With the content model and Content Plan established, we can begin moving real content into the new system.
The experiences we eventually create will sit on a continuum. At one end are pages that contain largely their own substantive content: a story, program, service, person, location, resource or other piece of information that can meaningfully stand on its own. At the other end are highly assembled experiences that may contain very little unique content of their own, instead bringing together related information from many different parts of the system.
We start with the first group.
These relatively self-contained pieces of information form our content pools. Rather than immediately trying to recreate every finished experience, we take the content identified during the stocktake and begin moving it into the content types and structures established through Content Modelling.
This is where rationalisation and migration happen together. Existing material can be retained, consolidated, lightly reframed or retired. Where the same information currently appears in several places, we can identify an authoritative source rather than carrying that duplication into the new system.
A program becomes part of the Program pool. A person belongs in the People pool. Stories, locations, services, events, resources and other meaningful content are treated in the same way. Each piece of content is structured according to what it is, rather than according to where it happened to appear on the old website.
At the same time, the placeholder structure established through the Content Plan allows the broader site to begin taking shape. Navigation can operate across the expected site structure and relationships can begin connecting pooled content with experiences that have not yet been fully designed.
This creates an important separation between content and experience. The content pool does not need to know every page, journey or experience in which its information will eventually appear. It provides the underlying information; later work determines how that information should be assembled and presented for different audiences and purposes.
That separation also changes the content-maintenance cycle. In a traditional page-oriented website, changing a piece of information can mean finding every page on which it has been repeated and updating each occurrence. In the pooled model, the aim is to maintain information once at its source and allow the experiences that reference it to reflect that change.
Starting with the content pools gives us real material with which to design the more complex experiences that follow. Instead of designing landing pages and journeys around placeholder content, we increasingly have structured, rationalised organisational content available to assemble.
By the end of Content Pooling, we have established much of the source material of the future digital system, while also having a working skeleton of the broader site through which navigation and relationships can already operate.
7. Experience Design
By this stage, we have most of the ingredients we need. We have …
- an audience model,
- an emerging navigation and content architecture,
- base atoms, a visual language and design system,
- structured content pools and a Content Plan
Now we bring those things together.
Most organisational websites have a core offering: products, services, programs, events, courses, locations or some equivalent representation of what the organisation actually does. We typically start there because these experiences sit close to the centre of both the organisation’s story and its audiences’ needs, and give us broad coverage of the visual systems to refine the experience that will influence the whole site.
We also start at the top of the experience and work down. We establish how …
- the global navigation works,
- how the page introduces itself through its hero and primary messaging,
- how breadcrumbs and other wayfinding operate,
- how local content is presented,
- how related content is drawn from the wider content pools, and
- how the experience resolves through calls to action and the footer.
This gives us our first complete expression of how the system works as an experience rather than as a collection of separate ingredients.
From there, we work through the content-pool experiences. Programs, people, stories, events, locations, resources and other structured content types need appropriate ways of presenting their own information while also exposing their relationships with the rest of the system. Because the underlying content has already been pooled and related, these experiences can increasingly draw relevant information into the page rather than requiring editors to manually recreate it.
Finally, we work through the remaining experiences identified in the Content Plan. These are often further towards the assembled end of the spectrum: landing pages, audience pathways, campaigns and other experiences that may contain relatively little unique content of their own and instead bring together information from across the content pools.
Importantly, Experience Design happens in the site itself.
We are not producing a succession of static mock-ups that are approved and subsequently handed to somebody else to reproduce in code. We use the real design system, real components, real content and real relationships to design the experience where it will ultimately operate. When something works, it is already part of the site.
This inevitably refines the Atomic Design system established earlier. Real experiences expose states, combinations and requirements that could not reasonably have been anticipated when the initial atoms and visual language were created. Components are adjusted, new patterns emerge and existing ones become more sophisticated.
That refinement is expected. The system was deliberately built for change.
The important discipline is that improvements discovered through one experience are considered as improvements to the wider system. A useful new pattern should become available elsewhere rather than remaining a one-off solution embedded in a particular page.
By the end of Experience Design, the site should be substantially real. A useful way to think about the target is 80% wide, 80% deep and 80% visually resolved. Most of the planned site exists, most of the meaningful content and relationships are operating, and the experience looks and behaves substantially as intended.
It does not need to be perfect. The remaining work is refinement rather than invention.
That is a very different position from completing a set of approved mock-ups and then beginning the website build. We already have the system, the content and most of the experience operating together.
We have designed by building.
8. Site Building
By the time we reach Site Building, there should be very little about the website that is still abstract.
The site is already substantially assembled. The content pools are populated, navigation and relationships are operating, the major experiences have been designed in the site itself, and the Atomic Design system has evolved into a practical set of reusable components and patterns. We are starting from something that is approximately 80% wide, 80% deep and 80% visually resolved.
Site Building is therefore not the traditional moment where approved mock-ups are handed to developers and development begins. Much of that work has already happened as part of Experience Design. This stage is about completing the wider digital system and bringing the remaining parts of the implementation up to the same level of maturity.
That includes completing functionality and integrations that sit behind or across the experience. Forms and their submission behaviours are completed, search is refined, analytics and conversion measurement are implemented, CRM and other integrations are connected,
A website is the outcome, not the system
Build for the next change
At the end of this process, we have launched a website. But the better test of what we have built comes afterwards.
What happens when the organisation introduces a new program? What happens when an audience becomes more important, the strategy changes, a proposition needs to be reframed or the brand is refreshed? Can the organisation make those changes through the system it now owns, or does changing the story once again mean changing the website underneath it?
That is where the sequence matters. Content exists in reusable pools rather than being unnecessarily repeated across pages. The audience model provides a continuing framework for considering who an experience needs to serve. Atomic Design gives the organisation a visual system that can evolve. Content Modelling provides structures and relationships that allow information to be reorganised, while Experience Design creates patterns that can be reused and recombined as new needs emerge.
The result is not a website designed never to change. It is almost the opposite: a website designed on the assumption that it will change.
That does not remove the need for future design and development. New ideas will require new capability, brands will evolve and technology will continue to move. The difference is that normal organisational change no longer needs to begin with the assumption that the website itself must be replaced.