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.

 

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.

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?