Vous êtes sur la page 1sur 13
Co py ri g ht TASullivan 1

Co pyrig ht TASullivan

Personas help us identif y the true users of the a pplication and the documentation.

Personas help us identif y the true users of the a pplication and the documentation. They help us understand who really uses the application to perform the tasks. It’s too easy to think of ourselves as the users – to identify with our own ideas of how the application should be or could be used.

Instead, we must identify with the true users and their tasks so we can know the parts of the application they will find intuitive and the parts they will need help understanding.

Develop personas of your true users—the actual client who will be using the software and (therefore) the user documentation. Personas help you to understand user motivations, expectations, and goals. Post personas for your projects next to your PC, and then use the persona as your focus to help you develop the “voice” (tone) of your documents. Knowing your true user also helps yo u to know how j ust how detailed to make yo ur document.

No matter what comfort level users have, the y want immediate answers to any problems

No matter what comfort level users have, they want immediate answers to any problems they encounter. They want to find and understand solutions in the least possible time so that they can continue with their tasks.

Understanding their expectations is critical to creating successful user documentation. All three groups expect to find and understand the answers to their technical problems immediately – preferably on the screen. If they don’t, they will call for support.

Remember that technology “resisters” are declining as “innovators” are increasing. Just as software engineers are building applications to meet user needs (not merely functional needs), we must create deliverables that are truly usable for the right group of clients.

Taking time to identif y the p ersonas involved in y our pro j ect

Taking time to identif y the personas involved in your pro j ect enables you to more easily understand and gather information from project sources, such as requirements, use cases, and wireframes.

Requirements, use cases, and wireframes all relate to the users’ tasks and workflows using the information garnered by BAs and UX associates’ research and interviews. As writers, we need to be able to analyze, understand, and use these requirements, use cases, and wireframes to identify the tasks and workflow Knowing this helps us to write our content in a more userfocused way. It also helps us clarify our writing style by helping us identify the terms we should use when referring to different feat ures or aspec t s o f the tas ks and the application. Client s generally prefer simple, nontechnical language. If we must use a technical term, we better be able to explain it simply and clearly the first time it appears.

Once y ou know who the true user is , y ou need to a

Once you know who the true user is , you need to a pply the concepts of heuristics, usability, and PET to your documentation.

Applying heuristic principles to user documentation means more than adopting a different writing style. It also means thinking and working differently, too . That means looking at your clients from their perspective, not yours.

To see y our client from y our client’s pers p ective , y ou

To see your client from your client’s pers pective, you have to first understand what their perspective is. You have to understand that your clients are trying to complete a task that helps them complete their workflow, and that is why they are using the application. If you can grasp that, then you can actually help your clients achieve their goal:

completing their work in a quick and efficient way.

Let’s start by spending a few minutes examining the differences between user workflows, user tasks, and software functions.

In the past , a client’s workflows were not alwa ys on the mind of

In the past , a client’s workflows were not always on the mind of either IT or the business. Consequently, user documentation often included involved steps to explain gaps between the user’s tasks and the application’s functions. However, with usability as part of the design team, along with BAs and product managers, there is more interaction with the users to determine the users’ tasks and workflows. The UX team and the BAs then develop design documents that help the software engineers create applications that more closely mimic the users’ actual workflows.

Those same documents can help us create user documentation that is more userfocused and tas k oriented. Whil e this may seem like a s imple concept, we often get lured into describing how the application works rather than how the user works. This graphic clearly separates the application functions from the workflow and tasks; we need to be sure we don’t move away from documenting the user’s workflows and end up documenting the application instead.

Most users perform more than one workflow in order to complete their jobs, and sometimes

Most users perform more than one workflow in order to complete their jobs, and sometimes the same task can appear in multiple workflows. For instance, the task of making and logging phone calls in Microsoft’s CRM product occurs in the workflow of managing clients, as well as in the workflow of creating campaigns.

User’s workflows are important because:

They define the number and type of audiences .

They are a roadmap to the tasks.

They help define possible deliverables.

They provide the organization for documentation.

Heuristically, we want to document user workflows and tasks, not software functions. Users only care

Heuristically, we want to document user workflows and tasks, not software functions. Users only care about software functions in the context of completing their tasks.

Driving to Work is a workflow that contains multiple tasks. These tasks also require the user to learn and use several functions of the car.

In our example, the workflow (Driving to Work) contains 3 user tasks. However, it’s easy

In our example, the workflow (Driving to Work) contains 3 user tasks. However, it’s easy to slip into the simpler mode of documenting the functions, such as:

Understanding the Shift Lever Manipulating the Steering Wheel Using the weather controls in the car

While it may seem hel pful to include information re garding the a pplication , users reall y just want to know how to use the tool so they can complete their work. Therefore, if it isn’t part of one of their workflows, think twice about including it.

User’s jobs usually entail more than one workflow. Workflows are usually comprised of more than

User’s jobs usually entail more than one workflow. Workflows are usually comprised of more than one task—not always, but most of the time. Tasks can be done independently of the workflow and of other tasks—again, not always, but sometimes. Tasks can sometimes entail several screens or menu options of an application to complete.

What does this mean when you are writing documentation?

You need to find out which of the user ’s workflows are included or impacted by the project.

You will probably have to group several user tasks together to complete a single user workflow (Driving to work—the user workflow—requires the tasks of starting the car, steering the car, and finding their way).

You may have to analyze several application functions to understand and document one user task .

You shouldn’t mistake application functions for user tasks – be sure the topic headings still describe user tasks, not application features.

Remember that your focus when writing is the user and his or her workflow, not the application and what it can do.

Whenever possible, talk or listen to the users as they describe their workflow. Keep in

Whenever possible, talk or listen to the users as they describe their workflow. Keep in mind t h at users may un derpl ay or om i t secti ons i n t h e i r wor kfl ow – t h ey k now i t so we ll t h at they sometimes forget to mention everything.

User representatives, such as product managers, can also be helpful in confirming the workflow.

13