Terminology is a very important part of the job of a technical communicator – whether it involves developing new terms for a project or following a pre-established list of terms. By using the rule “1 term = 1 concept”, the consistency of the content is maintained within documents, between documents, and between writers. This leads to improved quality as well as reduced costs and time, for both content development and translation.

On the other hand, being consistent about the terms used takes extra effort. No wonder that technical communicators are often seen by their colleagues from other departments as pedantic and overly detail-oriented when it comes to their emphasis on terminology. Nonetheless, the benefits of using consistent terms go way beyond the faster and cheaper development of technical documents. The following paragraphs illustrate with concrete examples how integrating terminology to a global content strategy can improve customer satisfaction and boost corporate image.

Help your customers help themselves — terminology to improve customer satisfaction

Bill’s story

Bill has bought an electric razor from ABCtech but now needs a new AC/DC adapter. The AC/DC adapter is described in the user manual delivered with the razor. He wants to order it online, so he searches on Google for “AC/DC adapter ABCtech”. The search returns nothing relevant. Although the user manual refers consistently to “AC/DC adapter”, the website refers (just as consistently!) to “power supply”. Bill might find, with some additional effort, what he is looking for, or he might think of calling the customer support (which generates extra costs for ABCtech). Or he might go ahead and buy a whole new razor because he concludes that the AC/DC adapter is not available separately. His satisfaction with the product drops. He is much less likely to buy products again from ABCtech.

What to take away?

With about 60 billion pages indexed on Google, finding the right content is like looking for a needle in a haystack. Helping your customers have easy access to the information they need when they need it leads to happy customers, while reducing your support costs. Happy customers are more likely to be loyal customers. Regardless of the type of content, a company-wide content strategy should include terminology: “1 concept = 1 term”.

SEO meets terminology — terminology to boost corporate image

The story of Catherine, Andrew and Simon

Catherine writes an email to Andrew about the product feature “EasyID”. In his answer, Andrew spells the product name as “Easy-ID”. An email is informal communication and does not, in theory, require spell checking of product names. But this email conversation gets forwarded to Simon from marketing, who copies a paragraph directly from the email as content for the website. The English website now includes different writings of the same product name; not to mention the repercussions on the consistency of the translation.

What to take away?

These inconsistencies look very unprofessional for (potential) customers. But further than that, the website might be penalized by search engines, like Google, as the keywords are not repeated between pages. As a result, the website might be ranked #6 instead of #3 in the organic search results. Customers will have more trouble accessing those pages when searching with keywords in a search engine. Nowadays, companies spend a lot of money on online marketing and the implementation of Search Engine Optimization (SEO) keywords. Their goal is to optimize their ranking in the organic search results of certain keywords. Content strategy should always involve the implementation of consistent terminology: using the same terms throughout the content (webpage, user manual, datasheet, order form, service request, etc.) can boost visibility and greatly improve corporate image!

And now what?

Is terminology about details? Yes. Are those details worth the effort? Most definitely. And the benefits go way beyond technical documentation. A content strategy that reaches across departments, products, and publishing media, and that includes global terminology management, can boost company success. If you are a product manager, a marketing expert or an SEO specialist: go ahead and get involved in the terminology efforts of your company! Everybody will win!

Are you interested in learning more about terminology and technical communication? Check out the online Master’s Degree in Technical Communication and Localization (TCLoc) from the University of Strasbourg.

Choosing the right path in the software industry might be confusing, especially for people with a non-technical background. Yet, the software industry offers numerous non-dev roles that are worth exploring. In this post, Valentin is sharing his experience with some of them.

When I decided to make a career change back in 2016, I was looking for a position in the IT industry that would not require a technical or programming background. I had spent the last 10 years as a manager of an insurance brokerage firm and this experience looked irrelevant to a career in the IT industry. The first idea that popped up was to become an IT project manager. So, I launched a plan to attain this goal. I did some research and quickly subscribed to project management classes, paying from my own pocket. I got a CAPM, and later an ITIL certification, with the hope that these assets would somehow help me get recruited as a project manager by an IT company. I even started going to project management conferences, hoping that networking might be the key to my dream position. Well, after a couple of interviews, I realized that I might never get a chance to start directly as a project manager. The hiring managers were asking me for some real experience in the IT industry and I had none.

The discovery of the technical writer’s job

Eventually, I started a job thanks to my language skills – a media analyst with German. Within two years, I got promoted to a project coordinator of a team of media analysts and looked closer to attaining the project manager status, albeit not in a software company. At that point, I got acquainted with another non-dev role that aroused my interest – technical writer of software documentation. As before with project management, I did my homework and took a series of online courses to prepare for the role. In contrast to my previous job hunt, this time I had some experience that looked relevant to my aspirations. Moreover, I had prepared a tech writing portfolio on GitHub and had volunteered at my project coordinator job to write some procedures and to produce some instructional videos. So, after about a year of fruitless interviews, an offer finally came my way and I was hired as a technical writer by a UK-based software company. This is how I embarked on a career in technical writing that has brought me a lot of fulfilment and opportunities ever since.  As a technical writer, I get to plunge into product details and explain things to users in the best possible way, and this is something I enjoy doing.

In the meantime, I had the chance to try another non-dev position in IT that turned out to be a hidden gem. The role of the software business analyst is similar to a tech writer in that both roles are producing documentation. However, the business analyst writes the documentation at the beginning of the software development process, whereas the technical writer steps in to explain the final product to the end-users. The business analyst is bridging the gap between the product owner and the dev team, translating business requirements into technical specifications. User stories are his craft and the dev team are his end-users.  The skillset of a business analyst is very similar to a tech writer and a transition between the two roles, especially within the same company, is quite possible. An advantage of this role is that the developers will recognize your skills immediately since they are consuming your documentation, whereas the efforts of the tech writer are sometimes underestimated by the dev team.

The three non-dev positions that we discussed – project manager, technical writer, and business analyst – are all interesting and are suitable for someone who wants to thrive in the software industry but is not a programmer. I am currently working as a technical writer for a US-based product company and my preference goes clearly towards this position. A business analyst is also a great role if you are looking for more interaction with the team and the customers. At the moment, my least preference goes to the role of the project manager. However, this would be a great role for someone who already has substantial experience in the software industry or is good with the coordination and motivation of people.

Currently, the global software industry is providing some great opportunities not only for programmers but also for people with business or linguistic backgrounds. However, if you want to be successful, you need to build a strategy and have a vision of where you want to go.

Web Accessibility is becoming more and more prominent in the digital realm – and that’s great news. Recognized standards such as the Web Content Accessibility Guidelines (WCAG) or the European Accessibility Act are pushing things in the right direction. What about technical documentation? How can technical writers make documentation more inclusive?

Why Does Technical Documentation Accessibility Matter?

Web Accessibility aims to make websites and other digital resources easy to access and to interact with, for people with a wide range of disabilities or socio-economic restrictions. When it comes to technical documentation, accessibility makes a lot of sense because everyone should be able to understand how the product they bought works and what safety measures need to be addressed. Therefore, accessibility practices should be applied from the beginning of the documentation writing process and not added at the end as an afterthought. Whether your technical documentation is digital or printed, many factors have to be taken into consideration to bring everyone on the same starting point.

Choosing the Right Font

Improving overall readability is one of the most obvious aspects of technical documentation accessibility, especially for people suffering from dyslexia. Picking the right font is a great place to start.

A study conducted by Luz Rello and Ricardo Baeza-Yates has shown that sans serif, roman, and monospaced fonts, particularly Helvetica, Arial, Courier, and Verdana are increasing reading performances of dyslexic people. Furthermore, the use of italic and underlining should be avoided. Emphasizing parts of the text in bold is, however, recommended.

In any case, larger fonts, high contrast accompanied by smart page spacing are proven to increase reading speed and make your page look much more neatly and clear.

Picking Colors Wisely

It is no secret to anyone, we do not see the world with the same eyes. Color blindness affects approximately 8% of men and 0.5% of women. To ensure a good reading experience for those suffering from a vision deficiency, using enough contrast between colors is essential. Black text on a whitish background is the best option for your main text.

Also, for obvious reasons, you should avoid using red and green to distinguish two elements, in a chart for example. Instead, try and add texture or other elements to make sure the legend is clear and people get the message.

Illustrations Are Worth a Thousand Words

In order to decrease the amount of text in your document, do not hesitate to add photos as well as other graphical elements. Not only does it vary the form of your message, but people might also be more receptive to an illustration such as an infographic rather than paragraphs of plain text. Of course, the previous tip on colors also applies here.

Moreover, if your documentation is available online, you should always pay close attention to filling the alternative text tag (“alt tag”). Be as descriptive as possible so that people equipped with screen readers or people with very limited internet access do not feel left out.

If this subject interests you, you should have a look at the principles of Universal Design for Learning (UDL) and the Gestalt theory. Both are great resources in terms of making visual content as interesting, clear, and accessible as possible.

Have a Minimalistic Approach

Over consumerism has led us to crave more minimalism in our lives. Technical writing is no exception. Being a good technical writer involves being able to leave out unnecessary details. Think “Enhance rather than distract”.

Going straight to the point leaves less room for misinterpretation. The goal is to provide documentation that people are able to understand and learn from. One way to do this is to simplify the document as much as possible. Here are a few tips:

  • Use lists to structure your content. It avoids using sentences when they are not needed and allows the page to feel airier.
  • Emphasize with boxes. Again, it is a great way to structure the information and isolate important parts of the text without adding too many distractions.
  • Keep the layout simple. Using clear title hierarchy and indentations is a solid base. Then, one paragraph should not contain more than one idea.
  • Avoid difficult words and jargon. Stick to simple language applying the Simplified Technical English (STE) standards. For instance, you should always favor the present tense and active voice.

We hope this article was helpful. Do you follow any accessibility guidelines when writing technical documentation? If you do, feel free to share your best tips!

Interested in reading more about technical communication? We have plenty more articles!

Sources:

As an English literature graduate who developed a rather unimaginable passion for technical writing many years ago, I was thrilled when I came across the Persona Method in Alan Cooper’s book “The Inmates Are Running The Asylum. Why High Tech Products Drive Us Crazy And How to Restore The Sanity” (1999).

The idea of combining fiction with product design instantly appealed to me. After all, technical communicators create information products, therefore applying this technique to that domain seemed like a good idea. However, I was really uncertain about the possibility to implement it in the business setting I found myself in. Would a small team of no-nonsense “technicians-assigned-to-act-as-tech-writers” be willing to adopt it?

Persona Method Yes or No

But before I delve into my own experiences, let me first answer the question you might have in mind now:

What Exactly Is the Persona Method?

Actually, although my introductory sentence may have implied it, the Personas that this technique refers to are not quite as fictional as The Great Gatsby or Oliver Twist.

For the most part, their personal details are based on hard facts: Marketing questionnaires, business survey, or similar means helped to establish demographic characteristics such as age, educational background, financial situation, and geographic location to identify the target group(s) for a product or service

The author mentioned above, Alan Cooper, generally credited with inventing the Persona Technique, first applied it to an IT setting.

His impetus was his increasing frustration with hard- and software that was not user-friendly at all, coupled with his observation that the software developers surrounding him did not consider users’ needs at all when coding and designing applications and interfaces.

As a consequence, he decided to confront these programmers with some characters that incorporated all the attributes of “average” users using the data collected in available customer surveys and marketing analyses. Cooper argued that if programmers were faced with individual “persons” rather than abstract data and were told to design for them, it would enable them to take user needs and user experience into account. Indeed, it is usually easier to relate to a human being (albeit a fictional one) than to statistics.

How to Create Personas?

