All those words
Some words are made of spandex: they can stretch, but only to a point. “User” and “customer” seem to behave like that. I’ve tried to keep them in check and use them in a very consistent way but I’ve slipped quite a few times, and it turns out their original definition is permissive in the first place. Besides, I observe that my favorite authors don’t seem to mind all that much.
So when I got seduced, some time ago, by the idea of “customer journey” because from a global Technical Communication perspective it made so much sense, I was somewhat irked: What about my users? Aren’t they allowed to travel every once in a while? Or are journeys an option only when we buy smartphones? But I understand now: it’s complicated.
Before I get to that complicated part, I must establish those three elements: the standard definition, my own usage and how a few book authors use the words “user”, “customer” and “audience”. That’s right: I must, I am compelled. I need to lay down my premises, so if I am biased in what follows, at least we know what the bias is. I understand this makes this post extra-long, don’t hesitate to jump to the “Customer Journey” chapter if you’re in a hurry.
Standard definitions
As we know, each expertise puts additional or specific meaning on common words, the common meaning being the one we find in dictionaries. That often creates confusions as the expert meaning may be very different, sometimes incompatible, with the common meaning. That is why in some cases we have to be specific in what we mean, depending on who we are talking to. In the matter in hand, our expertise is Technical Communication, and we need to start with the common usage of the words before we check if our expert use of them is any different. The following definitions are provided by the “Oxford Languages” dictionary, used by Google.
We discard the definitions related to law and to drugs. If we ignore the emphasis on the complexity of the tool (the “something” can as well be a shovel or a towel), the notion of action that is associated to a specific tool is at the forefront when this word is used.
So, when the “user” uses something, the “end-user” actually uses something specific. This is not the type of solid distinction we would want to rely on when writing technical content but hey, that’s what we get.
We discard the “person” meaning. Here, the specific actions associated with a specific tool don’t matter anymore, except only one: the purchase. And this time, it is about a relationship between someone and a business instead of between someone and an object.
I’m adding this word even though it is almost never used because I have found the occasional confusion with “customer”, some of them made by me. This is a surprise (for me): when I lay down the standard definitions, I see that “consumer” would be more comfortable as it covers both the purchase and the usage. But it may have been ignored precisely because it is too global, as authors may have preferred to mark a distinction between the two actions.
We discard the definition related to “a meeting”. This word appears more complex, I could not stick to only one definition as Technical Communication can take many shapes: It can be read, watched or heard. This array of definitions really suits the diversity of our profession. However, I don’t think I’m taking too much of a risk if I say the third definition is very close to what we mean when we use the word. Note that we are no longer specific to tools or actions, this term can almost be synonym to “people”, which makes it even more global than “consumer”.
Preferences
How did I use those words up to now? I started out with “user”, of course. My deal, as the usability specialist that I was during my first working years, was understanding how someone was performing a specific activity, and how that person was making use of a tool to perform it better than without the tool. I consulted on professional tools, and the users I was meeting typically would not purchase the tool. Their employer would, usually before they started working for them. I liked that situation and it became comfortable for me. I never wanted to work on a mass market consumer product, and the buying decision was the one I was the least interested in, in the usage life cycle of any tool. It still is.
I used the term “customer” only when buying was involved and it was the main focus of the discussion, which I think was consistent with the definitions we just saw. To me, user and customer were two different persons, and customer was the one I did not want to work with. I was not tempted to use “consumer” because I never saw it used in professional communications[1].
When I transitioned to Technical Communication, I remained in this area of professional tool usage. To this date, I have only once needed to analyze the purchase decision, except when it came to demonstrate that the audience I needed to help was not part of it. Whenever colleagues (usually in other services) or management referred to my audience as “customers” I tended to correct them either verbally or in my mind (Dexter-style). However, even though customer was only the buyer in the way I heard it, for my colleagues it could include usage. I know that now.
Whatever the actual usage situation of a tool is, and whatever the group of readers we are supposed to target, it appeared to me that in the Technical Communication world, when it comes to decide which content to create, we are attracted to support, directly or indirectly, the purchase of or the prescription decision for the tool. What I mean by this is when someone has the power of making an organization dedicate resource to content creation (the Product Owner or higher, usually), it is in most cases with the intention to have a direct effect on sales, as if everything needed to be Marketing. I didn’t like it, because I’m above all a “user guy”[2], but at least it explained why people wanted to slap “customer” on everything I was supposed to be doing. That is when I started to use “audience” whenever I could as it seemed to cover all possible target groups, especially as I realized that a significant part of the people using my content were internal to the organization, for a diversity of purposes that defied categorization. So, neither user nor customer.
Then, a decade ago, when I started to see how powerful a cross-silo effort on technical terminology was for most organizations, I began to follow the discussion around the notion of “customer journey”. It had a strong meaning for me because (in my opinion):
- External people need consistency in the way we name things, and they don’t segment their interaction with the tool the way we do.
- Internal people sharing words and meaning throughout all the product life-cycle is an absolute necessity if we want to make a “customer journey” a reality.
- A consistent customer journey is one of the best ways to have content creation a positive effect on sales, albeit an indirect one. That effect impacts the short, the middle and the long term.
Of course I was pretty annoyed by the fact that in all the presentations, articles, webinars, etc. about the “customer journey”, practitioners were talking about content that would be consumed by one same audience from before the purchase to the end of use (typically disposal). As someone who always write for audiences who never choose or buy the tools they are working with, I see that all the “customer journey” talk is not meant for me, and is not about the audience I want to help first.
But maybe I am mistaken and we are just using the terms loosely and each of those words actually mean everything. Or, we consider that we create one-content-fits-all and dividing the population in types has no point. Or, the situation where the buyer of a product doesn’t use it is so rare that creating special cases to cover that situation is overkill. Or, the customer is the closest to the wallet and therefore is the one we should focus on, any other target being a waste of time.
We need some solid knowledge and wisdom here, so let’s see what the Internet has to say about it. I’m kidding! Let’s read books!
Reading helps
A few months ago, I started to read a book where the author defined and compared the terms “user” and “customer” and I thought: that is interesting, this is very different than the way I use those terms, it is almost the opposite. But in the next 10 pages this author defined other basic concepts very familiar to me and I realized he had no idea of what he was writing about, and that was making the whole thing dangerously inaccurate. So I immediately shut the book, put a big red “KIP AWT” sticker on it, covered it in chains and padlocks, and buried it deep in the middle of the nearest desert, for a poor soul to discover it centuries from now, when we have more power to repel this type of Evil[3]. What else could I have done? I will never speak of that book again.
Fortunately, there are other books. Here are three of my favorite works when it comes to literature about Technical Writing:
I listed them by order of size (smaller first), which is a very important book characteristic for someone who moves a lot. I’m planning on making posts about books or even about webinars, in the future, as some deserve to be talked about and reviewed in depth. Just like those three.
None of those books explicitly define the terms we are looking for, so we’ll examine the parts of each book that should be the most loaded with them and check how they are used. I can’t call this an analysis as there is nothing systematical or statistical to what I’m doing, I’m just peeking around.
In Book 1, we’ll have a look at chapters “Audience”, “Customer Feedback and Community”, “Research for Technical Writers” and “Working with Customer Support”.
In the chapter “Audience”, the author uses “audience” when audience description is compared to persona definition, and then “customer” and “user” interchangeably. In the “Customer Feedback” and “Customer Support” chapters, passages are filled with “customer”.
In most of the content I’ve examined, topics and usual professional idioms elicit their associated terms. Here are examples:
- “Use case” => “user”.
- Content delivery format => “user”.
- Information architecture, structure, formatting => “audience”.
- Community, surveys, interaction through email and website => “customer”, only one exceptional passage where community is associated with “user”.
- “User feedback”, “User research”, “User conferences”, “User analysis” => “user”.
- “Customer feedback”, “Customer education” => “customer”.
- Customer Support => “customer” (occurrences of “Customer experience” and “Customer advocate” which usually are “User experience” and “User advocate” in other places).
When the author evokes relations between Tech Comm and other disciplines, UX is associated with “user” and Marketing with “customer”, although Marketing can also elicit “audience”. The general impression is that we educate the customer (Marketing), but it is the user that educates us (UX). Also, the association of “customer” with surveys and audience interactions seems to indicate that we acknowledge someone who speaks up when the person has given us money. Ok, that one may be a bit far-fetched: I was just tempted to write it. In the chapter about Customer Support, “customer” is used including in a context where user is normally used (like when describing usage procedures or talking about application engineers).
The chapter about research introduces exotic idioms. Note however that this section is about inside research (e.g. interactions with SME) rather than outside research (e.g. interviews with users). We have “Technical fields” that could be a substitute for “audience”, both being used interchangeably. Also “residents of the technical field” and a surprising unique appearance of “readers”.
This seems a bit chaotic. My general impression after checking Book 1 is the following:
- The use of “user” and “customer” seems to be driven by the context rather than by their intrinsic meaning, the context being usual idioms or, with higher priority, the type of Technical Communication activity we are talking about, including the other specialties we are interacting with. All in all, it seems we use those words out of habit rather than meaning, as synonyms having their preferred habitat.
- “Audience” is less frequent than the other two, and used in situations where we consider complex populations, as expected.
Book 2 doesn’t give us much more information. To be fair, I went through only one chapter out of 14, as the focus of the book is the characteristics of the content itself, not the Technical Communication activity as a whole. Besides, there is in this book, and in my opinion, a constant confusion between Tech Comm and UX territories[4] which drives the choice of words: “user” is king here. Also, it is about software (it is published in “IBM Press”). Interestingly enough, there is an “audience” and a “users” entry in the book’s index, but no “consumers” entry.
I went through chapter 3 “Task orientation” because it contained a section “Write for the intended audience”, which is the only one I saw explicitly about audience. Given the general focus of this chapter (tasks), the whole chapter uses “user”.
Note that in several places in the book, “user” is presented as a specific portion of the audience, and when it comes to take the type of audience into account when creating content, “user” is considered likely to be one of those types, probably the one with the highest priority. This is consistent with what we have seen before.
Here is an interesting example, chapter 5, “Completeness”, p.123: “Too much detail is frequently the result of writing to more than one type of user or to no particular user at all. Sometimes extra detail is included for the secondary audience, which can distract the primary audience” (so many times I have to explain that there is such a thing as too much detail!). Here, audiences are made of categories of users, including the special category “no particular user at all”.
The term “customer” is exceptionally used in one short section of chapter 3 about displaying recommendations to the user, in a consistent way, even though the examples that are provided display steps in a procedure, which is typically ‘tasky’ and would therefore prompt “user”. I was surprised, I don’t have an interpretation for this one.
Book 3 is my favorite, I don’t mind saying. Chapter 7 “It’s All About Audience” naturally draws my attention. Now that is a juicy, tasty chapter, because it has all our words, and then some. Actually, it is so dense that I’ll stick to this one and ignore the others. For today.
In some passages, there is again the same indiscriminate use of “user” and “customer”, but those are cases when, from what I see, those words relate to the product (“…how the customer really uses the product…”). Again, we see the influence of context. For example, when evoking Training and Customer Support, the author uses “customer”.
At the beginning of the chapter, however, the author clearly refers to the users of the documentation, not the product, and in that case the term “user” is generally used, but sometimes we see a “customer” popping up. It can be confusing sometimes. For example: “customizing the documentation for a key customer”[5], and a few words later “documentation for internal customers”. The first quote could refer to a customer of the product. The second looks like it is about a customer of the documentation.
According to the way things are described, what makes up the audience is the different users of the documentation, and those users may be the users of the product (“end-user” comes in handy here), the buyers or prescribers of the product, or any other group of individuals, inside or outside the company that may be a stakeholder in the product life-cycle. In the other books, I don’t think the authors meant “users” in reference to the documentation: it seems to me they generally referred to the population in contact with the product, not with the doc. Is it possible that when we say “customer journey”, we don’t just limit our scope, but we are looking the wrong way entirely? Not necessarily, it could be that there is such an overlap between users and customers of the product, and users and customers of the documentation that we can just forget about the whole thing and use whatever word comes up at the time. Like we do now.
Unfortunately, the author of Book 3 kind of ruins it for us: she describes the possible composition of a real-life audience, or doc users.
Here are a few groups we may want to help with our content (taken from Book 3). They certainly expect it from us:
The potential customer. In terms of journey, that group would be step 1. In situations that involve several of the groups described below, the “potential customer” could actually be a group of people having different roles, professions and objectives[6]. We will illustrate that in a minute.
The end-user. The people who actually use the features of the product. The author distinguishes novice and expert users, in terms of knowledge of the product. I have always observed that, indeed, we should not address those two groups the same way. Now there is another dimension of expertise: novice or expert in the activity that the product supports. Again, one same technical content would be understood very differently by those two groups. However, that type of expertise impacts the usability of the product for the most part, not so much the documentation, so we Technical Communicators tend to ignore it.
The consumer. Look, that word that we found at the same time more comfortable and never used! The author associates this term with the group that buys off-the-shelf products. I suspect this is typically the group that authors and speakers have in mind when they mention “customer journey”, groups for whom buying is seen as the main activity, even though our Author reminds us of the unwrapping and setting up activities (“out-of-the-box experience”) that are staples of this type of product. That makes this group stand out.
The installer. In the software industry, for professional products, this group is ever present and very influential. They are often called Application Engineers. This group also customizes the product and partly configures it. They use it before the end-user put their hands on it, and in some cases, they have priority over the end-users in the creation of technical content. I need to add that even though this group seems software-oriented, in machinery the documentation must include assembly and setup instructions, especially when the product must arrive on the premises in separate pieces (which is common).
The operations people. I tend to use “System Administrators”, which may be too specific. The people who make sure the entire system runs smoothly. Or just runs. Thanks to them, the end-users can use the product, and the product has an impact on how well the system runs. I’m sure you are familiar with the deliverable “Admin guide”, and you know how different the content is from the other parts of the documentation. Again, this seems typical of software, but for each factory or building someone makes sure the infrastructure operates, and that you don’t add stuff that breaks it[7].
The developers. That is software. Just one word: API. Ok, not a word, cut me some slack please. The API part of Technical Communication, typically for developers, has grown so much that it has its own standards. You do not want to mix up that type of content with the rest!
Trainers and trainees. Usually trainers have their own content, adapted to in-person transmission (very different from transmission through an artifact, like we Technical Communicators do). But like the book’s Author says, trainers use documentation and promote documentation to their trainees. Also, I am a big fan of Technical Communicators participating in the creation of practical exercises material, so that material is common to all trainers and also available from the documentation for a follow-up should any trainee be interested later on. More recognition for that particular audience group would go a long way towards helping users and trainers alike.
Customer Support representatives. I don’t have enough space here to stress the importance of collaboration with that group for the benefit of all the stakeholders, inside and outside the company. I think that, given the very specific circumstances of their work, this group may need not only specific content but also specific delivery systems.
This is what is found in Book 3. There are other possible groups, inside (the testing team, for example) or outside (what I call “elite users” or “gurus”, for example). In all my assignments, software or otherwise, all those groups were part of my potential audience (except Consumers and Developers). I know I am ignorant of the particulars of professional software end of life, there may be specific actors involved there.
The customer journey
How’s your “customer journey” now? Where is your customer? Who’s traveling, really? Let’s recognize at least that these audience sections, whatever they are called, are very different from one another and intervene at different steps of the product life cycle. Some of those groups may not even meet one another.
Some tenants of a simple straightforward idea of a customer journey, where a single type of person, that could wear the label “customer”, share their product’s story along almost every step of the way, could object that what we have just described is a special case, that covers only software, and only professional usage. This is why it can safely be ignored whenever we discuss the specifics of the concept.
I disagree:
- Professional software is ubiquitous, it is not only present in offices, it is in transports, hospitals, factories, etc. and in the professional world, very few of those have been picked by the ones who use them, just like very few are used by the ones who picked them. Most of us use these tools every day of work, that is, almost every day of life.
- We have seen that the multiplicity and the relative disconnection between audience groups is also a reality of hardware professional products. Some of our complex hardware tools, the ones for which we need knowledge help, are selected by others, installed by others and maintained by others.
- On the personal side, I can say that, looking for a job for the past few months, I see that 9 out of 10 job offers are situations where the “customer” is just one of the groups we are tasked to help, and not that often at the top of the priority scale. “9” is an approximation. It could be 9.03.
Today the product user (“end-user”) is still our official number one doc user. The other groups are closing in, sometimes some of them take precedence. But how many of us create technical content for the “consumer”, or support the out-of-the-box experience? Many, certainly, but not as many as the rest of us. I believe consumer-oriented communicators tend to be put under Marketing priorities, which makes sense as we want to influence the target at least as much as we want to help them, mostly at the beginning of the journey.
In most cases, the journey is a tad different than what we hear about. Here is a typical, albeit simplified, situation. I have kept aside the trainer, Customer Support, developers, and the “consumer”, so that we can have a clearer view.
A few things come to mind while watching this representation:
- “Customer” comes short of giving an idea of who is experiencing the journey. But let’s keep the expression, as it is now established.
- Each group have their own needs in terms of knowledge, angle, level of detail, etc.
- We can consider that some groups may also have specific needs in terms of delivery system (online/offline; electronic/paper; stable/fluid; etc.).
- Many of those groups also exchange tool-related knowledge between themselves and we should facilitate or at least support that.
- For simplicity, each group looks like a step in a sequential life-cycle structure but they each have their own journey that may extend over most of the product’s life. What we really have is an array of interacting journeys.
I took the liberty of separating the users’ group in “super users”[8] and standard users. The often-discarded reality of this type of situation is that in a given organization, only a handful of people have all the information about the tool as well as the full extent of customer contact abilities provided by the tool manufacturer. The normal users turn to super users for answers and support, and the super users turn to the manufacturer with pre-processed global requests. As a consequence, super users and standard users each require different types of knowledge and delivery systems, just like if they were separate groups. Besides, in many cases super users benefit from special training and in turn train the standard users, and as Technical Communicators, we should provide some support for that as well.
Making a list of preferred content and deliverable for each group would require more space and also some further work on my side, so maybe in a later post. Obviously, creating a globally consistent knowledge environment to support all the people involved in the life of modern tools calls for a multi-disciplinary approach. Working on the content itself is the easiest way for us to deal with it, but we also need to be adaptive when it comes to the delivery. I think we still need to develop methodologies for the whole “journey”. Today what we can do can only be based on solid investigation and leads to tailored solutions, and tailored means expensive.
This being said, it seems to me that our best shot at making a consistent “customer journey” come true, in addition to simply knowing who is included and what their needs are, is to start with the terminology. That is one thing that applies to everyone. Different groups have different expertise and use a different professional vocabulary but the technical terms that relate to our product should be controlled and shared. That means internally too, across services.
I have discovered that, when you work across the organization on discussing, deciding and sharing the right words, you don’t just end up with a list. The work itself reveals a number of issues swept under the rug where they create spending, disturbances and extra stress. Working on terminology is an amazing instrument for creating bridges and collaborations. Every now and then we would open a can of worms, as the saying goes, but we know that when those cans are closed and we don’t look at them they still do damage.
As for “users” and “customers”, I should learn to use “audience” and “documentation users” instead, I think it would reduce the risk of confusion between our tool and our tool-related content. As I am always recommending the application of usability techniques to Technical Communicators, I can see how vulnerable we are to all types of mix-ups. What do you think?
[1] At first the situation was different, as I started out in French: we don’t have the same overlap between customer and consumer. Consumer would be ‘consommateur’ while customer would be translated as ‘client’. The French ‘client’ can actually be translated to English by client, customer or patron, depending on context. It was a bit confusing, hence the benefit of just mimicking observed usage rather than trying to stick to the exact meaning.
[2] Great topic for a later post: why I think the end-user should have priority when it comes to technical content.
[3] We have the demonstration now that technology eliminates inaccuracy. Right?
[4] I hope I’ll have the time to give this point more space in a specific post, especially as the author seems obsessed with a part of our job that fascinates me too.
[5] Remind me to write that piece about that special deliverable often called “product documentation” that is aimed at people who must prescribe the product and need descriptions that are a bit technical but also a bit promotional. That content is not supposed to be used after the product has been purchased.
[6] We could see them sitting around a table in a poorly lit room, possibly wearing hoods. But they’re acting for the greater good.
[7] Like that raclette grill my father gave me that short-circuited, frying my computer in the process. Thanks Dad!
[8] I’m taking the term “Super users” from our sys admin colleagues; those are users of the system with more permissions than the average users.
