Blogging, evidence and the Mastermind principle

I had a bit of a crisis of confidence recently. One of my team was lambasting a blog we both read, because of the lack of references and evidence for the assertions.

Examining Clouds by katerha, on Flickr
(used under Creative Commons)

I agreed with her, but also squirmed inside. *I don’t link to many references from my blog. Hardly any, in fact.*

This squashed my plans for a couple of posts I had been brewing, until I was cycling home today, when I realised it doesn’t matter.

This blog is my opinion and my experience. And that’s fine, because you can ignore it. Or you can use my experience and ideas as a source to reference, if you want.

It’s not ok to omit evidence and references when your blog is effectively an instruction manual, and people are expected to change their behaviour and working practices because of it. That's my opinion, but if you're interested you can also read more about the history and benefits of evidence-based policy making.

I won’t link to my colleague's thorough critique of this particular non-evidenced blog post, to spare any blushes. But it was pretty satisfying to see it published, and that the author did respond.

My other recent crisis was about design. I was worrying that people would judge my professional skills based on the way this blog looks and works. 

I’ve made a slight changed to it recently, but it’s still a free theme and it doesn’t do what I want technically. I’m hesitant to find out if it’s accessible, although I have checked how it looks on a mobile.

And again, I decided that it doesn’t matter.

This isn’t a blog about design, technology or accessibility. It’s about content, and about managing websites. Hopefully I haven’t left too many embarrassing typos lying around the place, and the fact is that I leave other people to do what they do best when it comes to making websites function properly and look nice.
 
Following the Mastermind principle, it’s about achieving more by working with others, than you can as an individual (there’s a reference for you – to Think And Grow Rich, by Napoleon Hill). You can’t do everything yourself, and clearly, I can’t!

5 ways to be a great customer to your web team

I ’ve been thinking a lot about customer service since I returned from two weeks at Disneyworld.

Meeting Pooh

There is always the odd vacationing stress-head, but most people visiting Disney are in a good mood before they even approach their server.  And while anyone in a service role must be professional at all times, it must be a lot easier to tell people to ‘have a nice day’ if your customers have behaved well.

 

Here are some easy ways to keep your web team happy and Tigger-like while they deal with your request.

 

1. Be clear

 

This means: 

• Telling us whether it’s brand new content, or an update to an existing page.
• Providing a link to the page you are talking about.
• Trying to remember the difference between a website, intranet and extranet (although we do make allowances for Bears of Very Little Brain).
• Using tracked changes – we might miss something if you leave us playing ‘spot the difference’, and it takes ages to re-build a page from scratch.
• Telling us if your content is likely to change substantially before publication. We don’t want to spend hours building your page only for a brand new version to be supplied the day before it goes live.

2. Give us time

 

Web teams are usually running close to capacity and need to plan ahead for any large additions to workload. We have a lot of customers other than you, and have processes and tasks you don’t know about. You can help by:

• Giving us as much advance notice as possible.
• Telling us if you have a particular deadline to meet or if you’re Late, you’re Late, for a Very Important Date.
• Being realistic; sometimes we may not be able to help as quickly as you like.
• Understanding that what you think is a little change might be a big deal for us. For example, it takes a surprising time to add bookmarks and other accessibility features to a long document.
• Not chasing us precipitously (although it’s fine to chase if you haven’t been given an estimate of timescale, or we’ve missed our deadline).

 

 

3. Do your homework

 

Hopefully most web teams aren’t as scary as Scar in the Lion King, but you should still Be Prepared before approaching them, by:

• Providing good quality images; they should not be blurry, and any words or labels must be legible.
• Making sure you have permission to use any images and documents you send us, telling us if we have to include a credit.
• Complying with guidelines for preparing documents, for example, by adding metadata.
• Getting the appropriate branding and scientific or technical sign-off before your content gets to us – but be prepared for us to need to make changes (see below).

 

 

4. Respect our profession

 

There’s always room for a healthy debate and we never want to change the meaning of your content, but we do have to apply company policies (like style guides), follow best practice guidelines for the good of your users, and work within the technical constraints of a system.

 

You can increase mutual understanding and respect by:

• Involving us at an early stage, so we can help you make any major changes before you get your boss to sign off, especially if they’re a regular Queen Maleficent. Never tell us you can’t change something because it’s already been signed off.
• Not trying to prettify your content. We’re constrained by style sheets to ensure the website looks professional and consistent, and we won’t accept your Little Mermaid clip art.
• Accepting the consistent corporate style. Don’t be precious about your writing. If you want to make your own rules, get your own personal website; for organisations, the user is king, because the user is paying the bills.
• Letting us help you by suggesting structural and linguistic changes that make your content work better for people reading online and easier for search engines to find.
• Asking us why. We should always explain why we’re making a change.
• Coming to us with problems not solutions. Tell us about your users, and what they need, not that your boss has demanded you start a new Twitter account overnight.
• Using us as your guinea pigs. If we don’t understand the language you’ve used, chances are that new starters or people in a rush won’t, either.
• Not telling us how to do our jobs. I won’t presume to tell you how to design a house, perform surgery, re-house a council tenant or unpick a gene sequence. Please respect our years of experience and training in doing what we do.
• Coming to visit us, or picking up the phone for a chat, so we can understand each other’s needs.

5. Say thanks

 

We all just want to be loved, even those of us who seem a bit Grumpy sometimes.

 

 

If you one do one thing today

 

Most of this post is about empathy. In the words of Pocahontas:

 

"You think the only people who are people, are the people who look and think like you. But if you walk the footsteps of a stranger, you’ll learn things you never knew you never knew."

 

Recipe for a simple content migration

