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, 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.

TechCommNZ President Meredith Evans with Steve Moss, Winner of the 2018 Excellence in Technical Communication Award.

Editor’s Note: This article was written by TechCommNZ President Meredith Evans. Enjoy !

In New Zealand, technical communicators are thriving, but there are still many industries and companies that have no idea of what we do or the value we can bring. It’s the role of organisations like TechCommNZ (the Technical Communicators Association of New Zealand) to help change that.

What is TechCommNZ?

TechCommNZ is a professional association for technical communicators, based in New Zealand.

Established in 2007, TechCommNZ strives to represent those involved in any area related to technical communication, information design, editing, proofreading, quality assurance, or documentation. We recognise that our members have a wide variety of roles and responsibilities, with many branching out into related areas such as user experience, business analysis, instructional design, and training. 

But we’re not just about promoting the industry and those who work in it. We also provide learning and upskilling opportunities and the ever-important networking and socialising.

What do we do?

TechCommNZ is a New Zealand-wide organisation, but a large proportion of our members live in one of the three main centres: Auckland, Wellington, Christchurch, and Hamilton. Each of these centres maintains an informal ‘branch’ with activities such as speakers, dinners, and catch-ups. These are usually held outside of working hours, with Christchurch (in the South Island of New Zealand) currently being the most active branch. We also welcome members from outside New Zealand too.

Professional development

A core function of TechCommNZ is to provide professional development for members. We normally facilitate at least two workshops and four webinars each year. Prices to attend are kept as low as possible for members, but non-members are welcome to attend too (at a higher cost!). We’re always on the lookout for interesting topics and presenters, so if you have an idea for a webinar, or even a workshop, get in touch with me by email Webinars are normally held at a time that suits New Zealand and Australian members (morning Australian Eastern Standard Time) but if you miss the live webinar you can watch it later at a time that suits. 


Over the past few years, TechCommNZ has held a biennial conference, which moves around the three main centres. However, in 2019 we’re very excited to be taking our conference to the  Tauranga region, located in the gorgeous Bay of Plenty. We normally have between 60 and 90 delegates at our conferences. In 2018, we took part in a huge information technology conference called ITx. TechCommNZ was proud to host a one-day stream at this conference and present Steve Moss, one of our members, with an Excellence in Technical Communication award at the Gala dinner. 

You can read about our 2019 conference here

How we work

Keeping TechCommNZ thriving takes a bit of work. Our Board consists of nine people from New Zealand, and we meet mostly by Zoom (remote meeting). We try to meet in person at least twice a year. We are mostly a volunteer-run organisation. 

I hope you enjoyed reading about our organisation TechCommNZ. If you have questions or just want to chat about technical communication in New Zealand, I’d love to hear from you. You can contact me at or read more about TechCommNZ on our website.

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.

When it comes to writing technical information, it becomes essential to have good technical writing skills. Indeed this knowledge has to get its point through in a clear and precise way. However some technical information gets more understandable than other. And some content gets more appealing than other. That is because some people have understood that technical writing demands essential skills.

Technical information may be heavy for the reader. Therefore technical writing skills need to be developed to be useful. Here are five essential elements to improve your writing skills and so your technical writing skills.

1. You Are Writing for Human Beings

Never forget this point. Even if robots may have a great influence on the future of your content, people remain the main target audience. Always orientate your technical writing towards people.

Readers Are Different from You

You have to think about who you are talking to. Are you addressing to experts or people who don’t have a lot of knowledge on the topic? Depending on this, you will have to adapt your writing, otherwise your readers may not understand. For example, it may be better to use simplified technical English in your documents.

Adapt Your Content to Different People

Imagine your readers: they will have more or less different profiles. Some will master the topic more than others. To make sure everyone can access your technical information, try to go through your product guessing whether every profile would understand everything easily or not. This is something that can definitely make a difference when creating customer-friendly technical information.

2. Get New Perspective on Your Technical Writing

The more opinions you get, the more improvements you will achieve. Indeed, it is difficult to take a step back on your own technical writing skills because you created it yourself.

Go Back and Forth to Your Production

