Job Notices  VIEWPOINT

INDUS
Nov-Dec  2004 


 

IMPRINT

  Home

  Dear Editors...

  About Us

  Indus Archives

TIDINGS

  STC News
  STC India Diary

  Member Profile

COLUMNS

  ESP

  Grammar Dose

 

OUTLOOK

 Presidential Gavel

 Editors' Footnote

  

CRITIQUE

  Website Review
  Book Review
 

NEWS YOU CAN USE

  Jobs

 

Technical Writers as User Experience 
Professionals

By Anupama Gummaraju

Given the keywords ‘content’, ‘technical writing’, ‘CBT’, WBT’, ‘training material’, ‘proposals’, ‘user experience’, ‘usability’, ‘labeling’, ‘user interface’, ‘communication design’, and ‘information architecture’, which ones would you, as a technical writer today, recognize as associated with your profession?

The first six, or all twelve?

While terms like content, technical writing, CBTs, training material, even white papers, and test cases are associated with the realm of “technical writing”, the technical writing community by and large sees them as independent activities that do not combine with user interface design, labeling, or usability, that suggest a complete user experience (UX) activity.

So what is user experience? A Google search would give us the most relevant and industry standard definitions, so I won’t go into that here.

ALSO IN THIS ISSUE

Theme Articles

•  Documenting for Complete User Experience

•  U, Us, Use, User...

•  Theme Summary

Other Articles

•  In Search of the Perfect Template

MarCom and the technical writer or why do people keep calling me a liar?

For a holistic understanding, it suffices to quote Nielsen Norman Group, Jakob Nielsen and Don Norman being pioneers of user experience theory and practice, “User experience" encompasses all aspects of the end-user's interaction with the company, its services, and its products. The first requirement for an exemplary user experience is to meet the exact needs of the customer, without fuss or bother.... Till give us most of the relevant and industry standard definitions, so I won’t go into that here. For a holistic understanding, it suffices to quote Nielsen Norman Group, Jakob Nielsen and Don Norman being pioneers of user experience theory and practice, “User experience" encompasses all aspects of the end-user's interaction with the company, its services, and its products. The first requirement for an exemplary user experience is to meet the exact needs of the customer, without fuss or bother.... In order to achieve high-quality user experience in a company's offerings there must be a seamless merging of the services of multiple disciplines, including engineering, marketing, graphical and industrial design, and interface design.”

Going by the above definition, is “interface design” limited to user interface design (UI design) that is commonly understood as the “first line of interface” elements like screens in a software product, touch screens on a PDA, or a video game console? In our context, it goes beyond this scope to encompass the interfaces of any material that users might come in contact with as they use a product. It could be user manuals, context-sensitive online help systems, quick reference cards, or on-screen instructions that reside along with the elements in the first line of interface. This concept is clearly illustrated by Hackos and Redish in their description of various levels of interfaces contributing to the communication of a product’s use, the first level being the interface itself and the last being classroom training. Tooltips, button help, wizards, context-sensitive help, online or print manuals fall in between. See User and Task Analysis for Interface Design (Hackos and Redish).

If there is confusion in understanding the term UI design vs. UX design, then this would help. UI design includes analyzing, planning, designing, developing, and testing the first line of interface, whereas UX design includes similar activities for all levels of user interaction and user assistance. Therefore, a combination of UI and user assistance is UX. Hence, a user experience designer must have a skill combination of user interaction theory and design principles, UI design includes analyzing, planning, designing, developing, and testing the first line of interface, UX design includes similar activities for all levels of user interaction and user assistance. Therefore, a combination of UI and user assistance is UX, and therefore a user experience designer must have a skill combination of user interaction theory and design principles as well as user assistance theory and development principles.

If, as technical writers, we work on enhancing a user’s experience with a product, through specific channels like user assistance material that users touch, see, and feel every day as they use the products, then we are user experience designers.

Peter Morville, while explaining user experience design in his column Semantics, refers to the three circles of Information Architecture. His model contains three circles of equal proportion, which in turn combine in equal proportion, to form a Venn diagram. The three components are Context, Content, and Users. For more information, see http://semanticstudios.com/publications/semantics/000029.php.

However, his new model, The User experience Honeycomb goes beyond these three aspects to cover a more comprehensive range of components that make for a holistic UX. The honeycomb addresses concepts like Useful, Desirable, Accessible, Credible, Findable, Usable, and Valuable. While he uses this model in the context of developing better Web design, it also applies as much to any form of user experience design.

Clearly, Content cannot be separated from Context or Users. Recognizing that technical communication as an essential part of the user experience is not an end, but a means to identify the journey towards it, it poses further questions:

  • Where in the user experience picture do we specifically fit in?
  • Having identified where we fit in, how do we align our activities with the goals of achieving a good user experience?
  • What processes or methodologies are available to us?
  • How do we start applying the principles of usability and user experience in our work?

The next sections of this article attempt to answer these questions, but do not necessarily provide strict guidelines to follow.

Where in the user experience picture do we specifically fit in?

We fit in where there is a requirement to communicate a product’s use to its customers.

First, we fit in where communication plays a part. In authoring content for the product’s interface ranging from, but not limited to menu names, tab names, screen titles, field labels, button labels, error messages, warnings, instructions in wizard-driven tasks, online help, printed guides, reference material, online training programs, self-help packages, and so on.