Biscuit mix by eddie welker on flickr,
used under creative commons

This short checklist and method gives an overview for web and intranet editors who've not planned a migration before. It's purely from the editorial point of view, and omits any technical jiggery-pokery.

You will need:

• User requirements. Who are your users? What do they want? How will they use this information?
• Knowledge of the information architecture (IA) of the new site.
• Contact details for the content owner.
• Editorial style guide and any guidance on new content formats.
• Support from a manager and/or policy if there is conflict and you need to escalate.

Method:

Pre-heat the content owners by letting them know in advance that you will be needing their input.

1. Audit existing content, working with the content owner and overall user requirements.
• Decide what is current information that needs to be migrated, and what can be archived. 
• Identify content that needs re-writing to fit into the new IA or templates, and anything that needs editing to style or is a bit out of date.
• Identify gaps where new content is needed.
2. Arrange any archiving procedures - ensure copies are saved elsewhere and can be accessed by the required audience.
3. Commission new content to fill the gaps.
4. Arrange for any updates to old content to be supplied.
5. Draft edited versions of the old content in new style and template.
6. Edit any new or updated content that has been supplied.
7. Send all the draft, edited pages to the content owner. (Either use Word with tracked changes, or a preview version of the website, depending which best shows the changes you have made.) Invite comment and set a deadline for approval.
8. Receive approval or negotiate the final version with the content owner (apply the 80:20 rule if necessary, to reach a compromise).
9. Publish.
10. Schedule for review.

Serving suggestion:

Garnish your freshly-prepared content with an email alert or a homepage news feature.

When to back down

Boxing glove wind chime by JPott on
Flickr, used under creative commons

When do you back down, and when should you be bolshy? Is it a matter of experience, or are there any hard and fast rules?

 

There is plenty of best practice guidance that can be applied to websites:  

• Accessibility
• Editorial style
• Branding
• Usability
• Cross-platform compatibility

And lots more, especially for public sector websites.

 

Sometimes it’s hard to follow all the rules. Sometimes it's impossible – these rules can conflict with one another. For example, NHS branding guidance states that logos should be top right. But what happens if usability testing of your new homepage design shows that users commonly expect the logo to be the home button, and the home button to be top left. How do you resolve that?

It's also common to be asked to do something that breaks these rules. For example, you can be put under pressure to put a news item on the homepage that doesn't belong there.
 

You certainly don’t want to give in to pressure and just do something that’s against your judgement because you’re being asked to by someone higher up the food chain. But if there is a clear conflict of opinions or reasoning, someone has to make a choice. That’s where your organisational priorities and web strategy can come in.

In the logo placement example, is it more important to your organisation to do exactly what the NHS branding people tell you to do, or to make your website behave in the way your users expect? In the homepage news item example, is it more important to get an urgent message across, even though it's only relevant to a small handful of staff, or to delay the message while the content author sorts out a better way of communicating with his niche audience?

 

Because whichever way you go, you need to be able to explain why you chose that route, either pointing to empirical evidence (e.g. user testing) or a documented decision path (e.g. a policy, corporate document, meeting minutes, or email chain). Be clear who is empowered to make those decisions – is it you, or do you have to escalate?

 

If you really don’t want to back down on something, ever, you probably need to enshrine it in some form of policy, or if your organisation operates on a less formal structure, by convincing the highest authority (such as the CEO) of your case, so you know they’ll always back you.

 

For your own sanity, it is worth applying the 80:20 rule. This might mean applying all your best practice guidance in 4 out of 5 situations, and allowing 1 in 5 pages to not come up to scratch; or it might mean applying 4 of your principles without exception, and being flexible on the fifth rule. 

 

Eighty per cent compliance should be enough to demonstrate the usefulness and worthiness of the guidelines, without giving you a reputation as a harridan. The worst thing you can do is be so inflexible in applying rules, that people walk away and look for another solution in order to bypass you, whether that’s phoning your colleagues or boss to see if they’ll give a different answer, or building their own separate website.
 

Key points:

• A little compromise can be the key to a successful working relationship for years to come.
• Listen and understand their point of view.
• Know your boundaries and how far is reasonable to go to fight your corner, and when to back down for the greater good.
• Know what to do when you can’t solve the problem yourself.

 

A lot of this is about experience, but it’s also about being confident in your arguments (why you are asking for something to happen) and in knowing where you and your policies stand in the pecking order, not of who is more influential than whom, but of organisational priorities.

 

Dealing with requests for news features: Whose homepage is it, anyway?

Who's got top billing?
Image by Michael Comiskey
and used under creative commons

Webmistresses and intranet-meisters will quickly recognise a serial homepage news item requestor.

  

This person thinks their service, event or publication is the only topic that anyone in the world/organisation can possibly be interested in, and is so vital it must be featured prominently for at least a month.

  

You might think you can feature it for a day or two and then remove it and they won’t notice – wrong. The moment you give something else top billing, your phone rings, and they’re telling you that they’ve had loads of feedback that no one can find their information.

  

That’s not to say their anecdotes aren’t true. Those who have always been given homepage features for prolonged periods may not think it's important to put much thought into their permanent pages – if indeed they have them. They've probably not thought about making them easy to find, using search-optimised language. They have also trained their users to be lazy, so now they expect to be able to spoon-feed their audience with a direct link, rather than using the search or A to Z or navigation occasionally.

 

What to do