Avoid writing your technical content at once if you can. Technical information needs to be really clear and precise. And it is easy to lose yourself in the process of writing and think that everything is clear. But the contrary is likely to happen, at least in one part of your content.

What is advised is to take a step back and also leave the content for some time before getting back to it. This way, you will perceive it under a new light and make it better.

Get External Opinions to Improve Your Writing Skills

New points of view can come from the outside. Other people will perceive the output of your technical writing skills another way. Getting these new visions will contribute to improve your writing skills.

3. Make Your Message Clear and Precise

How to improve your writing skills? Your main goal has to make the information consistent and straight to the point.

Avoid Obscure Terms

Sometimes, you will think that one word expresses an idea in a great way. The problem is that people may not understand this word, or the notion behind it. Therefore, even though you are working on a technical topic, you should try to use clear words as much as possible.

Cut Out Superfluous Words

Technical information is not the easiest thing to understand. How can it make it easier when there are many details? When tackling technical writing, you have to go straight to the point. Otherwise, the readers may lose the train of thought and get lost.

Use Time-Independant Information

Your technical content is likely to get around for some time. Thus you have to be careful if you ever use time information. Because depending on when it will be consulted, this kind of information could make no sense. So make sure you use time-independent information.

4. Optimise the Format of the Text

You are sure that technical writing has no secret for you, because you think first of the people you give a message to and also about creating clear and precise technical information. But do you pay enough attention to the looks of your content?

Space the Text and Play with the Font

Text is composed of main words and of grammatical words. You should put stress on the important words to make them striking.

Here are two recommendations to do so:

  1. no blocks : avoid paragraphs of more than two or three sentences. No information will be lost in a sea of words.
  2. italics and bold type : emphasizing the main words of your information is essential to technical writing.

Enhance Crucial Information

There are more ways to enhance important elements in technical writing, so that information is understood perfectly. Here are three must-do:

  1. bullet lists : they are very practical to explain the steps of a process for example.
  2. headings : it is important to find essential information quickly. Headings are more visible than the rest, so make the mos of them!
  3. tables : they definitely help to organise information, depending on the data you have.

5. Create a Visual Article

Linked to the previous point, visuals and multimedia can really help to get your information through. This type of content represent a great backing for your technical writing skills. Visuals are something to remember if you are thinking of gamification marketing.

Get Visual with Photos and Videos

Let’s say it : technical information can be boring and be tedious for the reader to go through. If you want to make your technical writing efficient, think of visuals as a backup. Use images, photos and videos to make your content more alive and less abstract.

Including Graphics is Part of Technical Communication

In addition to photos and videos, you can illustrate information with concrete data. It will help the readers to visualise the information you give and make it clearer.

Bonus: Get a Technical Writing Certification to Improve Your Writing Skills

One great way to improve your writing skills is also to study! You can try to get the tekom certificate, which is highly reputed in the technical communication field. Just know that you can get this certificate and a diploma if you enroll into the TCLoc master’s degree, which will teach you a lot about technical writing. Follow us on our Facebook page or on our LinkedIn profile to get more posts about technical communication and more!

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


Tracy Osborn, Five tips for improving your technical writing and documentation, August 26, 2016

Nicole Legault, 5 Tips to Improve Your Technical Writing Skills Tom DuPuis, 9 Technical Writing Tips Every Writer Needs to Know, Septembre 27, 2017

Stephen Hawking once said, “Intelligence is the ability to adapt to change.” Constant change, quick decisions, and regular exchange about current tasks are key elements in agile project management. In the 2017 Pulse of the Profession report from the Project Management Institute (PMI), they concluded that “(…) 71 percent of organizations report using agile approaches for their projects sometimes, often, or always”.

In this increasingly agile-working world, the Scaled Agile Framework (abbreviated as SAFe) helps large enterprises establish agile processes on a company-wide scale. First introduced in 2007, SAFe offers comprehensive guidelines, workflow patterns, and consistent terminology. The framework is designed to encourage collaboration and alignment across a large number of scrum teams.

This is the complete SAFe agile portfolio as of SAFe 4.5:

SAFe 4.5 agile portfolio

The SAFe framework considers at least three levels in an organization: the Team level, the Program level, and the Portfolio Level. To find out more about SAFe, how it is implemented and how its components work together, visit the SAFe website.

In recent years, many companies have started implementing SAFe, including Cisco, Philips, the NHS, Intel, and Sony (Scaled Agile Case Studies, 2018). However, any technical writer looking at the portfolio will quickly notice that the portfolio does not mention technical documentation or technical writers – as technical writers, how can we integrate ourselves in this new process?

In one of my SAFe trainings, I asked our trainer exactly this question.

He said that, most probably, SAFe would consider technical writers a Shared Service. According to SAFe, “Shared Services represent the specialty roles, people, and services that are necessary for the success of an Agile Release Train (ART) or Solution Train but that cannot be dedicated full-time.” Shared Services are not part of the scrum teams (called Agile Teams in SAFe), but can support multiple Agile Teams with their skills, as well as other teams on the Program or Portfolio level.

Our technical writing team discussed this solution but concluded that it this approach did not fit our profile one hundred percent. Typical shared functions are only required for one to five features. An example would be the assistance from the User Experience team, which is only required for front-end features.

In contrast, you need technical documentation for almost every feature. The profession includes more than just the writing process, for example the creation of illustrations or multimedia content.
Additionally, although it is a legally required part of the product, engineers might not always understand which features need end-user documentation and which do not. Therefore, it is important for technical writers to be involved from the very start.

Our team tried two different approaches:

  1. Acting as an Agile Team
  2. Acting as a Shared Service

Acting as an Agile Team

The first approach, acting as a separate scrum team that only consisted of technical writers, helped us immensely in being an active part in the PI Plannings. Since we were a separate Agile Team, we had to present our PI objectives and our goals in the PI Planning. This led to an automatic involvement in the decision-making process, and our Scrum Master was part of the Scrum of Scrum meetings. The presentations during the PI Planning increased our visibility to the management and other Agile Teams.

As an additional factor, the predefined SAFe processes helped to align our own team better. During the PI Planning, we would get a better idea of the upcoming features and could plan for their documentation as required. We also allocated time to internal tasks that were documentation-specific, for example clean-ups. It gave us a forum to discuss improvement ideas for our documentation.

However, we still faced some issues: we now had a lot of planning overhead (for example tracking every task down to the hour every day), we kept running into reporting issues, and it was not the proposed SAFe solution.

Acting as a Shared Service

The second approach, acting as a Shared Service, had its benefits as well: we had less planning overhead since we did not have to plan our activities as meticulously. Instead of planning our own user stories during the PI Planning, we had more time to attend the other teams’ planning sessions.

Although this was the proposed SAFe solution, this approach made our presence during the PI Plannings less “official”. We still communicated with the scrum teams to see which features required documentation, but the Agile Teams themselves had less insight into our planned tasks and often had to ask if we had planned in “their” features.

Integrating Technical Writers into the Scaled Agile Framework

Ultimately, we found there is no one-fits-all solution. My recommendation would be to try out different approaches and see which one works best for your team. Consider these two factors beforehand:

  • Your goal: Ask yourself what the issue is with the way things are run now. What is the change you want to see? Our issue was that we did not always have up-to-date information about the features R&D was working on, so we had to make sure we received the necessary input. This worked out best when we were acting as an Agile Team. Your team might have other pressing issues, for example late updates to “done” features, missing updates from the scrum masters, or a general uncertainty about the new processes.
  • Your team size: We noticed that for teams with more than two writers, it made sense to act as an Agile Team and have our goals aligned. But after our team became smaller and consisted of only two writers, we had a higher workload and less time for the planning, so acting as a Shared Service team worked best.

Depending on the company, every technical documentation team works differently and scrum teams apply SAFe in different depths. Make sure to inform yourselves well about the SAFe processes and the Scaled Agile Framework to understand where your team can fit into the portfolio.

… and what about you?

Let us know about your experiences as a technical writer when working in agile or SAFe projects – how does your team work together? Have you tried different approaches to get more involved?

Leave us a message – underneath this blog post, on Facebook, LinkedIn or Twitter!