In order to create a Persona, the statistical data described above has to be “personified” to define the target group(s) of a product or service.

Let me use an example to illustrate this: If the majority of users of a new hairdryer are female teenage high school students that live in Spain, a user persona might be 15-year-old Isabella from Barcelona. Fictional details are then added to this “average user” to make the Persona more complex and thus more credible as a “fellow human”: For instance, Isabella could be the member of a swimming team in her free time, and an avid watcher of YouTube videos and Netflix shows.

What Are the Benefits of Applying the Persona Method to Technical Writing?

At the moment, except for software development, where Alan Cooper first introduced it, the Persona Method is mainly used in marketing. However, the statistical data it is based on is also very valuable to technical communication (TC), as it reveals who we should be writing for. Furthermore, converting abstract information into concrete personas can also improve the quality of technical documents.

The field of technical writing is similar to software development and marketing in that the material – created by technical communicators (such as manuals and catalogs) – is also closely related to the user experience and mainly is to fulfill the needs and expectations of a certain target group.

Having a particular person(a) in mind makes it much easier to find the right tone and terminology. We can put ourselves in the readers’ shoes when instructing them how to use a product or service, addressing them in a way they understand.

For more information on Personas in UX design, visit https://www.interaction-design.org/literature/article/personas-why-and-how-you-should-use-them, for instance.

What Are the Challenges of Using the Persona Method in a Conventional TC Setting?

That said, motivating a team made up of innovative, open-minded “nerdy” programmers in charge of writing the code for a hip new application to attempt applying this technique should not be too difficult. Given the high percentage of “Lord of the Rings” and “Harry Potter” fans among them, it is safe to assume they are willing to relate to fictional characters anyway.

But What if the Business Setting and the Industry Are Not Quite as Hip & Cool and the Staff Not as Nerdy as Expected?

Back to my own situation at the time when I discovered the Persona Technique: My work environment was arguably as far removed from the (admittedly fairly stereotypical) image evoked above as one can imagine: A medium-sized company in the domain of mechanical engineering, with 99% of the staff made up of predominantly male, purely technically minded, down-to-earth employees.

My immediate enthusiasm in sharing the idea of applying the technique in this setting was severely curbed. But then I remembered what one of the two technicians (let us call him Simon) assigned to the technical documentation team had told me earlier during our lunch break when I had naively asked him what his favorite novel was:
“Are you kidding me??? What’s the point in dealing with stories that weirdos with too much time on their hands felt the urge to write down, about strange characters they made up in their twisted minds?!”
In the end, however, my curiosity won over.

First, I started looking for success stories of the use of the Persona Technique outside of agile work environments and marketing for encouragement. I actually came up with some results, such as a library that used the Persona Technique.

However, in this particular case, it depends on the willingness of the staff to account for a certain amount of fiction in their daily surroundings is still rather apparent…

Then, since the tech writing team was to be my target group now, I started to consider their needs.

I came up with the following guidelines for my hands-on experiment:

  1. Do not overwhelm the staff
  2. Give them something they can relate to
  3. Suggest, but do not impose

…and this is how I approached the challenge:

  1. Although Alan Cooper suggests using more than one persona to cover a range of user needs, I decided to use only one. One reason for this was that the data I had unearthed about the users of the said machines revealed that the target group was pretty uniform. It was mostly made up of middle-aged men without higher education – and by “mostly”, I mean that there was almost no exception. Besides, I wanted to keep the introduction of this new method as low key as possible, so as not to upset the team members by putting several exotic characters on display which would soon get on their nerves.
  2. It was clear that the “prototypical user” had to be someone the team could relate to, that is, preferably a local person with a plausible background. So, I came up with “Matze” (a common nickname for the German first name “Matthias”), a 43-year-old married man, father of two children who grew up and still lived about 60 miles from the company headquarters. Aside from his job as machine operator, he also loved soccer. A life-size photograph of a guy who matched this description had easily been found and a mini bio had been added to it, along with some of his quotes and his expectations regarding user manuals for the machines he worked with.
  3. I turned this information into a huge poster that I put up on one of the office walls I shared with Simon and the other two tech writers. I did this in late December when my coworkers had already left for their holiday. On their return after New-Year’s day, they were slightly surprised and amused but studied the poster with interest – even if only as an excuse for a coffee break at first. There were no discussions about taking “Matze” off the wall again, and after a while, whenever one of them was handed product information by the product developers, comments such as “Hey, Matze would not understand this!” – “Matze wouldn’t be able to use this info, let’s leave it out” became commonplace in the office. Even though it was more of a tongue-in-cheek attitude at the beginning, we (above all Simon) kept referring to “Matze” in similar cases.

I leave it to you to decide whether my story is a “success story” or not, but I would like to encourage you to share your own experiences with me, either with the Persona Technique or with other approaches that, for some of us, might be just as exciting as the Persona Technique was to me.

As for myself, I was satisfied with the outcome, and I would be even more satisfied if I knew that one or two of the product developers read “Matze’s” comments as well, maybe getting a better idea of what technical documentation really aims at.

And what about you? Feel free to share your experience below with the Persona Method.

Meet Ken De Wachter, the professional translator, technical writer, and trainer who will be instructing TCLoc students on how to use MadCap Software products. His experience with studying, teaching, and working in translation and technical communication makes him the perfect choice for our extracurricular course on one of the leading tools in the industry.

In addition to the required teaching units in the curriculum, TCLoc students sometimes have the opportunity to follow extracurricular courses as well. These are optional courses that the program offers simply to provide students with more knowledge and skills. Teaching such a course is Ken De Wachter, owner of the consulting company Flynxo and professional in technical writing and translation. He has joined the TCLoc community to introduce our students to the most important tools from MadCap Software, a leading resource for authoring and publishing solutions for technical writers and translators. Before the start of his course, we were able to schedule a meeting with Ken to get a sneak peek. He kindly shared not only a glimpse of what he’ll be teaching but also what his professional journey has been like and what he’s up to today.

