Content design and creation

Our website design is based around information and tasks. It should be clear of distracting and unnecessary elements. It adapts (robust) to different devices and browsers, helping all users to access the content quickly and easily. As a council we have a legal duty and a moral duty for accessible and inclusive content for all our users.

People visit the council website for other reasons than what drives people to visit BBC News, Facebook, Amazon, John Lewis or most other websites. We have unique content, we are the owners of this information, and we are required to make it available to the public. In the main we are not competing with others for customer loyalty, or creating a space for customers to return too regularly.

Our peterborough.gov.uk website address has a high level of trust from search engines (we rank in the top 300 in the UK). If we have the keywords on our pages, we should get visibility on the first page of results. Visitors to the website see 'Peterborough City Council' as a trusted source of information.

People visit the council website mostly to complete a task, usually just one task, for example:

• submitting a form
• paying for something
• finding out information they expect the council to provide, or what they need to do next
• Following a link to our site for localised information

Many people want to do one of a relatively small number of tasks. We typically have a high percentage of visits to a single page. This is expected when all the content the user needed was on a single page, or we link to external pages for more detail, or an application form to complete a transaction.

Search engines and referrals (inbound links) to a page are the starting point for a significant proportion of customer journeys.

Overall time spent on our website is low (which is to be expected). Some pages, especially those for statutory services, containing unique information, advice and guidance will engage the audience for longer.

On average around 60% of sessions on peterborough.gov.uk are from a mobile phone. We need to consider the design of content on both mobile and computer screens.

Often, a user journey involves more than one step. For example, claiming a State Pension is more than just making the claim. It’s also finding out, if and when you’re eligible, and being told how much you’ll get, and when. So, the team working on this service will need to look at the whole end-to-end journey for their users, rather than just a single page.

More than webpages...

Content work does not only focus on the online service, though. Claiming a State Pension is something that involves offline steps as well. It involves getting two letters, which are a big part of the user journey. Making sure that these letters are clear and easy to understand is just as important as the content in the online service.

User research...

User research found that people expect a letter when they can get their State Pension. This letter is the main way that people find and enter the GOV.UK service Get your State Pension.

So, it’s important that this initial letter creates trust and explains what to do. The old letter that used to be sent users included a 12-page booklet. User research found that this wasn’t easy to navigate. The letter has since been redesigned and the content reduced to two pages. It now also includes clear headings, which means people can find the information relevant to them easily.

Designing for the whole journey

The experience of getting a State Pension does not begin and end with the online service. We should design for the whole journey – both online and offline. If we meet the needs of our users at all stages, then they will receive a good and consistent service that they trust.

User needs are also easy to mistake for other things. They can start to sound like business requirements, stakeholder wishes or even simply things a user wants. They become easy to dismiss as awkward obstacles to delivering something that ‘does at least do the job’. And they’re easy to negotiate away when they get ‘balanced against vital operational requirements’ and budgets. If we find any of those things are happening, we probably have not got a good picture of what user needs really are.

A user need is something that a person has to get done. The person might be a citizen, they might be at work, or be working in the council. Their need is there regardless of what existing system they might have to use. That’s just the current tool, and it might not be helping. They might not even really want to do the thing they need to get done.

User needs are not:

• giving users what they ask for (like easier ways to fill in the current form)
• what ‘we’ – people who work on a piece of information or a service – want to get them to do (like read and understand a piece of guidance)
• in conflict with stopping people doing bad or prohibited things – hopefully those aren’t things that they need to do
• optional extras, bells, whistles or gold-plating – quite the opposite.

Designing for user needs is boiling down services to the minimum necessary to give people what they need to get something done. No more.

But the minimum may differ from what the current service or system makes them do. It’s probably less. It may involve doing the hard work to make things simple. It should make a service quicker, simpler and cheaper.

Another way to put it is that user needs are about getting done only what’s needed. The goal of meeting user needs can sometimes get side-lined when the pressure is on to get something (anything) working and out of the door and ‘delivering value to the business’. But we can help to avoid building another costly, wasteful, difficult-to-use service, if we keep calling out anything that isn’t focused on what users need.

