Challenging misconceptions about readers

A problem many employees have is to make incorrect assumptions about their customers.

You can start to understand misconceptions in your writing department in the following ways:

• Research the writers.
  
• Work backwards from defects in the docs.
  
• Understand the types of misconceptions that typically occur.
  

The most common and pernicious assumption that writers make about customers is: "The customer is just like me." Often this assumption is a stand-in due to a void of knowledge. Sometimes it is more ingrained than that.

Another very common misconception is that customers are more focused on the software product than they actually are. In most cases, customers use a range of software products during the day, each with its own terminology, metaphors and processes. They might only use your product once a week or month, in which case they might not remember details between uses. Few of them will be expert users of the documentation, so you shouldn't expect them to remember a caveat you posted in the introduction or a definition you stuck in a glossary.

Another common misconception occurs at companies where developers provide customer support when problems are too difficult for support staff. The side-effect of this activity is that the developers start to think of the problems they solve as the norm and consequently over-emphasize the edge cases. They pass this bias on to writers, resulting in content that confuses most readers.

User research has two parts: the research and the dissemination of findings. Understanding misconceptions is especially important to the latter part. For example, personas should be designed to provide writers with user characteristics, but should also attempt to correct false assumptions. The pernicious thing about misconceptions is that they are internalized; frequently people don't even know that they're making the assumption. We don't always have to point out that their assumptions are in error; often it is best to just provide better information.

Personas should be prescriptive not descriptive

There are lots of things that R&D departments should be doing to collect information about customers, including:

• Direct methods: large-scale surveys, usability testing, round-table discussions, focus groups, interviews, in-situ observation, ethnographies.
  
• Indirect methods: surveying sales and support staff, mining the support knowledge base, collecting web usage metrics, collecting data on searches.

There are lots of ways that R&D departments should be helping their staff learn more about customers, including:

• Presentations, lunch 'n learns, written reports disseminating research findings.
  
• Metric dashboards that employees can use to track customer responses.
  
• Programs that let employees listen in on customer support calls.
  
• Poster campaigns.
  
• This list could go on and on.
  

Personas are just one way, among many, to disseminate customer information to employees. The thing about personas that many people don't get is that personas are fundamentally different from every other way to educate employees. Other methods present info and require interpretation. With personas, all that is done for the employee: there is no (or at least little) interpretation.

A small set of personas is going to be used as the stand-in for the entire universe of customers when employees make decisions about product design, implementation and documentation. They are a powerful tool that can fundamentally change outcomes.

Consequently, personas have to be prescriptive rather than descriptive.

Whenever you talk about personas with information architects, the first thing they'll say is "Personas must be based in research! They're garbage otherwise." But that is really missing the point. Yes, we should not just make stuff up about customers. We must have a solid foundation of real world knowledge. But NO, personas should not be derived from research.

Here's an example where the universe of users differs from targeted users: A company has APIs that app developers are using to develop games. Game developers make up most of the user base. But the APIs aren't fully functional for good game development, and the company doesn't have the resources to beef them up. The APIs are really only useful for porting games from other platforms. The documentation needs to be very different for porting games than for developing them from scratch.

Here's an example of personas that have no relation to the real customer base (I believe this comes from Alan Cooper's The Inmates are Running the Asylum, but I can't find my copy to verify that): When airlines were first developing those TVs that are on the back of seats, they used two personas: a young boy and an old woman. They deliberately chose edge cases because they wanted to be sure that the UI and controls would be simple enough that every passenger could use them. The personas are far from the average customer. The average customer is probably a 35 year old white male who is an expert user of complicated gadgets. Had those personas been based on customer research, airplane TVs would have many more features and be much more difficult to use.

Once we accept that personas should be prescriptive, then we can see some implications for how we should be developing them:

• Personas should not be created by researchers. They should be created by, or at least under the direction of, product managers and senior management.
  
• Research should be part of the persona development process, but any description of users should be checked against the question: And is this who we want to be developing for?
  
• Research will be useful in filling in "color" details of the personas.
  
• Personas should be considered temporary constructs that are useful for limited time periods. Customer targeting can change frequently, so personas should be tweaked for every product release cycle.

I foresee the other comment I always hear from information architects about personas, and that is: "You can't confuse development personas with marketing personas!" I'm not.

In my experience most attempts at personas fail, and I think the reason they fail is that they are descriptive. They are created by low-level employees - tech writers, researchers, information architects - who think they can derive personas from customer data.

I was starting to write this post a few days ago when I wrote my musings about visionaries and the lack of vision in software development organizations. We need a lot more vision in our companies, and a lot more dissemination of vision to writers and developers. The failure of persona development in many companies is just part of a larger failure of vision.

Note: My thinking about personas is markedly different from my usual approach to customer research. In most areas I favor a grassroots approach in which writers perform research themselves. Direct contact is always more pithy than only reading a report.