These are the standards that editors will be using for our online services. We will be using conversational language with residents, using contractions wherever appropriate such as "we'll instead of we will". The aim of our standards is to make the user journey (how residents get from A to B on our website) consistent and easy. 

Understand your readers

The council serves a wide variety of users, so it's critical to understand that when creating any online service for the council.

A user story that typically uses that services must be defined so that an online service (page, form, transaction) is justified and properly designed. Without a strong user story the page/form will not be published. The format to use is:

As a ... (who)

• I need/want/expect to ... (what?)
• so that ... (why?)

For example, "As a council resident, I want to apply for a suspended parking bay so that I can arrange a removal van or skip".

How users read

The government digital service design guide explains how our users read and why short sentences and plain English are so important. This is especially important in Barking and Dagenham, as many users do not speak English as their first language.

Write for the majority

Designing digital services for all does not mean trying to write content for everyone. The council serves a wide range of users. Content must be based on what the majority of people want to know - the typical user story would define that. Content that is written for everyone ends up confusing everyone.

For example, disabled access to council buildings should be a separate piece of content and should be very easy to find in its own right.

Be clear and concise

Our users aren't interested in the inner workings of the council. Users are interested in whether they're entitled to a service, what they need in order to get it, and how quickly that is.

Clear, specific information that provides just enough information to answer a customer's question will avoid causing any doubt or further questions.

Use the power of word

The words we choose to use can have an impact on how people will behave. Our words should encourage users to use online services by preference.

Whatever we write will have an effect; we should try to make sure that this effect is aligned to our objectives.

We'll use a persuasion to promote the best service option. These persuasive techniques rely on good editorial copy and information architecture.

For example, positioning the least preferred option low on the list and stating the negative attributes (lead time, cost) over its positive attributes (convenience, cheapness).

• "Alternatively, if you would like to pay, we provide a bulky waste collection service. The current average waiting time is one week."
• "For a small cost, we provide a bulky waste collection service where we can pick up your rubbish from your house at your convenience."

Writing for transactions (webforms)

There is the advice on writing government services from the government service design manual and the advice on writing government transactions, which gives more detailed advice on subjects like how content and transactions link together.

This advice applies to the transactional content we create at local government level just as much as it does at central government level.

Writing for search engines

Most users use search engines (like Google) to find information on the council website.

Our content must make it easy for users to find out what they're looking for whether navigating in the site or using search.

We will ensure that each page has a good search engine optimisation (SEO) by:

• using meaningful titles for web pages (titles that make sense to user needs); the GDS service manual and GDS content design has specific guidance on this
• using words our customers use, for example if our customers say "rubbish" then let's use that and not "waste"; search queries in Google Analytics will provide evidence
• having a meaningful page description associated to each content page in the content management system (this will appear on search results)
• starting each content page with a summary of what the user can do/find on that page
• having a short description of the service visible on the landing page
• assigning tags and keywords to each page, ensuring that we're capturing the range of terminology that users would describe services (such as bins, rubbish, litter, waste, trash)

User-centric text

The website will be written professionally, so that it is easily understandable by users. We'll minimise confusion on the website by:

• using words that are used by other channels (such as call centre phone options)
• using customer-focused plain language to describe our services
• using Google Analytics and Google Trends to understand commonly used search phrases and identify keywords
• not referring to team names or departments, instead, use 1st person tense (council is "us" or "we", the user is "you")
• not duplicating content from sources that have greater ownership or authority, such as central government agencies, NHS, the police, LFB
• using contractions ("we'll" instead of "we will" and "can't" instead of "cannot" unless we need to emphasise)

Accessibility

The council's website (including webforms) will meet the AA standard of accessibility of WCAG 2.0 by implementing the following measures:

• using simple content (plain English and with minimal council terminology)
• enabling screen reader software to work well on content and navigation areas (including tagging for webforms)
• enabling keyboard control of the website
• minimising use of images and where these are needed, to have meaningful captions
• ensuring alerts (pop up messages) do not adversely interfere with a user requiring keyboard control or screen reading software
• provide text alternatives for any non-text content
• font size adjusts when zoomed without loss of functionality
• provide user options for alternative background colours (where possible)
• no use of Captcha unless there is a compelling reason to
• maps should be used only when you're not referencing a UPRN (unique property reference number), where the address lookup would not pinpoint the exact location)

