As a technical communicator, you often start by categorize users into user groups where each user groups is given a name, for example Network engineer, System administrator, Operator etc. To make the user group come alive, you develop personas to represent each user group. But how do you, as a technical communicator, actually develop user groups and personas? And how do you determine what type of information to write and how to classify and organize information in deliverables based on a set of personas?

The whole purpose of identifying user groups and developing personas is to find a way to determine what type of information you need to write and how to organize and classify that information. The purpose of a persona is to help you understand who to write for; to select the level of details, style, tone and terminology etc. In my opinion, the user group approach has many challenges. Find out about them below. The size of the challenge depends on how homogenous or heterogeneous the user community is for your product. The challenges below may not apply for a product that is targeting a very small amount of users, maybe only the users within one (1) company. One of the problems, following the user centered design approach, is that you will not be designing for findability.

Let’s first look at how personas are used in product design and development. Someone in your company, maybe the product manager, has identified a market need for a new product (software application, hardware device etc). The need can be transformed into user goals and personas can be used to capture and make the user goals explicit and “alive”. The personas describe for example, the user motives, attitudes and challenges. A product is designed to help users accomplish their goals and needs, thus the personas are something the product designers are relaying on. The final product includes certain functionality and has a user interface that is designed to allow users pursue their goals as easy, efficient and secure as possible. A prototype is tested, in iterations, against real users to verify that the design meets its requirements.

How do we as technical communicators get into the picture? Following a user centered design approach, you start by identifying user groups. If the product designers had done their job, a set of personas are already available to you (most often this is not the case), which makes your life easier. What do you do then, given a set of user groups and personas? The goals each persona is reaching for can by assessed by looking at their responsibility. Real users are observed when using the product to capture how they are using it to reach a goal. Task analysis (for example Hierarchical Task Analysis - HTA) is used to model how a goal is reached. All tasks for all goals for a specific persona are captured in a specific manual; you’re developing role based documentation.

Instead of looking at the responsibilities and goals each persona is pursuing, you can make a list of all the questions a persona is assumed to ask. By asking real users, you can find out if your list of questions is valid.

What can go wrong? If you focus too much on the personas and a typical user representing the persona, you might end up in documenting the daily life of a specific user in a specific organization. Then you might document tasks that are not related at all to the actual product being documented. Another user, having a different role and responsibility in another type of organization, may find the tasks and goals depicted in the manual totally invalid.

A specific user, having a specific role and associated responsibility, in a specific organization is not actually looking in the product manual to find out what responsibilities he or she has or how to execute those responsibilities. At least I’m not doing it. End user assistance for a product shall help the user understand what problems, needs or requirements the product can help the user solve and how to use the product to solve the problems, needs or requirements.

What if the product development team hasn’t developed any personas? Then you must define user groups and personas yourself. How do you do that? You’re interviewing as many real users as possible, asking product managers, market communication and support/service people to complement the picture. The survey data is analyzed and an initial segmentation of the users can be done. Then you try to find common patterns where you group and categorize goals and tasks into user groups. Especially for global products, user diversity is great (and will be even more diverse in future) so no matter how much you try, the set up of user groups will be a generalized view that doesn’t match anyone.

Then what? You continue to identify the user goals, tasks and responsibilities each user group is pursuing. But hey; what you’re doing as actually what should have been done prior to start designing the product. Can your technical communication team afford such a user analysis in a development project  (lucky you, if)? When doing such a user analysis you might come across user goals, tasks and responsibilities that the product is not supporting. So the product is not designed to meet its audience. Do you describe how to use the product to solve a need, for which the product was not intended?

How do you identify the tasks and sub tasks that must be performed to reach a goal? Let’s say you are observing real users when using the product (maybe a prototype) to reach a goal. How does a specific user know how to use the brand new product? The user says “I don’t have a clue – you should tell me – you’re the technical communicator!”. So you end up asking SMEs or try out the product yourself.

You can identify the type of information users need to reach a goal, given a set of goals and tasks. Each task node in the HTA tree reassembles a DITA task topic. To each task you furthermore identify supporting descriptive information (concept and reference). The personas can elaborate the amount of prior knowledge you are assuming the users to possess. Given the prior knowledge, the level of information details can be determined.

How do you organize information in deliverables? Imagine a global product, used by many different user organizations in many different markets; small companies, large companies etc. Each organization has their own set up of roles, responsibilities and company tradition. Maybe you are developing one manual for each persona, including the information a persona is assumed to need. But what if several personas are doing the same task? Then you must repeat the same information in several manuals. Maybe not a big problem, but of a large amount of tasks can be done by many personas, then it can confuse the user navigating in several manuals in parallel. So the user centered design approach means that you are not designing for findability.

The personas describe fictitious roles, reaching for goals and tasks that don’t match any real user precisely. The personas makes you say: “we have categorized the world and we know your responsibilities and what you are trying to do and what type of information you need, so find the category you are in”.  Personas are imposing a knowledge model onto the world that is a generalization to which no one adheres. Your role/persona based manual is saying “Hey Mr/Mrs X, we know who you are, your responsibilities, and what you are doing and what information you need – in this manual you will find it all”. In how many cases is this a perfect match? Since a persona is not matching a specific individual, a specific individual may not feel that the persona role is something for him or her. Most often users must search through every type of manual to find what they are looking for. Again, you are not designing for findability.

The user community is also changing. So the personas must be a living thing. New future users have different domain knowledge, behaviors, responsibilities and goals. The user analysis, where the personas are developed, is a static snapshot, which means that the user manuals built on the personas may be obsolete in a near future.

A fundamental part when developing technical documentation, especially topic based documentation, is the metadata you use to classify content. I make a distinction between user evaluateable facets and user non-evaluateable facets (see my blog post http://dita.xml.org/blog/how-do-you-design-for-findability-part-2 for more information). Since personas is a way for the technical communicator to grasp and get control over the world, persona driven development often leads to metadata being user non-evaluateable, which hinders findability. The user must get into the head of the designer to understand how and why information is organized the way it is.

If you are having difficulties in developing user groups and determining what type of information to write, you should look at SeSAM (www.sesam-info.net); a new design methodology for technical communicators. Categorizing users into groups is not the starting point in SeSAM. But user profiles are a fundamental part in SeSAM. Users are different, that’s for sure.