• Spend some time with this problem user. Understand what they need, and offer genuine solutions where you can.
• Explain that it’s not wrong to expect users to have to work a bit and look past the homepage, as long as you educate them of the need to do so, and make the search and navigation work.
• Recognise that the web team may partly be to blame – have you actually checked that their pages are in the right places in the navigation, cross-linked them from relevant related pages, and done what you can to boost the return of logical search results? Is it easy to find archives of older news items?
• Explain that after a while users will become blind to the same old content. Better to take the feature away and bring it back again later in the month, because the visual impact of the change (especially of a new image, but even of the changing shapes of the words on the page) will do more to draw attention than a clipart icon that's quickly becoming part of the furniture.
• Explain the dilemma you're facing. For example, you might say there are 2,500 pages on the intranet and, believe me, everyone wants a slot on the homepage. We can’t possibly do this so we try to be fair, and rotate in everything in a timely fashion. but we must also ensure that the structure, search and permanent content is top notch, so everyone can find what they need regardless of the current homepage content. (Then drawn them into your plan to improve their permanent pages.)
• You may also be able to offer some alternative channels or widgets for promoting their content. For example, send them to internal communications colleagues for possible inclusion in the next all-staff email, or see if they can turn their news item into a question for a poll, interview for your staff magazine or feature for the chief exec’s blog. You might be able to re-purpose web news for your intranet, or vice-versa. If your organisation still has a print budget you could even send them off to a designer for a poster campaign.

  

Rather than seeing this person as a periodic pain, try to fix their problem. It may not rid you of the requests completely, but at least you’ll understand their requirements better and, with luck, they will understand why you can’t always give them top billing and appreciate that you are doing your best to help them. You’ll also hopefully be better able to differentiate between times when they are ‘crying wolf’ and when there is a genuine need to pull out the stops for them.

Defining 'web-ready' content

The green light.
Photo by lovesonic on flickr,
and used under creative commons

You should not - cannot - blindly accept every request to publish. Web teams act as guardians and gatekeepers to ensure only high quality content that makes sense in the broader organisational context is published online.

For me, ‘web-ready’ means:   

• If there are PR implications to publication of this information, it has been cleared with the relevant communications or press office lead, and appropriate arrangements for post-publication publicity have been made.
• The website is the most appropriate place for this to be published (rather than, say, the intranet,  or a newsletter).
• The content is yours to publish. Who wrote it, and who owns the copyright? Is it already available on another site you can link to? And if yours is an official website, such as that of a government organisation, an additional factor might be whether your organisation or department is obliged to publish this information. If not, why are you publishing it?
• Any technical content (clinical or scientific, for example) has already been checked by the appropriate expert or authority.
• Written to house style, with correct spelling, punctuation and grammar.
• If it is a publication or designed document, it conforms to branding policies, and ‘gateway’ requirements if your organisation has them (a series of checks performed by your publications or communications team, that may result in the issuing of a unique code or publication number).
• If it is a webpage, a suitable page template has been followed and a location for the content has been identified in the website structure.
• The content is accessible – for example, all images have appropriate alt text.
• Any supporting information, such as author details for metadata fields, has been supplied.
• There is a plan in place for keeping the information reviewed and updated, where appropriate, and a contact for any queries that arise after publication.

These checks can become second nature over time, but every now and again it's worth reminding yourself - and the people supplying content - about what you should be checking for and why.

Who we are: who cares?



Paper jam (courtesy of nanny snowflake
and used under creative commons)

One of my colleagues, Mrs P, is currently campaigning against the ‘Who we are and what we do’ paragraph that seems to start every department’s intranet page.

We’ve got something similar on the website. It’s a waste of space because basically, most users don’t care about the history of the department, who was appointed when, or your strategy for waste disposal. That’s not how your service users are going to get their job done. And all that descriptive padding and self-congratulation just gets in the way of people finding the useful information.

Intranet navigation shouldn’t be department-based because, for example, not everyone knows instinctively that it is IT who fix networking issues with the photocopiers, but if you have run out of toner cartridges, you have to log a call with Facilities instead.

People shouldn’t need to know who to ask to get a job done.

It’s even more important on a public website. How is a member of the public going to know that they’ll find information about their asthma clinic under the Specialist Medicine department’s page?

In theory, no matter how the navigation is structured, you’d hope that search would help. If you search ‘photocopier’ or ‘asthma’, you’d expect to find your answer.

But often departments are so busy describing themselves in important-sounding management jargon, that the simple keywords for their services are missing entirely. Or they are hidden on the fourteenth sheet of a gaudily-designed and poorly-constructed Excel document named ‘Useful Information v2.0’, where they are mentioned in a couple of FAQs.

So Mrs P and her team are re-focusing the intranet content around Services (things people can help you do) and Tools (things you can do for yourself), and keeping department information down to a minimum.

Please look for this ego-fluffing guff on your website or intranet, and consider whether it adds any real value for your users. If not, it’s most satisfying to hit delete... and wait to see if anyone actually notices.

User testing a new feature – the content perspective



Can you spot the fatal error?



Web managers and content editors should be participating in the testing of new features on your website (or separate apps if you have them). See James D Clarke’s blog on how not to launch an app for some of the things you can help avoid.

It’s not just about checking for typos or even house style:

• The manager or content person is usually not the person who has carried out the technical development, so you have a fresh pair of eyes to bring to the project.
• You have a pretty good idea about the level of ability and understanding of your users – and may be able to get hold of some ‘real’ users to help your techies complete their testing. 
• You’ll probably be a quite technically-savvy person, so if you personally struggle with any element of the application, it should be a major flag that there’s a problem. 
• And out of sheer self-interest, you’ll be at the sharp end of responding to any complaints, so it’s a good idea that you try to iron out any flaws before launch.

Test scripts