Meeting Ken De Wachter

It’s always exciting to have a new instructor join the community. Welcome, Ken! What motivated you to give this training on Madcap Software tools?

My contacts at MadCap told me that you were looking for a teacher and asked me if I wanted to be introduced. Of course I did! I’ve been teaching at the University of Leuven for ten years — mainly CAT tools, but these last years I’ve also taught terminology and technical writing. I also train professional translators and technical writers in companies. I love the contrast between those two profiles. Professionals know exactly what they want to achieve and care less about the rest. Students have a broader interest and learn at an incredible speed, but they often have less insight in real-life applications and business value. What I like most about teaching students is having an impact on their future career. I regularly run into alumni, and they often impress me with the way they implement the things we did in class. I secretly prefer teaching students, though the industry pays better. A good balance between the two is ideal.

Obviously, when I learned more about the TCLoc master’s degree program, my enthusiasm grew even more. As a translator and a technical writer, I’ve always been a strong advocate of interconnecting these two fields. This hybrid master is doing exactly that, and I’m really honored to be a part of it.

The Journey to Translation and Technical Writing

Well, it’s so great to have you. Tell me about how you got involved in technical communication and translation. How did you get where you are today? Where did you start?

During the final semester of my master’s degree in translation at the University of Leuven, I started thinking seriously about what would come next. I realized that I loved languages, but I didn’t really know how to make a living off that. Translating seemed like too much of a solo activity; it also implied that I would have to become a freelancer. That scared me a lot.

At that point, I was writing my master’s thesis under the supervision of Prof. Frieda Steurs, one of the leading ladies in the field of terminology. She put me on the track of specialized language and terminology and showed me its economic opportunities and business value, which helped me envision my professional future. So, I enrolled in a postgraduate programme about language technology and computational linguistics. After graduating, I got recruited by the university and worked on a variety of projects — all of which revolved around terminology and translation quality.

And how did you like that kind of work?

At the start, I loved that job. I got to travel all over Europe, see its most beautiful cities and work with incredible people. It made me a true European citizen. However, after five years, the high pressure and work pace caught up with me. I had just gotten married and was tired of being away from home so often. So, I cut back my hours at the university and got a part-time job in an ICT company as a technical writer. To be honest, I thought that it was going to be boring to write user documentation, but I actually enjoy it a lot. ICT is a fun domain to work in. Being a tech-savvy linguist amongst developers is great because I have a completely different skill set. 

You’ve continued combining jobs in these fields ever since, it seems. Why does this appeal to you and what are some of your current projects?

I’ve always been too restless for a traditional nine-to-five, but I want the stability of a fixed income. The combination of working part time as an in-house technical writer and having my own little consultancy company, Flynxo, gives me the best of both worlds.

My regular job is at Collibra, a fast-growing company that develops software for data management. It’s an agile environment with monthly releases. Quite a challenge for the documentation! We write our user documentation in MadCap Flare, with GitHub as our versioning tool. Our workload depends a lot on the engineering teams. I’m constantly in touch with different development teams to discuss new and updated features. I keep a lot of plates spinning, so I have to split up my work into tasks, then prioritize and plan them. Having freedom and responsibility really keeps the work interesting. Some weeks, the developers deliver a lot of new features, so I can only document the most urgent things. Other weeks, developers do more backend work that doesn’t affect end users directly, so I can do in-depth research and document business cases and best practices. 

I also enjoy having little adventures on my own, so I founded Flynxo. In the beginning, I mostly worked with terminology and translation technology. Later, I expanded into authoring technology. Mainly, I give training on SDL Trados Studio, Memsource and MadCap Flare. 

In the past 10 years, I think I’ve seen every kind of organization in Europe and every domain. I’ve worked with “typical” translation agencies and freelance translators, but also with government agencies, a wide range of in-company translation departments and even the army.

Other domains I’ve worked with include automotive, healthcare, pharmaceutical, finance, energy, ICT, transport, e-commerce and heavy industry — each with their own particularities and requirements. 

My favorite project is helping Translators without Borders (TWB) set up a terminology workflow. After a humanitarian crisis such as a hurricane, crisis response teams from all over the world go on site to help. One of the challenges is often communication; TWB provides linguistic services. We’re now working on a project to manage crisis and COVID-19 terminology, translate it into many languages of lesser diffusion, and disseminate it amongst translators and interpreters.

The Role of MadCap Software

You have quite a variety of professional interests! Although you’re certainly qualified to teach many subjects related to our curriculum, you’re providing our students with training on MadCap Software tools. What’s so great about MadCap Flare and how does it relate to technical communication?

Flare is MadCap’s flagship. It’s an all-inclusive authoring suite with powerful single-sourcing capabilities. You write content in a relatively easy editor and combine those pieces of content into a concrete target. You write it once, but you can reuse the content as often as you need. You can also tag content if you want to create different user guides from the same content. That allows you to create tailored user guides for specific companies or user types.

For example, imagine you need user guides in PDF and HTML for starters as well as advanced users. Your product may also have different licensing types and optional modules. Some customers may have specific requirements and custom features. You’d need dozens of user guides with a lot of overlapping content. In theory, it’s possible to do that in MS Word. In practice, it would be impossible to keep all the documentation consistent and harmonized. 

Every change in your product, big or small, requires updates to the documentation. You don’t want to dig into dozens of Word files trying to find the relevant sections. You want a central repository of content in which you can make the required changes. Our company releases product updates almost every two weeks, so we need to follow the development cycles closely.

That’s where Flare shines. For each user guide, we have a “target” defined in the software and the target knows which content is relevant for its guide. So, we simply update the content in the central repository and move on. All relevant user guides will be updated automatically.

MadCap Flare and Other Documentation Software

Wow, that is amazingly efficient. But how does Flare compare with other technical writing solutions? What are some similarities and differences?

