Georgina has more than fifteen years' experience writing and editing for web, print and voice. With a background in marketing and a passion for words, the time Georgina spent with companies like Sausage Software and cemented her lasting interest in the media, persuasion, and communications culture.

Georgina's articles

  1. How to Write (Better) Release Notes in 7 Steps

    For some businesses, release notes are the only way product enhancements are communicated to customers. For others, they’re a sideline, developed entirely separately from user communications.

    But if you want to do more with less — if you want to improve customer retention communications without having to do a stack more work — your release notes could be an unexpected, but valuable answer. Especially if they’re well done.

    Release notes document new features, enhancements to functionality, and bug fixes. They’re usually concise and fairly direct, and naturally assume a level of familiarity with your product. The process I’ve set out below should make it easy to produce good quality release notes for your product that meet that need for your business and your customers.

    But, if you want, this process will also provide you with solid fodder for other release communications — like emails or blog posts or feature tours — that can help remind customers how committed you are to improving what you offer to them. And let’s face it, we all want to know we’re loved even after we’ve made a choice and signed up with a service.

    Let’s see how this can work for you.

    1. Be clear on your target audience, and the purpose of the notes

    Who reads release notes? For some products, the majority of users will check out each release note; for others, it’s a very select, specific subset of the main userbase.

    Once you know who you’re creating the release notes for, you can understand why they’re reading the notes. And that drives the next step.

    The release notes for the product I work on aren’t read by anyone but a very small percentage of users within key client accounts. And they have very specific reasons for reading the release notes – some have internal documentation they need to keep updated, for example.

    But for some products, the release notes are read by a large portion of users who want to avoid the marketing spin – who want to get to the heart of the product and hear direct from its makers. Knowledge like that won’t just inform what you include and exclude – it can impact the tone in which you write the notes, and how you present them.

    2. Work out what they need to know

    Release notes are generally expected to document what changes have been made in the current release of your product. So obviously, you’ll have an idea of what you need your readers to know about.

  2. Bring Your Help Docs into Your UX Design

    When do you develop FAQs or self-help content for your product?

    For most startups I’ve worked with, the answer is “just before launch.” By that time, you’ve nailed down what the product is, what it does, and who it’s for. So it seems like the perfect time to throw together a few likely FAQs, perhaps around questions that have arisen out of user testing.

    Or is it?

    I’ve found that the best way to create help information is during the development of the user experience.

    After all, your support is part of that experience, right?

    If you make self-help part of the UX design, you can:

    • avoid wasting time writing help no one ever has a need to read
    • avoid “documenting features” for the sake of it
    • link help to the points at which users actually need it
    • develop context-specific help that users actually use — and appreciate.

    I’m guessing you’ll agree, in principle, that a user-centric approach to help is a good idea. Yet many product managers, owners and developers want to document processes or features end-to-end.

    The thing is, users don’t often struggle with a whole process, end-to-end. If they do, you have bigger UX issues to address.

    More commonly, there’ll be specific sticking points in the process where the user is confused, usually around ideas or tasks the users are unfamiliar with, or aren’t expecting. User-centric help lets you address those elements directly and specifically, in situ.

    It allows you to get users who actually need assistance to your self-help right from within your app or product, because you’ll have created targeted help that’s worth linking to from key points in the interface, like error messages or feature tours.

    And it also helps cut down your help-creation workload.

    The alternative to user-centric self-help is to guess: to provide more general content (since you don’t know when in the user experience users will access it) and hope they wade through it to find the stuff they need. This is less than ideal, and less than useful. Help like this sees helpdesk costs increase.

    So let’s see how hard — or easy — it is to develop user-centric help.

  3. A 6-Step Plan for Creating Genuinely Useful Product Support Pages

    It’d be nice to think that your product UX is so exceptional that users won’t ever need any help with it. But until every user thinks exactly like you do, your target audience and users will have questions.

    How will you answer them?

    This six-point plan should help. Not only that, it will help you create help information that actually helps you identify problems with your product UX – problems you can ameliorate, if not solve, with better design.

    Let’s see how.

    1. Determine the purpose of your help pages

    Working out what you want your help pages to do is a pretty obvious first step. Depending on your product, audience, and support strategy, your online help pages’ purpose may vary:

    • Is it a place where users can help each other?
    • Will it let users contact your support staff direct? In real time?
    • Is it a place where users can access self-help?

    You’ll likely already have an idea of what purpose, or purposes, you want the pages to serve, but it’s good to put it into words up-front, before you begin to consider help formats or technologies.

    2. Choose which user actions will be served by your help pages

    This is an important point, one that directly reflects your overall support strategy.

    Yet it’s easy to get this bit wrong: to decide you’ll create an FAQ page and expect it to do everything users need, or to simply list an email address, and pay support staff to answer common questions that could more effectively be answered with some FAQs.

    So think this through. What kinds of questions, if any, will be addressed on your help pages? Which user actions will you provide self-help for? And what will be the next step or steps for users who can’t resolve their issues on your help pages?

    One point here: it’s easy to start thinking that all users will just contact support if you list a phone number or email address, so why bother with help pages?

    But in my experience (and probably yours), a majority of users do want to self-help. This can be great for your support strategy, if you take the time to work out where the breaking points are, and how far you actually want your self-help content to go.

    3. Identify the points in each use case where a user will seek help

    Now it’s time to go a bit deeper and look at actual use cases you’ve used to develop your product.

    Look through the key use cases, page flows and actions users will pursue within your app, and make a list of the questions they’ll have, or problems they’ll face along the way. Perhaps you’ve already done this as part of the UX design and dev process. Great. The important thing is to identify where in your product help is needed, and what will be helpful at those points.

  4. UX Challenge: How to Make More Readable Lists

    The bigger a site or service gets, the more support requests it usually has. And the longer its list of online help articles becomes.

    Whether they’re simple FAQs or more instructional how-tos, once the list is long enough, you’ll usually want to break those items up into groups for easier navigation.

    So far, so good. But what happens when those groups start getting longer, and you need to group the items each contains? In practice, you won’t always want to split groups into subgroups with headings. Here’s a case in point:

    Read an email
    Create an email
    Use spell-check
    Include emoticons
    Use formatting, fonts and colours
    Change the text direction
    Add files as attachments
    Add images
    Add images inline
    Add an email signature
    Save a draft email
    Send an email
    Reply to an email
    Forward an email
    Get a read receipt

    We’ve been told for years that menus aren’t meant to have more than seven items, but web users are expected to use long lists all the time — in search results, in forms, and on ordinary content site web pages.




    Faced with this problem recently — along with the challenge of ordering a lot of help articles, I decided to do some research into whether there might be better or worse ways to order long lists of help articles.

    What’s the problem?

    The list above may seem logical to you. Indeed, that was the whole idea. That’s the procedural list order I used in the test. The list starts with composing an email, then steps through all the things you might do as you compose that email, and finishes with the things you’d probably do after that, like sending and forwarding.

    The order is pretty rough — you could argue that the Reply to an email article should come before the one on composing email — but you get the idea. In terms of “precision” ordering, this is about as good as it gets for most content managers.

  5. The 3 Second Copy Test: If You Wouldn’t Say it, Then Don’t Write it

    Does your content “resonate” with users? Does it empathise? If your help articles, system emails, or website copy are lacking the spark of true engagement, your language choice could well be to blame. So, here’s a 3 second way to test your copy. Getting personal In my experience, the best way to address users through […]

  6. Does Bad Grammar Make Bad UX?

    Ever since we started creating graphical user interfaces, we’ve been trying to make them friendlier and more usable. Sometimes those two goals coincide; sometimes they don’t. When space is at a premium, and you need to minimise ambiguity, the most direct approach is often best — which is why the button in this interface says […]

  7. Putting Web Standards for Writers Into Practice

    If you’re wondering how web standards for writers play out in practice, you’d better read this post. Recently I took a look at the website of my country’s leading telco, to see how they handled the standards I pointed out recently for web writers. The company’s name is Telstra, and it maintains the basic landline […]

  8. Sparkicons: Can We Make Better Links?

    Around this time last year, Mark Boulton proposed a new way of communicating information about linked content online He called his idea sparkicons, building on Edward Tufte’s description of sparklines, and pointed to some examples on large content-rich, link-heavy sites: Wikipedia and the BBC. He also created some examples of his own. Mark Boulton: I’m defining […]

  9. Writers and Wireframes

    “Do you have wireframes?” I asked a client this question not so long ago, and the answer surprised me. “Not yet, he said, “but they’re not far away. In the meantime, here are the sections of content we need written, so if you can get started, that’d be great. We’re on tight timeframes here!” The […]

  10. Web Standards for Writers

    Remember the bad old days of all those “writing for the web” articles? Now, people writing for the web don’t just have other writers to rely on for advice—they have real, live standards to follow! Hooray! Here, I’ve pulled together some of those standards, and explained why they’re useful, and for what kinds of web […]