|
Services | Tips | Theory | WebPoems | Workshops | Books | Articles | Lisa | Jonathan |
Our Articles ... |
On Personalizing Content |
On
Personalizing Content
On
Kids' Software
|
The Dangers of Personalizationby Jonathan Price Talk presented at Society for Technical Communication Region 5 Conference, Houston, TX, October 12, 2001. Personalization is coming to technical communication, and the results may not be pretty.
Ironically, just as e-commerce and the database-driven Web make personalization possible, in fact required, on many sites, we are discovering the downside of personally selected interfaces, searches, content, and opt-in e-mail. |
Background The growth of personalization in Web commerce and syndicated content is changing our conception of audience from a fuzzy mass to a series of distinct individuals. Back when we were busy creating a book or a help system, we often started with a rather vague description of a fairly unified group of users, with one or two subsets. But now that a Web site can interrogate each visitor and retain personal profiles using cookies and database records, we are surrounded with one-to-one marketing, individual wish lists, personally selected interfaces, and individual content delivered by services with names such as, yes, Individual. The mass audience, appropriate (even inevitable) for a book or a single help system, is disintegrating into thousands of individuals, with a myriad of roles, goals, tastes, tasks, and preferences [2, 14-16, 20, 21, 26-29, 31, 34]. Accustomed to personalization on the Web, our users want to locate only the answers to particular questions. These consumers do not like to read. They reject books, dislike help systems, and, in fact, refuse to use these large document-like blocks of data. They insist that we tailor the information to them, on the fly. So, using content management systems that rely on object-oriented databases, we are transforming our old books into sets of discrete objects, some as small as glossary terms or product numbers, some bite size (procedure steps), others more filling (a whole procedure, the reference for a command). Exploding our legacy documents into distinct objects makes them easier to re-use in multiple circumstances (several different Web pages) and display formats (Web pages, cell phones, PDAs), customizing content for whatever device the recipient is using. We also offer multiple menus leading to the same information objects, because on the Web we do not have to follow the tradition of books and help systems, which tend to provide a single main table of contents. On the Web, convention and the ease of linking allow a company to offer not just one, but half a dozen menus, so a user can find information in which ever context he or she prefers. Looking up information on troubleshooting a particular hard disk, for instance, one user might conceive of the information as living under Computers, Peripherals, Hard Disks, Product Lines, Product Number. But another user could find the same information following the menu chain starting with What You Want to Do, through Store my Files, to Electronic Storage, down to Hard Disks, Product Lines, and Product Number. Through multiple menus, each offering a different perspective on (more or less) the same set of objects, users can pick the browse paths they feel most comfortable with, and therefore increase the likelihood of success. They find the paths that mean most to them, personally. By tagging the objects with XML we also allow users to decide exactly which parts of our documentation they want to look at, which parts they want to leave in icon form for use as needed, and which parts they want to hide. For instance, an engineer might ask to see the functional definition, syntax diagram, parameters, and an example for each command reference, iconizing more rarely used information with buttons that would pop up information on prerequisites, processing algorithms, status, and shortcuts, while refusing our offer of information on error messages and menu locations, as unnecessary. Another user might want the error messages displayed, while hiding the example, and iconizing the menu locations. Because the XML tags identify each element in these terms, we can, through software, allow users to pick and choose the elements they want automatically displayed, turned into buttons, or kept out of sight. Essentially, we can allow users to build their own documentation, defining the layout and content they want, and we draw the pieces out of the underlying database, as needed [12, 18, 19, 23-25]. Increasingly, users email us with questions. The writers who must answer these messages look up the answers in the database, pick the most relevant response, and drop it into the reply. Instead of writing books, the writer is answering mail, but instead of having to draft a new e-mail message for every correspondent, the writer draws on previously created objects, to expand the replies. Similarly, writers who are assigned to participate in user discussion boards must often look up a few facts, copy the text, and post that as part of the ongoing thread. Having access to previously written chunks, not just entire chapters, increases the speed with which these writers can get back to the user. In effect, the writers are acting like clerks in a mail room, selecting this, that, and the other object to drop into the envelope, and send off. From the user's point of view, these messages, whether in regular email or discussion boards, address the unique problem, without any other jabber. Personalization, here, means getting the relevant answer fast, rather than saying "Read the fine manual." Furthermore, by defining attributes for these objects (subject, products mentioned, natural language used, type of documentation, date) we afford users the opportunity to make much more subtle and personal searches for the information they seek. Advanced searches like those in Amazon allow people to avoid the twin devils of too many hits, and too few. In a large database, then, each user has a much better chance of getting search results that correspond to his or her personal wishes. As technical communicators, then, we are being driven to adopt an object-oriented approach to our information, using vocabularies developed in XML, so that our users can find just what they want, quickly, view it in exactly the layout they want, or get the information directly from one of our people, who picks the right info object and pops into the reply. We are also beginning to investigate content management, customer relation management, and syndication software, the tools that are most need by technical communicators, in this new role as conversationalist. In all of these ways we are edging toward a world in which we personalize the communication, moving from a publishing model (we make books, you read them) to a conversational model, in which we respond to questions from our users, as quickly and adroitly as we can, tailoring our responses to their personalities, concerns, and tasks. Dangers for your user Danger #1: Customizing means stereotyping, which can often lead to mistakes. Once we have identified a person as part of a niche market, we follow business rules that tell us what content to emphasize, but we may inadvertently leave out, de-emphasize, or hide content that this particular person wants. In this way, customization may conflict with true personalization, and with our desire to offer all our information to everyone, even if it is not thrust in their faces upon arrival. Solution: Remind people that you have lots of other content. Put icons on their home page, suggesting they click and go to that content. Pop up messages once a month pointing out some relevant content that is not directly accessible from their home page. If we ask a lot of questions on the personal profile, but do not make use of the answers to pinpoint the content we should deliver, we frustrate the person who spent ten or fifteen minutes filling out the form. They feel insulted each time they come to their personal home page. "This isn't me." Solution: Identify content types or topics that might be relevant, and advertise all those on the person's home page. Build better business rules to take advantage of the personal information you have been given. If we do not ask enough questions, we may drop the person into the wrong category, offering irrelevant content. "Why are they bothering me with this stuff?" Solution: Interview your users, as JoAnn Hackos and Ginny Redish suggest in User and Task Analysis [13], then build much more subtle profiling forms. Work out correspondences between a personal fact and the relevant content. Build those into business rules, so you can deliver that content automatically. Danger #2: Allowing a person to pick and choose content may mean some content gets lost, for that person. People forget that they chose the content being offered to them. They forget that there were other choices they could have made; they do not know what else you have to offer them. Having chosen not to display reference manuals, they may then come to believe you do not have any. Solution: Periodic reminders of other content you think might be relevant, and invitations to look at the full range of content, including stuff you believe is irrelevant. People grow and change. The content that someone chose six months ago no longer may no longer apply to their job. Solution: On every section of their portal, urge people to edit the content. Put an Edit button in the title of each grouping. Make change convenient. Danger # 3: Your organization may violate the user's trust. You may be completely trustworthy, yourself, but your organization may decide to sell the user's personal information to unscrupulous spammers, or fail to protect it from hackers [1, 3-5, 8-11, 17, 22, 30, 32]. Solution: Campaign for real privacy. Offer to rewrite the privacy policy in plain English, then insist that the company follows it. Speak up in protest when marketing starts keying popup ads to the profiles. Become a new kind of user advocate.
Dangers for you Danger #4: Identifying several niche audiences means writing more. You may not have to rewrite every information object for each audience, but you do have to tailor some passages for individual audiences. Solution: Rewrite text that is sensitive to audience goals and roles- introductions, overviews, lists of features and benefits, concepts. Come up with several different menu paths, one for each group. Identify the top priority objects for each audience, and revise those to target the group, with appropriate examples, references, goal statements, problem statements, suggested content. Danger #5: Updating the database, creating group content, and answering customer e-mail means that you are getting personal, and becoming an Subject Matter Expert (SME). Your idea of your role as a writer must change. You have been a neutral but helpful authority so far. Now you must become an individual, with unique characteristics-yourself. Solution: Build a collection of boilerplate answers to e-mail questions. But start each e-mail with phrases borrowed from the user's message (not whole paragraphs) to prove you have actually read it. Then drop in the boilerplate message. End with something personal. This means coming up with an e-mail persona, hobbies, interests, content you are willing to reveal about yourself. Oh, and your actual name, e-mail address, and, if you are really bold, a phone number. Wow, that changes your relationship, doesn't it? Even if you do not have to answer e-mail, you are becoming a subject matter expert, rather than a creator of books, or a maker of Help systems. You no longer turn out finite documents, tangible things. You simply learn, and respond to questions, implied or real, derived from e-mail, discussion lists, or your own chats in the hall. You enter the process, but give up turning out products. You join a conversation. Danger #6: Your idea of your audience must change. You can no longer settle for vague generalities like "beginning user." The pieties of audience analysis go out the window. Solution: You must keep thinking: what content can I come up with for this particular group? You may have to characterize niche audiences as personas, in Alan Cooper's sense-with a real name, car, goal, work environment, and photo [6, 7]. Danger #7: Your idea of your work must change. You can no longer hope that a single large document will address the needs of several different audiences, somewhere. Solution: For each object you create, you must consider which audiences it is a top priority, so that it is brought to their attention. You'll identify those audiences in the object's attribute for something like Priority Audiences. As you write, adapt your tone to their ear, put in examples that make sense to them, mention goals they identify with, solve their problems. Now, of course, you are in danger of proliferating objects. Instead of single sourcing, your group may be on the verge of proliferating, and, in the process, becoming identified with one or two favorite audiences. Danger #8: You must be evaluated on new criteria. A manager can no longer evaluate a writer on document delivery and deadlines. You can't be judged o whether you got out half a dozen manuals on time in the last quarter, or met with the standards committee regularly, or kept your nose clean, during the recent layoffs. Solution: Managers must develop new criteria, based on your new role as IT Subject Matter Experts ("It's me!"). How many objects of interest to each group have you updated? How many new topics did you create, for each group? What efforts have you made to learn more about your subject-and your groups? Oddly, your value increases as you become more human-not just a repository of wisdom, but a participant in the community of users. You should get a raise when the discussion group asks you to become the moderator. Customization and personalization, together, challenge our traditional notions of audience, structure, and process. Exciting in many ways, these trends also threaten our equilibrium, and demand a new way of writing, working, and relating to our users. We are being drawn into a more equal exchange, making communication more like conversation than publishing.
Resources 1. Agre, P. E., and M. Rotenberg (eds). 1997. Technology and Privacy: The New Landscape. Cambridge, MA: MIT. 2. Allen, C., D. Kania, and B. Yaeckel. 2001. One-to-One Web Marketing, Second Edition: Build a Relationship Marketing Strategy One Customer at a Time. New York: Wiley. 3. American Civil Liberties Union (ACLU). 2000. Do You Know Where Your Data Is? http://www.aclu.org/action/privcard.html 4. American Express Company. 1998. Customer Privacy Principles. http://home3.americanexpress.com/corp/consumerinfo/principles.asp 5. Bank One. 2001. Privacy Policy. http://www.bankone.com 6. Cooper, Alan. 1995. About Face: The Essentials of User Interface Design. Indianapolis, IN: IDG. 7. ---. 1999. The Inmates are Running the Asylum: Why High-Tech Products Drive Us Crazy and How to Restore the Sanity. Indianapolis, IN: Sams. 8. Davies, S. 2001. Time for a byte of privacy, please. Privacy International. http://www.oneworld.org/index_oc/issue697/davies.html 9. Federal Trade Commission, U.S. 1999. How to Comply With The Children's Online Privacy Protection Rule. http://www.ftc.gov/bcp/conline/pubs/buspubs/coppa.htm 10. Gilbert, J. 2001. Privacy? Who needs privacy? Business 2.0, January 23. 42. 11. Givens, B. 2000. Privacy expectations in a high tech world. San Diego, CA: Privacy Rights Clearinghouse. http://www.privacyrights.org/ar/expect.htm 12. Goldfarb, C. F., and P. Prescod. The XML Handbook. Upper Saddle River, NJ: Prentice Hall. 2000. 13. Hackos, J. T. and J. C. Redish. 1998. User and Task Analysis for Interface Design. New York: Wiley. 14. Hagen, P. with H. Manning and R. Souza. July 1999. Smart Personalization. Cambridge, MA: Forrester Research. 15. ---. 2001. Demand Chain Redefines Personalization and CRM. Cambridge, MA: Forrester Research. 16. Hansell, S. March 26, 2001. Marketers find new avenues on the Internet. New York Times. 17. Hartman, D. B., and K. S. Nantz. 1996. The 3 Rs of E-Mail: Risks, Rights, and Responsibilities. Menlo Park, CA: Crisp Publications. 18. Holzner, S. XML Complete. New York: McGraw Hill. 1998. 19. Hunter, D., with C. Cagle, D. Gibbons, N. Ozu, J. Pinnock, P. Spencer. Beginning XML. Birmingham, UK: Wrox. 2000. 20. Levine, R., C. Locke, D. Searles, D. Weinberger. 1999. The Cluetrain Manifesto. http://www.cluetrain.com 21. Locke, C. 2001. Gonzo Marketing: Winning through Worst Practices. Reading, MA: Perseus. 22. Manjoo, F. 2001. Spam spam spam spam spam. Wired News. http://www.wired.com/news/ebiz/0,1272,44095,00.html?tw=wn20010525 23. Martin, D., with M. Birbeck, M. Kay, B. Loesgen, J. Pinnock, S. Livingston, P. Stark, K. Williams, R. Anderson, S. Mohr, D. Baliles, B. Peal, and N. Ozu. Professional XML. Birmingham, UK: Wrox. 2000. 24. Megginson, D. Structuring XML Documents. Upper Saddle River, NJ: Prentice Hall. 1998. 25. Morrison, M., et al. XML Unleashed. Indianapolis, IN: Sams. 2000. 26. Norlin, E. February 21, 2001. Personalization Newsletter, Vol 3, No. 4. personalization@personalization.com 27. Norlin, E., and C. Locke. 2001. The Titanic Deck Chair Rearrangement Corporation (newsletter). tdcrc@topica.com 28. Peppers, D., and M. Rogers. 1993. The One-to-One Future: Building Relationships One Customer at a Time. New York: Doubleday. 29. ---. 1997. Enterprise One to One: Tools for Competing in the Interactive Age. New York: Doubleday. 30. Rotenberg, M. (ed.). 2000. The Privacy Law Sourcebook: United States Law, International Law, and Recent Developments. Washington, DC: Electronic Privacy Information Center. 31. Sterne, J. 1996. Customer Service on the Internet: Building Relationships, Increasing Loyalty, and Staying Competitive. New York: Wiley. 32. Visa. 2001. Privacy Matters. http://www.visa.com/ut/faq/privacy.html 33. White, C. March 8, 2001. Custom Fit: Personalization can greatly improve productivity and usability while providing key marketing advantages. Intelligent Enterprise, 26-31. 34. Zemke, R., and T. Connellan. 2001. e-Service: 24 Ways to Keep Your Customers when the Competition is Just a Click Away. New York: American Management Association. |
Services/Tips/Theory/WebPoems/Workshops/Books/Articles/Lisa/Jonathan
Copyright 2001 Jonathan and Lisa Price, The Communication Circle
Return to our site at http://www.theprices.com/circle
Email us at JonPrice@AOL.com