A Guy Called Matze – How the Persona Method Improves User Experience (UX) in Technical Writing?

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?

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:

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

…and this is how I approached the challenge:

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