The undercover designer: how a tech writer can influence product design
Several months ago, I ran a workshop with 60 technical writers from around the world. They were all hungry to improve the user experience of the software they worked on.
I asked how many of them worked for companies that had user experience (UX) design teams or a UX designer on staff.
None of them did. Not one.
On one hand, that’s horror-film level scary. On the other hand, there’s a huge area of opportunity for them to do what they want: improve the user experience of their products.
I’m a writer who’s fortunate to work alongside the designers at Atlassian, but over half a decade ago, I worked for another company as a technical writer. That company had no design team or full-time designer for us to rely on. So I tried to fill some of the user experience void. I was an undercover designer.
Maybe you’re in a similar position and wondering what to do. If so, I’ve got some basic things you can do to start improving the experience of your product or website.
If you see something, say something
In the U.S., there’s a safety campaign reminding people to stay alert and not to assume that others have alerted authorities about something suspicious. Posters in trains and airports and other public places say “If you see something, say something.”
The same thing goes with the user experience of your product: if you see something that could be improved, tell someone. Tech writers have strong ties to their users, and they have a good sense of when an experience is broken. By the nature of their jobs, they understand information architecture and its role in good and bad design. I assume you do, too.
Your goal, of course, is to be as constructive as possible when you speak up. Hopefully, you’ve built relationships with developers who can be allies and help you get improvements into the product. In my experience working on teams without designers, I’ve found that developers are usually pretty appreciative of help improving the user experience.
Product management and product owners can also be allies, and they are the ones who can help prioritize work for the developers.
But what if you have a suggestion that runs into some resistance? Maybe it’s time to get your quality assurance (QA) colleagues involved. They might be better able to describe the situation in terms that speak to developers. Another reason to pull QA into the discussion is that it can raise the profile of your request. Improvement tickets may come from a lot of sources, but developers pay close attention to bugs and issues filed by their QA peers.
Get over yourself
If you have a hunch that there’s a usability problem, see if there’s any data to corroborate your idea. You’re not bending statistics to support your agenda; you’re looking to see if there truly is a problem.
I remember working on a feature, and I was convinced there was a UX problem. When I went looking for data, I couldn’t find anything that supported my hypothesis, so I let it go and looked for bigger data-supported problems.
Not everyone is fortunate enough to work in a company that is rich in user data, but there are still ways you can gather data, both quantitative and qualitative. Both kinds have value.
Talk to your coworkers on the support team and find out the most common issues they deal with. At the least, they can probably give you a top 10 list of most common issues. Ideally, though, they can give you the number of support incidents, time to resolution, and associated costs per issue. Those are solid numbers that you can take to product leadership to say there’s a problem. And later, they can be the benchmarks when you check back to see if a change has lowered those numbers.
Maybe your technical writing team has online documentation. Check to see what analytics exist for that. What help or knowledge base pages get the most hits? What terms are people using to search the docs? Those can suggest usability problem areas.
Finally, you can do some basic user testing yourself for some qualitative data. For starters, you might be able to use coworkers from other departments as test subjects. It’s better, though, to test on actual users or random members of the public. Make sure you know and abide by your company’s legal restrictions when testing on non-employees.
How do you actually conduct the test? Well, you can get some useful insights just from sketches or wireframes printed on paper. Don’t let the thought of making wireframes scare you. We’ll talk about that next.
Quick on the draw
Now’s the time to create. It doesn’t matter whether you’re trying to test an idea on a user, win support from management, or give developers guidance on what to build. Make something.
Here’s the good news: you don’t have to be an artist for this. You’re just trying to make something that conveys the basics, so a sketch or a wireframe will do.
Here’s how I think of the terminology of UX design. There are three main categories: sketch, wireframe, and mockup. They sit along a continuum of fidelity, and any of them can be turned into something interactive — a prototype.
The best place for you to start is sketching on paper with a pen or pencil (or Sharpie if you want to be really design-y). Whiteboards work great, too. Sketching allows you to focus on the underlying structure and not get bogged down in typography or colors.
I like to focus on the user flow through a feature, which I tend to do with a series of quick sketches that I can then refine based on feedback.
Then I turn them into wireframes, or simple digital representations. Still, I’m focusing on basic elements and not fussing with typography and color. And since this post is focused on writers and others who may not be visual designers, don’t feel like you have to use the same software designers are using. Sure, Sketch and Photoshop (or Illustrator) are great, but they may be more than what you need.
You’ve probably got other tools that can create workable mockups; think Powerpoint or Keynote. Even Excel or Google Sheets would work if you wanted, though I wouldn’t want to do it. Also, take a look at Balsamiq Mockups. It’s an inexpensive, easy-to-use wireframing tool that your company may already have.
The mockup stage is a good time for more feedback. Conventional wisdom holds that people will be more willing to suggest changes when the design is not final. After you’ve heard from coworkers and users about your wireframes, make another round of updates and pass them on for implementation.
This is usually as far as I take my design work as a non-designer. Once you get to that stage, your developers can probably apply existing visual styles to the structure and experience you’ve built.
Step up your game
If you want to learn more, the good news is there’s lots of stuff out there. Some of it is free. For instance, you may have access to UX-themed meetups, depending on where you are (don’t overlook meetups when you’re traveling).
I’m in Austin, which has groups like Austin UXPA, IxDA Austin, Enterprise UX, and Ladies that UX Austin, to name a few. You might also hit UX topics at meetups on content strategy or product.
Another freebie is social media like Twitter or blogs (including Medium, of course). If you’re into podcasts, you’ve got options there, too. (Probably more than I can mention.) For instance, Jared Spool’s User Interface Engineering offers podcasts that touch on a variety of UX topics, often with experts from around the industry.
Karen McGrane and Ethan Marcotte host Responsive Web Design, focusing (obviously) on responsive web design, but you’ll hear plenty about UX principles from them. Also check out 99% Invisible, which is about the designed world. It’s not always about software, but it gives plenty of useful insights–and it’s always a good listen.
Don’t limit yourself to just following blogs and podcasts on software and user experience. One of the things that got me fired up and has been very helpful over the years was the book The Back of the Napkin by Dan Roam. I also listen to a variety of podcasts, and I find myself making notes of parallels I find between the UX world and the non-UX world.
Go get ’em, tiger
If you’re out there feeling like you’re the only one who cares about UX, take heart. You’re not. Remember, several months ago, there was a room full of writers just like you. They are undercover designers now, and you should join their ranks.