Contact phone numbers

We will display phone numbers only when necessary. If a service does require a phone number to be displayed, we will publish public numbers only (contact centre main numbers where possible) and never direct dial numbers unless there is a compelling reason to do so.

We'll arrange options to prioritise online channels where appropriate; if the service is an emergency, then the phone number will be clearly presented.

Contact email addresses

Whenever possible, we'll display webforms instead of emails. If a service does require an email address to be displayed (and if there is a user need), we will publish only team mailboxes and not individual email addresses.

Where there is a choice of contact options, we'll promote webforms or self-serve methods before we display an email.

Displaying locations and building addresses

When referring to a location on the website, we'll:

• show the full address, including the post code
• enable the post code to link to a map
• display the accessibility information for buildings managed by the council, by:
  • having content explaining disabled access
  • having a link to the AccessAble page for that building
  • ensuring the details on AccessAble are correct
• display a map if it adds sufficient value to the typical user of that page
• show directions or pictures only when there is a clear user need (based on the typical user)
• avoid multiple maps on a page

Dates

Dates should always be presented in this format: DD Month YYYY (such as 18 April 2018). Timeframes on the website must be clear and not confusing (if stating "the last 4 years" we need to say since when).

Prioritisation of transactions

The website will prioritise transactional services and information requests by:

• identifying and promoting transactions that are most used by customers
• adjusting tasks based on seasonal fluctuations (for example school admissions)
• using My B&D to authenticate customers and capturing information, unless there is no value in doing so
• using call to action buttons effectively
• promoting self serve and integration e-forms before any other contact method (emails, phone and in-person contact will be minimised/relegated)
• provide useful content to lead into transactions, to manage expectations
• adopting the design principles and standards agreed by the council

Links

Normal links within the body of content text will appear as underlined and in red. When quoting publications or references to other sites, they should have a hyperlink to that document or site, or at least stating exactly the name/date of the document. That includes council documents where these may be available on ModernGov.

External links should open in a new window to allow the users to return to the Barking and Dagenham site if needed.

Features

We have an editing and publishing manual which explains the technical method of deploying each feature. The information here is to inform when these features should be used and how these should be used to enhance user journeys. The over-use of features can detract from the main message and purpose of website content, so care is needed when using any of these features.

Call to action (CTA) buttons

These buttons link to an online action on a content page, such as:

• completing an online form
• making a payment
• directing a user to another site where this is important for the user to continue

CTA buttons will be formatted as follows:

• they'll stand out by having larger text in a coloured box
• they'll be positioned carefully so that users can get to the transaction quickly; normally near the top of the content page but not always
• they must be tested before and after publishing to ensure the link works correctly

Chapters

These allow us to display a large amount of content on a page as expandable chapters.

• we prefer to use these rather than accordions 
• they are more accessible and they allow you to link directly to the chapter or to specific content in the chapter
• chapters can be displayed horizontally or vertically (vertical is preferred option in most cases)
• chapters are best used when the text is a step by step process
• chapters do not display well if the chapter heading is too long and generally you should think about how you can keep titles as short as possible
• Gov.uk has more guidance on titles

Accordions

Accordions allow us to display a large amount of content on a page as expandable chapters. The following standards will control the use of accordions:

• these won't be used just to link content - that's what landing pages are for
• they'll be used to reveal information that some users may find useful, but not all (optional details)
• there must be a minimum of 3 chapters to justify an accordion (1-2 chapters should be normal content with headings and paragraphs)
• we won't use an accordion if the content is less than 2 lengths (folds) of the screen- this is a short page that will be arranged by headings and paragraphs
• by default, an accordion will show all chapters collapsed, so that a user will need to click on a chapter heading to expand (reveal) the chapter content
• the arrangement of accordion chapters must be based on user needs
• CTA buttons will generally not be buried within an accordion unless there's a reason to (such as deliberating reducing that transaction/link)
• content with accordions will follow the same standards as non-accordion content, but with flexibility for summary information (such as listing libraries)