If your organisation is well-versed in user acceptance testing (UAT) and protocol-driven, you may be given a script to follow. This is a series of instructions about which buttons  to press and what to enter in which boxes. You will be asked to ‘pass’ or ‘fail’ specific actions, and provide notes.

Offer to be the guinea-pig for the test script before other users are asked to follow it, so you can ensure the script is well-written and makes sense to people who haven’t been involved in development.

Beyond the script

Even if you do have a script, it’s always worth going ‘off-piste’ and looking at other aspects that may not have been included, because the script is often about technical functionality and you have other feedback to offer.

Look at all the content for house style, spelling, grammar, punctuation and plain English. But most importantly, check the text actually assists the user of the application. Is there too much distracting and irrelevant introduction blurb, or are some key instructions missing?

Persistent issues

If you discover persistent styling issues (developers seem Fond Of Using Capitals, for example), you must gauge whether you can provide one overall change instruction that the developers can apply throughout the site, or whether you need to go through each page editing as you go. The latter can feel very time-consuming and pedantic but remember not everyone is trained to spot stray apostrophes – your skills are needed to avoid distraction and nuisance for users.

Not just the obvious

Remember to look at text that doesn’t appear at first glance. When you fail to complete a mandatory field in a form, does error text appear, and does it make sense? If you have to register to use a function, what is the wording in the email confirming that you filled in the form? If there are security questions, are there enough options for everyone to use them (not everyone has an oldest niece, a place they got married, or a pet)?

Break it – they’ll thank you

Lastly, actually positively try to break the system. Put letters in a phone number field and see what happens. Put in the wrong password. Click buttons if you are not sure what they do.

Don’t feel bad if you spot errors. Your development team should have built in time to fix any problems, and in the long run they will be pleased that it was you who spotted the problems, and not the big boss or an important external stakeholder. Be nice when you provide your feedback, and offer to help where you can, because you have a lot to offer.

How to get content: 4 ways to avoid more meetings

Building relationships with content owners is really important. But one meeting can so often lead to another, and as a website manager you find yourself having the same conversation over and over again (sometimes with the same person).

Them: We need a website for our department.
You: Let’s start with some information about the services you provide and helping people to do useful things such as contacting you. We can put this on the organisation's website, where people are expecting to find it.
Them: That’s easy. I’ll have something for you next week.

In the majority of cases, the content never appears.

Rather than wasting your time repeating yourself, try to find out why the content is not being supplied, and if you can help.

1. Make it clear you don’t need a perfect polished product.

They may be great at their profession, but not everyone is confident in writing. Tell them that knocking off a few bullet points with the plain facts is fine, and that typos don’t matter. You’ll take care of the style and proofreading.

2. Offer to interview them.

You can do this over the phone or in person, with your lead contact and other members of their team. Then write up your notes into draft web pages, and send it to them for checking or filling in the gaps.

3. Find someone else.

Diplomatically ask if there is another person in the department who can take some of the burden. In a hospital context, consultants often want to take the lead, but may not have time. But junior doctors, nurses, administrators and even patients can do the job just as well. They just need time, knowledge, and enthusiasm.

4. Write it yourself.

As a last resort, if you really need some content and it is not forthcoming, gather what information you can from the internet and their publications, and draft something yourself. 

• Walk round to the ward or department, and take copies of their leaflets. 
• Use a person's (public) LinkedIn profile to draft a biography. 
• Look at similar services in other countries or towns, to get ideas for headings and the types of content that users may find useful.

Don’t worry that there will be gaps for specific details such as email addresses. Then send the draft to the service manager and ask them to fill in the gaps, assuring them it will not be published until they have checked it. Be prepared for their outrage at any errors – but you’ll definitely get a reaction, and hopefully some publishable pages.

Six unwelcome words and phrases

Every pixel of your website is precious. But we often waste space with filler words and phrases that make our sites look tired and don't help our users.

The words I'm shooing off my pages are:

1. Welcome

There's nothing more cheesy than a 'Welcome to my website' message.

It's old-fashioned and naff.

Instead of: 

Welcome to the Members’ area

Make your heading: 

Members’ area

2. Note

'Note' is a waste of space when used as a heading or in bold at the beginning of a paragraph. Readers scanning the page will only see the word note and will miss the subject of your Note. 

Note: cheques should be made payable to the Fund of Elizabeth.

or

Cheques should be made payable to the Fund of Elizabeth. 

This also applies to NB.

3. Please (excessively and ungrammatically) 

Be polite but don’t tie yourself in knots. Give straightforward, direct instructions.

Readers are reminded to please take their bags with them. 

Can quite easily become:

Please take your bags with you.

It also makes you sound desperate if you have to plead with your users:

Please download the booking form.

Instead, make the first word the instruction. You'll also be front-loading the action keyword and making your text easier to scan:

Download the booking form.

4. Thank you

Say thank you when someone has actually done something. For example, after a web form has been submitted, a thank you message can confirm that they have completed the task, and can tell them what will happen next.

But there’s no need to thank people just for coming to your website:

Thank you for visiting the organisational intranet. We hope you find it useful.

Use the space to highlight some top tasks or features that the user might be looking for. They have come to your site to do or know something, not to read inanities.

5. On this website you will find...

If your content and navigation is any good, you can drop this phrase.

Instead of:

On this website you can find out about the role of dental nurses, get information on how to train, and the career options available.

Get your teeth into some decent menu headings and links:

• What dental nurses do
• Training
• Careers

Don’t waste your homepage repeating the menu links. Highlight something fun or useful instead. 

6. Coming soon

Never load a blank page and say that the content is on its way.

What a horrible disappointment for your user. And when is soon, anyhow? 

Strip out the wasted words

