It started with the small stuff. I sweated it all: field labels, button positions, lining up the label and the field, ensuring the icon was understandable. After 2 1/2 years of correcting designs, the heavens opened: the project was delayed, and no one could do the requirements and UI design. How were they going to get it all done? Special T (that’s me) stepped in to save the day, of course. “If you don’t have time, then I’d like to do it.”
I don’t care; I’ll take scraps (err—experience) where I can get it. I come from a technical communication background and seen many successes and failures with user experience in the software world.
It started as a backwards, fix-the-design approach but eventually became a more forward process, designing from a blank slate. Technical communication skills can be a great starting point to an interesting and more lucrative user experience career, if the communicator knows how to apply those skills.
User experience professionals can also learn some lessons from and find potential recruits in technical communicators as they have skills that can be applied directly to the design process.
Technical Communication Skills
Technical communicators may be the only user representative in an R&D group. As a more traditional role, managers have some embedded idea of professional responsibilities. In these situations, the communicator must speak up often: when an error message sucks, when a field label is inappropriate (or misspelled), or when the flow of a wizard doesn’t work.
Communicators must understand both the forest and the trees, and they must constantly scan for inconsistencies. As a best practice, communicators create documentation plans that include help topics, embedded assistance, and context sensitive help. When the plan doesn’t flow, the communicator speaks up to illuminate the shortcomings of a design. (A solid plan, like a solid information architecture, highlights when a feature is problematic or just doesn’t fit.)
As a communicator moves from novice to master, emphasis moves from editing messages and button labels to the placement of those elements. Grouping fields on a form or the location of forms in a program transforms into scenarios and use cases behind those forms. This is how I started my move from technical communicator to user experience.
Along with the big picture/detail skills, communicators must be able to structure information and see the not-so-obvious structure of an interface. Structuring information starts with the documentation plan, but goes beyond that exercise. As features are fleshed out, more information becomes available and must fit into the plan. I liken it to expanding an information architecture: your architecture can be too ridged, too flexible, or appropriate and accommodating.
Eventually the ambitious communicator can start to develop the initial design instead of fixing it, or find opportunity in a design vacuum, as I did. When I volunteered, the project leads thought this was a perfect fit. I always complained about the design, so why not let me do the initial design? (I also benefited from a trusting team that worked well together.)
Giving something in return: how communicators can help UX pros
Communicators are the UX professionals’ natural ally. Since communicators know that fantastic documentation can’t make up for a poor design and system architecture, they champion the cause of better design and information architecture. Communicators are in the trenches, talking with QA and developers about problems and how to solve them.
On multiple occasions, coworkers asked me about changing a design that was created by the UI designer. “It’s just a small change, can’t you just make it? It’s not a big deal.” Having seen the results of a lot of small changes, my responses included:
- I’m sure the designer would love to address your issue…
- I’d love to help you, but I really feel that I would be stepping on toes by fixing the problem myself…
- He won’t bite, I’m sure he’d be happy to talk to you…
- I know he’s busy, but I’m sure if you told him it was urgent, he’d be able to help you…”
Communicators reinforce the idea of a formal design process and back up the designer in advocating a positive user experience. In certain company cultures, designers can be seen as antagonistic to developers and QA. Communicators can use relationships with these roles to smooth the way for the UX professional.
How to make that move
Based on personal experience and speaking with other communicators and UX professionals, here are my recommendations for making the move either as an employee or independent:
- Ask and don’t take no for an answer: The best way to get what you want to is to let people know what you want. It’s a good life skill. I became a communicator because I asked for the job. Once I had communication experience under my belt, I started to ask for UX opportunities and unknowingly started structuring and restructuring information in help systems with better information architectures.
- Just do it: If you see a need, fill it. Sometimes it may not be appreciated, but more often these kinds of actions are labeled as “proactive.” If you see a bad design, sketch a better one and show it to the most appropriate person, being sensitive to the group dynamics and company culture. Make sure you appreciate the effort already given and stress that you are representing the users’ interests.
- Build relationships: with coworkers and managers, making sure to tell them your career aspirations. Tell them in terms of “this is what I do and this is how it can help you.” One day, when a developer or manager has a problem, she might think, “Theresa told me she could help me if I ever had this problem…” It takes effort (and constant vigilance!), but it can work.
- Get a mentor: I’ve had several mentors over the years. At one company, the UI designer taught me task analysis, user analysis and UI design. He did several training sessions for the whole team. After joining the IA Institute, I found a mentor to help me identify my transferable skills and learn how to sell my services.
- Get your foot in the door: Taking a communicator contract can be a foot in the door to a UX job. You can get in, do a great job, figure out the company culture and scope out the opportunities for UX work.
- Take a class, network, moonlight: To gain knowledge outside a company, take a class on UI design or information architecture. Many websites have lists of these kinds of classes. Networking at local user experience groups is a great way to meet peers. Eventually, you might find small contracts you can do in your spare time. When you want to complete your move, you will already know people.
- Do informational interviews: From your networking, you’ll know people. Meet them for 20-30 minutes and ask them what skills they use, what challenges they face, what they like about their job, what they think you can do to make the move, what the market is like. Keep in touch, keep networking.
Remember that it might take longer than expected: I love when things happen overnight. I’m an instant gratification kind of person, so naturally my move is taking longer than anticipated. I keep advising myself to stick with it. As an external motivator, my spouse would freak if I went for a career change! Being independent was enough of an adjustment.
Conclusion
I’m following my professional passions from communicator to user experience professional. I’m a mover and am trying to smooth the way for those who will come after me. Not all communicators want to be in the UX field, but for those who do it is a natural move.
For those already on the design side of the house, hopefully technical communication colleagues can become allies, and you can look to them for support, insight, and maybe even as your next new hire!
Special T:
I followed a similar path, moving from technical communication to content strategy and IA. Yes, it is logical, and yes, it is possible, but there are a lot of folks who don’t see the connections.
I have noted to some colleagues that there is a little bit of IA within all technical writers. Technical communicators make the complex simple, using structure, language, and design. In essence, this is precisely what IAs do.
Another group of professionals who could make the transition are those involved with technical training. As a technical writer I used trainers as a primary source when I needed to understand the audience needs. Trainers possess invaluable first-hand knowledge of the product and the user base. Most have excellent people skills (that translate well into user interviews). Most easily adopt the user perspective (they *are* users, after all), and most have the technical savvy to communicate with designers.
Thanks again for the article.
This is a really good article. I think sometimes technical ‘communicators’ don’t sell themselves well (this is often within the typical persona), and sometime they overstep their bounds in the organisation, and never get another chance. The key is making the most important stakeholders realise that technical communicators have value, and actually demonstrating that value when technical communications get the opportunity – exactly as you say.
There is lots of overlap between technical communications and IA, and between technical communications and interaction design. It doesn’t mean everyone wants to, or can, make that switch, but there are a lot of transferable skills for those that do.
Hey There…
I actually went down the similar path. Not really by choice, but it was the education courses I had available to me. Technical communication principles are extremely valuable when is comes to creating the user experience: advocate for the audience and do it concisely. Which is loud-and-clear in this article.
It was not the technical skills Theresa applied that really stood out, though. It was the fervency with which she applied herself. She saw opportunities that interested her and she seized them. That’s awesome and ultimately that’s what it comes down to: You have to almost altruistically apply yourself and consistently champion the audience, the visitor – not the “user” – it’s all about the PERSONs who are going using your applications.
Nice article, Theresa. Very encouraging.
I wonder if there is cause for flipping the statement round, slightly.
“Technical Communication IS I.A.”
I’m a technical writer, and part of the Usability team at the moment, and I’m constantly re-enforcing the notion that good information design, and structure, is an intrinsic part of the product. The product is not just the software but the entire experience the user has, and so includes the software, documentation, training, and through to cultural tone set by the company website.
Special T:
Right on target, as usual. Thanks for sharing…and for providing valuable information to those interested in growing their careers.
I can’t wait to hear your presentation, “Transitioning Your Career from Technical Writer to Technical Communicator,” at Documentation and Training: The User Experience in Vancouver, April 19.
I look forward to your sharing your experiences with us all.
Again, thanks for a great article.
Scott Abel
TheContentWrangler.com
It was really enlightening to go through your article specially for my interest in user experience designing. As a technical communicator, I believe if we can have excellent design in place than there won’t be any need for documentation. That would leave some of us out of job, and this is why I place so much importance in user experience design. Good stuff!
As in information architect and technical communicator, I’ve been thinking a lot about this lately. In working on a large taxonomy, I started to realize that I was using my audience analysis, business requirements analysis, and indexing skills from the “old days” as a software technical writer. I started thinking of more similarities between IA and Technical Communication and have recently concluded that the “inputs” to the tech comm and IA processes are very similar, if not the same. The outputs differ because the commumications MEDIA are different.
Nancy Zacks
preciseword.com
My TC graduate program at the University of Washington ( http://uwtc.washington.edu/ ) had a lot of focus on documentation and technical journalism. We are also strong in the areas of user research and usability testing (due in no small part to our department chair, Judy Ramey, a respected usability expert). My personal focus, information, interface, and interaction design, was addressed, but not to the same extent as the research and documentation branches.
However, I think it all fits together well. When people ask what TC is, or what our department does, I have a standard response: it’s about understanding an audiences need for information, and then satisfying that need, whether by documentation, journalism, a web page, software product, or device interface. By that definition, we all fit under the larger TC umbrella. Anyone with good TC skills probably has a good foundation upon which to build a UX skill set.