I’m in Cape Town for CS Forum 2012. It’s great. Even better, I’m here to speak at CS Forum 2012. That’s exciting.
For reasons I can no longer remember, I shunned Powerpoint in favour of Prezi. Here’s the resulting presentation:
Recently I’ve worked in a group looking at a large part of our site structure and information architecture (IA). This hasn’t just been a bunch of web experts sitting around talking in cosy acronyms and agreeing with each other. Instead we’ve been dealing with people from all around the company (which means, yes, having to speak in plain language to regular people) and disagreeing amongst ourselves as we do.
I like explaining things to people who don’t come from my little corner of the world. It means I have to think clearly and go back to basics, which often leads me to new realisations. I also like having good debates with other web people who see things differently to me. This reminds me that the basics I go back to are subjective, and sometimes worth rethinking. Getting both of these things out of the same project has taught me a few things worth sharing. For now I just want to get these things listed briefly; in time I’ll write a post for each of them.
The difference between the separate-but-related concepts of IA (the structure that fits all of your pages together) and navigation (the links, buttons, feeds, searches and other things that people use to move around your site) can be really confusing to non-web types. Your site’s menu is derived from your IA, but the rest of your navigation need not bear any relation to it. Try explaining that to someone who only sees the web as a user.
Internet users don’t need to know the difference between how sites are put together and how you move around them. But when those same users are also stakeholders in an IA project, things can get tough.
You’ll probably find yourself building an IA long before you move onto creating the content that fits into that architecture and gives your site the rest of its navigation. These tasks can inform each other and solve problems for one another, but if you need to get one of them done and agreed upon first this isn’t going to happen properly.
The moment you sketch out your IA or site structure in a visual way – whether as a tree, in a spreadsheet or in any other way – you’ve made a representation of your site, or a metaphor for it. You have to do this since it lets you visualise the whole thing, but it subtly changes the way you see your site in other ways too.
While you’re rearranging branches on your tree or cutting and pasting cells around a spreadsheet it’s easy to forget that you’re working on a metaphor for your site – something that your readers or users will never see – rather than the site itself. All metaphors are imperfect, but good ones have the unfortunate side effect of (a) letting you forget that they’re not real, and (b) obscuring some things as they clarify others. You and your team all need to remember that the picture you’re building has to turn back into a website.
Your site structure starts from the homepage when you map it out, but you can’t expect your users to always begin there. They might search their way into any page, or begin from a landing page about a particular product, sale, or campaign. They could get a deep link from an ad, a referring site, a friend, or from something you push through social media. You can’t see this in a visual representation of your IA.
Visual IAs also obscure the way people will work if they’re on your site to do more than one task. Even if they start at the homepage for task #1, they won’t go all the way back to the top to start task #2.
Incidentally, this is a problem with a lot of professional user testing, which presents subjects with a homepage and then gives them a job to do. That’s not a realistic way to watch someone use the web.
Words are wonderful things but they’re never as exact as you need them to be. This is especially true when you’re talking about wayfinding, navigation, labels, and categories of content. You need to keep your conversations really clear or you’ll end up thinking something different, but nodding in agreement.
For example, when you say “products” you could mean:
If you say “we need to boost ‘Products’ up”, it’s not clear whether you’re talking about the location of the word “Products” in a menu, or informational hierarchy (the number of levels between your homepage and the section about your products), or content strategy (the way you talk about your products), or the stuff that your company makes (the quality of your products).
In a discussion about IA everything on your site is both what it is, and the idea of what it is. Often it’s also the place where that idea belongs in relation to everything else. Don’t be afraid to admit when you’re confused, and keep your conversations as clear as you can.
===
This post is 953 words long, with an average reading grade of 10.0.
Editing content? It makes sense to review major changes as thoroughly as new content, and to have a shorter, easier process for minor changes. The hard part is defining each type of change.
You might be able to publish minor content changes without any approval, and just give the content owner an FYI. But it’s more common in large organisations that the minor process will cut out everything except the content owner’s sign-off. Either way frees up time that you’d otherwise spend getting little content fixes rubber-stamped.
“Major” and “minor” changes aren’t always easy to tell apart. Strong definitions help reduce the grey area between them. Whatever you do, don’t try to “clarify” things with more categories. All that does is create more grey areas and two new problems: spending more time grading content changes than actually working on them; and the thankless work of building multiple review processes. This quickly turns into ranking your stakeholders by importance, and Pandora herself couldn’t build a box strong enough to contain that political shit-storm.
So, stick with only two processes and reduce confusion by defining each change type as best you can.
More than one aspect of a change can make it major. List things that would make a change major: any one of them alone is enough to send your content through the major review process.
Even minor-looking changes can alter who you’re writing for, which changes the content’s strategic aim. Anything that touches the strategic level is a major content change.
Every piece of content should have a clearly defined target audience. Check whether your new version of the content still fits this audience.
Example: Returning a faulty Shiny Widget
Say you have a webpage about your company’s finest product, the Shiny Widget. The H1 is “Shiny Widget” and the page is all about it, but there’s nothing saying what people should do if their Shiny Widget breaks during the warranty period. You quickly draft a sentence or two, which seems minor.
But when you check who the page is for, you see that the audience is “Potential customers who haven’t got a Shiny Widget yet”. Your new content isn’t for that audience. Either you’ve spotted a strategic gap – there’s no content for people who have already bought a Shiny Widget – which needs a larger solution, or you’ve drafted words for the wrong page.
As well as its audience, the purpose of every piece of content needs to be defined and documented. This is another part of the content’s strategic intent, so any change to it is major.
If you’re looking at a dedicated sales page for the Shiny Widget and trying to fit in after-sales service, this isn’t a minor change.
If you’re not just re-wording existing information but changing the content’s “informational load”, it’s a major change. This isn’t about the word count – it could be as little as half a sentence – but about what the content “knows”.
Examples include:
All of these can be very light changes in terms of words, but they’re all new concepts that you want your reviewers to see, and fact-check.
After every other condition, this is a catch-all. List both a numerical and a percentage change. If the word count crosses either threshold in either direction, it’s a major change.
Lots of minor changes over time can equal a major change. Compare your new content’s word count with the last version that went through full approvals. Don’t let minor changes stack up unchecked.
Adding a missing full stop? Fixing a spelling mistake? Just do it.
If you’re just fixing copy to meet your style guide or brand tone of voice, that’s minor. Your approvers and stakeholders should already know about these things so they don’t need to be involved again.
It’s not pretty, but you might “need some words to fill a gap”. If you plug it by basically repeating something that’s already on the page, that’s a minor content change. (You probably have a problem with your page design, though.)
Let your reviewers help define major and minor changes. You want a category of change that they’re not worried by, so they need a say. Without their buy-in this will never work. Be clear that the major-minor split will save time without hiding things from them.
When you can’t be certain that a change is minor, the best policy is to keep your reviewers in the loop and treat it as major. It can be a good idea to ask whether they’d like to be included next time a similar change goes through – they might just count themselves out.
Content reviews are risk management. By favouring too much review over too little, you’re at to the “cautious” end of the risk appetite continuum. Bosses don’t often like people at the “reckless” end of the scale.
You’re better leaning towards consulting too often – being open about the things you’re changing and why – than appearing to hide changes from people who deserve a say.
(If you have stakeholders who don’t deserve a say, or who withhold approval for unnecessary reasons, taking your work underground will only make things worse between now and when you tackle these problems properly.)
The more often you work with a stakeholder the better they get to know you and your work, and vice versa. This helps builds trust and makes it easier to work together. It’s much better than appearing to be the uncollaborative sneak who doesn’t know when to ask for help.
All the guidelines, definitions and documented processes in the world can’t beat a trusting relationship between you and your stakeholders or reviewers.
===
This post is 1,073 words long with an average reading grade of 8.3.
After too many years of organic growth, your corporation has a messy online presence. Sound familiar? Even though there’s no strategy, your sprouting content has followed some guiding principles. Identifying these is an important step to constructing a proper content strategy. Here’s how to dig them up.
Big corporates have been on the web for the best part of 20 years, doing what we euphemistically call “growing organically”. Now their online content is messy, overgrown and plentiful. It’s unhelpfully constructed. New growth spurts where it can; where nothing can grow content ages and dies without ever disappearing.
But even organic growth has some rules or patterns. These don’t deserve the name “content strategy”, but finding them is a step towards forming the crafted, intentional strategy that your company needs. When you know what caused the patterns, or where the rules of your untamed website came from, you’ll understand why your online content contains what it does, see what’s worked (even if accidentally), and work out what needs to change.
You just need to know where to look and what to look for.
Organic growth is disorganised, but it’s not random. Take a look at what’s grown successfully. Which parts of your website are biggest? You’ve probably got some expensive microsites – what are they about? What’s most prominent in the navigation?
There are two possible explanations for the winners of the organic race for life. Their oxygen came either from your audience, or from within your company.
Find the content that looks important, and then check your analytics to see what’s actually popular.
You also need to examine your company. The web content that you have, especially before you start planning it properly, is an expression of your corporation’s main preoccupations.
There are clues in the way your company manages those of you who work on its web content. I’m not naive enough to believe that there’s a perfect thread connecting your annual personal performance reviews, your boring monthly team progress reports, and the job descriptions that you all supposedly work to. But these things all reflect what your company cares about, so they’ve been affecting the shape and size of your organic web-garden for years.
What counts as success for your web team? Even though you’re working without a proper content strategy, this is the corporate world – you’re still measured somehow. Your boss probably uses the horrible word “metrics” to describe the measurable things that matter most.
When your web team is in its long monthly or quarterly meeting and there’s a heap of Powerpoint being projected, what’s on the one slide that matters? It’s the slide with the graphs and numbers and the comparisons to last year. It’s the “how we’re doing against our main goal” slide.
What is that goal? Total visits? Sales conversions? Form completion rates? Whatever it is, this is a major part of your accidental content strategy. (Let me guess: Your company measures your online sales, which are doing just fine while your after-sales service content is out of date and out of place.)
You’re probably given an annual going-over by your boss and your boss’s boss – what do they care about the most when they’re trying to work out if you should get a bonus this Christmas?
Is it the precision of the content you work on? Is it the amount that you produce? The response you earn in social media? Whatever your bosses care about, it’s been guiding the company’s content for as long as it’s been on their agenda.
A third way to decode the “strategy” of your messy, organic site is to look at what the people who work it have officially been meant to care about. Anything that isn’t measured, but was written into a job description, could be a secondary part of the puzzle you’re putting together.
Once you’ve worked through the evidence that’s online (the things that are fittest after having survived the unplanned world of old corporate web), in your web analytics, and in your company’s self-measurement (job descriptions, performance evaluation criteria and team targets), you’ll know why things have ended up the way they are.
Now you have a starting point as you start working on a proper content strategy. Onward!
===
This post is 920 words long, with an average reading grade of 9.0.
When you write corporate web content, a lot of approvals and sign-offs stand between your first draft and the big shiny “publish” button. I usually need 3-5 “stakeholders” to be happy with my work, but I’ve heard horror stories about companies with as many as 11 points of sign-off. Adding more people to the mix almost never improves quality, but you can keep crappiness at bay if everyone (including you) understands their role.
Their are plenty of blogs out there where writers reel off instructions to reviewers (Bad Language’s “The Art of Feedback” is one of the better ones), but that’s only half of what we need. Yes, it’s important to give reviewers a few pointers. But it’s just as crucial that you, the writer, know what you need to do too.
You need to be a team, and understand each other’s roles. Here’s what I suggest writers ask of approvers – and what we writers have to do in return.
Everyone in the review process is an expert in their area, responsible for something that no-one else is (otherwise they shouldn’t be there). Writers need the expert opinion of reviewers, but we don’t want the legal department to reorder our work or the marketing team to mess around with the small print. My guidelines for reviewers say:
Spend your time giving us feedback from your specialist perspective. Share your expertise with us, and show us where our copy doesn’t meet your expectations. Leave general editing to people with a full understanding of how web writing works.
People usually like this instruction. It makes their job easier, smaller, and better defined. And here’s what I offer them in return:
As much as you trust your legal reviewer to know the law, they trust you to write quality, acceptable copy. You need to understand their concerns and see how your draft needs to change. No matter what changes they request, you’re going to write a redraft that satisfies your reviewers and fulfils all the requirements of good web copy (readability, SEO, consistency of tone, etc).
Know your craft, and be ready to explain it. For example: “I couldn’t use the exact phrasing you recommended because it didn’t fit our brand voice”, or “Yes, we need to explain that point, but it’s covered in this other page which we can link to rather than repeating ourselves here.”
You’re a specialist. Make it clear that when you fix problems you have more on your mind than just the issue the reviewer sees.
As a reviewer you don’t need to care about every aspect of the content you’re working with. Spend your time looking for things that your part of the business can’t live with. It might be something like:
Don’t rewrite anything when you find a problem. Instead, point the issue out and describe your concern. (If you find the same mistake or issue more than once, you only need to explain it the first time). This should be faster for you, and easier for the writer.
Of course you can suggest new words, but always give comments first.
Why writers prefer comments
A good comment tells the writer what the problem is. Then we can weigh it up along with comments from other reviewers, fix the copy, and learn for next time.
Why rewritten copy frustrates writers
Rewriting copy can seem like an easy fix, but the final version has to be acceptable to other reviewers, to web best practice, and to corporate and web guidelines. Unless you’re familiar with all of these things your new words will probably create as much of a problem as they solve.
Multiple stakeholders can leave writers to cobble together an acceptable compromise from overlapping redrafts of the same content with no idea what problems actually need fixing. It’s even worse if a sequence of reviewers sees each others’ rewrites rather than the original draft.
Feedback from reviewers isn’t always easy to receive. The process is a negative thing, because people are looking for what you’ve done wrong. (They’ll ignore everything that you did right. That’s just the way it is.)
Make sure you completely understand all the comments from your reviewers before you start on a new draft. Look past the bits that seem like insults or nitpicking and get to know what your reviewers are thinking and why. Ask follow-up questions.
Once you understand why something’s not right, don’t just fix it and move on. Look for similar pieces of text and fix them, too. Let whatever the review teaches you inform other work that you do.
We need expert, informed reviews of our work, which means that you need to know the copy that you’re commenting on. Read it once to get an idea of its order and structure before you start commenting.
Reviewing takes time. It’s not as quick as a normal email reply. It’s not a meeting you can turn up to unprepared.
We have to give reviewers time. If you need something live by Friday, don’t expect approvals to start and end on Thursday.
Find out as early as you can who you’ll need approval from. Let each person know how much copy you’ll write, and ask how much time they’ll need. If you have to, reduce your schedule as well as theirs.
===
This post is 1,006 words long with an average reading grade of 8.4.
A lot of people are interested in, and passionate about, writing but there’s not often a clear way to take that hobby and turn it into a career. One the best parts of my job is finding people in that position and helping them turn writing into a skill they can sell.
This list is lesson one. It’s seven things that I introduce to already well-practised writers who are starting in the web world. Without them they’ll never go from being spare-time writers to earning pay cheques that say “web writer”.
This is almost always new to the writers I work with (which isn’t surprising, given how low accessibility rates within large parts of the web industry.) Writing accessible web content isn’t difficult but it can be the difference between silence and conversation.
Accessibility isn’t about disability, so I avoid the old example of “the blind man and the screen reader”. Separating out part of the web-using world as “people who need accessibility” infers that there’s no gain (or maybe even a cost) to the majority of users, which is wrong.
Accessible web content is inclusive. We’re not bolting an “extra” audience onto the side of our core audience. We’re making our core audience as large as possible by letting you be a part of it no matter how you navigate or read the web, or how well you see (if at all), or how you use assistive technology. And that makes our content easier to use.
Even better, the techniques that make written content more accessible overlap other things on this list. (My post on good link text gives an example.)
This is an easier “sell” than accessibility, even though both increase your audience. A little bit of SEO knowledge can be a bad thing – if you don’t believe me spend 3 minutes reading a keyword-stuffed content farm – so approach SEO with caution.
I’m against anything that strays too close to algorithm-chasing. If you’re writing for the robots first it doesn’t take long for human readers to work out that something’s not quite right. Your writing should make it clear to search robots what you’re writing about without being inhuman.
Writers need to know:
Almost all of the writers I work are already publishing words in one way or another – usually they’re helping with things like brochures or letters, or they have personal blogs. Some are even freelancing on weekends. But so far none have had a style guide they need to stick to.
Like every other corporation we have an in-house guide that solves a lot of grammatical or stylistic things that would otherwise come down to preference, and so differ between authors. For example we keeps things consistent by preferring contractions (“isn’t” over “is not”) and using commas to divide thousands (as in 5,000). We also have additional web writing guidelines.
Referencing every stylistic quibble back to a pair of documents takes time and isn’t an easy habit to pick up, but once you have a feel for a given style it makes writing faster.
Another staple of the corporate world. As well as our style guides we also have a particular brand voice – a way that everything we say should sound. MailChimp’s Voice and Tone is a fantastic example.
Getting brand voice and tone right takes time and practise. Reading examples helps but nothing beats writing, failing and succeeding for yourself.
It’s a big change for a hobby writer, no matter how skilled, to have to sound like someone else. Writing the same thing in different voices can be a good start. (For example: explain your job in a paragraph or two. Then write that explanation like your boss would, then like a bored cynic, then like a hyperactive child.)
I haven’t found a better way to introduce and demystify HTML than to share Mandy Brown’s wonderful article “Markup”. She explains how HTML creates a relationship between your words and their appearance, and then puts designers and readers in control. Writers need to know what meaning HTML can give text (“this text is a heading” means a lot more than “this text is big and bold”), and how to mark up their own text.
Fortunately, there’s a plus side to all this: HTML is easy to learn. Even if you never peeked at the source for a website, never so much as a