Click here to monitor SSC

Product Marketing Manager, former technical author, and a helping of content strategy on the side.

Who writes the words? A rant with graphs.

Published 11 November 2011 1:13 pm

If you read my rant, you’ll know that I’m getting a bit of a bee in my bonnet about user interface text. But rather than just yelling about the way the world should be (short version: no UI text would suck), it seemed prudent to actually gather some data. Rachel Potts has made an excellent first foray, by conducting a series of interviews across organizations about how they write user interface text.

You can read Rachel’s write up here.

She presents the facts as she found them, and doesn’t editorialise. The result is insightful, but impartial isn’t really my style. So here’s a rant with graphs.

My method, and how it sucked

I sent out a short survey. Survey design is one of my hobby-horses, and since some smartarse in the comments will mention it if I don’t, I’ll step up and confess: I did not design this one well. It was potentially ambiguous, implicitly excluded people, and since I only really advertised it on Twitter and a couple of mailing lists the sample will be chock full of biases.

Regardless, these were the questions:

  1. What do you do? Select the option that best describes your role
  2. What kind of software does your organization make? (optional)
  3. In your organization, who writes the text on your software user interfaces? (for example: button names, static text, tooltips, and so on) Tick all that apply.
  4. In your organization who is responsible for user interface text? Who "owns" it?

The most glaring issue (apart from question 3 being a bit broken) was that I didn’t make it clear that I was asking about applications. Desktop, mobile, or web, I wouldn’t have minded. In fact, it might have been interesting to categorize and compare. But a few respondents commented on the seeming lack of relevance, since they didn’t really make software. There were some other issues too. It wasn’t the best survey. So, you know, pinch of salt time with what follows.

Despite this, there were 100 or so respondents. This post covers the overview, and you can look at the raw data in this spreadsheet

What did people do?

Boring graph number one:

I wasn’t expecting that. Given I pimped the survey on twitter and a couple of Tech Comms discussion lists, I was more banking on and even Content Strategy/Tech Comms split.

What the “Others” specified:

  • Three people chipped in with Technical Writer. Author, apparently, doesn’t cut it. There’s a “nobody reads the instructions” joke in there somewhere, I’m sure.
  • There were a couple of hybrid roles, including Tech Comms and Testing, which sounds gruelling and thankless.
  • There was also, an Intranet Manager, a Creative Director, a Consultant, a CTO, an Information Architect, and a Translator.

That’s a pretty healthy slice through the industry.

Who wrote UI text?

Boring graph number two:

Annoyingly, I made this a “tick all that apply” question, so I can’t make crude and inflammatory generalizations about percentages. This is more about who gets involved in user interface wording. So don’t panic about the number of developers writing UI text. First off, it just means they’re involved. Second, they might be good at it.

What? It could happen. Ours are involved – they write a placeholder and flag it to me for changes. Sometimes I don’t make any.

It’s also not surprising that there’s so much UX in the mix. Some of that will be people taking care, and crafting an understandable interface. Some of it will be whatever text goes on the wireframe making it into production. I’m going to assume that’s what happened at eBay, when their iPhone app purportedly shipped with the placeholder text “Some crappy content goes here”. Ahem.

Listing all 17 “other” responses would make this post lengthy indeed, but you can read them in the raw data spreadsheet. The award for the approach that sounds the most like a good idea yet carries the highest risk of ending badly goes to whoever offered up “External agencies using focus groups”.

If you’re reading this, and that actually works, leave a comment. I’m fascinated.

Who owned UI text

Stop. Bar chart time:

Wow. Let’s cut to the chase, and by “chase”, I mean those inflammatory generalizations I was talking about:

In around 60% of cases the person responsible for user interface text probably lacks the relevant expertise.

Even in the categories I count as being likely to have relevant skills (Marketing Copywriters, Content Strategists, Technical Authors, and User Experience Designers) there’s a case for each role being unsuited, as you’ll see in Rachel’s blog post So it’s not as simple as my headline.

Does that mean that you personally, Mr Developer reading this, write bad button names? Of course not. I know nothing about you. It rather implies that as a category, the majority of people looking after UI text have neither communication nor user experience as their primary skill set, and as such will probably only be good at this by happy accident. I don’t have a way of measuring those frequency of those accidents.

What the Others specified:

  • I don’t know who owns it. I assume the project manager is responsible.
  • "copywriters" when they wish to annoy me.
  • the client’s web maintenance person, often PR or MarComm

That last one chills me to the bone. Still, at least nobody said “the work experience kid”. You can see the rest in the spreadsheet.

My overwhelming impression here is of user interface text as an unloved afterthought. There were fewer “nobody” responses than I expected, and a much broader split. But the relative predominance of developers owning and writing UI text suggests to me that organizations don’t see it as something worth dedicating attention to. If true, that’s bothersome. Because the words on the screen, particularly the names of things, are fundamental to the ability to understand an use software.

It’s also fascinating that Technical Authors and Content Strategists are neck and neck. For such a nascent discipline, Content Strategy appears to have made a mark on software development. Or my sample is skewed. But it feels like a bit of validation for my rant: Content Strategy is eating Tech Comms’ lunch. That’s not a bad thing. Well, not if the UI text is getting done well.

