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?