Tables

Tables are useful in displaying numerical information or service options, such as Council Tax banding. Headings will be a different colour so that they're easily distinguished and text within table cells are kept minimal.

Do not use tables for cosmetic changes to layout, for example, to present a list because you think it looks better that way. Consider the alternatives:

A table may not always be the best way to present your content.

A simple table can often be replaced with a:

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

Images

There will be minimal use of images. In general, these add little or no value to the user. Instead, they cause unnecessary issues with:

• data consumption on mobile devices
• poor rendering on different devices
• accessibility for partially sighted users

We'll use images only where they clearly will enhance the user journey.

Where images are used, the following standards apply, see the GDS standards:

• it mustn't jeopardise the council's reputation
• it mustn't endorse something, such as a brand or opinion
• it must be something that we'd find suitable on a council poster or magazine
• acceptable formats are jpg, png and gif files
• size should be 960 pixels wide by 640 pixels high at 72 dpi
• resize images using free software like GIMP or an online photo editor like PIXLR, as smaller file sizes mean that pages load faster
• avoid putting borders around images: the image should go right to the edge of the frame (called full bleed)
• before uploading an image, give it a meaningful name (for example barking-town-hall-front.jpg is a good file name for an image of Barking Town Hall; avoid meaningless file names like IMG00023.jpg
• the council must have permission to use the image, either taken or owned by the council
• written permission must be granted by the owner and shown with clear attributions and copyright - see the GDS standards for attributing images

Positioned either:

• within the content of the body, justified to the left of text, with no wrap-around text, which a short caption (1 sentence, max 10 words)
• within the sidebar, if a logo and link to another organisation is appropriate
• within the sidebar, if a user story is a feature of the page

Call out boxes

Call out boxes are a useful way of highlighting key/important information for your users.

This information could get lost within the normal content and not seen by the user if they are skim reading the page. There are 3 scenarios where a call out box is appropriate:

1. Standards

If there is a time limit on a service request or documents that are needed. For example, to highlight to a parent registering a birth that this must be done within 42 days of the birth.

2. Information

If there is a service-related issue that we want users to be aware of. For example, if we're aware that an issue has been reported already and there's no need to report it.

3. Warning

Usually an important instruction that a user must follow. If the user doesn't follow this, there are potential serious consequences. For example, a warning message to say the service is an emergency and needs a phone call, not to complete the webform.

Image gallery

These will generally be used for promoting campaigns, events or community.

Side bar

There are different elements that can be placed in a sidebar, such as:

• links to other sites (where we want to promote them, using their logo)
• user stories (to demonstrate how a user has been/could be helped with this service)

Templates

Website templates control the styling and available features, helping to keep the site consistent and user friendly. Having too many features on a page (or the wrong combination on a page) can be confusing to the user and cause issues with page load and responsive rendering.

1. Basic page

Most of our content will use the basic page template, this is a straight answer to a question or providing straight forward information. Features can be used with this template to help present the content in the best way for the user.

2. Landing page

Landing pages are essential to ensure content pages are grouped logically together. We'll use the following format for landing pages:

• section name
• a short description of the section (1 sentence, maximum of 20 words)
• links to top tasks (where appropriate)
• link to content pages within that section (maximum 16)
• if there are more than 16 content pages within that section, then sub-sections should be used
• links to content on other areas of the site that are a logical fit for users (for example, reporting an abandoned vehicle can appear in both the Parking section and the Roads and Pavements section)

3. News, events and campaigns

There are set templates for these areas of the website. Only the communications and events team will be authorised to use these templates. These will provide features that enhance the visual impact and plug-in functionality of the site. For example, these templates will enable booking tickets to events or linking neatly with social media.

Guide users

For long or complex processes, we'll guide users on the steps they need to take. There are different ways to do this:

• chapters - this is content with steps broken down on a page, such as how GOV.UK checks eligibility for Universal Credit
• smart answers - these are decision-tree revealing content, for example maternity pay entitlement. Presented as flat content this would be a list of confusing rules. But with smart answers, a series of questions can guide a user through the process. The difference between a smart answer and a form is that a smart answer provides information, advice or guidance at the end of the process. A webform provides a transaction at the end (triggers a message or integrates with something)
• videos - but only where a typical user would benefit from this

Webforms

We'll find the right balance between what we handle inside and outside a transaction as shown in the GDS service manual.

Outside the transaction

The website content pages should explain information in a simple way, nudging users towards the transactional form. The content pages on the website should give users an idea of whether they can use the service. This might mean including some high-level eligibility information, for example if users need to be a certain age or live in a certain area to use the service.

It's okay to include broad statements like "this service is for businesses, not individuals".

You could also give users information about the wider context of the task they're doing and what they might need to complete the transaction.

Avoid putting information about the service and eligibility within the transaction as this will cause frustration if a user starts to complete a form only to find out they're not entitled to the service. It is easier to manage this information in the web content rather than within the transaction.

If users can get to the webform straight from search (internal or external) without landing on the page first then having a small intro becomes important.

Inside the transaction

Transactions must be as simple and as short as possible; we'll only ask what's needed to run the service and what's relevant to the user.

Questions will only be included if that information is really needed to deliver a service (without the information the service cannot be delivered)

We won't ask monitoring questions (such as gender, age, sexuality, ethnicity, disability and religion) unless there is a clear reason for capturing that information and if we make it clear that the reasons are justified. We'll challenge services who wish to capture this information to ensure there is justification.

Where possible, we'll allow pre-populated fields in webforms (either from My Account or the user's device)

