|
–Geoff-Hart.com:–Editing, Writing, and Translation —Home —Services —Books —Articles —Resources —Fiction —Contact me —Français |
You are here: Resources --> 2006 -->
Personas and the technical communicator
Vous êtes ici : Ressources --> 2006 --> Personas
and the technical communicator
By Geoff Hart
Previously published as: Hart, G. 2006. Personas and the technical communicator. Usability Interface 12(2), October 2006 <www.stcsig.org/usability/newsletter/0610-personas.html>
Unless you've been living in a cave for the past 10 years, you've undoubtedly heard about personas. (If you have been living in a cave for 10 years, write to us; we need to develop a persona for you and your fellow troglodytes.) A persona is a character sketch that provides enough understanding of a product's user or the documentation's reader that you can design to meet their needs. Unlike stereotypes, personas lead you to focus on the essentials (that person's needs) rather than odious generalizations.
Alan Cooper first popularized personas as a tool for developing usable software, but like all good tools, personas have been adapted to other purposes—such as writing documentation. (Some might call this an example of the "if all you have is a hammer" syndrome. Speaking as a huge fan of impact-driven fasteners, I'm not one of those people.)
What's the problem with personas? They're a new concept to many communicators, and thus sufficiently unfamiliar to make them difficult to use. To help solve this problem, I'll present a couple of personas to show you how it's done, and illustrate their implications for documentation. (All names have been changed to protect the real people on whom the personas are based.)
The persona: Sticky Sue is a harried executive assistant, with a college education and a good grasp of computers. She uses Microsoft Office daily, and led the sexual harassment lawsuit against Microsoft over the seemingly lewd google-eyed ogling behavior of Clippy the Paperclip. Based on her unsavory experience with Clippy, Sue has never again used online help. Instead, her office is cluttered with "For Dummies" manuals (a lawsuit over the dismissive nature of these titles is pending). Because Sue uses so many software features, these books are now double their original thickness due to the Post-it® notes that identify key pages, thereby eliminating trips to the index. Sue has also expanded this strategy to cover the bezel of her monitor and the sides of her computer with Post-its. (An advantage of this approach is that it lets her hide her login password and other confidential information amidst the sea of Post-its.)
Documentation considerations: Users such as Sue clearly want to create their own documentation, focusing on their unique needs, and customize their navigation through the documentation. To answer these needs, we should create a quick-start manual composed exclusively of Post-it notes, so users like Sue can rearrange the pages into whatever order seems most efficient on a given day (pink post-its apply only on Tuesdays, for example). Designing documentation for complex products to fit on Post-it notes is certainly challenging, but offers many unexpected advantages. For example, it encourages concise writing and facilitates single-sourcing of the documentation for the upcoming cell phone version of Microsoft Office and other products.
The persona: Jeff is a technical communicator with 20 years of experience. In addition to being a busy editor, he spends many hours daily on e-mail, mentoring colleagues and answering questions—questions about the intricacies of using software to produce documentation, about the nature of documentation, and about life at work. Jeff is connected continuously to the Web via a high-speed connection, and spends hours researching answers to writing questions. Oddly enough, he actually reads computer manuals and online help for fun, and many "how to" books and books on communication theory fill the groaning bookshelves in his office.
Documentation considerations: To meet Jeff's needs, deliver documentation in the form of leading questions that arrive via e-mail. This caters to Jeff's mentoring nature by encouraging him to explore in order to answer these questions. Additional documentation should be provided in the form of sponsored Google advertising; this way, whenever Jeff uses his Web browser to research a topic, he immediately sees links to the relevant section of the developer's Web site. Because these links are dynamically generated using Google's patented AdWords technology, they provide an efficient path into the documentation. Moreover, maintaining the documentation on the Web site ensures that the most recent documentation is instantly available, is truly minimalistic, and promotes learning by exploration.
See? Personas aren't so intimidating. I encourage you to create some of your own!
©2004–2024 Geoffrey Hart. All rights reserved.