User needs aren’t optional extras. When we get them right, they’re the core of what any service is there for.

To design content that helps the user get things done, it’s useful to write down the specific user needs you’re working with.

User needs typically follow the structure (story):

• As a…
• I need to…
• so that I…

Good example: 'As a carer. I need to get financial help. So that I can carry on looking after the person I care for. This is a valid user need because it does not suggest a specific solution. You might need to produce a combination of features and content to make sure the user need is met.

Bad example: As a carer. I need to use a benefits calculator. So that I can find out if I can get Carer’s Allowance. This is not a valid user need because it creates a ‘need’ to justify existing content, and suggests a specific solution that may or may not be right.

Assumptions we make when designing a piece of content or service can often be wrong. We need to find the best solution to meet each user need.

Acceptance criteria

Acceptance criteria can help define a user need. Write a list of what must be done for the need to be met. For the above example this could be when the user:

• understands what carer’s allowance is
• understands if they are eligible
• can apply for carer’s allowance
• understands how much they are entitled to

Each 'story' can also be prioritised:

• Must have this requirement to meet statutory/core business/customer needs
• Should have this requirement as it has been defined, but project success does not rely on it
• Could have this requirement if it does not affect anything else on the project, and is in budget
• Would like to have this requirement. There may be little evidence, established needs or seen elsewhere as an example. Future requirement or lowest priority.

A user journey map is a way of showing a user’s journey through a service over time. It may include many transactions and different services. It starts where a user’s need for that service arises, and ends at the point where they stop using the service.

A journey map is a visual representation of the process that a user goes through to accomplish a goal. User journey maps show all the things that are happening, and how all the back-end systems work together to create the user experience across the journey.

There are many ways of organising user journey maps, and you’ll hear them called different things: use cases, storyboards, and many more.

As a content designer this mapping may start with the service (service interview). This may take place as part of understanding the process and the content required. Although you may find out later during user testing customers have their own way of doing things!

For example when mapping out a service you might include the following

• Who is the service for?
• Who else might use the service?
• Who is the service not for?
• What is the starting point for the journey?
• What is the end point for the journey?
• What are the intermediate stages, (service interactions and wait times)
• What are the most critical stages (must haves) in the journey
• What are the most likely points where the customer could seek advice or support

Sometimes it’s hard to fit something into a straight-up linear journey. There may be offshoots, cyclical bits or too much variance in the steps and activities from one user to the next. Having said that, trying to make a clear user journey diagram out of it can be a useful way of understanding the problem, or how you should be approaching the problem.

Even the most complex journey can help, you can learn that there are very few fixed points in this journey that all users will share – it spans too much time and too many possibilities. Exposing this in the user journey, can focus your work on tackling smaller, more specific user scenarios (project scope). The outcome will be a set of digital transactions and content that are grouped into services that serve broader user needs.

The process of mapping user journeys can be useful because:

• the things you’ll be designing content for will usually be a component of a bigger journey
• it will show you how the information, service or transaction you’re working on fits into this bigger user journey and highlight what other things might need to change, and who you need to be talking to in order to make those changes happen (Heads of service, Transformation, IT, Commissioning)
• it can help you to have those conversations about what needs to change.

This often means being:

• specific
• informative
• clear and to the point

You should also ask yourself:

• Who am I writing for?
• Why am I doing this?
• What am I trying to say?
• What do I want the reader to do?
• Would I ever say what I have written?

Put yourself in your audience’s shoes.

• How much do they know already?
• What will they search for? Will they automatically read it, or do I need to attract their attention?
• 'What do I want the reader to do?' - What does the reader want to do! What are they going to do! (user behaviour).
• How much time do they have to take in the information? Where are they reading this? At home? In the workplace? Whilst commuting?

Content must be easy to find and navigate

An individual’s process of finding and absorbing information on the web may follow these steps:

1. I have a question.
2. I can find the page with the answer easily – I can see it’s the right page from the search results listing.
3. I have understood the information.
4. I have my answer.
5. I trust the information.
6. I know what to do next/my fears are allayed/I do not need anything else.

