How to re-envisage your web content from the ground up
This text is appropriated from a talk I initially gave at ContentEd 2017 and have subsequently given in museum training sessions for the South West Museums Development Group and for Bradford Museums, as part of my consultancy work in my role as Content Strategist at One Further.
In this article I go through the tools and processes I’ve employed to redesign and re-envisage every page of content on a website in parallel with a new website build. It’s based on work I originally did for the Oxford University Museums. I was initially hired by the Ashmolean, and once that project completed I rolled out this same process on new websites for the other Oxford University Museums and Gardens: Oxford Botanic Gardens and Arboretum, Oxford University Museum of Natural History, Pitt Rivers Museum, History of Science Museum. My job was also to instil a culture of digital knowledge across the staff force so teams would be able to continue updating existing pages and planning new pages in a consistent manner that also spoke to best practice for web.
The overall structure of this piece is in three parts:
- Content planning and research: 5 tasks I used to get more data on how well the existing site was performing for our audiences
- Planning and testing a new Information Architecture (IA) and site navigation
- The documents I used to guide writing of the content: (a) content manuals to guide content writing in the first case, (b) a style guide to create consistency and best practice in web content writing going forwards, (c) a set of training sessions designed to up-skill staff across the organisation in topics like Search Engine Optimisation, writing for web and how to use Google Analytics.
It’s best before you undertake a large content project, like a website rehaul, to have an idea of overarching content strategy. This content strategy ‘quad’ was invented by a company called Brain Traffic, home of Kristina Halvorson who you might know from her (very good) book on the subject Content Strategy for the Web. Brain Traffic have subsequently developed a newer content strategy quad, but I don’t find it as intuitive, so I’ll be sticking to their original version).
What’s apposite about the original Brain Traffic quad is that typically when people think of content strategy they think of the content components: they think ‘what am I going to write?’ — the ‘substance’ of the text on the webpage; and ‘where am I going to put it?’ — the ‘structure’. But 50% of the success of your content is to do with how well you’ve thought about your people components: your governance and workflow.
Particularly in organisations with lots of different functions, like museums. It’s fairly straightforward to project manage a website where you create exactly the same content as was on the old website from scratch, or even buy in scripted content migration. But if you want to make meaningful change to your content, particularly content that sits outside your area of expertise, you’re going to have to work with different teams and get them to frame their expertise in a way that is appropriate but also in keeping with the site tone, style and design as a whole. So I’m going to run through the tools and processes I’ve used for building up content and structure at the same time as creating buy-in, shared understanding and policies to allow for the ongoing evolution of content within the principles and research underpinning the strategy.
At the start of a web content redesign project you’re going to want to work out what’s working on your current site and what’s not working and why, this will help you focus the time you have to dedicate to the redesign.
I. User research
1.1 Create a content audit
The first thing I like to do right at the beginning of a project is a content audit. A content audit looks at every page of your site and allows you to very quickly build a blueprint of how well different section of your site are performing. It allows you to isolate sections that are very baggy — loads of pages that no one is looking at; and also sections that are too sparse — lots of traffic to these pages but not enough content to meet the user appetite. This helps give me a sense of where the time will be spent in the project in terms of building up new content, and what low hanging fruit there is in deleting swathes content that does not meet a user need.
You can put what data you want in these columns along the top, I tend to keep mine fairly simple and look at hits to each page in a 6 month window, time on page, bounce rate and exit rate from your Google Analytics. (Although you’ll have different metrics if you’re on Google Analytics 4.)
There are tools that will allow you to do a scripted content audit, I’d strongly recommend against this. It’s slow and mechanical but I really think doing a manual content audit is the best way of getting to know the shape of your content and building up a picture of where to concentrate your energy. All the frustration you feel at going through boring pages is really useful when it comes to culling content when you redo it.
This document stays with me throughout the project. You can see in subsequent columns I might work out who the current page owner is, I might later in the project add in insights from user interviews about what these pages need to do in the new site, so it becomes a key planning document as I gain more data on what the new webpages need to do to meet user needs.
1.2 Internal staff interviews
Doing this data analysis up front puts you in a strong position to start discussing with colleagues what you want your new site pages to look like. A website cuts across the entire organisation. And if you’re trying to add that layer of consistency and coordination across different site sections you’re going to need to get used to modulating your overarching tone/design/approach to the needs of specific site sections (e.g. Plan your visit vs collections page). By speaking to colleagues early, and getting them involved with the insights from the data, you create buy-in for the project, get stakeholders used to thinking in a user focussed way, and get important information on the offer different parts of the museum have to communicate to the public.
1.3 External audience interviews
Just as important, but often relatively neglected in big organisations, is talking to your external audience. I would tend to begin a project asking the organisation to segment different types of website users (typically academics, family members, community groups, subject specialists/ enthusiasts and teachers). Sometimes we recruited friends of friends or asked for volunteers on our social channels or a website survey. In the past I’d mainly done these interviews with audiences face to face, particularly local audiences. But since COVID I haven’t found a drop in the quality of user interviews done remotely, and it certainly takes less time! This also means that some of the problems with recruitment before are lessened: I’ve spoke to a lot of people with a lot of time on their hands as part of user testing, for whom Museums are quite an easy sell, and I’ve spoken less to busy people who we are more actively competing for their time. That’s less likely to be the case now.
When conducting user interviews it’s a good idea to have Henry Ford’s maxim in your head: ‘if I’d asked my customers what they’d wanted, they would have asked for a faster horse.’ It’s tempting to look to your audience for all the answers to guide your product development, but they are not experts in digital content / products, as you are. The point of this exercise is to understand the motivations behind their interaction with you, and the scenarios in which your museum overlaps with their life and aspirations. It’s then about translating that motivation and context into digital best practice. So in Henry Ford’s case that was about understanding the need for speed, efficiency, comfort — and then using his superior engineering understanding, devising a solution that could meet those needs more effectively than anyone had before him (or could be achieved on a horse).
1.4 Formulating insights into user stories
As you’re going about doing your interviews, you can start pulling out scenarios in which your audiences might land on your website as user stories. User stories are the building blocks for how you should go building your new web pages: they’re your nuggets of how what the museum offers intersects with your audiences’s interests. It works like: as a ‘busy mum’ I want ‘to find out what learning resources X museums has’ so that ‘I can get some inspiration for home educating my child this afternoon’.
As I’m developing my content I tend to add user stories I’ve identified to the relevant pages in my content audit and/or navigation specification (more on this later). This means that when I come to writing the page I have a brief to write to, and I can prioritise the more important user stories above more marginal ones.
1.5 Surveys
Getting audience data from surveys on your website and social media is a useful additional way of getting a mix of qualitative and quantitative data. You can get some quantitative stats for survey questions with fixed responses as well as some qualitative data from open text fields.
There’s lots of software available to generate surveys. At One Further we use Survicate and often tests websites for content engagement, user intent and exit feedback. I’ve also in the past used Survey Monkey, Bristol Online Surveys (designed for educational institutions) and Google Forms linked to a simple pop up on the website.
1.6 Personas
Personas can be useful if you’re dealing with lots of stakeholders to make your internal stakeholders more aware of meeting user needs (as opposed to internal needs). However, I think a lot of time can be wasted in unnecessarily complicated personas, or personas not based on actual data but on stereotype.
There’s no set formula for personas, my preference is to tie them closely to the actual research and use for example keywords this persona would be likely to use to land on your site and typical pathways through your site.
I prefer personas that are quite simple and follow a spectrum of engagement: broadly, browsers, followers, searchers, researchers. It’s similar to ‘paddlers, swimmers, divers’ methodology used for in-gallery interpretation. Both are based on the idea that audiences will want a varying levels of information depending on how interested/knowledgeable they are on a given topic. Essentially a browser type audience mainly wants a quick appraisal of information and stimulating images. A diver wants the detail. To avoid alienating the majority of browsers, progressive disclosure allows you to ring-fence detail to those who have specifically indicated they are after it, by putting those pages deeper in the navigation hierarchy and by having specific keywords in the title to signal the granularity of the content it covers.
II. Navigation Specification
At this point in the project you’re probably ready to start thinking about your new navigation structure. So far in this piece we’ve looked at techniques for building up information on what you want to write and how your audiences might search for it. We’re now going to look at organising that content in a logical fashion on your site. This is more pertinent to users browsing for content within your site, as opposed to those coming from search.
2.1 Card sorting
A popular technique for getting stakeholders engaged in mixing up their existing navigation is card sorting. Card sorting essentially means putting all the names of current site pages on a card asking people to sort them into logical groups.
2.1.1 Open and closed card sorting
There are 2 main different types of doing this: ‘open’ and ‘closed’ card sorting.
Open card sorting is when you ask people to group cards together and then assign a label to the logical groupings. It’s a better option if you haven’t already defined your overall navigation structure.
Closed card sorting is when you ask people to sort cards under a pre-defined navigational structure.
The trouble with card sorting is that people rarely have enough context about what is on specific pages to make meaningful decisions about where to group them.
People often seem to try and replicate the structure they remember from the existing site and don’t try and think about a different way of logically grouping it.
It’s much easier for people to spot patterns in types of card/page (all of these are staff) than to spot common user stories, especially when it’s not clear what the content of each page it.
I might use card sorting if stakeholders were very resistant to changing existing navigation which seems entirely illogical, as the card sorting could then be a useful data point.
2.1.2 Card sorting based on user journeys
I’ve also run card sorting where I’ve asked stakeholders to pretend they are a user persona and sort pages relevant to them under different use cases: for example, imagine you’re a busy mum looking for learning resources, what would you search for and what pages might you expect to land on?
In general the findings from the card sorting are not always particularly groundbreaking in my experience. Equally a lot of discussions that came out of card sorting about what the pages are and what they are trying to achieve are useful, and begin to get your stakeholder group engaged in the logical process of redesigning your site.
2.1.3 Treejack
At One Further we generally use Treejack. This is essentially a survey where you ask people where they’d expect to find certain bits of content on the site, and you present them with a range of options.
It’s good for validating navigational decisions you’ve made. It also allows you to draw up graphs like this to help visualise if users are struggling or confused about where a particular bit of content might live.
2.2 Navigation specification
So generally by this point in the process you’ll have a fairly good idea of where you want content to live. This nav spec, much like the initial content audit, can be as simple or complex as you like. I like to fill out the columns with associated user stories, page owner, perhaps benchmark data to beat, and possibly some workflow about approval and status. (So it has the other components of the original brain traffic quad built in; substance, workflow and governance).
One thing to consider when developing site content in a navigation specification like this is that’s probably not exactly what a user will see, things may live on the primary level in your web hierarchy that aren’t sufficiently important to surface in the main bar.
No one of the three examples here is better or worse, it’s just worth bearing in mind, and working with your web design team, to factor in the context in which an audience member may land on subpages based on how the navigation is designed.
Footers typically become a catch all for content that can’t fit anywhere else, or content likely to be searched from google (press, contact details). The National Trust have also linked to their microsites here, pages that won’t necessarily turn up in your site search. The other feature that’s often in the footer — although not pictured here — is the site newsletter.
III. Writing web content content
This section is about the tools and processes you can put in place to keep content consistent as it is being developed. I’ll talk about 3 things I’ve used in the past that have proved helpful: 1) a digital style guide, 2) a content manual for planning page content, 3) digital knowledge staff training sessions.
3.1 Digital style guide
The purpose of this is to keep editorial consistency when writing text. I generally compile these from 4 main sources.
- you may already have a style guide that’s particular for print, this is a good starting point for lifting organisational specific conventions around capitalisation. But it shouldn’t be adopted wholesale as some things that work fine for print (for example the use of italics and ampersands) are not good practice on web.
- The best source for credible research into writing for web seems to be Jakob Nielsen and his influential report How People Read the Web (full paid report is linked to here), though dated, still has some really useful observations about how people scan a webpage and useful pointers about formatting and chunking text so that it can be more easily read online.
- The Government Digital Service’s A-Z style guide has appropriated a lot of this research. Some of their content is specific to government departments (e.g. here A levels and ampersands, but others — like ‘abbreviations’ are useful elements to fix on your own style guides).
- I’ve also tended to add in organisational specific vision/values/tone of voice principles so that this style guide feels particular to the organisation and informed by agreed communications priorities.
These four inputs should help guide you to create your own A-Z style guide and allow you to create consistent web pages that conform to best practice for writing for web. Consistency here also helps reduce cognitive load for your users as they get used to scanning pages of your site for information in consistent places.
3.2 Content manuals
So in this final section of the talk I’ll talk about actually developing the content, we’ve got the relevant tools and processes in place and generally right up to this point everyone has been very chilled out and pleased you’ve done some things they’ve been meaning to do for a while like talk to their visitors. Stakeholders can get much more nervous when you actually start creating content. So how do you get round that?
In my experience the biggest criterion of success is trust, how much do key stakeholder trust you with their content? Do they feel informed and like you’re moving them in a coherent and positive direction? Much of this will depend no how successful your advocacy has been throughout the research phase.
Typically the most difficult stakeholders are probably also the most busy and ones who knew the least about web. (Often, though not exclusively, the academics. I’ve written in more depth about getting sign off from academics here). I have in the past been send vast word documents stuffed full of footnotes and suggest that we just upload that for web.
To pre-empt this, one thing I developed was a content manual, and I’ve provided a screenshot of the rationale. The content manual amalgamates:
- Findings from the research pertinent to this page
- Where this particular page existed in the site navigation and expected user behaviour to reach it
- I then assigned the information this page needed to provide in a relative priority order
- Then I visually screenshot what each visual module would look like and suggested text of approximately the right length.
- I then allowed the stakeholder to modify this text around the same character limit.
All this gave stakeholders an understanding of the aim and success criteria of the page and the visual design principles. It wasn’t that I was writing the copy, but giving very clear, informed and specific guidance about the text, which allowed the stakeholders to meaningfully input but in the context of a strict structure and coherent design principles. To my knowledge, this content manual approach is new, I haven’t seen anything similar.
And the format of these manuals varies a lot depending on the stakeholders. That’s part of the art of content strategy, commercial didn’t want nearly this much bumph they just wanted to see their charts going up and lots of screenshots. The art of this judge is judging the appropriate sign off format to allow people to input meaningfully and understand the rationale and principles behind the structure you’ve created.
3.3 Digital Knowledge staff training sessions
Something that’s helped me create buy-in and organisational understanding in the past is by creating staff training sessions in parallel with the new web build. By covering topics like how to use google analytics, writing for web and Search Engine Optimisation, I was able to skill up staff in different areas of the organisation in the skills and knowledge they’d need in order the edit existing pages and create new ones whilst keeping to the principles of web best practice and within the overarching strategy the site had originally been built with.
Further reading
If you’re about to undertake a major web content project, I’d recommend the following books as sector-leading in providing an overview of best practice and thinking in the field.
- How People Read on the Web from the Nielsen Norman Group; this is mentioned above, it’s the best research I’ve found that has looked forensically at how people scan webpages and isolated how that’s different to print, and what that means for a web content writer. There’s a free summary here, but if your institution’s happy to pay for the full paid report, there’s more detail in there.
- Content Strategy for the Web by Kristina Halvorson; this is just a really sensible, step by step guide covering a lot of the same ground I’ve outlined here. A good ‘how to’ manual to have to hand before undertaking your first big web content project.
- Content Design by Sarah Richards. Sarah Richards (now Sarah Winter), was at the helm as Head of Content at Government Digital Service at the time they were getting set up, defining the standards of things like the A-Z style guide and how to employ agile project processes to large web content. She created the term ‘content design’ which has since generated great swathes of employment in the form of government ‘content designers’. It’s a great, pithy read and worth its weight in gold.
So long, farewell.
Finally, best of luck! If you have questions, feel you want additional help or advice, please do get in touch: georgina@onefurther.com.
