Katie Johnston, content editor on the redevelopment of newzealand.govt.nz, shares her approach to writing for responsive websites.
People are online everywhere these days — not just on their home and work computers, but on tablets, MP3 players, smartphones and not-so-smart phones. We can’t guarantee how someone will look at our content, so we’ve designed beta.govt.nz to work just as well on a mobile phone as it does on a desktop. This is called responsive design. It’s different to a ‘mobile’ site, where the content changes based on the device used to access it — our content is the same all the time, and the design resizes around it.
One of the challenges of a responsive project is keeping in mind that your content can (and will) be viewed on tiny phone screens. Below are a few things we do when creating content.
Preview in phone-size
One of the easiest ways to check that your content will work on a mobile device is to set your browser window to be phone-sized. Ignore the desktop version — check your content for length and flow on the smallest device it’ll be read on. You’d be surprised how much you find to tighten up once you see your paragraph spilling off the bottom of the screen.
Check to see if your content management system offers you the option to preview on different screens — or you can use a free tool like responsinator.com to show you how your page will look on different devices.
No tables
One of our biggest and most contentious style guide changes has been to remove tables from the site.
Initially, we thought we had a code problem — tables are tricky to deal with responsively — but we also started to find that users weren’t finding content in tables as easy to use as we thought they would. I think tables are a holdover from print where people could follow a grid with their finger — on screen they're much harder to make sense of, especially when you can’t control exactly how they’ll appear. I’ve found there’s nearly always a better way to show information that’s easier to follow.
It seems counterintuitive to those of us who cut our web-writing teeth in the days when everything went in a table, but I think it’s made our content better. It’s forced us to think harder about the context and order of the information, and the hierarchy of how people will use it. Tables are excellent for presenting a lot of information in a small space — but that doesn’t necessarily make that information easy to digest or use.
Make it shorter — but not less detailed
I disagree with web-writing guides that say things like “aim for half as many words as you would in print” — I think web writing principles (clarity, brevity, structure) apply to all writing. If you can use half as many words, you should always use half as many words.
But that brevity should never come at the expense of user experience. You haven’t written good content, no matter how short, if your user later ends up lost, surprised, or on the phone for missing info.
One of the biggest traps online is repetition — I’ve worked with a lot of business owners who’d get scared that users would miss a point in the content, and ask for it to be repeated down the page. Or on the next page. Or both. Instead of making the point in question more visible, the page became so crowded and unwieldy that the user was probably less likely to read any of it.
We think this is why structure is so important — getting your pages right, your headings right, your parts of processes in the right order. We’re always looking for the task or mission inside a page — and if we find more than one, we split the page. It’s a work in progress, but we’re aiming for content that’s fully comprehensive without ever being overwhelming.
What’s next?
More testing. More refining. We’re about to kick off our next round of user testing, where we’re hoping to find out more about how people think about navigating tasks. We hope this will give us more clues about how to break up our pages and link between them.
These are a few of our techniques — if you’ve got others, we’d love to hear about them in the comments.