Second, as “usability” of a product and “user-centered design” gains prominence on the roadmap for companies, user assistance as we know today (help systems, manuals, etc.) will perhaps reduce in volume and be completely replaced by smart, new, user assistance material that have not yet been conceptualized. The latter will differentiate the cutting-edge products and the companies that make differentiating products.

To write for multiple deliverables or to develop the next generation of user assistance material, it is obvious that technical writers need to be aligned with the product’s designers as well as the product’s developers and perceive communication from the point of view of the “designer”.

Having identified where we fit in, how do we align our activities with the goals of achieving a good user experience; what processes or methodologies are available to us; how can we start applying the principles of usability and user experience in our work?

Does it suffice to know UX / usability principles in theory? They can be implemented in the context of a technical writer in a (software) product company by tightly integrating our communication/user experience processes with the product’s design and development processes.

Where feasible, technical writing groups today are already integrated or are trying to integrate their process into their organization’s development process. While this is a big step forward in integrating with the role players of product development, the more critical aspect of integrating with product design is beyond the reach of many. Integrating into the development process is good, but this still leaves one short of getting involved in the stage where the targeted user experience is researched, analyzed, prototyped, and documented for implementation during development.

Going further, it is not enough to integrate a technical writing process with the design and development process. The need is to integrate a UX process into the design and development process.

If you cannot achieve this on paper in your organization, achieve it in principle, in your team members’ mindset and in your daily tasks. This will enable conceptualizing, planning, executing, and measuring your communication activity based on user experience principles.

It is not enough to say that we need to start thinking ‘user experience’ or ‘usability’ in our daily writing activities. If we can identify what it is about ‘usability’ and ‘user experience’ that applies to technical communication and why, then identify methods of applying usability and UX principles to communication, we are certainly getting somewhere. Is user experience limited to usability? No. It extends to interaction design, information architecture, taxonomy, and so on. ‘Usability’, however, is a prime factor in assessing how the communication that we produce enhances our users’ experience.

What we can do

Apply UX processes, methodologies, measures, and tests, by using available industry standards. Design your own or tailor them to suit your purpose, if required. Techniques and checklists to measure the usability of documentation are available. See the STC Usability Special Interest Group’s web site (www.stcsig.org/usability/topics/docs-usability.html).

  • Include achieving better usability of documentation in your project plans.
  • Identify areas in which you can start using usability principles, like task analysis. This is essential to producing user-centric material.
  • Add Audience Analysis and User Profiling as mandatory activities in your Documentation process. Combine this activity with the software requirements gathering stage and the user interface design requirements gathering stage. If you cannot participate here, but your development and UI design teams have this information, use it; do not begin your technical documentation project without it.

Vesa Purho of the STC Usability SIG has developed a set of heuristics to evaluate documentation. His paper titled, Heuristic Inspections for Documentation – 10 Recommended Documentation Heuristics, provides valuable guidelines. This is an exciting step in this direction, and you can use these heuristics be used to measure usability of your documents. One way to use them is to derive more specific checklists from the heuristics and add company and product specific statements to be used in planning and evaluation.

Members of the Usability SIG have also published a Usability Checklist for Documentation, a Structured Heuristic Evaluation for Online Documentation (Kantner, Laurie, Shroyer, Roberta and Rosenbaum, Stephanie).

See www.stcsig.org/usability/topics/docs-usability.html.

Move from a system-centric mode to a user-centric mode

As user experience professionals, the focus must shift from a ‘system-centric’ view of approaching technical writing activity to a ‘user-centric’ one. John M. Carroll advocates communicating with a user-centric approach in The Nurnberg Funnel: Designing Minimalist Instruction for Practical Computer Skills, published in 1990. He presents an approach to documentation that is learner-centered, rather than system-centered.

Being learner-centered or user-centered in our approach to documentation is the very basic step towards achieving a better user experience. In a system-centric model, the technical writing activity might cover documenting the product, its advantages, installation and related procedures, features, modules (if any), menus, screens, dialog boxes, fields, and the like. The table of contents for such a document/document set would be based on how the product is built from a systemic or engineering point of view. As long as you have covered all the product’s features, menus, and screens, provided a search facility, and perhaps an index, the job is considered done.

In a user-centric model, the technical writing activity covers designing and building user assistance material that provides users with clear task-focused, procedural material. It asks questions like:
What tasks does a user want to accomplish using this product? What is the end result that the user expects to achieve after he uses a product feature?

A task-based or scenario-based approach to communication would take care of the essential purpose that you want to achieve through your communication. Document simple tasks by giving procedural instructions. Break down complex tasks into chunks of simpler tasks; allow users to be able to find their way out of problems or errors easily, through procedural instructions.

See this article, which is a primer on Minimalism:
http://stcmontana.org/CyberNews/Feb2004/LP_minimalist.htm.

To sum up, there is a clear need to assimilate technical communication into the realm of user experience. Pioneers in this area have already defined some guidelines, suggested some methods, and provided us with some techniques to achieve user satisfaction through design and communication. It is quite up to us to put this into practice if we want to differentiate ourselves as designers of communication.

References

NN/g: Nielsen Norman Group (www.nngroup.com)
Usability Special Interest Group, STC
www.semanticsstudios.com, Sematics (User Experience Design)
Microsoft’s Inductive User Interface Guidelines ( http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwui/html/iuiguidelines.asp)

(Anupama Gummaraju is Group Lead for Technical Communication with Infosys, Bangalore.)


STC India | Home | Contact Us

Copyright © 2003 India Chapter STC. All rights reserved.