I’ve been talking with a lot of software companies recently about what they do to make their products user-friendly. One of the areas I’ve been exploring is how decision-making about the various components that make up the software product is divided between team members. One of the key components is, of course, the user interface.
The wording in the user interface (or UI for short) – by which I mean button-names, field labels, error messages and informative text, tooltips and pop-ups is something I’m particularly interested in. “Ownership” of decisions about these turns out to be quite a heated topic in some teams – but who’s best placed for it? Here are some of the opinions I came across…
Developers should choose the words in the user interface
This is the situation I’ve seen most – likely because a lot of the companies I’ve talked to are small to medium-sized companies which can still remember their days as a start-up – when there wasn’t anyone other than the developer who could think about the wording in the UI. Here are some of the arguments I heard in favour and against this way of working:
Pros
- Developers are already working in the UI, so it’s natural that they should do the words too.
- Changes to the words – or adding new words – requires changes to the spacing or layout of the UI, so developers should do this, so that all aspects of implementing the UI are handled by the same person.
- Developers already have to understand the details and motivations of the features they’re implementing, so they’re well placed to think about the wording too.
Cons
- Developers are often distant from the end-users – in fact they may not ever meet them – so can’t understand their needs or expectations.
- Developers are too close to the functionality they’re implementing, and with the best will in the world can’t help letting that familiarity colour their decisions about what wording or information the users need. (Evidence of this is the use of class names or function names in configuration dialogues or action buttons – the developer’s mindset accidentally leaks into the users’ world.)
- Other people in the team know much more about how people explore and use software products than the developers do.
- Developers are often confident users of software, and don’t recognise the need for additional help and guidance from the wording in the UI.
User Experience designers should choose the words
This is another common situation and one that most of the user experience designers I’ve talked to take for granted, once someone with UX skills has been added to a development team. Developers and technical authors on the team don’t always agree, though…
Here are some of the arguments I’ve heard for and against user experience designers having responsibility for choosing the words in the UI:
Pros
- The words are part of the interface; user experience designers are designing the interface … so of course, they should decide what words need to be written.
- User experience designers are closely involved with usability testing, so are well placed to understand users’ terminology and make sure it is used in the UI.
- The need for words is closely related to other aspects of the design of the UI – the more the UI can be made intuitive, the fewer words are needed.
Cons
- User experience designers often come from a visual design background. They prefer clean, minimal interfaces and decisions about where to put words are coloured by this (though what is most visually appealing is not always best for users).
- User experience designers believe that their UIs are optimised for usability, so are often not open to the need for additional guidance and helpful wording in the UI.
- Design work is based on an understanding of ideal target users and contexts of use; other teams – such as support teams deal with the reality of the many non-ideal users, who have less knowledge than expected or encounter more errors than anticipated.
Technical authors should choose the words
Technical authors often end up acting as the representative of the user on development teams, so often end up making recommendations about wording. Their recommendations meet varying degrees of welcome, though: ranging from them having full ownership of all wording in the UI through to their recommendations being dismissed or added to the bottom of a long to-do list of future fixes.
Pros
- The words in the UI need to be closely related to the words in the help or other supporting documentation, which are written by technical authors.
- In agile teams, the technical authors often work on writing any help needed alongside the UI development happening. Since they’re already thinking about the wording in one place, they might as well extend their thinking to the UI so that terminology and workflows are consistent.
- “Help” or “support” isn’t something separate from the UI. There’s a continuum of information to help users learn and troubleshoot their software, and this is best managed from a single place – rather than separated between different job roles. Technical authors are the people who think about learning and troubleshooting, and the best way to support both is often with information or embedded user assistance in the UI … so technical authors are best placed to make decisions about words in the UI.
Cons
- Wording changes or adding help to the UI often requires rearranging the layout of the UI. Technical authors can’t do that, so shouldn’t have control over these decisions.
- Technical authors worry too much about helping people, but most people don’t really need a lot of help – so it should be confined to separate help pages where people who really need extra support can go and find it.
- Technical authors write help. The wording in the UI isn’t about helping people, so why would technical authors have any involvement in it?
Marketing copywriters should choose the words
This isn’t actually something I’ve come across in any of my conversations with software companies, but it was proposed by some recent articles in the content strategy domain, so I thought it worth including. Here’s one of the articles, by Des Traynor.
As I haven’t come across companies that work this way, I don’t have any pros and cons to share.
So, who should choose the words in software user interfaces?
In the teams I talked to, I didn’t come up with a conclusive answer. As you’ve probably spotted, the pros and cons above contradict each other and aren’t conclusive for any of the roles. There’s so much variety in how teams are run and wherein the teams the various skills are found, that it doesn’t seem that any specialism is better at choosing words for the UI than others. Good quality, usable software can be produced by teams where any of the specialisms I came across get to make that choice. What I did see was that the best software UIs came from teams where it was clear who had the final say over wording. This person also had contact with users and took responsibility for all the wording in the UI.
So, my answer is: it’s not so important who chooses the words; what matters is that someone does it, and that person has the knowledge needed to make informed decisions.
But that’s just me. I’ve only talked to about 20 software companies, and I’d love to hear what goes on in others. Please do share your experiences.
P.S. We’ve published more articles on how you can create great user interfaces, such as ‘Self-support begins with the UI‘, and ‘(UX) Writing the docs‘. If you have any questions on either, you can always contact us here.
Originally published 27.09.11