Imagining Your Audience

I recall some time back hearing Alex Epstein discussing what I believe he calls subject matter experts in some of the early episodes of his Human Flourishing Project series. Of particular benefit (and difficulty) is the ability to determine whether someone is (or is not) one of these.

I like to think that I am pretty good at identifying subject matter experts, but I am also in the somewhat frustrating position of being unable to explain exactly how I do it. What I can say about my somewhat intuitive process is that an important part of how I can tell comes from how they communicate. Can someone explain what he is thinking about in a manner appropriate to his audience? (I emphasize part here: Some experts are ... unpracticed ... at communicating with people outside their field.) Generally, though, it seems that someone who can do this has a solid percepts-through-concepts grasp of his field.

Perhaps because of this, an expert understands what someone with a different level of expertise would need to get up to speed. Perhaps, especially for an expert who interfaces a lot with the public or other specialists, it's largely due to practice.

Again, having a good grasp of one's field isn't always enough to communicate well, as software developer Eric Raymond cautions when he writes "A User Story About User Stories." Fortunately, he offers us a workaround:

Are you targeting conservatives, liberals, or human beings? (Image by BBH Singapore, via Unsplash, license.)

The way I learned to use the term "user story", back in the late 1990s at the beginnings of what is now called "agile programming", was to describe a kind of roleplaying exercise in which you imagine a person and the person's use case as a way of getting an outside perspective on the design, the documentation, and especially the UI of something you're writing. [bold added]

Raymond provides his own example of a user story in part because the term in his industry has been watered down over time to the point that many people there are not doing what he did -- which was come up with a real person, very different from himself, who might nevertheless be part of his audience. Not only that, he recommends triangulating from one character to others as a means of finding other aspects of one's work to make more accessible.

It works even better if, even having learned what you can from your imaginary Joe, you make up other characters that are different from you and as different from each other as possible. For example, meet Jane the system administrator, who got stuck with the conversion job because her boss thinks of version-control systems as an administrative detail and doesn't want to spend programmer time on it. What do her eyes see?

In fact, the technique is so powerful that I got an idea while writing this example. Maybe in [the] reposurgeon[ suite]'s interactive mode it should issue a first [line] that says "Interactive help is available; type 'help' for a topic menu." [bold added]

It is very interesting as a writer to consider this point, and I'd say that goes double for anyone who thinks he's already doing that. Raymond goes on:

However. If you search the web for "design by user story", what you are likely to find doesn't resemble my previous description at all. Mostly, now twenty years after the beginnings of "agile programming", you'll see formulaic stuff equating "user story" with a one-sentence soundbite of the form "As an X, I want to do Y". This will be surrounded by a lot of talk about processes and scrum masters and scribbling things on index cards.

There is so much gone wrong with this it is hard to even know where to begin. Let's start with the fact that one of the original agile slogans was "Individuals and Interactions Over Processes and Tools". That slogan could be read in a number of different ways, but under none of them at all does it make sense to abandon a method for extended insight into the reactions of your likely users for a one-sentence parody of the method that is surrounded and hemmed in by bureaucratic process-gabble. [bold added]

The one-sentence "parody" can -- very cautiously -- be used as shorthand for what you want to do, which is how I suspect this situation originated. But it is clearly not a substitute for doing the imaginative work.

And that goes double for opinion writing. I favor free markets, but most of my audience will favor policies that are antipodal to them in one or more ways. Am I shoehorning -- or even writing off -- my potential audience with stereotypes, like hippies, or rednecks, or "low-information voters?"

Or am I trying to understand how they might have gotten to the point where they think such things as abolishing the police, or severely restricting immigration, or imposing tariffs are good ideas? What concerns have them looking at these things? What kinds of arguments are they hearing? What might they already have in their minds that could help them appreciate better alternatives?

Speaking for myself, I can see how this approach could help me with the two biggest obstacles -- aside from time, lately! -- to being a more productive writer: knowledge and accessibility.

On the first, I frequently will come up with what sounds like a great idea for a column, only to discover after a little bit of research, that I don't know enough about the topic to make an argument I am satisfied with. The above technique is no cure-all: There are some topics any writer will have no business writing about. But for some things, this might indicate which areas to look at, such as one's knowledge gaps about what might be informing the context of parts of one's audience.

On the second, if one finds talking to other people easier than writing, one now can simulate an audience. Perhaps this is another technique that can help with the psychological distance problem, shortening the amount of time between drafts or cutting down on the amount of editing one needs to do after reading a piece to others or hearing it read, as I already do.

Just as there are limits to who might use a software package, so there will be to commentary. I won't be pitching anything to a Marxist professor any more than a software designer has to worry about someone whose only use for a computer is to read or stream Netflix from a Kindle. And the degree of fleshing-out is an interesting question, as is how frequently one want to might use the technique. These things seem like the kinds of questions one has to answer by doing.

That said, this sounds like a technique that can be applied to commentary, so I am glad Raymond decided to write about it.

-- CAV