In the category of complete authoring suites, the biggest competitor of MadCap Flare is Adobe RoboHelp. The tools are a bit similar. Although Flare is the younger of the two, it quickly took a large piece of the market. Obviously, it’s also a matter of personal preference, but I think Flare is easier to use and more complete.

Some of the biggest competitors of Flare aren’t really proper authoring tools: MS Word and wikis such as Confluence. I often compare it with sleeping on the couch. It works, but it’s not comfortable and gives you a pain in the neck. Typically, Word and Confluence are used by companies that don’t really want to invest in proper documentation.

Then there’s DITA. DITA is not a software application, but an XML architecture that was designed for documentation. You can author the DITA XML files in any XML editor, such as Oxygen and XMetal, or even Notepad++. You can create the actual output files by importing the DITA XML files into a publishing tool such as Adobe InDesign or FrameMaker. Though I like some of the features, DITA is too complicated for most companies. 

Finally, there are markup languages such as Markdown and Asciidoc. Just like with DITA, they’re not software applications, but they provide markup to write documentation. Also similar to DITA, they have some very good features, but user-friendliness is not one of them.

MadCap Software and the Industry

Tools and technologies are constantly evolving and being updated. What are some of the ways MadCap Software has affected or been affected by the technical communication industry?

MadCap is growing fast and has made it easier for companies to publish attractive documentation. This creates a lot of awareness of the importance of user documentation. They also evangelize topic-based authoring very efficiently. They also really excel in building community — there’s an interesting blog section on their website, a Slack community, and my favorite conference of the year: MadWorld.

If you work in a company, it’s easy to get stuck in your ways and routines. MadCap really succeeded in connecting technical writers across companies and industries. After all, technical writers in other companies face similar challenges. By reaching out to them, you can see how they solve problems and learn from them. Or, alternatively, you can help them.

A great example of this is the use of interactive elements in user documentation. Three years ago, we didn’t use any dropdown selectors or buttons in our user guides. Then, during a session at MadWorld, a speaker showed some examples of them and shared a simple JavaScript to make it possible. My colleagues and I started using it at Collibra, and some of our developers improved the JavaScript further. Obviously, we shared the upgraded version with others. So, the MadCap community gave something to us, we used and improved it and then gave it back to the community. Everybody wins.

TCLoc and MadCap Software

This idea of community is definitely a value shared by the TCLoc master’s program as well. What information and insights will you be sharing with our students during your course?

Simplistically formulated: students will learn the most important features of MadCap Flare. They will be able to create a documentation project from scratch, edit the content and publish it in HTML and PDF. Obviously, we’ll cover a lot of tips, tricks and best practices. Realistic, hands-on materials will show both the advantages and the limitations of single-sourcing. Students will do some real writing and content structuring. We might even throw in some JavaScript to make the content interactive!

The goal is to have students go beyond the “simple use” of Flare and come out of this course as fully independent users!

It sounds like it will be a great course! We’re so excited to provide access to this software and training to our students. Thank you for taking the time to do this interview and for lending your knowledge and experience to our program!

Are you familiar with MadCap Software products? Which one is your favorite and what do you use it for? Let us know in the comments! Also, if you are a TCLoc student or alumni, contact us to see if you are eligible to receive licenses to access MadCap Software products and other software tools.

Joining the TCLoc community of instructors is Hilary Marsh, a content strategist with decades of experience and president of Content Company, a content and digital strategy consultancy. She is a leading expert on effective and efficient content creation, organization, and management. Having already created and taught graduate-level courses on content strategy, she is excited to share her experience and insight with TCLoc students and show them the important role content strategy plays in technical communication. In this article, she gives us a sneak peek of her course and shares with us the professional path that led her to where she is now.

Discovering Content Strategy

We are so excited to have you as one of our instructors, Hilary. You have so much hands-on experience in the field. Did you know from the beginning that you wanted to help people create great content? How did you get your start? 

My path to working with content started during my studies. I went to Syracuse University for psychology and magazine journalism. When I started at Syracuse, I was studying English. In my spare time, I helped edit the university’s literary magazine and learned, to my surprise, that the school offered a program in magazine journalism, so I transferred into that program. My professors stressed the importance of structuring articles with the most important points first, finding out the details behind the facts for a powerful story, and learning about the audience. I also studied psychology, which taught me about how people’s minds work. I find that I use both sets of skills in my work every day!

After graduating, I started my professional career as a magazine editor and then went on to be a copywriter for a large cosmetics company, where I wrote copy for both sales representatives and consumers. When I discovered the internet around 1995, I wanted to use my combined skills in editorial judgement and promotional/informational writing in this new medium. However, at the beginning, it was a struggle, because people assumed that websites were primarily about the cool technology and design, and content was an afterthought. (Unfortunately, this is still the case far too often even 25 years later!)

My first experience with writing digital content was for a nonprofit arts website. After that, I got a few assignments writing web copy for some corporate brand websites. I also wrote some magazine articles about websites’ business models. When I moved from New York City to Chicago in 1997, my previous work experience led me to a job for a major printing company, where I led the effort to revamp their corporate website, manage its content, and start their first intranet. In 1999, I took a position with an e-commerce beauty startup.

It sounds like, little by little, you got closer to what you wanted to do. Had you heard the term “content strategy” at this point, or was it still just a concept you had imagined? 

I first heard the term “content strategy” at a conference in 1999, defined as applying a publishing mentality to a website, and I knew that that’s what I had been trying to invent. Several months later, I began working for Sapient, an interactive e-business consulting company, starting their content strategy practice in Chicago. I also taught a class in web content and information architecture for University of Chicago’s Graham School.

When the dot-com bubble burst in 2001, I was laid off, along with my whole team. Since I knew that every website needed a content strategy, I started a content strategy consultancy, Content Company, with my first client being a student from my course. I worked with that client, a large financial services firm, for several years, first helping them revamp their corporate site and then winning a large contract against major consulting firms to lead the content strategy for their first web-based intranet. I also started speaking at conferences about content management and content strategy, trying to help people make the connection between their business and their content. 

