Writing for responsive design

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.

3 comments

  1. Comment #1. Sarah:

    Would like to see a comparison where you took a table and how you made it into a paragraph/bullet points, or whatever…. it’s a scary world for many web writers to even contemplate doing this, so would be good to see an example of how it can be done.

  2. Comment #2. Jason Kiss

    Thanks for the article, Katie.

    I agree with Sarah: An example would be very helpful. From an accessibility point of view, we often recommend that complex tables be turned into one or more simple tables. If the table contents allow it, converting even simple tabular content into non-tabular content is possibly a better recommendation to improve comprehension generally for everyone.

    I think some types of content and the relationships between them will be easiest to understand and use when displayed in a table, but don’t disagree that a lot of the time certain content in a table could be better presented otherwise. It would be good to get a sense of what questions to ask in order to decide if certain content is better off in a table or not.

  3. Comment #3. Katie Johnston

    Thanks for the comments! So far we’ve mostly had relatively simple tables to deal with, and most of these we’ve changed to simple pages using headings and bullets — one good example is the school terms page: https://beta.govt.nz/browse/education-and-training/schools-and-colleges/school-terms-2013/

    When we looked at it in a table format, we found that it didn’t really scale very well when viewed on a mobile phone — the dates belong with their terms, and having the terms as headings rather than a table column means the text can fill the space available but it’s also it easier to scan through each term.

    This IRD content has a bunch of tables that had a similar problem on small screen sizes:
    http://www.ird.govt.nz/how-to/irdnumbers/
    We turned this page into three separate pages, because it contains three separate user tasks — apply for an IRD number for an individual, a child or a company — and restructured the tables into a process with bulleted lists, eg: https://beta.govt.nz/browse/money-benefits-and-tax/tax-tax-credits-and-refunds/get-an-ird-number/

    Whether our theories will hold up once we see a really complex table is yet to be seen — but I’m feeling relatively confident those should be able to be broken into their constituent pieces. Generally, complex tables are complex because they’re dealing with multiple missions or tasks within them, and we’d split those out if possible anyway. If anyone’s got an example of a really gnarly table, shoot it over and we’ll see how it plays out!

Navigate Posts