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.

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.

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.

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?