It was a challenging time, because while content strategy was a known entity for the people and agencies that practiced it, most companies had no idea it existed or that they needed it!

It must have been difficult to convince companies that they needed something when they didn’t know it existed. Fortunately, you were helping spread the wordand still are today! What are some of your more recent projects?

In 2005, I started working for the National Association of Realtors (NAR), an association with more than 1 million members. I oversaw the organization’s member website and started its first social media program. My team and I worked with the organization’s staff to ensure that members understood what NAR offered to them and that could easily take advantage of its myriad programs, products, and services.
I left NAR in 2011 to restart my consultancy. I currently consult with associations, nonprofit organizations, government agencies, and corporations. In 2013, I developed and taught the first graduate-level content strategy course, for Kent State University. Over the years, I’ve spoken at numerous content strategy, UX, digital, and technology conferences in the United States, Germany, Denmark, and Australia. I also run mentoring groups for current or aspiring content strategists—the next one will start in January 2021.

Defining Content Strategy

Today, the idea of content strategy is not just accepted, it’s essential. But what does this term mean, exactly?

Content strategy, as I first learned it back in 1999, is identifying the who, what, where, and how of publishing content online. Since then, we’ve created deeper definitions, encompassing our understanding of everything needed to create a sustainable strategy for the organization’s content. The definition I use nowadays is this: 

Content strategy is the practice of planning and assessment for the creation, delivery, and governance of useful, usable, effective content. 

I added the word “effective” to the definition this year, because I wanted to make sure that organizations understand that content needs to have an explicit audience and clear, measurable goals.

It sounds like a thorough, inclusive definition. How can it be applied from different perspectives and to different contexts?

For the clients I work with, content represents their work—their programs, products, and services. Content strategy, then, is taking a strategic approach to the content OF and ABOUT their work. Kathy Wagner, of Content Strategy Inc. in Vancouver, Canada, calls the first type of content “core content,” distinguishing it from the marketing content about the work.

If you do an online search for “content strategy,” many of the results are actually about content marketing strategy. Content marketing strategy is about creating and then promoting content for marketing purposes, such as blog posts, customer stories or testimonials, and campaign-related content. Content marketing strategy uses many of the tactics and techniques of content strategy, but only for marketing-focused content. 

The vast majority of valuable content that organizations create—the core content of their programs, products, and services—exists because the business exists. This includes content from the events they offer, information about the organization’s history, publications they produce, educational courses they offer, and so much more. This content doesn’t exist for marketing reasons at all and, without it, the organization would literally not exist and there would be nothing to market.

An example that’s especially relevant for technical writers is help content. The audience for help content is existing customers, and the goals are about increasing customer satisfaction and reducing support calls and complaints. These people were “leads” for marketers and became “users” of the website. 

Considering the variety of content that exists, what is the most important thing to remember regarding content strategy?

Successful content is that which works for the audience and, therefore, the organization. A true organization-wide content strategy would make sure that the audience is at the center of all content decisions, whether it’s marketing content, product details, or support information. These decisions are about planning content; making sure it has the right voice and tone; stays updated; uses the organization’s taxonomy; and follows the criteria for promotion, maintenance, and retirement/expiration.

Making sure content is relevant to the audience is more complex when the audience may live in a variety of locations. Simple one-to-one translation of words is almost never enough to produce content that is relevant to audiences, so this has to be planned for from the beginning. The work involves creating internal lines of communication, establishing the right workflows, making sure the CMS templates accommodate multiple languages, and designing the pages to accommodate various requirements.

Teaching Content Strategy

As many of our students already work in fields related to technical communication and localization, they might already be aware of the importance of content strategy. How will this course help them understand it and use it in their professional lives?   

This course is an introduction to the broad set of content strategy tools and techniques, with an emphasis on the core of audience understanding. It also covers topics that make content strategy especially challenging, such as planning content collaboratively, establishing success metrics, managing change, and getting senior-level buy-in. The course introduces these new concepts and practices and invites students to integrate and apply them to their own experiences and professional expertise.

By the end of the course, the students will be able to better facilitate content planning, improve content quality, and establish sustainable practices. While these skills are certainly applicable to translation and technical writing, they are also very relevant to those who work in project management and visual communication.

Content strategy is such an interesting topic and has so many applications. We’re proud to have you teaching it in our program. Thank you for your time and keep spreading the word about content strategy!

What did you think of this article? Do you use content strategy or do you see the need for it in your current job? Let us know in the comments below! If you’re interested in this course, check out the rest of the curriculum on the TCLoc website. And don’t forget to check out other articles on our blog!

Meet Serge, the reckless French bunny that improved child safety in trains and accidentally made a statement about technical communication.

Safety signs are a core element of technical communication as well as a source of growing concern. Our lives are increasingly swamped with machines, devices, chemicals, energy, and speed—all of which provide great benefits, but also involve substantial risks. Consequently, as the technical communicators of tomorrow, we need to grasp these issues and put in place the relevant warnings to protect people from danger. 

For decades, technical communication regarding safety has mainly targeted consumer goods and particularly the industrial sector, where workers face multiple risks under the pressure of productivity requirements. As a result, useful guidelines and regulations on safety notes and warning messages have been developed, implemented, and refined, such as the European Machinery Directive 2006/42/EC or the ANSI Z535 and ISO/IEC 82079-1 standards.

The challenges of communicating safety hazards 

What makes hazard communication so difficult?

As far as hazards are concerned, such guidelines often recommend using standardized pictograms and texts to provide consistency, conciseness, simplicity, and comprehensibility across cultures and contexts. Lately though, a growing emphasis has been placed on adapting such standard messages to different target audiences, contexts, and reading conditions (as in tekom’s “Safety Notes and Warning Messages.”) After all, warning signs do not concern solely consumer products and workplace safety (already subject to a remarkable degree of standardization), but also public spaces and facilities. With equal importance, warnings are not always directed to trained workers or consumers in top form. While young children or elderly people will probably never use a steel press or an industrial oven, they may well step on slippery surfaces or go through heavy automated doors regularly. Consider, for example, the multiple hazards that plague public transportation.

