Technical Writing & UX


This is a great piece that highlights a lot of the views I’ve had on writing for a long time:

Specifically this quote:

“Technical communications is an inherent part of user experience. Anything that involves people interacting with something is inherently part of the user experience. Your situation, sadly, is not uncommon. In many of the organizations for which I’ve had the honor to work, the technical communications (TC) folks are often the last to know what the UX team is doing. Ironically, these professionals are usually the first to point out usability issues. They need to understand how something works so they can describe it to somebody else. When they’re brought in at the end of the process, they don’t have an opportunity to influence the design as they should.

Would love to hear other people’s thoughts on this topic, or good stories/examples of this actually happening at companies. It would be great to start a simple playbook that helps folks argue to be brought into the design, UX, and general production creation process earlier.


Many of you will not be surprised to hear from me that once upon a time (history alert!), this division of tech writing and UX did not exist. UX as such didn’t exist, for that matter, although the work that’s generally covered by the term certainly did… @lemay makes the point eloquently and succinctly:

So much more to discuss here, too …


So with TW and UX – what are your strategies. I’ve just looked through @bethaitman’s slidedeck; the guides that I see are not consistent.

(FWIW, I saw this tooltip:

The source object qualifies for a target object, there is no link to an existing target object, but there is more than one correlated target object (that is, more than one possible match on the target system). This situation is detected during source object changes and reconciliation.

and got the OK to start pushing better text in the UI – or should I say “microcopy” :))

I know I’ve asked on the twitters…


In terms of the argument about why tech writers should be involved, I’d say it’s to do with the skills we bring. We’re good at explaining what software does to users - that’s what we do. And we can use those skills to improve software’s UX, by improving how the software explains itself to users.

If tech writers can get involved in early-stage design, we can make such a difference. It lets us identify areas that are complex/hard to explain, and fix them before they get any further.

@mikejang : I’ve found it easiest to get in on the process when I’m seen as the “words person”. I review stuff people have written (anything, even emails). If they can see I’ve improved it, they’re more likely to ask me for help in the future. Sometimes developers ask me about naming classes etc, because they think of the tech writer as the person who’s good with words. But it also means, when they’re writing an error message, they’ll ask me to review it.

I think the same can work with designers - if you can show the difference you can make, hopefully they’ll be happier to let you in on their process. Asking to attend user research can be really effective, especially if you can make good suggestions based on the user feedback.

For reference, my team’s current process is roughly like this:

  • Designer creates mockups for a feature based on discussions with product owner and team
  • Designer posts mockups on our board
  • Team puts up their comments on post-its (and I’ll do a string review and scribble suggestions on)
  • Designer iterates on mockups, and we review all the text together
  • User testing

The idea is that, when the mockups are ready to be user tested, they’ve already been through a tech comms review. It means we can get much more useful feedback, rather than just watching users struggle with things we already know are badly explained or hard to understand.


Thanks Beth,

That’s helpful. You’ve set out a process that I’d be happy with.

General Question for all:

Is there some virtual tool for “post-its” on UIs (that would match Beth’s current process)? We’re not all co-located. (Right now, I’m doing my best with markups / notes / screenshots in Google Docs)


btw, @bethaitman has put together an awesome blog post on the subject, ref


Not sure it belongs here, but I’ve been wanting to see this piece on the same page with Beth’s blog/related work. Great minds, etc!


Glad you liked the blog post! I just asked our UX team for their suggestions about remote tools. A few options:

  • Sometimes they just post screenshots on Slack, and comment beneath. Not that different than your Google Docs process.
  • If you use Balsamiq for mockups, MyBalsamiq lets you suggest alternative designs, and gives you threads of feedback, but apparently it’s a bit clunky.
  • does online post-its (so you can stick to screenshots), but apparently is now expensive, so ConceptBoard is an alternative.
  • Other tools they thought could help include Notable, Invision, Basecamp, and Huddle, but they’ve got less experience of those.

But there was a general feeling that it’s much harder to iterate on mockups of designs if you’re doing it remotely. Easier with a usable protoype that you can interact with (eg skeleton HTML/CSS).

(Sorry - I would have put in links for all the tools, but the forums wouldn’t let me because I’m new! )


Another alternative for Slack/Google Docs could be Trello. I think of it as pinterest for project management and am using it for a variety of projects that require collaboration.


Salesforce Trailhead is a project built on UX & tech doc working together. It’s been very effective.
At some companies, ALL written content (even if in error message or UI screen) is edited by tech doc group for voice and style adherence.




I can now contribute some personal efforts, based on my talk last month on UI Text at OSCON

  1. YouTube:
  2. Slide Desk:

I had a live audience of about 100, maybe 2/3 UI Developers. I was the only writer in the room.

While our UI team generally looks to me for text, my goal is to help everyone on the UI team make better decisions on UI Text.