The interactions between Technical Communication and UX can be destabilizing, and I believe they have been from the start of their cohabitation in design and implementation teams. I am thinking primarily of the Software Industry as I’m more familiar with it, but I have seen it in other sectors. The difficulty comes from the fact that our purposes as well as our practices overlap significantly, and at the same time they are separated by profound differences that are not always clearly identified, which creates confusion. Disagreement. Rivalry even. I’d like to give my take on those differences and similarities, and provide some help to navigate them. I know for a fact that we have a lot to gain in collaborating efficiently.
I will not attempt to draw here a definition of Usability, or UX (I use those terms interchangeably): that would require too much research. I developed a fraction of the skills that UX requires, and I discontinued my exploration of it. I will only consider some of its characteristics when it seems relevant to compare them to Technical Communication. Discussing the full list of traits is a delicacy we can save for meetings that need extra debate and colleagues who need extra entertainment.
Prior to throwing my thoughts on the web about this matter, I read a few articles and posts online. Internet makes things so fascinating. It is like witnessing reality undergoing mitosis and building “reality tissue”, with the particularity that each new reality is slightly different from its parent. How can anyone “know” anything today? For example, I saw that Wikipedia suggests that UX and Tech Comm are competitors, where the former started to replace the latter a few years ago and the present trend is to work towards a possible collaboration instead. That is propostr… testosterou… prostasterou… that is absurd! They’re not competitors, none replaces the other, and they have been collaborating for decades. Let’s swipe left all of this and let me share yet another reality, based on personal experience.
Story time
I started out as UX specialist at the end of the 90s. I lived in a location where we worked hard to promote technological innovation, which was expected to drive the whole region economically. That it did. With our small business[1], what we wanted to sell the most is the participation of a usability specialist in the building of a new product concept, in prototyping and in the early stages of development, user research style. That was fully consistent with our education: Cognitive Psychology research. Backed up by my Master’s degree, mentored by a recognized pioneer and expert in investigative usability, fueled by hundreds of research papers each month that we were browsing from Ergonomics Abstracts, I have to admit that Technical Writing wasn’t even on my radar, and if it was, I would probably have looked down on it. Where I come from, usability research has a strong tradition that goes back from the 60s, decades before a few big names became the official “founders” of the discipline.
At some point I worked on a product that was made out of different elements assembled to build an entire installation. That design part was considered very complicated by the user base and the product was purchased and installed only by an elite. The company wanted to expand the market by removing that fear of complexity. Investigation led me upstream to the people who really prescribed the product and designed the installation, and I got from them an easy-to-apply procedure. The interesting part is my client was the documentation department of the firm. They had this 100-pages paper booklet full of technical details printed in small font, that was the actual scary part of the product. My 6-pages procedure made from pictures and drawings could replace about 70 of those pages, because the details were not helping the audience, they were in the way. So as a usability specialist, I worked for technical writers, they were my clients. So much for looking down upon Tech Comm.
After that, I still did not clearly assign “writing manuals” to a specific profession. Probably because that client’s people I worked with were Engineers who happened to take care of the doc. Today, I can clearly see that their documentation was so scary because they wrote it as Engineers. During that period, instead of performing the service I wanted to sell[2], I performed several observations and evaluations of the navigation side of information systems destined to be distributed on CD-ROMs, or accessed from computers. Some of them, according to my own definition, were Technical Communication artifacts, the others Communication tools. I was sometimes a Technical Writer without being aware of it.
Then I spent five years learning the job on a position where I had both Technical Writing role and Usability role. As “adoption specialist”, a position that was objective-driven[3], I could collect all the practical experience that would help me better understand the similarities and differences of both disciplines. Later on, I decided to stay in the Technical Writing lane, but I never could stop using UX techniques to find answers, and I always tried to explain those techniques to my colleagues because applying them is much easier, natural and useful that they suspected.
Ultimately, both professions’ objective is to determine what the needs of other people are. Other professions, like Sales for example, are more focused on what they want and, as you know, when we are asked what we need we tend to respond with what we want. So, investigation in Usability just like in Technical Writing is designed to go beyond what people tell us. Same objective, same techniques.
Now we both help people do something with a tool, but in the Tech Comm case, we need to add an extra step: knowledge artifacts.
 |