All these phrases and words are really easy to fall back on - like FAQs - when you are in a rush or can't be bothered to have a fight with a content author. But they're all unhelpful bits of padding. Let's show them the door.

The question I’m most frequently asked

In some circles I have a reputation for hating FAQs (frequently asked questions). This is why.

FAQs often creep in because people are too lazy to write proper web pages or are too scared to say no when departments say they want them. HR and IT people are particularly fond of them.

And there’s no need. They are easily re-written. Just change the questions to headings.

e.g. “How do I book a course?” becomes “Book a course”. 

FAQs are bad for many, many reasons. Some of the main ones are:

• They don’t front-load the keywords that you want people to see – your eye is drawn to the What, Why and How in the question, rather than the important words (e.g. in the above example, you want people to see the word “Book”). People scan rather than reading every word online, and this format doesn’t help them find the information they want quickly.
• They are often repetitive. The same answer is given to multiple questions.
  e.g. “How do I do thing x ? Contact person y. How do I do thing z? Contact person y."
  Instead, just have a clear heading at the top or bottom – “Contacts”.
• They create grammatical headaches. Should it be “How do I…” or “How do you…” ? They are hard to write well, and also hard to read, because the user is distracted, thinking about what is meant by “I” and “you”.
• They don’t lend themselves to a logical layout. Due to the endemic laziness of the format, you often find them listed by date issued, rather than grouped together by subject. There may also be multiple answers to the same questions, issued on different dates. It is better to have a simple heading and the correct, current, information under it.
• There are lots of extra words when you try to write in Q&A format. But online, less is more. People won’t read long sentences and paragraphs online. Be less chatty and more direct.
• They often end up as a single, very long page – again, really hard to read. Better to break the information into logical sections and multiple pages.
• FAQs aren’t good for SEO (search engine optimisation) either. There is unlikely to be a good summary of the content at the top of the page if the key information is scattered throughout a number of answers.
• They’re old-fashioned. This doesn't reflect well on the rest of your website.

The general rule is that if you need FAQs, the rest of your content is structured badly. I grinned when the lady running my recent GDS style training said something similar. It's worth noting that FAQs are banned on www.gov.uk and these guys base their style guide not only on theoretical best practice, but on user feedback and testing.

What have I missed?

Emergency preparedness for web teams

Should web publishing staff be actively involved in emergency preparedness training?  

 

I’m not talking about social media – I think it’s becoming more mainstream to include SM in emergency response, and therefore in training exercises. Just think of Twitter Gritter, or look at the way BTP tweets to let people know when there’s a ‘one-under’. In this blog I’m thinking of the day-job web officer who may be uploading the press releases (you’re lucky if your press officer can do it themselves), and is certainly publishing the supporting pages - FAQs (*shudder*), detailed professional guidance and pithy public advice. 

 

Of course a lot of this depends on your organisational structure; this is another argument for close integration between the press office, social media and the corporate website. But too often the web team are still seen as the dumb, mechanical tool of the organisation – no more responsive than a typewriter being used to bash out the latest media statement.

 

While it’s important that the web team shouldn’t hold things up in an emergency by querying every misplaced comma, they do have a significant and enduring contribution to make. They’re not just there to provide something for your tweets and Facebook pages to link to, or to generate a ‘further information’ URL to add to your Notes to Editors.

The supporting pages that your web team publish are the ones that are going to be pored over, not just during the crisis, but in future when people look back to see how you handled the situation. It’s not much good if you can’t find them through Google or your own site search, if they break when you look at them on a Mac or mobile, or if it’s hard to navigate to them logically through your IA. A naff little homepage ‘quick link’ can’t stay there forever, and won’t help with future SEO.

Your web team must be able to stay calm in a crisis and have the tools to do their job. This means: 

• They need to understand the organisation’s processes for responding to a major incident (What’s the target response time for this? Who needs to sign off before a page is published? Who should be told if someone spots an error or ambiguity? Who needs to be sent a link as soon as the page is live?).
• They also need to have experience of working under pressure, so that they can anticipate their own fallibility (Does this need a second pair of eyes?) and perceive errors in judgement in others who are stressed (Do you really want to move that web page now? You do realise it will break the link that you’ve just sent out in a press release?).

So next time you’re planning a major incident exercise, think about your back-office webbies as well as your PR team.

No e-news is good e-news...

"You know about websites – you can set up an email newsletter, can’t you?"

If you’re thrown in the deep end of news-by-email and email marketing, here’s a buoyancy aid.

Before you start

• Have a clear purpose. What’s the business goal? This sets the content agenda.
• How will you measure success? Generate custom URLs to track website traffic coming from your mailing.

Content

• Make your subject line interesting and relevant to your subscribers. Not ‘Issue 12 of the hospital newsletter’ but ‘A&E waiting time improvements, beating superbugs, and more’. If you have a system that tracks opening rates, try two different subject lines on a sample of your mailing list, and mail the remainder with the best-performing hook.
• Choose the right From address for extra impact. Are you more likely to open an email from a real person, or from ‘Hospital News’?
• Content needs to be relevant to the business goal – think twice about issuing a re-hash of your latest press releases.
• Keep it brief.
• Make it easy to browse. If there are multiple articles, include a contents list that will be the first thing people see when they open the email.
• Follow normal writing for the web best practice. Chunk text using headings and bullet points and write meaningful hyperlink text.
• Proofread.
• Set a sustainable schedule if you’re aiming for regular mailings, especially if you need to get others to contribute or sign off content.

Data protection (stay with me)

• Where did you get your mailing list? People need to agree to you using their information for this specific purpose.
• Include a privacy statement saying how you will use and store personal details.
• Make it clear how to subscribe and unsubscribe.
• BCC. Don’t share your mailing list with everyone on it.

Design and technical bits

• Branding should be consistent with your corporate identity and ideally with your website – especially if you’re linking from your email to your site.
• Use HTML email for designed elements. Styles needs to be applied in-line rather than using something like a stylesheet.
• Make sure the email can be read as ‘text-only’ – some email systems don’t allow graphics and HTML or give users the option to turn them off.
• Don’t clog up inboxes with large emails.
• Avoid attachments, because they can get your email caught in corporate spam filters.
• If you’re using an third party system to send emails on your behalf, make sure the provider has whitelisting measures in place to ensure emails are not flagged as spam.
• If you’re using a mailing system that is pretending to come from your corporate email domain (‘spoofing’), tell your network team to ensure your own colleagues can receive your emails.
• Test on all different types of email – from Outlook and Hotmail, to how it appears on smartphones.

Finally

Keep evaluating against the business goals. Innovate, iterate, and enjoy.

email etiquette - to CC or not to CC

Is your work inbox stuffed with incomprehensible, oversized or irrelevant messages? Follow these simple tips to make sure colleagues and customers smile when your email arrives.

get your message across

• Use a meaningful subject line – never leave it blank.
• Keep it short – one subject in one email.
• Use clear English – not jargon.
• Avoid abbreviations and acronyms unless you’re sure the other person understands.
• Check your spelling and grammar – a misplaced apostrophe can change the meaning of a sentence.
• Don’t write ALL IN CAPS (which is hard to read, and is seen as “shouting”).

what about the bells and whistles?

• Use ‘urgent’ flags sparingly.
• Use simple formatting – use the standard font and avoid lots of fancy colours, bold and italics.
• Avoid BCC – it’s sneaky.
• Don’t CC ‘just in case’ – only copy in people who really need to know.
• Rather than attaching large files, save them in a shared drive.

when not to email

• Can you phone instead? Or even walk round and talk to the person?
• If you’re in a bad mood, don’t bang out a cross email and hit send. Save a draft and come back to it later.
• Don’t use sarcasm because it can easily be misinterpreted. And never write anything in an email that is libellous or otherwise inappropriate – even as a joke.

These tips are intended for work email but I think most of them can be applied to your private correspondence too. And if you're organising a hen night, one extra rule - be judicious in your use of exclamation marks...

Looking back to look forward

What have you achieved in the last week? What about the last month, or the last year? What did you achieve in your last job?

We’re a month into the New Year, and for me it’s also been a couple of months since I changed job. It’s a period of relative calm and, I think, a better time to reflect.

For a web manager, the days can feel like a blur of removing capital letters, running reports, meetings with content providers and battling to fix glitches. It’s really important to step back occasionally, to see the progress you’re making, and recognise each of these regular tasks as part of the bigger picture. So if you’ve done all these things today, you’ve also been implementing the editorial style guide, making yourself accountable, developing your content strategy and ensuring your site is reliable and usable.

Keep the evidence

Don’t wait till you’re buffing up your CV or preparing for your appraisal to look for the evidence. Keep a record of everything you’ve done as you go along. It’s easy to forget all those single new pages you’ve added or sections you’ve reviewed, when your website feels like a never-ending task. But it looks impressive for your boss – and is a great psychological boost. Look how far you’ve come and how much all those little changes add up.

It all adds up to a plan

The same applies to looking forward. Don’t wait till you’re asked to write a plan, then stare at a blank page until you pass out (or start writing “I am a fish” over and over). You have ideas and thoughts every day, and they might not be earth-shattering on their own, but they can add up to a great plan. And capture your subsconscious genius. 

• When you spot an out of date page but don’t have time to edit it immediately, write it down on your ‘review’ list. You WILL forget it.
•  When you’re on a competitor’s website and spot something interesting they’ve done but don’t have the resources or contacts to produce your own version immediately, write it down on your  ‘new content wish list’. 
•  When you wake up in the night because you just couldn’t get that menu structure to work, write it down on your list of items for user testing or to talk to colleagues about.
•  When your boss mentions her grand schemes that you don’t quite ‘get’ after she comes back from the latest board meeting, put them on your ‘blue sky thinking’ list and mull or research them when you get a chance.

An evolving picture

It’s not just about lists – visual cues help.

Take screengrabs for posterity, not just of things that have obvious or flashy design elements like your homepage, but of basic content pages and menus. The best websites evolve slowly over time rather than having massive redesigns every couple of years. As the web manager you’re so close to your site you barely even register the incremental differences that altering the size of the standard font makes, or making it grey rather than black. This quickly gets absorbed into ‘normal’. But in 2 years time when you compare, you’ll see a massive change.

Counting your successes

And while it can be tricky to measure some things, it’s obvious to keep a regular track of your web statistics – not just top level statistics, but examining growth or otherwise of new areas or parts you might want to get rid of. Record the number of pages added or edited or approved or rejected. Track the number of requests into your mailbox, and how quickly they were responded to.

So now the festive whirl has faded (and the pain of writing all those handover notes has eased), I’m enjoying looking back, putting my achievements into perspective, and learning how I can realise the potential of the new opportunities ahead.

I miss my CMS

I’ve just moved to a new job and left behind a content management system (CMS) that I specified, procured, and then worked with for about three years. Call me sentimental, but I miss the old girl. And not just that particular CMS – I miss having one at all (except for a teensy bit of the intranet).

I'll explain why I’m feeling so bereft:

• Speed. With a CMS you should be able to add an item to the site’s A to Z in a couple of clicks rather than 15 minutes copying, pasting and editing multiple pages.  And who wants to have to search the whole site every time you change a link, making the same change in multiple places, when you could  update it in a link library just once and have it shared immediately across the site.
• Workflow. Forget pestering your boss to ask her to approve your work. Within a managed system she might get an automatic notification, or maybe even a nice orderly approval queue. And wouldn’t it be nice if she could see exactly what changes you made from the old version, and refer to an audit trail that doesn’t rely on manual updating of spreadsheets.
• Quality assurance. As well as spotting broken links and accessibility issues, if you can lock down your WYSIWYG editor you can prevent all sorts of extraneous colours, fonts and styles sneaking on to your website or intranet (those pesky contributing editors...).
• Support. When it all goes wrong, it’s great to have a whole user community and some experts (paid to be) on the end of the phone, rather than always having to wade your lonely way through reams of code or rely on – gulp – IT support.

Of course all this depends on having a CMS that is fit for purpose, that suits your way of working and that’s really giving you value for money.

There are always a few niggles. But guys, however much you hate your system when it doesn’t save your painstaking editorial changes or forces you to go into the code to sort out a nested list, spare a moment for CMS-less me.

Send technology, and tea.

PS They didn’t pay me.

Managing contributors in a devolved content management system

One of the toughest parts of a web manager’s job is dealing with the groups of authors who have access to your content management system (CMS).

Not every organisation has a CMS, and the question of whether or not to devolve any element of editing in the first place is quite another blog post. But if you use any kind of devolved system you will probably have come across some or all of these challenges:

• People who insist on access ‘just in case’ but actually never use it
• Regular users who simply can’t – or won’t – take on board house style, web best practice, or anything else you regularly end up correcting
• Managers who want to have final sign-off and don’t understand why communications / the web team want to check their work
• Profligate uploaders who have no idea about version control, putting on multiple versions of the same document
• Tweakers who just want to play with the code or use every colour and heading and clip art image they can find

And there are plenty more. But rather than make this post a moan, here are my top tips for reducing the pain. 

In fact, you might even reap some benefits and save some time and energy.

• Make it a prerequisite that editors must use the CMS regularly. It is the once-a-year users, and those who try to use it for the first time six months after their training, who cause the most problems. It will usually be genuinely quicker and easier for them, and you, if they simply email you their updates.
• Provide more than just technical training, whether that is running workshops, a blog or providing one-to-one support. Help editors understand style, accessibility, writing for the web; share your expertise. Make sure they know how to get help.
• Keep editors informed of changes and ask their opinions – making them feel valued and part of a community will help your relationship with them.
• If you can, adjust CMS settings to restrict the amount of freedom your editors have. If possible, prevent them from being able to get into the code, or make simple changes such as removing the ‘italicize’ button from the style options in your WYSIWYG editor.
• Don’t just rely on your CMS though - use a workflow to approve or reject content centrally. This enables you to ensure consistency and uphold standards. There will always be someone who uses bold instead of an H2 style, or insists in writing all in caps.
• For those who oppose you approving their pages:
• Demonstrate the value your editorial hand can add, for example by re-working a section of their content and providing evidence of improved usability.
• Suggest a trial period to allay their fears.
• Ensure you really are adding value; you may have no need to approve committee papers, policies, financial statements or press releases. Considering allowing this kind of content to bypass the workflow.
• When rejecting items, explain what the editor has done wrong and why and ask them to make corrections. If you always do it yourself you can’t expect them to learn.
• Regularly review the list of CMS users and don’t be afraid to disable accounts of those who haven’t used it recently or who are unresponsive to training.
• Work with key stakeholders to enshrine your principles in formal policy.

Do you disagree with my list? What rules work for you? 

What to Tweet: ideas for everyday organisational tweeting

Congratulations on setting up your corporate Twitter account. Now: what are you going to say?

For public sector organisations who are only just starting out, it can be daunting coming up with enough material to create a useful, active account.

Sometimes we all get tongue-tied when faced with “What’s happening?”

This is my go-to list, but I’d love to know what other types of tweets you post regularly.

News and media

• Press releases – as long as they are not the only things you tweet. If you publish them on your website you may be able to generate an RSS feed to automatically post these to Twitter. 
• Breaking news, such as disruptions to services or major incidents. Ensure you have the appropriate authorisation in place and it is part of your overall communications and media handling strategy. 
• Positive news stories about your organisation. Even if they’re almost word-for-word reproductions of your press releases, the headlines used by newspapers are often more attention-grabbing, plus radio and TV news sites may contain supplementary audio or video clips. 
• Instances of your experts talking about national issues in the media, being published or receiving awards - even better if you can trail them in advance of a TV or radio appearance.

You could also publish rebuttals of negative news stories, but treat with extreme caution especially if it’s an emotive or sensitive issue. If you get a direct question by @ or DM, seek an official line and advice from your press officer. It may be appropriate to steer the discussion offline. And sometimes it’s best to stay quiet.

Web, print and multimedia content

• Links to new content, or existing content that you’re particularly proud of or that is particularly topical. This could be:
  
  • Video
  • Photos
  • Patient experiences 
  • Departments or services 
  • Transactions that can be carried out via your website
  • Job vacancies
  • Performance measures and statistics
  It’s ok to pick a random piece of content. People don’t read your Twitter account like a book so most of them they won’t remember you tweeted the same video when it was first put on YouTube 6 months ago and even if they do it might remind them to watch it, comment or retweet it. But don’t spam everyone with the same video every day for a week.
