When should we humanize our products?


#1

Yeah, I know, the topic is anthromophorporphization… (since I can’t spell it, and I tend to stutter when I say it, I have a bias against it :))

Some discussion in the “Generated” or “Built” topic made me think about the topic.

I just googled it, and found quotes like;

“Although text that has been anthropomorphosized may be entertaining, an international audience is better served by presenting text in a straightforward manner.”

I disagree. Strongly. But I recognize that we can’t say that our products feel badly when users get errors.

I’ve never taken a tech writing course. From my searches, it seems like tech writing course push students away from humanizing our products at all costs.

So what do y’all think? When should we humanize our products?


#2

Hmm… interesting topic. Can you give us a couple of examples of text in which a product has been anthropomorphized? I’m having a hard time imagining exactly what sort of humanization we’re talking about here.

(I’ve never taken a tech writing course either, but I’m always curious to learn about methods that are either exalted or forbidden by conventional wisdom. Particularly when it gives me an opportunity to make up my own mind about them. :slight_smile: )


#3

I know… written by lawyers… .http://www.thejuryexpert.com/2009/09/anthropomorphism-in-technical-presentations/


#4

There’s a time and a place for everything. Lawyers have nothing to do with it. You need to know your audience. If you are trying to describe authentication to a jury (who may not understand the network authentication process), then yes, that could be the place to “dumb down” your presentation. However, if you are giving a presentation at BlackHat, to an advanced audience well-versed in security, then no, that is not the place. (Disclaimer: I work for a security company. I would be appalled to see that content in a technical presentation at BlackHat.)

Know your audience. Don’t do something just because you can.

(For what it’s worth, you also want to be careful if you are localizing content. What you find amusing and cute can be quite offensive in another culture.)


#5

Hi Sue,

One line from the WTD 2014 conference sticks in my head: ‘Developers are people too.’

For me, a different audience changes what I put into my docs – e.g. I might not include information on how to install SSL certificates in my docs for developers.

OTOH, I think developers are more intimate with their products, i.e. they’re more likely to want to humanize them.

As for the risks associated with localization, I think they’re higher with more general audiences. I suspect end users who aren’t in tech have higher expectations with respect to cultural norms in documentation.

(FWIW, I feel no certainty about any of this, I just want to encourage discussion.)

One more bit – as I work on Identity Management products, a lot of what I write about includes extra detail on the network authentication process. As you write about security products, I’m guessing that you might do the same for SSL certificates.

One more edit — I should provide an example of what I mean – I think it’s OK to say

“The browser responds with a warning about your newly created self-signed certificate.” as opposed to:

“A warning about the recently created self-signed certificate appears.”


#6

You need to know your audience’s tolerance for it and not go overboard. Remember Clippy the Microsoft paperclip?

That said, if you want to boil something down to the most simple way of saying it, making it more human-like could be a great technique. Analogies can be useful too. Back in 1993, when I was taking one of my first computer courses, I remember making an analogy that a computer is like a house with many different rooms. If you wanted to retrieve a file, you had to go to whichever room you left it in. Whenever someone around me was struggling to understand “directories”, I would explain it in terms of the house analogy. It seemed to get the point across quickly.

What this is making me believe is that you would only humanize products when you are trying to communicate concepts that are brand new to your reader. What I mean by that is that if, for example, you decide to show a developer how to install SSL certificates (see comment above), you don’t want to appear condescending by humanizing the information.

Session authentication and anything that involves a negotiation are good ones to humanize. Thanks for raising this topic.


#7

To make it much more humanized:
“The browser isn’t sure what to do next and warns you about your newly created self-signed certificate.”


#8

I’d think humanized text would be harder to internationalize as suggested previously. Translation would be a bear, so to speak.


#9

I think it’s important to distinguish between talking to humans about computers and talking about computers as though they were human (or even canine).

Browsers, for example, can respond and display, but they can’t feel or have emotional reactions. Attributing decidedly human (or sentient) attributes to a mechanical device or process (e.g. a browser) is, at the very least, inaccurate, if not completely inappropriate. (OTOH, if you want to name your car, and refer to it as him or her, that’s entirely your prerogative. I swear that one of my cars had a serious attitude… I digress.)

That being said, there’s no reason to talk to people (e.g. those reading your text) as though they were as mechanical as the subjects of the docs. You want your text to be as technically precise as the audience demands, while keeping in mind they are still people. What that looks like, of course (and as mentioned frequently above), depends on your audience.

For example, Windows old BSOD (Blue screen of death, which appeared when the operating system crashed) was great for kernel and device-driver developers (if not a little too vague) but completely befuddling to end users. Which was “better,” depended entirely on the audience.

Also, brevity does not have to be synonymous with snippy. Brevity can be appreciated when the reader is in a hurry or has an urgent problem to solve. In those cases, cutsey, anthropomorphized language would be infuriating–as though the writer didn’t realize how dire the situation was. But a respectful and reassuring tone might be appreciated. (e.g. “Disk error? These five steps can help…”)

Analogies to explain technical topics or concepts make perfect sense, but referring to directories as houses in technical docs (i.e. stretching the example too far) can become confusing. For example, unless the whole UI adopted this metaphor, I wouldn’t describe saving a file as “When you’ve finished your letter, take it to the bedroom and put it to bed.” At the same time, there might exist a context in which that would be a welcome description of the task.