Safety signs in public transportation

So, how do conventional safety signs fare in settings like public transportation? On the one hand, mass transit involves obvious risks such as turnstiles, moving vehicles, power, opening and closing doors, going up and down, in and out. On the other hand, commuters include people of all ages, conditions and impairments, often busy or in a hurry. The result is a minefield for technical communicators: multiple dangers to warn about, different audiences with specific needs, and the requirement to be simple and concise. 

Now, think about children. They are curious, restless, easily distracted, and very often either unable or unwilling to read. Write “Keep away!” and kids will already be too close; add a “Do not lean on the door!” sign and they will probably lean on the sign itself. Finally, children can never, ever, be expected to mind the gap. Luckily, very young humans are not the only funny little animals to board trains. In Paris, France, a rabbit has been getting his hand trapped in the subway’s doors since the late 1970s—all for child safety.

How can we adapt safety signs for children?

Hazard communication through cuteness

Our friend Serge was created in 1977 by Anne Le Lagadec (inspired by the endearing lack of prudence of her own pet bunny) and slightly updated afterward. From its very inception, this cartoonish and anthropomorphic rabbit has placed his hand in the wrong place, thus warning about the dangers of automated doors—and beating many expert technical writers in the process. These eye-catching stickers are placed at a medium height (around children’s line of sight), include a caution message (often in several languages), and are highlighted in visible colors, such as yellow, red or orange. Under the message, a visibly surprised and scared rabbit shows both the risky behavior (placing the hand on the door) and its consequences (getting trapped). 

Hazard communication for children: Adapting the standards

So from a technical writer’s standpoint, what standards would be applicable to such a caution message? In principle, warning signs should stand out and include identifiable but abstract pictograms, coupled with a short text specifying the danger involved, its possible consequences, and the ways to avoid it. Nevertheless, when children are the main target group, signs should be adapted accordingly. 

As suggested by a recent research project by Waterson, Pilcher, Evans, and Moore, warnings intended for children should avoid the high level of abstraction so coveted in other, more standardized contexts. According to this study involving 210 British children, conventional signs using abstract pictograms and short texts can be difficult or even impossible for kids to understand. In this sense, the authors make some recommendations to enhance awareness and comprehensibility of the warnings: 

  • Use colors to improve visibility and convey intrinsic information (red for danger, for example)
  • Feature cartoon-like characters that attract the attention of children (such as animals or superheroes)
  • Endow such characters with recognizable facial expressions
  • Use the visuals to show both the cause and the outcome of the dangerous behavior in point

Therefore, we have a complex task ahead of us: assessing the specific needs of vulnerable groups and reconciling them with the existing restrictions and general guidelines. 

Nonetheless, we should not be discouraged. Serge got it right on the first attempt more than 40 years ago and, funnily enough, straight from the pencil of an advertising designer! Little wonder this sticker has become an inspiration for safety signage and warnings in other public transportation systems, home and abroad.

Remember, mind the rabbit!

The TCLoc master’s is proud to announce that it has joined once again the Adobe Tech Comm University Outreach Program. Thanks to this academic partnership with Adobe, TCLoc students will have access to the Adobe Technical Communication Suite in order to gain firsthand, practical experience with these leading software tools for creating and editing technical documentation.

“With our master’s program in technical communication and localization, we seek to provide courses that give students opportunities for hands-on, practical application of the competencies they acquire during their coursework using the best tools available,” says Dr. Renate de la Paix, program director. She continues, “The Technical Communication Suite is the most popular collection of tools used by the industry for creating and editing technical documentation. In our Technical Publishing class, for example, we use Adobe FrameMaker because it allows users to publish natively across channels, mobile devices, and formats, and to create content with best-in-class XML/DITA support.”

The TCLoc master’s focuses on practical skills. By using the latest versions of leading tools such as FrameMaker, Captivate, and RoboHelp, students will be prepared for employment in the technical communication industry. Thank you, Adobe, for enabling our students to use the Technical Communication Suite free of charge for study purposes!

Before the 2019 November on-campus meeting, the TCLoc Team took a trip to Stuttgart for the annual tcworld conference, joining our past, present, and future TCLoc students at this inspiring event.

The tcworld Conference

The tcworld conference is organized by tekom Europe, the largest technical communication association in Europe with over 9,500 members. It takes place in Stuttgart, Germany, every year. The tcworld conference is the largest international event for technical communication in the world, boasting over 4,500 participants as well as over 250 presentations and workshops (in English and in German). Presentation topics cover everything related to technical communication from visual communication and user experience to augmented reality and artificial intelligence.

Speakers at the tcworld conference are all experts in their field and we were happy to see that some of them are also part of our team of instructors. TCLoc’s new instructor for software documentation, Konrad Brust, gave a short, insightful talk about the localization of video games. Shumin Chen hosted a workshop on Simplified Technical English (STE), the subject she teaches for TCLoc. Jordan Stanchev hosted two workshops, “Building Your First Taxonomy for Classification of Software Documentation” and “Visualize It! Creating Graphics and Images in Software Documentation.” TCLoc’s instructor of terminology management, François Massion, gave a presentation on terminology in the age of artificial intelligence. Also, Kirk St.Amant, TCLoc’s usability and user experience design instructor, presented “The Psychology of the User Experience—Approaches to User Testing and Product Design,” which proved to be a conference favorite.

In addition to the numerous presentations at the conference, the tekom fair is also a key point of interest, hosting around 150 software manufacturers and service providers. It is the only trade fair for technical communication worldwide. The conference also welcomes universities that offer bachelor’s and master’s degrees related to technical communication, setting up booths for them to present their programs. This provides the invaluable opportunity for students and educators alike to stay abreast of the most recent developments, standards, and technology in technical communication and related fields. TCLoc, an online master’s program at the University of Strasbourg, is always in attendance.

