Author Archives: jeffreyuw
Effectively addressing digital audiences is a critical function of being a technical writer. However, our authors this week demonstrate how difficult this task can be. Not only are audiences fragmented in a digital space (as Bernadette Longo points out in chapter 6), but there are many cultural practices and barriers that prevent us from communicating to everyone adequately (as Barry Thatcher shows in chapter 7).
Besides fragmentation and cultural barriers, I would argue that algorithms also create challenges for technical writers to adequately construct, address, and engage with digital audiences.
There are many algorithms that can make it challenging to form a digital audience. For example, Google’s algorithms can make it challenging for users to find your content. In order to rank on the first page, you have to follow rules and tackle specific key terms. I’ve learned that in order to get my articles to rank, they need to be over 1,000 words, mention the keyword more than once, link to multiple websites, have the article be linked on other websites, be published on a Google trusted site, be shared by others, have numerous pictures, and the list goes on.
If you follow these rules and algorithms, it can be quite easy to rank and gives users a means to find your content. However, these rules don’t make it easy to address audiences effectively. I have found myself spending so much time trying to meet the requirements (such as saying the keyword more than 50 times), that I wonder if I’m actually creating helpful content for users. The search results are also so competitive and manipulated that you have to write sensational headlines and more just to get noticed. I’m not saying it’s impossible to write SEO (search engine optimization) content and not have it be helpful, but it certainly presents a challenge to content writers to construct and address digital audiences effectively.
Tom Johnson, a well-known technical writer, states that writing good documentation can be challenging because it can feel like your writing to the “absent user”. That’s because documentation platforms provides little or no measurable means to track how users engage with your content. Of course, as Tom Johnson points out, there are numerous tools that can be used to gather knowledge and feedback of how users are engaging with your documentation — surveys, web analytics, plugins, etc.
Even though we have these tools, I believe Tom Johnson makes a good point that digital spaces (like documentation) don’t inherently give us many tools to understand how users engage with our content. I find this same challenge when writing a corporate blog. I know users are visiting my content due to web analytics and other marketing tools, but it can be difficult to know if the content is addressing their actual needs. In a digital space, the best means to get feedback from users is from surveys, but even this can be challenging because users are usually flooded with so many different forms of digital communication. And when users do take surveys, they can provide general, or extremely non-specific feedback.
No matter how you cut, the web (by design) does not give technical users many helpful ways to address their audiences. They must go out of their way to interact with end users and get feedback. I believe this is why technical writers have to train themselves to become more customer and UX-driven. Without these practices, technical communicators cannot be effective at their job.
Algorithms can also make it challenging for digital creators to create engaging content. For example, have you ever searched a simple question on YouTube and can only find 15 minute long videos that take forever to answer the question you searched? That’s because YouTube’s algorithm favors longer videos, which forces creators to prolong their videos to meet these arbitrary requirements. That means creators could be spending more time trying to extend their video length, rather than creating quality content that actually helps users with problems.
What to do?
While specific rules and algorithms can limit technical writers, they can be easily overcome. In the end, it’s the job of the technical writer to be aware of these rules and continue to find ways to communicate effectively despite them. It’s the reason why we are hired. We’re expected to not just know how to address audiences effectively, but know the algorithms that effect us from being able to communicate adequately.
Chapter 1 and 2 of “Digital Literacy For Technical Communication” focuses on the history, the role, and the value of technical writers. Chapter 2 can feel like a downer because it discusses how the role of the technical writer can be vague for managers. In fact, Dicks writes “Technical communicators need to worry about how they are perceived and evaluated and whether they might be likely sources for being reengineered and either either eliminated or outsourced” (64).
I have felt these worries myself at times. After a copywriter left the company, my manager decided to hire a different role versus hiring a new writer. It made me wonder if he didn’t see the value of having two writers on his team. Dick outlines his four points for how technical writers can still show their worth in today’s companies. In my post, I’m going to discuss how I show my value to my managers and company. I’ve discussed iterative design enough in my previous posts, so I’m going to leave this skill out of the list (although I heavily suggest gaining design skills as a technical communicator).
UX Expert or User Advocacy
I believe technical writers have a better understanding of the company’s customers than most employees in a organization. That’s because technical writers have to think about the needs of the customer whenever they write a blog post, a case study, documentation, etc. This puts technical writers in a prime position to lead UX (User Experience) efforts in a company.
I commonly contribute to UX discussion, especially in regards to the design of my company’s website and products. However, it is not enough to simply know UX. In “Don’t Make Me Think, Revisited“, UX professional, Steve Krug, states that most believe they know UX regardless if they have been trained or not.
As technical writers, that means you must become versed and trained in UX practices. Back up your assumptions about users with usability tools. I am currently designing a usability study using a research tool called UserTesting. With this tool, I plan to run 10 unmoderated tests that will help me understand how users feel about my company’s website. I am also running a survey to better understand user’s direct feedback about the company. Through these efforts, I am showing my company that I can lead my company’s UX efforts. I am bringing consistent value by helping them gain more insights about our customer base.
I don’t think I need to discuss how content strategy works because most of us already know it. But I do believe we possibly underestimate the value of this skill. In my experience, I’ve run into two types of writers in companies — those who just want to write, and those who strategize and write. I totally understand just wanting to be left alone to write and not focus so much on the strategy part. Content strategy takes away time from writing. And most of the time, the content plans you put together can be hard to stick to. However, you will gain respect from your colleagues if you do spend time putting this strategy together.
I realized the value of content strategy after interviewing marketing directors. I’ve been interviewing directors a lot because my company is currently looking for one for our marketing team (this person would essentially become my boss). One candidate asked me some interesting questions after our interviews. She was extremely interested to know how I spend my time as a writer. Based on her questions, I could tell she was trying to figure out if I was a writer who just wrote, or if I was willing to be content strategist as well. This caused me to reflect on other questions director candidates have asked me, and they are always asking me about my content strategy. Even when I meet with my non-marketing director, he is asking me about my content strategy.
Even though content strategy isn’t my favorite thing in the world, I’ve learned that many see tremendous value in taking the time to spin up a plan.
The Bottom Line
You may be feeling that this list is extremely marketing oriented. Like Saul Carliner’s history of the technical writer in Chapter one of our readings, my list has a personal dimension to it. There are still many ways technical writers can add value to their company through other means: programming, documentation, product management, etc. I would love to hear how the rest of you have found ways to bring value to your company, organization, or even to yourself, in your profession.
Ever since I joined the MSTPC program, I have noticed a repeated theme throughout technical and professional communication literature. Technical communication often doesn’t seem to know what it is, what it does, or why it matters. I have read many research papers that seem insecure about the profession and try to pinpoint what technical communication is and who it is for. Notable technical writers like Tom Johnson have even tackled this issue in posts like “Why is there a divide between academics and practitioners and tech comm?”. In my Theory and Research class, I wrote my final essay about why researchers seem to explore the identity of the technical writer more so than other professions. I understand all professions do research about about their own field, but technical communication is one of the first fields I’ve run into that seems unsure of itself.
I saw some of these themes of identity in Blythe, Lauer, and Curran’s article “Professional and Technical Communication in a Web 2.0 World.” However, these authors seemed more sure about what technical communicators do and seem to be okay with the fact that technical writers are a diverse bunch with a wide skill set. They focus less on “What is a technical writer?” and instead, “What does a technical communicator do?” I particularly enjoyed and agreed with this quote from the piece, “In other words it is not enough in a Web 2.0 world to ONLY write effectively, you must branch out and be a master of many skills and tools.” Blythe, Lauer, and Curran explore these many skillsets and tools throughout the paper and it inspired me to create my own list of common writing tasks and tools I use in my day-to-day job as a technical content writer:
|Most often used types of writing||Most often Used Tools|
|1. White Papers||1. Google Drive (Doc, Excel, Slides)|
|2. Case Studies||2. Sketch|
|3. Blog / Syndicated Content||3. Slack / Email|
|4. Website / Landing Pages||4. UX Research tools like Ethnio|
|5. Blog / Syndicated Content||5. HubSpot|
|6. Press Releases||6. Asana|
|7. Advertising||7. WordPress|
|8. Strategy / Planning / Internal Sales documents||8. Survey Tools|
Most Often Used Types of Writing
I decided to create two different list of my writing tasks / tools to show the multifacetedness of technical writing. For instance, many of my “most often used types of writing” involves doing more than just writing (especially the higher ranked types). To create a strong white paper or webpage requires knowing design skills, information management, and UX expertise. Sometimes, I spend more time designing white papers and case studies with design tools than I do actually writing. This often makes me feel more like a visual designer than a technical writer, but I would argue that you would need to know skills from both trades to make a compelling document that is exciting to read.
Case Study Design
I created this document above to explain how Jacuzzi is using my company’s platform to create a connected hot tub. One of the biggest challenges with case studies is they offer a lot of information and most clients don’t have time to read them. As such, I believe it is important to create a document that would excite clients and can be read quickly. For this case study, I create a document that is easily scannable with data visualization and short paragraphs, while adding visual interests with color contrasts and visuals. I had to use design tools like Sketch to make visuals that draw the reader’s attention and use information management skills to organize the information in a way that is compelling.
The Importance of Tools
In “Using Social Media for Collective Knowledge-Making,” Longo discusses how technical communicators must become masters of ICT technologies. I would add to that and say that technical communicators must master more than ICT tools nowadays, but also must become a master of design, information management, task management tools, and more. The number of tools required to be a become a proficient technical communicator is only increasing too. However, while mastering all of these tools is helpful and certainly increase career opportunities, I wouldn’t say a technical communicator must be an expert at all of them.
The Bottom Line
As a marketing technical writer, it makes sense why I see visuals and design tools as such an important element of being a technical communicator. However, a technical communicator who focuses on creating internal documentation may not need to know the same number of design tools as I do. They may prioritize other skillsets and tools that I may not even know about. And that’s the benefit of being a technical writer – there is so many different routes and paths to specialize in. These wide range of skillsets and purposes make it hard to define what a technical communicator is, but it is certainly not a weakness. It’s something we should celebrate more.