• New publications, such as your annual report, corporate plan or even simple leaflets. If you have a regular magazine, you can tweet that the new issue is out, and repeat this while highlighting various articles over the following days. 
• Your other channels (sparingly, as channels can attract disparate audience segments). Tell your Twitter followers you’re on Facebook, YouTube and Quora, as well as on the end of the phone.

Promotion

• Events such as open days and meetings. Trail them in advance. Invite questions before and during. Tweet updates and multimedia during the event, and link to the minutes, transcript or other records afterwards.
• Fundraising for your organisation. You can’t link to each individual’s JustGiving page but you can draw attention to big charitable events or outstanding achievements.
• Advice and campaigns. Whether it’s the winter flu jab or a campaign to keep a particular service in operation, Twitter can gather people together and spread messages. The messages you see on posters round your organisation can become the theme of a week’s tweets and you can invite interaction, comment and support, as well as sharing evidence and arguments.

Feedback

• RT compliments from service users – with caution. Do ensure you put the tweet in context by researching a little way into the timeline. It would be insensitive to retweet a compliment about your cancer nurses when the author’s father has just passed away on the ward. And ensure you also thank the user.
• Invite comment. You’re on a social platform. Ask questions and request feedback about your organisation but ensure it’s then channelled appropriately.

Community

• Local news and events, especially those that are related to your organisation’s area of expertise and the interests of your followers. Thus local councils, health service, emergency services, universities, community groups and charities might, for example, retweet selected items of one another’s content. This adds to the sense of community and you may like to adopt a geographical hashtag.
• Relevant national news and events, especially if you can add a local spin.

Inspired?

There’s no magic formula about how many tweets you should issue per day and it’s certainly better not to tweet than to constantly spam your followers (what not to tweet is a whole ‘nother blog post). One or two pithy nuggets a day might be quite enough, if the quality is high. Test different styles and frequencies on your particular audience, and see if it has an effect. The worst crime of all is silence – registering an account and never using it, or using it a few times then drying up completely.

Tell me about your sources of inspiration and what you think of my list.

Top of the class?

Yesterday saw the publication of the Socitm report that informed a discussion group entitled ‘How good is your hospital’s website’, at the NHS Web Futures ’11 event.

The report is:

“...a mini survey of the usefulness and usability of nine high profile, city-based hospitals in England... [which] assessed how easy it was to complete five common tasks likely to be high on the priority list of every patient...
“The survey revealed a distinct lack of customer focus likely to leave patients and visitors struggling to find this key information.”

Before you read the mini survey of NHS hospital websites in full, I’ll declare my interest, which is that ‘my’ hospital, Southampton General (part of SUHT) came out rather well.

I have mixed feelings about this. It’s all very well being the model pupil but if you and your small selection of classmates are all dressed in shades of ‘must try harder’, and some of the kids you consider the cleverest (such as Imperial or King's) are excluded from the rankings, then it’s a strange victory.

On the other hand, I viscerally support the principle of focusing on the user experience, rather than giving in to internal politics or lazily building everything around corporate structure. I agree we have a lot to learn from web best practice in general, and from each other.

Socitm didn’t carry out this survey for their own amusement; there’s a suggestion that they could facilitate a programme of review, learning and networking for the NHS similar to Better Connected, from which local government websites benefit.

Why might we want this?

An external source of validation might:

• provide new qualitative and quantitative measures of success;
• instil a healthy sense of competition and enable benchmarking;
• give less experienced web teams a basic roadmap and some good examples to follow;
• gain recognition for the work carried out by web teams and add weight to negotiations for resources (in local government, CEOs and elected members are rather interested in Better Connected scores);
• create economies of scale: for example, if the review questions were based on evidence of user requirements, it would save individual Trusts repeating the same basic research.

What do we have to lose?

I've got some questions:

• How much would it cost to sign up to the process? (Though what price a poor website?)
• Is it valid to have objectives set for us by an external body?
• Might some organisations become lazy and reliant on the service? It would not solve all our problems for us – there’s still hard work involved.
• What if one size doesn’t fit all? Some websites might fail to meet very specific and valid local requirements while they are busy trying to meet nationally-agreed, but less locally-relevant, criteria.
• What ‘teeth’ does this review have? Council websites haven’t improved solely as a result of benchmarking. Many other factors been important, notably government requirements for certain services to be provided online, and mandatory submission of links to certain content to the central DirectGov hub.

A taste of things to come

Events like NHSWF are rare opportunities for NHS webbies to meet, share and learn. Should we go down a route similar to Better Connected, with perhaps an ‘official’ (DH-sponsored?) flavour, it might be the shape of things to come.

The report summarises the model of good practice and ‘top tasks’ tested in the survey, but a few points leapt out from the ‘How good is your hospital’s website’ discussion, facilitated by John Fox:

• The importance of being able to find particular top tasks direct from Google – how many of us focus on menus and the homepage, and neglect SEO?
• The fact that some very pretty websites were actually impossible to use. They can fool your stakeholders but fail when you are a patient or visitor.
• It’s particularly important - and difficult - to prioritise user experience if you are a Trust with multiple distinct hospital buildings or sites.
• Sometimes we overlook the basics. We mustn’t get blinded by our specialist knowledge and forget that many really don’t know or care about, for example, the difference between primary and acute services.

In reality

It was disheartening to note defeatism among some website managers.

 “I would like to, but you don’t know how strong and influential those people are”

Maybe I’ve just been lucky to work in two public sector environments where I’ve had a supportive boss, been encouraged to innovate, and always felt able to put forward a reasonable argument for change.

Partly it must genuinely be due to issues with corporate culture, personalities and politicking, but partly I think websites in some NHS organisations just don’t have enough weight, by which I mean expertise, evidence, experience and resource. Might a national comparative survey and support service help?