A website only works if people can find what they need quickly, complete their task and leave without having to think about it too much.

Use heading levels (Heading 1 to 6) to break up your content and give it a sensible navigation structure. Headings are important for accessibility. They enable a user to navigate your content with assistive technology or keyboard shortcuts. Ensure headings are descriptive and tell people what content follows that heading.

• The name of your page in Contensis (page title) is also a heading level 1 on the published page. It is good practice to use only one Heading 1 per web page.
• The page title is the most important on-page SEO element. The page title should describe the page content, include relevant keywords, and be unique for every page.
• The page title should be less than 70 characters in length. (Or front loaded to avoid key information being cut short in search engine displays.
• All headings are weighted heavily for search engines and internal search. Consider how you can load them with search terms/key words. You must balance SEO with accessibility and still provide a logical navigation structure for the page.
• Within Contensis you can start a content page with either a level 2 heading, body copy or another element like an image. All these follow on from the H1 page title.
• The first heading on your page should be heading level 2. Use another heading 2 when changing the concept or subject.
• Heading 3 a sub-heading of the H2 heading. Use these to break up a complex concept or subject
• Heading 4 is a subheading of heading 3. (We rarely go deeper than heading 4).
• You can choose to enable 'Anchor links' at the top of your page. This can anchor to just H2 headings, or H2 and H3 headings on your page. It can be useful for long pages with many concepts, or actions/stages. The list of headings at the top of the page can introduce all the key content on the page.
• Never skip heading levels, for example from H2 to H4. Users with assistive technology may tab through headings - a missed heading level can make this confusing.
• Do not use bold text instead of using sub-headings. This is inaccessible because a screen reader will not recognise it as a header.
• Never use a heading for just decorative or visual impact.

Watch this Why you should use the correct heading structure in your content video which shows how a screen reader interacts with headings. If you can’t see the video, you can read the full transcript in the description section.

Further information

• W3C - Structured content
• W3C - headings

Do not make your customer work harder than they need to, remember people only read 20 to 28% of text on a web page. This quicker you get to the point, the greater the chance your target audience will see the information you want them to. If you write only a single paragraph but it is full of things users do not need to know (but you want to say) then it’s still too much.

Your customer will scan the page looking for 'what they need', so give it to them. The overall length of the page becomes less relevant if structured correctly and you use components like contents anchors, accordions to reduce initial distractions. Try to avoid blocks and blocks of paragraphs without clear separation and defined purpose.

It is often best to keep your content to fewer pages, to avoid users landing in the wrong place or half way though the content you have created. We also have paginated templates that bring multiple pages together as a process flow, under a single standard section heading if required. 

There is no universal minimum page length for web pages, as the ideal length depends on the page's purpose and content quality. However, for SEO purposes, at least 300 words is required to avoid being classified as "thin content". A directory listing or an event may legitimately be much shorter, but this page template should be marked up as structured content.  

Keep your body copy as focused as possible.

You are likely to be battling outside factors for people’s attention. They might be looking on a mobile on a train, trying to complete their task online in the middle of a stressful family event or any combination of situations. If you want their attention, do not waste their time.

1. Do not repeat information, do not split concepts. Group your content within clear heading structures.
2. Use headings to enable scan reading and allow the user to find what matters to them the most. Include the important points, actions first (front load page) tapering down to lesser detail.
3. Break up your text with descriptive sub-headings, accordions, and lists. This helps to make reading and finding relevant information or tasks easier.
4. Paragraphs should have no more than five sentences each.
5. Don't be afraid to write instructions - tell the user what to do.

Further details are included in our style guide and writing in Plain English

Images and graphics can make content easier to understand for many people. They serve as cues for people to orient themselves in the content. Images can help make a page look more inviting and create a style or brand. They can sometimes provide more information than the written word.

Images can scale and change proportion based on viewing devices. The sizes below are therefore considered optimum, so still avoid important content towards the edges. All images should be uploaded to the CMS  at 72dpi, ideally at the proportions - although further cropping can be done in Contensis where you reuse an image in a different way.

There are several ways to add visual elements to your Contensis page. Do not use the 'Markdown' option (pencil icon) in the 'Markup' or 'Accordion' components. Images added using 'Markdown' may not meet accessibility guidelines.

Composer options

Image

• The default display for our image widget is the full width of a page. This can create large breaks in useful content with portrait or deep images. On some devices large full screen images can hinder touch screen scrolling.
• The largest image width you need is 1000px at 72dpi. Any larger than this will increase the file size and page loading times. 
• You can add an optional caption to the image
• You must include alt text.

UI Card

UI card is short for user interface card. This function should mainly be used for in-page navigation.

• They can be used for high impact 'circle off need' on pages that customers land on.
• They can direct users to related content within the same, or different sections of the website.
• They can be combined with 'external link components' to link to an external url.
• They may also feature on the first page of a section (landing page) it is recommended not to use more than six, to avoid poor user experience on mobile devices.
• A UI card must contain a 'hyperlink',
• A UI card must have either a 'title' or 'description', but both can also be used.
• Image alt text must be different to the UI card title or description.
• You can add as many UI cards as you need, but they are fixed to display as three per row. Adding two cards will leave a gap at the end. Adding 5 or more cards will start a second row. On a full page (no nav) if you use exactly 4 UI cards they will display 4 up - if you need another row, you will need to add another component.

Optimum Image size 72dpi 350x350px.

Markup with image

This component allows a text box (markup) to be combined with an image within two columns. You can choose if you want the image to the right or left and how much of the page width it takes up. You can also apply a background colour to create blocks of content on the page. The second column will move below the first column on mobile devices.

Optimal image size 72dpi Image will fit the chosen width (percentage of page).
For example 50% = optimal is 500px wide but at 25% 250px wide is optimal.

Card rows

This component enables a range of options for you across columns. When you add the card row you can choose either 3 or 4 columns and choose if you want a background. You can then start adding the 'vertical cards'. Both 'card row' and each 'vertical card' components are saved in the CMS and can be reused.

• 'Vertical cards' can contain an image, as well as other elements 'title', 'markup', 'button'.
• Each element of the card is optional.
• For images there is also an option to display a rounded image. (use square image proportions).
• You could use this function to display three or four images across the page. This looks best when all images are proportional to each other.

Images are set to fit width of three or four columns - for example 250px at 72dpi is the optimal width for four-up.

News

Adding a thumbnail image to the article populates the image in the list view, and also the board/carousel. The images in the list view have fixed square proportions, align to centre and non-square proportions cropped. The images on the board can range from square to landscape and fit to width first, with image crop top and bottom.

Optimal image size 72dpi width 400px, height 350px

Hero banner and header images

These functions allow more ways to add imagery to your page and create an engaging initial impression, or to link pages together visually. 

• Hero banners often combine a full width narrow image, with a heading and button. 
• Header images sit between the header and the page, or behind the page title. They can be a single image on every page, or they can be unique to each page. If an image is not included, the page will just display a background colour in this space.
• The banner on the homepage, should celebrate Peterborough and change overtime.
• The banner can be used as a branded element on pages that remains in place for a long time.
• Where hero banner (text and button) is included, the large banner should be used.

Image size displayed within the container is very varied as has to work for a number of devices - so the safe zone is the central area of image and needs to be carefully selected (or designed with multiple images that work well together). 

Optimal image size  is 72dpi width 1300px height 250px for the homepage. For other pages you can use the larger banner option this increases the depth to 350px. (Note the safe zone for mobile in your design).

On mobile view the area displayed is reduced to the central area of the image and is fixed to 350px high and on an average device is around 350-400px wide. 

For screens less than 600px (or on high zoom) both the large and standard banner area is reduced to 250px high to avoid image filling screen entirely.

Image Slider (not in use currently)

• The image slider features and options are the same as above. The main difference is you can add many images within the same display space.
• It looks best if all images are the same proportion.
• Requires user to click through, so secondary images may not get seen.

Making images accessible

A text alternative (alt text) must be provided with all images. You will get a warning in the right-hand column in the CMS if you have not entered any alt text.

Alternative text 'description' should:

• be accurate and informative. Present the content as the image does. "A chart showing the team structure" is not correct alt text for a team structure chart. You should describe in alt text exactly what you can see in the chart, names, positions, and direct reports.
• be succinct. A few words are usually enough; and shouldn’t be longer than a short sentence or two.
• contain the same words if any are present within the image. Although text within an image, should be carefully considered.

Alternative text 'descriptions' should not:

• contain duplicate information that is in the surrounding text or caption.
• use phrases such as 'image of' or 'graphic of'. Screen readers identify images and objects so the user may hear "image image of an apple.
• be included where the image, or object is purely to enhance the design of the page. These elements need to be marked up as 'decorative', see below.

Decorative images and objects

If decorative images are used, the text alternative should be entered as ("") to show the only purpose of the image is to add decoration to the page.

Complex diagrams or maps

You may find that there is too much information to include in alt text. In this situation you could caption the image and then add more detail into the body copy of the page. You may need to also consider adding a way to request this information in an alternative format.

Accordions are useful where only certain content will be of interest to users. This can be useful to avoid lots of scrolling, or for a user to see all the options.

Do not use the 'Markdown' option (pencil icon) in the Accordion text editor.

• The title of an accordion is a Heading 2 when considering your page structure.
• Accordions suit content dependent on a specific situation or a question. For example: 'I have applied but not received an email'. These should be in context to the main information, never create a page of resources, or a page of FAQs. 
• Accordions allow users to scan page content (headings). This enables them to choose the content they want to read.
• Accordions help us to understand what users want. With analytics data we can see what content is popular and adjust the order of accordions. Or re-consider the scope of the entire page.
• Accordions should not be used to hide content from a user.

Avoiding FAQ, resource, documentation pages built with Accordions

FAQs are strongly discouraged on our website. If you write content by starting with user needs, you will not need to use FAQs.

FAQs are discouraged because they:

• duplicate other content on the site
• cannot be front-loaded (putting the most important words people will search for), which makes usability difficult
• are usually not frequently asked questions by the public, but important information dumped by the content editor
• mean that content is not where people expect to find it; it needs to be in context
• create standalone content that can cover a range of differing needs that when together make the user read more, than when in context to a task.
• can add to search results with duplicate, competing text
• are not user centred. How does a user know if the question they have is 'frequently asked'. 

Government digital services explain why they don't use FAQs.

Having an FAQ page shows you have thought about what your users should know, but have not thought about your users. If your content isn't answering users' questions, revisit it.

You could:

• break out chunks of text with clear headings that summarise within the context of the main subject or task
• write more concise sentences that get the point across quickly
• front load your sentences and headings with popular search terms
• Consider why the question is being asked and resolve it at source

Tables

Tables should only be used to present data. Do not use tables for cosmetic changes to layout. For example, to present information in three columns.

Data tables and alternatives

A table may not always be the best way to present your content if very complex. If your data source is wider than 3-4 columns, or has both horizontal and vertical heading, consider if the data can be presented in multiple tables.

A simple two column table could be replaced with a:

• series of bulleted lists with headings and subheadings
• single bulleted list, using commas to separate the information

If the data is intended for re-use, or filtering, consider including a CSV download. A complex data set could also be replaced with a custom solution such as an XML data feed from source document, with search and filters dropdowns to display relevant data (maybe a costed solution requiring development).

Making tables accessible

Tables should have a heading/caption, technically this content is part of the table and is different to using a H2/H3 etc before a table on the page. The user will know there is a table and what that table is for, allowing a user to skip the table. Click 'show caption' in table properties. Populate the top row on the actual table with a descriptive heading/caption.

Tables must always have a header row, which explains the content of the columns helping users understand the table’s structure. Headers appear in bold as default. The header should also have a 'scope' applied (ie - what cells , vertically or horizontally are linked to this heading).

Break long tables into multiple simple tables. Even accessible tables are still tricky for some users to understand.

Do not use tables with merged cells.

Creating tables

Be careful when copying in tables from other sources as this can import bad code. It is often best to recreate the table to ensure it is coded correctly. In Contensis a table copied in may have a double line around the outside of the table, indicating a potential issue.

To add your header row, select the row, and go to 'Row properties' > 'Row type'. You can change it from 'body' to 'header'.

You can also change the alignment of text in the table here, but avoid setting artificial heights, as this can create problems on different devices. Let the content dictate to size of the table.

We leave the table on all the default settings as part of our website style. However it is possible to apply styles from the table properties option.

Iframes can be useful to bring in isolated content from external sources without the need to recreate or own it. This could be maps, videos or a data feed for example. You need to add a title (not displayed) and then enter the script.

• As iframes load after our cookie controller and are a window into another web domain. So, this can load cookies onto the user's browser as they enter the page or interact with the content. This may conflict with user choices made when entering our website. There are often ways to stop cookies, but this is often a case-by-case basis.
• As the content comes from another domain, checks the content for accessibility. Also check if the iframe works at a range of sizes, desktop, tablet, mobile. 
• Don't add any scripts you don't understand, or there is not any clear documentation for the iframe script - contact the web team.

The YouTube embed component is an iframe but specific for videos.

We have a corporate YouTube channel - videos can be uploaded to this channel by contacting the communication team. You can also embed any video on YouTube.

Visit the YouTube video link and click 'share', then 'embed' to get the script.

• You must tick the 'Enable privacy-enhanced mode' option to disable cookies loading automatically.
• You can set a time, this image frame will be displayed in the video preview
• Copy the embed code displayed

The video should have captions set up within YouTube (accessibility).

In Contensis add a title (not displayed) and paste in the embed code.

If the video contains critical content, you could add an accordion with the transcript for the video. Or consider any critical content within the page content. Sometimes it may be quicker to read the content, than wait for it in a video.

Creating hyperlinks

Hyperlinks (urls) can be used by users to navigate through content on a document or on a webpage. They work best when written in a descriptive way. Hyperlinks need to be easily identified by the screen reader so should be given a clear and accurate title that informs the user where they will be directed to.

Type your descriptive text - eg 'Apply for a secondary school place'. Then highlight this text, and click on the chain link icon in the content editor.

If a link takes you to another website, then this should be explained eg - 'View the schools ratings on the Ofsted website'.

Link field - add the full url for an external url, for internal urls you can click on the site tree icon at the end of the field and then find the page you want to link to. It will then display as a relative url (not include the full domain name) eg /residents/my_page_title.

Title field - this is optional - adding this will display the title when a user rolls over the hyperlink with a mouse (displays a tool tip). However this function does not work for mobiles and touch screens. If you use a good descriptive link, the title field is not a necessity.

Target - this should be current window apart from a very few exceptions, as part of accessibility guidance the user should be the one to control if they want content to open in a new window, which they can do easily. New window if not expected breaks features such as browser back button. The default should be 'current window' for most hyperlinks you will add, even to external websites.

The exceptions could be a help window, or terms and conditions information as part of a form for example. If a link opens in a new window or tab, this should be included in the link description. 'Terms and conditions (opens in new window)'.

Considerations for hyperlinks

• Screen reader users may skim a document by navigating from link to link. Avoid ambiguous link text that is difficult to understand out of context (e.g., "click here").
• Link text should contain no more than 70 characters
• Don't use the same hyperlink on a page with two different descriptive texts

Short URLs

If you want to promote a certain page, when you are doing a print campaign, or social media posts you may want to consider a short url. The web team can provide these after a quick look at the requirements and usage check.

• www.cambridgeshire.gov.uk/residents/children-and-families/fostering-and-adoption
• www.cambridgeshire.gov.uk/fostering

This is preferable to an encoded/anonymous short url such as bitly links.

Buttons and external links functionality

Buttons should be reserved for calls to action. Eg apply for a school place. Don't use buttons to make a hyperlink more visible.

The 'button text' field should be descriptive, just like a standard hyperlink. It should be clear on the action being performed. 

The 'link' field will allow you to link to a page, or an external link which must be created. External link can be reused so consider this when naming it within the CMS so other authors can find it, and not create duplications.