I’ve been involved in a lot of website projects over the years, and one thing I still find surprising is how often the technology is decided before we’ve properly understood what the website needs to do.
“We want it built in WordPress” is a common starting point. HubSpot comes up a lot too, as do various other platforms that an organisation has used before or that somebody within the marketing team is familiar with.
There’s nothing necessarily wrong with any of those choices, and familiarity with a platform obviously has its advantages. The problem is making that decision too early, before you’ve had a chance to understand why the existing website is causing frustration in the first place.
For me, that’s where a website project should really begin.
Start with the problem, not the platform
Before we recommend any technology, we want to understand how the website fits into the organisation and, in particular, how the people responsible for marketing actually need to use it.
That means looking beyond the front end and asking some fairly practical questions. How quickly can the marketing team launch a new campaign or create a landing page? What happens when they need something that doesn’t fit neatly into an existing template? How often does a relatively simple request have to go through a developer? Where is content being duplicated, and where does brand consistency start to slip?
Individually, these can seem like relatively minor frustrations. Across a large marketing team, though, they quickly add up to a lot of wasted time and an increasingly difficult website to manage.
This is why I think defining the technology after the scope is so important. You need to understand how people work, what is slowing them down and what the organisation is likely to need from its website in the future. Only then can you make a sensible decision about the technology that sits underneath it.
A rebuild doesn’t necessarily solve the problem
One of the risks with any major website project is focusing so heavily on the new website that you overlook the processes and limitations that made the old one difficult to manage.
You can spend months redesigning a site, improving the user experience and bringing the visual identity up to date, only to find that six months after launch the marketing team is still dealing with many of the same issues. Creating a landing page still requires development support, new content requirements still have to be squeezed into rigid templates, and relatively straightforward changes still take much longer than they should.
The website might have improved considerably from a customer’s perspective, but internally the organisation is still working in much the same way.
A rebuild gives you an opportunity to address both sides of that equation. Of course the website needs to be engaging, intuitive and representative of the brand, but it also needs to work well for the teams responsible for keeping it relevant after launch.
In many ways, that second part is what determines whether a website is still working well three or four years down the line.
Moving beyond page templates
Traditionally, a lot of websites have been planned around a collection of page templates. You might have a homepage, a service page, a case study, an article and a couple of different landing page layouts, with the CMS built around populating those predefined structures.
That approach can work perfectly well for a relatively simple website, but it becomes restrictive when an organisation is producing a large amount of content or running campaigns across multiple products, services, audiences or markets.
Marketing requirements aren’t particularly predictable. A campaign might need a slightly different combination of content, a new proposition might need to be communicated in a different way, or a team might want to test something that nobody thought about when the website was originally scoped.
If every variation becomes a new template or a development request, the website gradually becomes harder to maintain and the marketing team becomes increasingly dependent on developers.
We’ve found a modular approach gives everyone much more flexibility.
Rather than trying to predict every page the organisation might need, we can identify the components it regularly uses to communicate: things like testimonials, statistics, videos, product features, forms, case studies, calls to action and different types of content blocks.
Those components can be designed and developed properly as part of the original build, with enough flexibility for them to work in different contexts. Marketing teams can then combine them in different ways depending on what they’re trying to achieve, rather than having to commission something new each time.
Where headless CMSs starts to make sense
This way of thinking is one of the reasons we’ve been increasingly interested in headless CMS platforms and, in particular, Sanity.
There’s plenty of technical discussion around what “headless” means, but for most marketing leaders I don’t think the terminology is especially important. What matters is that it allows us to separate the way content is managed from the way that content is ultimately presented.
That gives us much more freedom to structure the website around the needs of the organisation rather than around the conventions or limitations of a particular CMS.
With Sanity, for example, we can think about content as structured information and reusable components rather than simply content that belongs to a particular page. We can then build an editing experience around the way the organisation actually works, giving marketing teams the tools they need without exposing them to unnecessary complexity.
From a development perspective there are significant advantages to that approach, but I think the more interesting benefits are operational. If a marketing team can create and adapt pages using an established set of components, a lot of the everyday dependency on development disappears.
Developers can concentrate on developing the platform and improving its capabilities, while marketing teams have much greater control over the day-to-day experience.
Flexibility still needs boundaries
There is, however, an important balance to get right. Giving marketing teams more control over the website shouldn’t mean giving everyone complete freedom over how pages look and behave.
Anyone who has inherited a large website that’s been running for several years (more often than not with multiple development teams) will know what happens when there aren’t enough boundaries. New layouts get introduced to solve individual problems, slightly different versions of existing components start appearing, and quick fixes made for one campaign somehow become permanent features of the website.
Over time, that creates both a development problem and a brand problem.
A well-designed modular system should provide flexibility within a defined framework. The typography, spacing, colours, interactions and responsive behaviour can all be established at component level, which means the person creating a page has meaningful choices without needing to make design decisions from scratch.
I think this is particularly relevant when we talk about brand guardianship. Traditional brand guidelines are useful, but ultimately they still rely on every person interpreting and applying them correctly. A digital design system allows many of those decisions to be built directly into the tools people are using.
It means teams can move faster without consistency being the price they pay for that speed.
Thinking beyond the website
There’s also a wider opportunity here that I think will become increasingly important.
If you’ve already invested the time in defining how a brand behaves digitally, creating reusable components and establishing clear rules around typography, colour, imagery, spacing and interaction, it seems fairly limiting to think of that purely as a website design system.
The same thinking can inform the wider marketing ecosystem, from campaign landing pages and email through to social media and paid digital assets. That doesn’t mean every channel should look identical or that a single system can automatically create everything a marketing team needs, but there can be much greater consistency in the underlying building blocks.
For larger organisations producing a significant volume of content, that has obvious advantages. Teams spend less time recreating assets and making the same design decisions repeatedly, while the brand remains more consistent as the volume of marketing activity increases.
The website starts to become less of a standalone project and more of a foundation for the wider digital brand.
Why we’re working with Sanity
None of this means I think Sanity is automatically the right answer for every website project. In fact, deciding that before understanding the brief would contradict the whole point.
There are projects where WordPress, HubSpot or another CMS will make complete sense. The decision should depend on what the organisation needs, the people who will be managing the website, the wider technology landscape and where the platform needs to go in the future.
What I like about Sanity is that it gives us the freedom to approach those questions without having to start with a predefined idea of how the website should be structured.
We can understand the content, the users, the marketing requirements and the wider digital ambitions first, then create a system around them. For organisations that need to move quickly, produce a lot of content and maintain consistency across a growing digital estate, that can be a very powerful approach.
And ultimately, that’s the point. The CMS itself shouldn’t be the starting point of the conversation.
If you’re considering a website rebuild, I’d spend less time initially asking which platform you want to use and more time understanding where the current website creates friction. Talk to the people who use it every day, look at where development time is being spent, understand what your marketing teams repeatedly need to create and identify where the existing system is getting in their way.
Once you understand that, the technology conversation becomes much easier.
Because most marketing teams don’t really need a new CMS. They need a better way of working.