And that’s the caveat to this whole post. I couldn’t care less who writes UI text, provided they consider the user and don’t suck at it. I care that it may be falling by default to people poorly disposed to doing it right. And I care about that because so much user interface text sucks.

The most interesting question

Was one I forgot to ask. It’s this: Does your organization have technical authors/writers?

Like a lot of survey data, that doesn’t tell you much on its own. But once we get a bit dimensional, it become more interesting. So taken with the other questions, this would have let me find out what I really want to know:

  • What proportion of organizations have Tech Comms professionals but don’t use them for UI text?
  • Who writes UI text in their place?
  • Why this happens?

It’s possible (feasible is another matter) that hundreds of companies have tech authors who don’t work on user interfaces because they’ve empirically discovered that someone else, say the Marketing Copywriter, is better at it. And once we’ve all finished laughing, I’ll point out that I’ve met plenty of tech authors who just aren’t used to thinking about users at the point of need in the way UI text and embedded user assistance require.

If you’ve got what I regard, perhaps unfairly, as the bad kind of tech author – the old-school kind with the thousand-page pdf and the grammar obsession – if you’ve got one of those then you probably are better off getting the UX folk or the copywriters to do your UI text. At the very least, they’ll derive terminology from user research.

6 Responses to “Who writes the words? A rant with graphs.”

  1. Anonymous says:

    This is fascinating. I tried to get some similar information through a Quora question, with limited success.

    Your findings confirm my suspicions. I suspect developers are expected to write the text in most companies. Hopefully the tide is shifting on that.


  2. ser11hill says:

    I agree with you melanie!

  3. Krokman says:

    ‘I don’t have a way of measuring those frequency of those accidents’

    QA is very important also ;)

  4. Roger Hart says:

    Oh, of course QA and testing are vitally important. But I wonder if user interface text is even part of the test/QA criteria in most organizations. If it is, how does the bar get set?

    Lots of people ship pretty shonky user interfaces and user experiences, and still have nominal QA processes. What gets marked as good enough to ship will always be a reflection of the organization’s priorities and the skills of the team.

  5. BuggyFunBunny says:

    My experience with User Experience Designers (although never with that title, and mostly with Fortune X00 companies’ intra-net apps) is that they’re driven to make Fancy Lipstick rather than a Healthier Pig. IOW, most often they’ve made a clean simple interface into an arcade game of flashing bits and pieces. No, thanks.

    What defines a UXD, anyway? I know what it means to be a Database Developer, but a UXD?? Is this a Guild Apprenticeship? Wikipedia (which leant the acronym) doesn’t say. Unless the UXD, or a coder surrogate, codes new widgets for the device, we’re stuck with the digital implementation of analog controls we’ve always had; i.e. mostly html cruft.

    Is the final say on whether to use a pick-list or auto-complete input box lie with the UXD? Is that the sort of thing you mean? If so, what is the theory (equivalent to normalization)? Why should it not be the case, as it always should be, that form follows function? Why is that not sufficient guidance? Why is it that our UIs (no matter the title of the creator) still implement flat file drek, and more so with the resurgence of data dump datastore like NoSql? A hundred or more inputs on an endlessly scrolling web page? I can’t imagine a UXD who would countenance such, but that problem can only be fixed by cleaning up the datastore. If form should follow function, should not the UXD be subservient to the schema specifier? The data is what matters, after all.

    Here’s a challenge to the UXDs in the audience: tell us why is it that iPad, et al, are morphing soft keyboards, when what is needed is a data structure which can be implemented with passive input (picking from widgets)? Why is it that there is *still* talk of getting Office on iPads? Here we have a new UI paradigm (well, new if you’re unaware of what’s been going on in warehouses for decades), yet we’re continuing with widget analogs from a 1950 Ford!

  6. Anonymous says:

    UxD in my experience is confined to product development. Very few IT organisation (with the exception of some expensive government work) will ever have someone with the role of User Experience Designer.

    That doesn’t mean that all internal intranet/lob apps look like crap and are difficult to use. But it sure as hell means the majority are.

    Unfortunately the majority of coders relent to the “just get it done” school of software development and the majority of IT managers to the “just get it out” school of management.

    When done correctly, with skilled developers, those who take care to read UX guidelines (we do exist!) it is possible for an internal app to look good, have great form and function and also be easy to use.

    One thing is always true though, that never comes about without extensive UAT. Users’ must be involved in the design, build and testing of the application. They must be business focused, and they must be as interested in delivering a polished application as a keen and great developer.

    In PD you don’t really have end users in the same way you do in internal dev. Hence the need for UXD (in my opinion) however. At the very minimum I think Business Analysts (where internal IT departments have them) and IT staff responsible for delivering applications, should be experienced and trained in user experience.

    Unfortunately, for internal IT. It can be hard enough getting budget for a PM or Business Analyst (and that’s in FTSE 100 companies!) never mind a user experience designer.

    Caveat: Although this is my impression of the companies and organisations I’ve worked with (Banking, Government, Hospitality, Oil & Gas, Insurance…) It doesn’t mean their approach is right nor I think it is, and I haven’t been anything other than unlucky… Also, I have worked with UXD in various defense projects. They were more interested in the amount of pressure required to press a mouse button, and the brightness of the monitors we were using… Go figure.

Leave a Reply

Blog archive