TCLoc and tekom: Bridging the Gap

This is why the TCLoc Team looks forward to this event every year: tekom and TCLoc have the common goal of bridging the gap between education and industry. tekom organizes this annual event in order to promote and facilitate the exchanging of ideas, research, and technology, thereby driving the industry towards excellence. Conversation and sharing within the industry is necessary to create and maintain standardized best practices in technical communication and related fields. Likewise, communication between industry and education is essential for the proper training and certification of technical communicators. 

TCLoc’s founder and program director, Renate de la Paix, also recognized the importance of this, motivating her to create TCLoc, which is the only online master’s program that combines a degree in technical communication and localization with the tekom certification (offered in the technical communication module, which is identical to the TCTrainNet course -professional level- offered by tekom). Graduates of the program are therefore well-equipped with practical knowledge of technical communication as well as its related fields and tools. The program (including the TCTrainNet course) is constantly being updated to stay on top of new developments and technologies in this ever-evolving industry. It’s partnerships like TCLoc and tekom that promote high quality standards in education and the workplace.

Have you been to the tcworld conference? What did you think? Let us know in the comments below and join us next year at the tcworld conference in Stuttgart, Germany, November 3-5, 2020.

Would you like to validate and increase your experience as a technical writer? Click here to apply to the TCLoc master’s program!

Product documentation can potentially be confusing, incoherent, and ambiguous in many situations. Recognising language ambiguity usually takes months, if not longer.

Several aggravating factors include: 

  • A constant need to churn out or translate volumes of documentation, manuals, and working standards.
  • Rarely questioning the relevance or validity of legacy documentation.
  • Allowing unclear parts of your technical content to snowball into substantial chunks that will eventually make up parts of your “user-unfriendly” help guides. 

Finally, let us not forget the insidiously familiar workplace jargon that often explains why we tend to ignore simpler alternatives that could help us express our thoughts with greater clarity.

From workplace jargon to user-friendly words

Sometimes, realising the level of complexity of one’s technical content involves an epiphany of sorts once the writer catches a glimpse of technical writing in Simplified Technical English (STE). This is true for one of our clients, who is both an experienced technical author and documentation manager:

“A training course helped me better appreciate the objectives of Simplified Technical English from a technical writer’s perspective. I like the fact that STE promotes the use of less complex sentence structures and does away with unnecessary words like: ‘would’, ‘should’, and ‘might’.”

Do we have a problem? If so, fix it!

For example, if you look up the meaning of the word “fix” in a standard dictionary, the definitions are aplenty, from “fixing a technical difficulty” to “fixing up a meal in the kitchen”. Given the many possible meanings that hold true for the verb “to fix”, one could also distil as many interpretations of the word in a sentence.

According to Simplified Technical English, Issue 7, January 2017, there is a solution for this. Instead of “fix”, synonyms such as “ATTACH*”, “SET”, “REPAIR”, and “INSTALL”  powerfully extend our understanding and knowledge of what “fix” really entails when paired with various contextual clues.

© ASD, 2017. All rights reserved. 

The next five words: are you thinking of these too?

Keeping in mind that these are not the only unproductive words I talk about in my workshops, they are among the most frequently discussed ones. 

© ASD, 2017. All rights reserved. 

The word “should” usually indicates duty or correctness that points to a desirable or expected state. However, it still allows the possibility of non-compliance. “MUST”, on the other hand, makes it clear that the instructions are mandatory and leaves no room for a different reading.

© ASD, 2017. All rights reserved. 

Besides the roughly 900 approved words found in the STE general vocabulary, the STE specification also includes a list of non-approved words. “Would” is one of those words that is easily replaced by a more straightforward and approved STE word like “CAN”.

© ASD, 2017. All rights reserved. 

In the STE general dictionary, the approved word examples in the 2nd column are very useful to technical writers who are transitioning from Standard English to Simplified English. This is because they provide the writer with the correct use of words in a real-life context that would be difficult to think of independently. Here, we see that “CAN” is once again a very helpful alternative to the verb “may”. Using too many words that point to the same or similar meanings can be, at times, overwhelming for your readers, especially when documentation becomes lengthier and more detailed.  

© ASD, 2017. All rights reserved. 

By this time, the effects of STE on everyday words that pose as potential roadblocks to concise writing are clear. Instead of “transfer”, STE encourages the use of “MOVE” or “INSTALL”. This adds granularity to one’s choice of verbs, making technical work instructions more detailed and easier to follow.

© ASD, 2017. All rights reserved. 

The preference in STE for the verb “MAKE SURE” over “confirm” is again another unique characteristic of this standard. This is very likely so because the maintenance committee (made up of a diverse mix of linguists, engineers, and translators) deems “MAKE SURE” a more fitting word with more frequent usage to back their word choice. 

What are some popular words in STE that trained technical writers have adopted to date?

We asked over 30 technical writers and this is by far the most comprehensive response to date:

“My favourite STE verbs are ‘APPLY’, ‘ATTACH’, ‘MAKE SURE’, and ‘SHOW’. The verb ‘APPLY’ has multiple use cases for our documents. The verb ‘ATTACH’ is a great utility verb because common alternatives like ‘mount’ are not approved. The verb ‘MAKE SURE’ is extremely helpful in cautions and warnings, as well as in some procedural steps. Finally, the verb ‘SHOW’ is extremely helpful when I write about background processes and how things work in general.” 

STE as a game-changer in our technical communication landscape

Can you envision a future where STE serves as the primary language reference for content creation and development in your field? 

We would like to hear from you. Leave your ideas in the comments section below!

Learn more about what STE can do for different types of documentation here.

Thank you for reading, we hope you found this article insightful.

Want to learn more or apply to the TCLoc Master’s Program?

Click HERE to visit the homepage.

Thanks from the TCLoc web team.