| Figure 1: same objectives, different focus |
This introduces differences. I see mainly three aspects that make Technical Writers distinguishable from UX professionals despite the fact that we all have basically the same objective:
1. The diversity of objects we are designing.
2. The diversity of the population we are designing for.
3. The moment in the development cycle we are stepping in.
The objects we are designing
We are specializing in knowledge artifacts. Usability professionals can be tasked to design anything (including knowledge artifacts). It is easier to create a set of solid guidelines for the creation of quality documentation, than for the creation of quality anything. That focus makes it often possible for us to produce good content without having to investigate our audiences. UX, on the other hand, almost always require some level of research.
There are such things as UX guidelines, in particular for user interfaces. Sometimes, a Usability professional will just go through some sort of checklist to verify that no usual aspect of a given user interface has been neglected. Readability, navigation, guidance, visual grouping of elements that share functional characteristics, etc. There are elements of a user interface that have been extensively studied for years and we now know how to get them right. For example, the standard form field, the one where we enter data, is one of the oldest user interface elements we know. Everything about the usability of form fields has been researched and known for decades. When we come across a badly designed field (doesn’t give a hint on the data format or constraints it requires, for example), we know that the development team makes great efforts to not be aware of our existence.
Still, when one works on the design of a professional tool, object or software, or on something that never existed until one or one’s friend decided to create it, there is little ground for previous research, and the field is not so known as to allow for pre-existing guidelines. The number of unknown situations UX can be dealing with is infinite. Hence few guidelines, and much bigger risk of getting it wrong.
Talking of UX guidelines, even though I should not mention this because it is off-topic and I tend to get carried away, I just saw it again recently and… it’s beyond my control: the rule of 7, sometimes called the Miller’s law (slap a name on it and it immediately becomes more valid). It is a good example of research result too good to be corrected. It is said that we can store in short term memory about 7 elements, plus or minus 2, and therefore lists or groups or user interfaces in general should present no more than 7 items for better cognitive comfort. Or something of that nature. The 7 elements can be individual objects or groups of objects (called “chunks”) if we find a way to group the items.
This comes from research in human memory, which I am familiar with because it was my field of choice when I practiced research at the university. Theories are tested in experiments, those experiments usually being tasks given to subjects, and those subjects usually were students, specifically Cognitive Psychology students[4] when it comes to Cognitive Psychology research. In the fifties, research produced that number 7, the average number of elements that could be held in short-term memory. As the results were stable, that number became powerful, almost magic. The author himself, George A. Miller, started the title of his scientific paper (1956) with “The Magical Number Seven…” A few years later, some researchers started to realize that memory can be better for some populations than others, and in this respect university students were abnormal: they are young people literally spending they days training their memory and motivated to do so. Not statistically representative. Additional research showed that for the global population the number was actually around 4, plus or minus 1, and the actual capacity was dependent on our ability to create chunks. Furthermore, the ability to create chunks varies among individuals. That was found over 60 years ago, yet the magic number 7 is still presented by some as a golden rule of UX, probably because “7” feels more magical than “dependent on an ability that varies”. Internet didn’t help here, I must say.
Lesson: if we have a doubt about guidelines, in Usability or in Tech Comm, there is often a way to put it to the test. Let’s do it then, there is no need to feel like a heretic if we question guidelines, it’s just how science works.
Anyway (apologies for the digression), Technical Communication is more focused in terms of type of objects it creates, and therefore that part is more controlled, better known, easier to get right and less risky. It is all a matter of degree, of course, but that may give rise to an impression of “we are true pioneers” from Usability specialists. On that particular aspect, I think they are.
The population we are designing for
When a product is created, it is intended for a given population. Sometimes, we can make out several populations in terms of usage. Or a big one with sub-groups. The Usability specialist needs to know those populations, research them, and very often creates descriptions, often called personas, that we Technical Writers can use to make sure our content covers all the needs.
One way to see it is we aim for the target that UX has set, and this is, in my opinion, the first step in our collaboration. We should use it as much as we can, and try to stay aligned with it. The Usability specialist probably does not expect a Technical Writer to come and suggest adjustment of their targeting. My recommendation is to avoid doing that if possible, but in case it happens, there are ways to ease the reveal. Some recommendations below, in the part about collaboration.
So, in terms of audiences, we start with about the same level of complexity as UX does. And then it gets interesting. How many of us have been in an originally simple situation where we just write a manual for a homogeneous group of end-users, until one of our colleagues comes, puts a cheek down on the corner of our desk[5] and starts asking for additions, modifications and, worst of all, justifications for this or that piece of content. After a few visits, we realize that the things we write may have more than one audience and maybe we need to think of a more complex architecture.
Welcome to the internal audiences and to the Global Content Universe. Everything is connected. What we write to help external audiences also helps colleagues, but not in the same way. What we send out there must be consistent with what we have in here. Some people who need outside content also need inside content and should be able to find it with consistent search keys. Colleagues who write other type of content need to be aware of what we sent out. We also need access to internal feeds and have to automate the transfer of information. In short, the content we create is not isolated, it is linked with all the knowledge inside the organization and it interacts constantly with it. And it is alive too.
From the audience point of view, we end up dealing with a situation that is usually way more complex than the one UX is dealing with, all the more as some of our audiences are incompatible with one another with regards to what they need: type of knowledge, approach, level of detail, angle, etc. That is, if we see our organization as a system. Our Usability colleagues rarely see this, and I don’t see a reason that they should. Do you think we should communicate more on that towards them? I don’t know.
The place in the development cycle
UX can be involved from the very start of any tool’s design. They can work with a sketch drawn on a greasy napkin. It is rare but I was lucky, I had the opportunity to do this type of thing once. From just an idea of something that doesn’t exist yet, a specialist can run it through some research, go through a checklist of all the aspects to be taken into account, present things to unprepared individuals, observe reactions, collect comments, work on different scenarios, and end up providing a solid report with options, risks and recommendations.
And then UX can work alongside the project every step of the way, with a variety of techniques that are adapted to the current stage of development. Maybe I’ve said it before, but Usability is way more exciting than just deciding the right color and shape of a user interface button. Us Technical Communicators, on the other hand, need to wait until things are set, or almost set.
That is because we need to write the truth, and in product development, the truth is known at the end. UX works on what could be, but we need to write what is, after the decisions, simulations, developments, fixes and tests are done. Although this last sentence is not 100% accurate. We can argue that for shorter delays and better distribution of the workload, most Tech Comm methodologists recommend to start writing before testing is done, even as soon as the specification is produced, that is, before the functionality, or change, is even implemented.
That is a very good idea, as the saying goes, on paper. When situations are as clean as boxes that point arrows to other boxes. Don’t get me wrong, sometimes things happen just like in the process diagram. But most of us have known what we could call very fluid situations: implementation is modified several times up until testing, whole functionalities are added or scrapped over priority swaps, development is rushed and tests uncover major bugs, which in turn leads to fixes that can change the whole behavior of what we need to describe. Going over what we have written previously, to spot the parts to update, takes time in the best of cases. If the organization’s content management procedures impose specific operations or validations whenever a new draft version is produced, the update time can skyrocket until the Technical Writer burns out with everyone around wondering what could have caused this because they are not aware of the extra maintenance effort[6]. All in all, not really a productivity gain. Besides, the periods of calm between the rushes can be used to make punctual improvements to the documentation system, or the processes, or the tooling, etc. instead of making drafts that will have to be updated all at the same time anyway (just after testing and before release). I will develop that workload thing in a future post…
The result of the situation is that in the flow of things, Usability and Technical Communication have a radically different rhythm. In addition to that, and this takes a huge place in how we collaborate, a large part of what we produce is a direct consequence of the choices (or suggestions) made by UX. This is especially obvious in software when we describe how the user interface is used, but it also applies to physical objects. Pulling that lever, pushing that button, unscrewing that nut, all in that precise order, can be a sequence that have been set up because usability demonstrated it was the easiest way, or the most intuitive way for the end users.
One way to say it is UX determines what we have to write, especially if most of our content is instructional. Again, that feels a bit hierarchical, and it may happen that some of our Usability colleagues behave as if it is. This time, I think we have to let them see how things happen on our side. Some of their actions can have a devastating impact on our job if there is no communication. I’ll provide an example of how we could approach that, down below.
I have to add that we having to write the truth doesn’t mean there is no creativity in our job (another occasional misconception UX may have towards us). Far from it. First, we need to find which part of the truth should be laid down depending on the audience. The “whole truth” would drown anyone, including the writer. Second, the architecture, navigation, taxonomy, terminology, etc. require just as much design effort as any product functionality. Third, the content delivery options offer so many possibilities that in most cases, there isn’t one single best solution. I think it would be nice if our UX colleagues could have a glimpse of that too. Who knows? They could share great ideas!
 |