#10

My deep thanks to Bob, who has articulated what I’ve been trying to figure out how to explain for several days now – with evident lack of success.

Amen to his comments about what browsers do or don’t do (and therefore how it is reasonable to talk about them), and to his distinction between talking to humans about computers and talking about computers as though they were human.


#11

Thankfully we’ve come a long way since 1993’s house analogies when I was helping students who had never touched a computer before and couldn’t get why the instructor was making us change directories in DOS over and over again. The files never went to bed or relaxed in an easy chair. The analogy ended where it began.

However, what else do you suggest doing when even the engineers have a hard time describing how a negotiation/authentication process works? Display resolution is another type of negotiation that can be hard to explain (e.g. connecting to a virtual desktop or remote computer from a smart phone, laptop, or other computer) without showing the computers “talking and thinking” on their own.

I’m interested in alternatives, but my default is to always use an “If …then” table when talking about complicated authentication or negotiation processes. I carefully handpick my scenarios and write as clearly and concisely as possible. I’ll also limit the columns to one “if” and two “thens” or two “ifs” and one “then”; otherwise it gets too messy to read.


#12

RE: "The browser isn’t sure what to do next and warns you about your newly created self-signed certificate."
By the way, when I wrote this line in a comment further above, I was not suggesting to write like this in any procedure or narrative. What Mike wrote (“The browser responds with a warning about your newly created self-signed certificate.”) is not humanized language in my opinion. It sounds normal.


#13

As a developer, I definitely appreciate documentation that is more humanized. For one, it makes reading documentation a lot more bearable. Especially when discussing complex systems. It’s a lot more readable to break them into simpler, concrete ideas with meaning, vs describing complex systems as a whole in a very monotonous tone.

On many points, @bobwatson hit the nail on the head…


#14

For anyone who is wondering what the TL;DR is:

It’s important to distinguish between talking to humans about computers and talking about computers as though they were human (or even canine).


#15

RE: how to explain complex things that were originally invented by engineers, and often for engineers? Yeah, that’s a tough one, indeed.

Having now been on both sides of that problem (as an engineer creating things for tech writers to describe and trying to document things invented by (and, more to the point, named by) engineers, the answer is to get the two together very early on. Simple!

(Yeah, right!)

When I was an engineer designing a new feature or library, I had a hard enough time trying to figure out what it had to do and how to get it to do that (and then iterate through that process several times). I’d make up names that were good enough to get the job done in whatever context I was working and then those would slowly get baked into the code. When things settled down, I’d contact a (generally very scarce and overworked) technical writer to write something that would then make it easy to understand and to use (how hard could THAT be, anyway?!)

Well, now I know.

Later, as a writer, I was called in during the early stages of another development project. Alas, early for me was still late in the game for the developers. They’d already baked in the logic and many of the names and concepts. Worse, I came in cold while the developers had had months of discussion and early design. So, in a 1-hour meeting, I was expected to do something that made it all easy to use. (Again, how hard could that be?)

Ease of use starts at the beginning of the design and must be considered as a design requirement throughout the design and development process–it rarely (i.e. never) happens accidentally. Monitor resolution and security protocol negotiation were probably not designed with ease-of-use as a requirement. Often, such things are driven primarily by hardware limitations (e.g. squeezing the most performance out of slow communication lines, limited control signals, etc.) So, what they save in hardware engineering and manufacturing costs, they spend in customer support and training. Whether that’s a net win or loss, depends on many things.

So, the TL;DR version is that engineers and technical writers need to understand each others’ workflow and each others’ contribution to the end product. However, that’s going to involve a lot of retraining on both sides.

WRT computers talking and thinking, in HTTP and REST, we use request and respond, evaluate and determine, and the like.


#16

I don’t know that “humanized” language is harder to localize, per se. If anything, it would be easier, if it’s easy to understand and apply a human context. What is hard to translate are idiomatic and colloquial expressions and to understand the context of speech in a technical document.

I’m not sure what would happen when trying to translate something like “pressing the Enter key makes the app happier than a pig in the mud,” for example. Mainly because of the contextual ambiguity that presents in a technical document. Are you talking literally about pigs in mud (e.g. in farming app) or do you just mean that things will go swimmingly, er I mean well, after that action? I suppose you could tag that as a colloquial expression, so the translator knows not to translate it literally, but now you’ve made it doubly complicated: 1) the inherent indirection of a colloquial statement and 2) the additional metadata to indicate the indirection of the statement itself. Seems like more trouble than it’s worth, to me.


#17

To me, “humanizing” != “colloquial language”. I do agree that “colloquial language” is more difficult to translate.

The developers behind a product frequently have trouble starting with a ‘big picture’ view thereof.

For developers who are new to a product, a ‘big picture’ view is essential. We as technical writers need to know how to start with that ‘big picture’, to synthesize our products (in non-marketing language), and then relatively quickly, get into “the weeds”, in the context of user (in this case, developer) stories.

e.g., “Here’s how you can take advantage of feature X, and this is the code snippet that makes it happen.” yada yada.


#18

Here is another example of anthromophorporphization. I realize we’ve moved on and the recent discussion is more about humanizing language, but I found it interesting to see people try anthromophorporphization in technical writing!


#19

Another example at:

Start at the 12 minute mark where the messenger with the key goes to the pub.