The user's details should be captured on the last page of the webform.

Spellings and grammar

Barking and Dagenham follow the Government Digital Service style guide for spelling and grammar. For local Barking and Dagenham spellings, see below:

Barking Abbey

Capital A.

Barking and Dagenham

In normal references to the borough or the council, write as above. The ampersand should not be used unless in a council logo, or where it is part of an organisation's name.

Barking Learning Centre

Capital B, L and C, all the time, but lower case if referred to as the "learning centre" or "the centre". After first mention, qualify BLC in brackets, then abbreviate to BLC on subsequent mentions, but remember the rules on abbreviations.

Note that the word Lifelong is no longer part of its title.

borough

Lower case b, unless as part of the London Borough of Barking and Dagenham.

Broadway, Barking, The

It no longer uses its Theatre title, so any use of the word, such as to qualify the nature of the building, should be with a lower case t.

Councillor

for written communications, the abbreviation "Cllr", when followed by someone's name is as acceptable as "Mr" or "Mrs" would be. However, when writing for the internet, accessibility requirements dictate that the word "Councillor" in full should be used. Please note the word "Cllr" is not followed by a full stop.

Councillor only has a capital C when followed by a person's name. Mentioning a meeting of councillors requires a lower case c.

Dagenham & Redbridge Football Club

The ampersand (&) is correct. However, when mentioning the club on the internet, it should be replaced with the word and (not &) to comply with accessibility guidelines.

GLA

Greater London Authority (not Assembly).

government

Lower case.

Heathway

it is the name of the street, so "The" Heathway is unnecessary.

London Borough of Barking and Dagenham Stadium

The home ground of Dagenham & Redbridge Football Club. The word and in the name of the stadium and the ampersand (&) in the name of the club are both correct.

Marks Gate

No apostrophe.

Mayor, The

The Mayor is all you need for a job title. The Worshipful might be part of it, but it looks off in a 21st century publication or communication, and is probably only necessary on certain official documents or invitations.

Postcodes

The correct format is letter(s) numeral(s) space numeral letters, for example RM10 7BR. The format of the first half is variable (for example NW10, E1, EC4N, N22), but the second half is always the same.

There are no commas anywhere in the postcode, and only one space.

Postcodes should only be used with an address to which you are directing someone or inviting a written response. Any other time is too much information.

Postcodes can be useful on the internet as a reference for sourcing location maps.

Road and street names

Use full title, not Rd or St.

Telephone numbers (London)

The correct form is 020 7xxx xxxx or 020 8xxx xxxx. Not 0207 or 0208.

Terrace houses

Not terraced.

Transgender

All one word.

Ward

When used to describe areas within the borough, lower case w, even if preceded by the actual ward location, for example Abbey ward.