| Figure 2: three differences |
How can we work in harmony with UX?
I couldn’t draw a table with, for each particular of our respective professional profiles, a specific solution to implement. It would take a while, and I just don’t think things work that way. I’m more comfortable with applying global approaches and seizing local opportunities.
For the record, a large chunk of what I’ll suggest below this point is further developed in a course I created: “Usability Investigation Techniques Applied to Technical Communication”. The course will soon be accessible from this blog. An actual Tech Comm investigation project (topic of the course) is the perfect opportunity for interactions with our Usability colleagues (topic of this post): there is a lot of information to share and it creates common ground.
First of all, when we start any mission, one of the first thing we do is discovering who is everyone. We find an excuse to talk to as many colleagues as we can, so we can have an idea of who does what, who is the source of what information, who is aware of what we do, and who needs our help. It also allows everyone to discover who we are. From what I have seen, helping out colleagues whenever we can, even if it is not “part of our job description”, is the general approach that gives the biggest boost to global and individual productivity compared to any other approach[7]. Don’t take my word for it, try it a couple of times.
Technical Communicators can be useful to everyone, as we said before, but from what I saw, Usability colleagues tend to consider we need them more than they need us. Maybe they are correct. It doesn’t mean we cannot help. I suggest our starting point is to see how our audience can send spontaneous feedback to us. When an audience sends feedback about the documentation, there is always some degree of confusion on what is documentation and what is the product, so if we receive significant feedback, chances are some of it is actually about the product. We go see our colleagues and propose a way to send everything we receive that is about the product, on a regular basis, in a convenient format. It is small but it lets us start somewhere.
Then, there is the matter of the pictures that we include in the documentation. This one may be specific to the Software Industry. User Interface screenshots is a typical example of our dependence to UX design choices. If they decide to improve the User Interface, we will have to update all the impacted documentation. As I was pointing out in another post, text is updated easily, pictures… not so much. What makes the matter worse is that for some aspects of the UI, our colleagues can make a last-minute change without it being planned and processed with trackability like all code changes, mostly because almost everyone (mistakenly) considers certain UI changes cosmetic and unimpactful, not important enough to be reported, so it all goes unnoticed… until someone discovers the documentation doesn’t align with the product.
This one requires some preparation. Coming to a colleague with “from now on, you report to me any change you make!” is not a great plan, especially with all the hierarchy-like illusions going on. We can invite our colleagues to a short meeting, 30 minutes tops, to review the upcoming UI changes in the next 6 months. We won’t get all of them, because many changes will be spontaneous, but it is a good place to let them know of our reality. We give a simple presentation where we show a few examples of screenshots that we use, embedded in the documentation context (caption, instruction steps, etc.), and we give a few numbers: how many pictures of UI we have, how much time it would take to update them, how much time it would take to check them all for changes ourselves (and why we cannot afford to do it), and how long before a release we need to be aware of any change if we want to make it on time: we show the example of a trivial element in one of the screenshots that would be moved across the screen. Just a few minutes of information and a request for help, no drama, and we hope that it stays in memory.
As soon as we see that our colleagues are willing to give us a bit of time, we go for a discussion about the UX plans. It is very important for us to know about the strategy, starting with knowing if there is one. Just like us or any of our colleagues, having a strategy helps anticipating what we are going to do and what we will push for: we make plans for a reason that gives us motivation, and consistency. Furthermore, having our Usability colleague explain the strategy makes us better understand the product and collect information about its usage, which is gold for us. It helps us choose the best way to create procedures, explain concepts, and in the case of more complex products, suggest a usage methodology. That suggestion can be in what we explain, but also in the architecture of our content. Even with modular content, where sequentiality is proscribed, the navigation context can suggest a story. I think this is much more important than we suspect. And finally, knowing the strategy lets us guess which parts of the product, features or UI, we need to focus on when we check if there are any unreported change.
In those early conversations, we need to remember to reveal some of what we know about planned implementations for the product, because we may be in a position where we have more information on what is going on than the UX team. We should let it show so our colleagues see that we can also help them anticipate.
As a rule, with everyone, we should jump on any opportunity of lengthy conversation, because it lets us know two things about any colleague: whether or not they are interested in their mission, and whether or not they are interested in what we are doing. Those are two essential drives in any collaboration, and one of our early tasks is to find who are the best sources when it comes to get additional information about the product. It is sad to say but if there is no interest to be found, we are better off keeping the interaction to a minimum because our energy would be wasted. Insisting for something when the motivation is not there turns to harassment faster than we realize.
Like I explain in my course, an audience investigation is the best setting for a rich interaction with our UX colleagues. First of all, we should never do one without letting them know, for several reasons. One, they may have an ongoing operation with which we could interfere (because of communication, or soliciting the same persons, or using the same resource, etc.). Two, they could help with the procedure one way or another. Three, they can share ideas about what we could find, or about the group we are targeting. Four, they get better awareness of what we do, and it reduces the distance between us. If our target audience is internal, it helps them see that our mission is a bit deeper than just describing what they do for the user. Five, them discovering it after the fact may lead to misinterpretation, and this is usually not good for trust. You see, many reasons to share.
During any investigation, in addition to all the data we collect about our documentation system and about our audience’s activity, we always get some feedback about the product’s usability. We should transfer that to the appropriate colleague, and that person should not be surprised to see it coming from us. Also, if a specific issue about usability is revealed, we should first talk to them before reporting anything to Product Management. Maybe it is a known issue and there are plans to tackle it, and we don’t want to step on any toes.
After the investigation, we ask if our colleagues want a summary of the results. It can help our common understanding of our user base. It is also one more opportunity for discussion. In the rare case when we realize that the user profiles as they are drawn by UX may need some adjustments, the best moment to raise the issue is in front of results. This helps only if we have been transparent about our investigation, our objectives, our selection process for recruiting respondents, etc. and if on top of that our colleagues draw the conclusion themselves from the results, it is just perfect.
Famous quotes
Our work is often called the “last line of defense” when compared to all the previous actors along the development process, in particular when compared to Usability. Due to the fact that we come at the end, and also that we usually have shorter production cycles, we can absorb some of the issues that couldn’t be fixed by those who contributed before us. It could be bugs[8], but also functionality or behavior that turn out to actually be complicated. We are the ones that are supposed to have that explaining magic, which allows us to make complexity disappear. Sometimes it feels like it gives everyone else a free pass to create convoluted features, and then give us a “if you can’t explain it simply you don’t understand it well enough”. Don’t get me started on that one. It does happen that some procedures are so twisted that describing them as if they stand to reason makes us feel bad, ashamed even. And there’s just so much magic we can produce. Still, we need to tread lightly when we discuss this with our UX colleagues, I’ve seen some of them get defensive because they see they could easily be blamed for it. There are many reasons why we can have a skilled, motivated Usability specialist and a bad UX, just like we can have a good Technical Writer and a bad documentation. Some of them can be grouped under the label “historical reasons”. In any case, when famous quotes are drawn, bevare, bevare, bevaaare! I call it a “one-quote-fits-all” justification.
Here's an example that has been haunting me for over 20 years, probably because I’ve worked almost exclusively on complex professional tools. Sometimes, a colleague considers that a product or a feature is so intuitive that documentation is unnecessary. That person may pronounce those famous words: “A User Interface is like a joke: if you have to explain it, it’s not a good one”. That quote is usually attributed to Martin Leblanc, although I have seen it signed Joanna Peña-Beckley. That puts us in a difficult situation: maybe that person is living in a dream world where reality is defined by simple, short but elegant, smartly formulated statements, and we have to explain to them that in real life, well, things are not always that elegant. It may be a friend, which makes things awkward.
In any industry, we can come up with tools that are either both complex and flexible (many functionalities that can technically be used in any order) or based on a counter-intuitive premise, and there is no way we can make them so intuitive that they fly like a good joke. Highly customizable products, built like Legos, present some challenges as well. Making something so intuitive that no documentation is needed is a great direction to take, and who knows? We might get there. But in the meantime, before deciding that we’ll leave end users without help, always verify that they don’t need it.
I hope all of this helps understand our friends’ point of view, and gives usable advice on how to share ours. I wanted to talk about embedded help, which is sometimes a disputed area between Usability and Technical Writing, but I really should stop writing now and leave all that for another post. That’ll give me the time to collect more info on this topic. If that bit is urgent, you will let me know.
[1] Us=me and my associate who had a PhD, I just had the Master’s.
[2] I was, then and always, a terrible salesman.
[3] Objective-driven means that, for example, my goal as Technical Writer was not to produce a user manual, it was to help users adopt our hard-to-understand breakthrough innovation as fast and easily as possible, using documentation, by any means necessary. I ended up making a user manual, a reference guide, tutorials, an HTML quick guide, command line help content, training content, and a quick reference.
[4] Research is often performed in universities and over there, students are more than low-hanging fruits: they are laying-on-the-ground fruits. Just scoop them from the faculty lawn.
[5] Actual memory of a real person. I won’t give any names.
[6] I have seen that: in a team of 7, over 100% turnover in 10 months, with management and HR thinking they have been “unlucky with the recruitment”. No one dared calculate the cost of that.
[7] We can totally do it without putting ourselves in danger of being swallowed or overwhelmed, “give as much as we can” is not synonym to “give everything”. We can do that and also keep ourselves safe.
[8] When we cannot fix it, we can “document the bug”. Faster, easier, cheaper.
