When I grew up I had four best friends. After university, we all dispersed into very different jobs — one into journalism, one into strategic planning, one into advertising, one into corporate comms, and I moved from solicitor to information designer. In the last five years or so, something funny has happened: all our job descriptions are starting to look the same. Disciplines in the digital workforce are merging. My friends and I are doing similar tasks and use the same skillsets.
Last month, I had the pleasure of attending the UX New Zealand 2015 Conference in Wellington. It was great to be in a room of like-minded people, who place real customers at the centre of their thinking and approach to work. At the Conference, it was clear that UX professionals are disproportionately happy in their work.
One of the Conference highlights for me was the opening speech by legend US information architect and publisher, Lou Rosenfeld. He talked about how he came up with the design and layout for the books his company publishes. Quite simply, he took his books out and tested them with real people. He wanted to learn whether he could make an age-old product like a hardcopy book easier to use. Turns out you can.
His testing gave him insights into how people actually use technical books. For example, he discovered that people engaged more with books that started with a short section on how to use the book and what it covered—a more detailed guide to the content than a simple table of contents. He also discovered that the back cover was largely ignored. These discoveries, and more, heavily shaped the book design his company still uses for all its books today.
Savvy digital teams these days often test the navigation and design of a prototype website (or app) with real customers. What they learn helps them design a product that is easier to use. But all too often, long after go-live, budgets dry up and user testing stops.
We all know that a big part of the usability of your website is the usability of the actual content. Web writers can learn so much about how to fix a section of their site by testing the content out with a small group of real users.
“I don’t have the time or money for that” I hear you say. Well I say keep it simple and practical — even small scale user testing is valuable. I highly recommend getting into the swing of testing your content in small batches and often.
Just 30 minutes one-on-one with 5 people can highlight exactly how to fix problem content. You’ll learn more than you ever could in a meeting with 5 colleagues, trying to guess and agree on why a section is performing poorly.
You can test any type of content — web and intranet pages, technical manuals, online help files, documents and books.
Pick a critical section of your site that you know is not working, but you’re not sure why. To some degree, site analytics will confirm if the right people are finding and staying on these pages.
Start by listing the type of people this section targets. Be as precise as you can. Try and avoid saying ‘everyone’ or ‘the public’. Who exactly is this particular section for? New passport applicants? First-time breastfeeding mothers? Local recreational fishers? Inbound travellers? Marriage celebrants?
Find 5 people who best match the description. Ask them for their help. Where practical, visit them or invite them to your office.
Your objective is to observe how they use your content, without directing them at all.
After observing them, ask direct questions to get the rest of the story.
Take what you learn to make your content more useful and usable. Share your insights with site designers, developers and other writers.
On the web, your audience can feel invisible. You are writing for a bunch of people you typically never meet.
Regular user testing gets you out into the world and connecting with real people. You'll gain personal satisfaction and insights galore. You’ll meet the people who appreciate your work. And with their help, you can improve their experience. That feels good and right.
Happy you. Happy customers.
I really found your list helpful. However, one culprit needs to be exposed. Was-were. The only thing I remember learning as a clue was: 'if' demands a 'were'. Could you comment on the rules?
- - - - - - - -
Good to hear from you with this classic question.
Old grammar rules stick in our minds like chewing gum in the hair. The rule you remember is no longer a rule (perhaps it never was) but a choice. I tend to use ‘were’ out of habit myself, but 'was' is now more than acceptable—it’s the norm. The Style Manual (Commonwealth of Australia 2002 edition) explains a logical flaw in the original rule, and says:
In Australian English the ‘were’ subjunctive is falling into disuse, replaced by ‘was’ for ordinary purposes. This then makes the ‘were’ subjunctive a distinctly formal choice in terms of style.
I love the Australian Style Manual for its clarity, layout and index, and because it’s up to date. It’s worth noting that the Yahoo Style Guide, Economist Style Guide and Fit to Print don’t even bother to mention this rule—it’s a non-issue.
That’s the way it happens! The first grammar rules we learn are more than likely unreliable even at the time, but they stick tight in our brains like old chewing gum.
So we can carry on using were after if, but have no reason to blame others for using was. It's annoying, isn't it?
- - -
Image by Jared Eberhardt, CC BY-SA 2.0. "I smashed gum into his hair in the hot tub and it sort of melted to his scalp where my dad had to shave it out.
Deep in the Diploma of Web Content lies a nifty little course on Editing Web Content. This one is crucial, because research shows that editing content correctly can double the usability of a web site.
Editing is always a step-by-step process. And always you start by asking the big questions, such as: