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.
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)
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".
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.
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.
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.
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).
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.
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:
The website will be written professionally, so that it is easily understandable by users. We'll minimise confusion on the website by:
The council's website (including webforms) will meet the AA standard of accessibility of WCAG 2.0 by implementing the following measures:
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.
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.
When referring to a location on the website, we'll:
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).
The website will prioritise transactional services and information requests by:
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.
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.
These buttons link to an online action on a content page, such as:
CTA buttons will be formatted as follows:
These allow us to display a large amount of content on a page as expandable chapters.
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:
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:
There will be minimal use of images. In general, these add little or no value to the user. Instead, they cause unnecessary issues with:
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:
Positioned either:
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.
These will generally be used for promoting campaigns, events or community.
There are different elements that can be placed in a sidebar, such as:
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:
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.
For long or complex processes, we'll guide users on the steps they need to take. There are different ways to do this:
We'll find the right balance between what we handle inside and outside a transaction as shown in the GDS service manual.
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.
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.
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.