Print all of the articles in this issue - STC SIGs

STC Usability Interface - August 2003 Page 1 of 2 

The Usability SIG Newsletter 

Usability Interface 

Usability Interface is the quarterly publication of the Usability SIG. The purpose of the 

newsletter is to provide technical communicators with up-to-date and in-depth 

information on how they can apply usability design and testing techniques to their 

products. It is mailed to all SIG members. 

August 2003 - Moving Information Online 

Publishing Chapter Newsletters on Paper or Online 

By Scott Wilson, Lanette Cornwell, and G. David Heath 

Three Chapter editors recount their transition from paper newsletter 

publication to online. 

Results of the Usability SIG Member Survey 

By David Dick 

A summary of the online survey conducted in February 2003. 

How the Usability SIG Survey Was Developed 

By Naomi Kleid 

Naomi describes how she designed the Usability SIG member 

survey. 

The Harmonics of Usability 

By Adele Sommers 

Adele describes the contributions of Thomas Gilbert, John Bowie, 

and Genichi Taguchi to software development. This article appeared 

in the August 2003 (Vol. 42, No. 7) edition of the Performance 

Improvement journal, and reappears here with permission of the 

International Society for Performance Improvement. (c) 2003. 

Attending an STC Conference on a Shoestring Budget 

By Kathy Bine 

Kathy offers suggestions for attending the 2004 conference 

Columns and SIG News 

Thoughts on Publishing Our Newsletter 

By David Dick 

A response to the online survey conducted in February 2003. 

The Search for a Well-Defined Usability Discipline 

By Karen Bachman 

A reflection on the current definitions of usability, the challenges 

http://www.stcsig.org/usability/newsletter/home-0308_pdf.html 9/23/2003

STC Usability Interface - August 2003 Page 2 of 2 

and opportunities we face as a discipline in search of a definition. 

Letter to the Editor: A response to "Crisis in the Profession" 

SIG News 

• Scott McDaniel Speaks to the Washington DC Usability SIG 

• New Jersey Usability SIG holds Summer Picnic 

SIG Home | About the SIG | SIG Activities | Resources | Topics 

Newsletter | Conference | Bookshelf | Toolkit 

Comments or questions? 

Please send your email to usewww@lists.stc.org 

© 1998-2002, Society for Technical Communication 

http://www.stcsig.org/usability/newsletter/home-0308_pdf.html 9/23/2003

Publishing Newsletters on Paper or Online - STC Usability SIG Page 1 of 4 

STC Usability SIG Newsletter 


Publishing Newsletters on Paper or Online: 

A Profile of How Three Chapter Editors Did It 

This article was originally 

printed in the August 

2003 issue (Vol 10, No. 1) 

About the Authors 

Scott Wilson is the 

Managing Editor of 

Technograph, Los Angeles 

chapter 

Lanette Cornwell is the 

Managing Editor of 

TECHcomments, 

Southeast Michigan 

chapter 

G. David Heath is the 

Managing Editor (2000– 

2003) of Carolina 

Communiqué, Carolina 

chapter 

Why We Switched from Paper to PDF 

By Scott Wilson 

In September 2002, we moved from a paper newsletter that was 

mailed to our members to an electronic version (PDF file posted on 

our web site, with an e-mail notice sent to every member whose e- 

mail address we know). 

Initially, there was some concern about electronic-only distribution. 

Some people just liked the paper copy; others wanted to know what 

the council was going to do with the money saved. 

After five issues, things settled down. We lost one advertiser, and 

we compromised with the paper-only people by printing 20 copies 

of each issue at Kinko’s (about $1 per copy for eight pages, black 

and white). I bring the 20 copies to each chapter meeting. 

As for contributors, we didn’t have many before, and we don’t have 

many now. But I don’t think the electronic delivery instead of paper 

delivery has been a factor; at least, no one has brought up that 

issue to me. 

All in all, I think the decision was a good one. We save a lot of 

money (printing and mailing costs), the newsletter is more timely 

(no 1-month lead time anymore), and it’s easier for me. I 

recommend it. 

Why We Switched from Paper to PDF 

By Lanette Cornwell 

Southeast Michigan chapter made the switch from paper to PDF 

posted on the chapter web site. In November/December 2002, we 

started talking about the switch in the newsletter and at chapter 

meetings and urging everyone to sign up for the online chapter 

discussion list. In the January/February 2003 issue, we continued 

the discussion. The March/April issue, in production now, will be 

posted to the chapter web site only, by March 1, and a postcard has 

already gone out reminding members that they won’t be getting a 

paper copy in the mail. 

We’re saving several hundred dollars per issue in printing and 

mailing costs by doing this. 

http://www.stcsig.org/usability/newsletter/0308-whyonline.html 9/23/2003


The reasons for urging discussion list membership were: (1) a 

notice will be posted to the list as soon as a new issue is posted, 

and (2) any urgent, time-sensitive notices can reach the maximum 

number of members through the list. 

We’ve had negative feedback from only a handful of members, and 

most or all of those had to do with the discussion list instructions 

we published not working for them. 

Why We Switched to a Web-Only Newsletter 

By G. David Heath, Managing Editor (2000–2003) of Carolina 

Communiqué, Carolina chapter 

We used to distribute the Carolina Communiqué by mailing a 

printed version and posting a PDF version on the chapter web site. 

Eventually, we found that budget and scheduling issues were 

making the printed version impractical, so we sat down in July 2001 

to reconsider the newsletter. What should its focus be? There was a 

lot of overlap between the information in the newsletter and on the 

chapter web site. Could we develop a more eye-catching design? To 

keep down printing costs, we maintained a plain, black-and-white 

look. If we distributed it entirely online, should the newsletter be in 

PDF or HTML format? There were a lot of issues to consider before 

making such a big move. 

Where We Were 

We had been mailing the printed newsletter because we assumed 

that not all members of the chapter had access to the Internet. We 

also felt that a printed newsletter that arrived in members’ 

mailboxes was a tangible benefit of chapter membership, unlike a 

web-based newsletter that would be available to members and nonmembers 

alike. We provided current and past PDF versions on the 

web site both as an archive and as a way to promote the benefits of 

STC membership to non-members. 

The newsletter contained a mix of informative articles and news of 

upcoming meetings and events—information that was also posted 

on the chapter web site. Because this information was timesensitive, 

it was essential to get the newsletter into members’ 

mailboxes on time, but the newsletter’s busy volunteer staff was 

having a hard time meeting the rigid schedule. In addition, the 

bimonthly schedule, introduced in 2000 to hold down printing and 

mailing costs, made it difficult to include information on meetings 

and events late in the two-month period. And there was some 

duplicated effort and cost, because we also mailed a monthly 

postcard to all members announcing upcoming meetings and 

events. 

Our most important concern, however, was that printing and 

mailing costs were a significant item in a tight budget, despite the 

simple design and the bimonthly schedule. Reducing or eliminating 



those costs would make a considerable amount of money available 

for other, much-needed member services. Michael Harvey, then 

President of the Carolina Chapter, supported the idea of an 

exclusively online newsletter because it would let us "reduce costs 

and be more creative at the same time. Going [entirely] online 

would let us publish longer, more thoughtful articles and use color 

more generously without worrying about rising printing costs." And 

the web version would be especially useful because we could link 

from the newsletter directly to references. 

Some research showed that several other professional societies 

were switching from printed newsletters to web-based ones, mainly 

for cost-containment reasons. So we knew that others had been 

successful. We decided that if we discontinued the printed 

newsletter, but included more information in the monthly postcard, 

we could provide the required news of upcoming events to members 

who had no access to the Internet (a situation that seemed 

improbable in 2001). 

We held an open meeting in August 2001 to debate the pros and 

cons of web-only delivery, and ultimately voted to eliminate the 

printed newsletter and fully explore the opportunities offered by 

web delivery in PDF format, beginning with the November- 

December 2001 issue. We rejected the HTML format because we 

were concerned that this would simply become more web site pages 

rather than a separate and distinct newsletter. 

However, an even better solution from a usability point of view, 

which I recently implemented for the newsletter that I edit for 

another professional society (the Carolina Association of Translators 

and Interpreters, CATI), involves a PDF version of the complete 

newsletter that is announced to members via an e-mail that 

includes a table of contents with links to printer-friendly HTML files 

of all the main articles. Members can read or download the 

complete PDF newsletter, and they can use the e-mail's HTML links 

to print selected articles. (For layout purposes, parts of articles are 

often continued on different pages of the newsletter.) An important 

usability advantage of the HTML links e-mail is that members can 

save printing time and paper—and because only members get this 

e-mail, it is clearly a benefit of membership in the society. 

Focus and Design 

After the chapter decided to go ahead with the web-only PDF 

newsletter, the newsletter staff took the opportunity to rethink the 

focus and design of the publication. Because information on 

upcoming meetings and events was already on the web site, we 

chose not to duplicate this information. This decision made us think 

carefully about the purpose of the newsletter. What material would 

be most useful to our members? 

We decided the newsletter should focus on thought-provoking 

articles of interest to Carolina chapter technical communication 

professionals. We wanted these articles to be the kind that 

members would want to take time reading, thinking about, and 



possibly responding to. 

The switch to web delivery meant that we no longer had to restrict 

the newsletter to black and white, and we were no longer limited to 

four pages (a folio) or a multiple of four pages. An end to the cost 

constraints imposed by printing also allowed more creative 

formatting and the use of color. 







Results of the Usability SIG Member Survey Page 1 of 2 






See related article 

How the Usability SIG 

Survey Was Developed 

Results of the Usability SIG Member Survey 

by David Dick 

The first Usability SIG survey was conducted in 1996. I thought that 

2003 was an ideal opportunity to survey our members again. Due to 

cost constraints, the survey was only available for 30 days. Of 

the1600 members, 85 responded to the survey. That might be 

considered a low response, but statistics show that a response rate 

of over 5% is considered good. 

Yes, we read every reply. The Usability SIG team reviewed the 

results and have a strategy to make improvements. 

Results of the survey are posted on . The following 

are samples of the responses received. 

What You Said You Like about the Newsletter 

Many stated that we are doing a good job, and we appreciate the 

praise. The survey provided us sufficient feedback to understand 

how we can improve quality. 

Topics You’d Like to See Published 

We received 44 different suggestions for topics that you’d like to 

see published. However, they can only be published with your help. 

If you have other ideas for topics, please contact me if you are not 

sure about what to submit and how. 

We are accepting original articles and case studies, anecdotes, 

cartoons, and book reviews on the following topics for the January 

2004 issue: 

• How to identify a bad GUI design 

• Usability testing and EPSS 

• Usability for online help 

• Case studies on applying usability techniques (and creative 

solutions to problems). 

Submission deadline is 30 November. Send your articles to 

david.dick@swift.com. 

How You Would Like to See the Newsletter Published 

The majority of responses indicated a preference for a hardcopy of 

the newsletter, some people had delivery problems (i.e. non-receipt 

of the newsletter), some people offered suggestions for electronic 

http://www.stcsig.org/usability/newsletter/0308-surveyresults.html 9/23/2003

Results of the Usability SIG Member Survey Page 2 of 2 

delivery. 

How the Web Site is Useful to You 

Many people replied that they like the archive of information, 

bookshelf, tool kit, reference material, and focus on technical 

communication. Overall, the web site is a useful learning tool for 

beginners and experienced usability advocates. 

• To look for recommended reference material—books or web 

sites about documentation/online help usability testing. 

• Toolkit contained several checklists I wanted to consider. 

• Look for resources and links to other sites. 

• To look something up mentioned on the e-list. 

• To get information about and directions to a meeting. 






http://www.stcsig.org/usability/newsletter/0308-surveyresults.html 9/23/2003

How the Usability SIG Survey Was Developed - STC Usability SIG Page 1 of 3 






About the Author 

Naomi Kleid is President 

of InfoExact, Inc., see 

www.InfoExact.com. She 

can be contacted at 

nakleid@mindspring.com. 

How the Usability SIG Survey Was Developed 

by Naomi A. Kleid 

When the leaders of the STC Usability SIG wanted to run a survey 

of its members, I volunteered to design and deploy the survey. At 

about the same time, I also volunteered to work with my local STC 

chapter to run its Employment and Salary Survey (see articles 

describing the creation of this survey and presenting some of the 

findings in the September 2003 issue of Carolina Communiqué at 

www.stc-carolina.org). Although I had extensive experience 

creating surveys and analyzing survey results, working on these two 

surveys taught me a lot about a new survey tool. 

While the Carolina chapter wanted to do an online survey, the 

Usability SIG survey did not start with that intention. We considered 

doing a mail survey by including the questions in the January issue 

of Usability Interface. However, the costs of mailing to the 

membership and having the membership mail the survey back, and 

the tasks associated with designing the survey pages and tabulating 

all the responses by hand argued against a mail survey. 

Getting Started 

As I investigated running an online survey for the Carolina chapter, 

I learned that for $19.95 per month, I could have a professional 

subscription at SurveyMonkey.com that would permit me to set up, 

run, and take down the data from both surveys concurrently. The 

results would be tabulated separately, and delivered both in HTML 

files for display purposes and in spreadsheet files for further data 

analysis. Both organizations agreed to run their surveys during the 

first quarter of 2003, so I split the three-month cost between them. 

The Usability SIG survey development followed the procedure 

outlined by Chauncey Wilson in the January 2003 issue of Usability 

Interface (see: "Methods and Guidelines to Avoid Common 

Questionnaire Bloopers"). 

To start, I asked the SIG leadership the following questions, to help 

identify the goals of running the survey: 

• What are the purposes of the survey? 

• What are your key questions? 

• What things / information would you like to know as a result 

of the survey? 

• What decisions are you grappling with? 

• What kinds of changes might you consider making after you 

get some data? 

http://www.stcsig.org/usability/newsletter/0308-howsurvey.html 9/23/2003


The purpose of our survey was to identify the audience of the 

newsletter, what they wanted for content and distribution method, 

and how the newsletter could increase SIG membership and 

satisfaction. While these answers appeared to focus on the 

newsletter, they also suggested an interest in getting feedback on 

the Usability SIG, itself, and other SIG offerings such as the web 

site, e-mail discussion group, usability sessions and SIG sessions at 

the annual conference, and possible training options. These issues 

suggested a broader scope, one that was consistent with the role of 

online surveys as defined by Dr. William MacElroy, also in the 

January 2003 issue of Usability Interface (see: "The Role of Online 

Surveys in the Usability Assessment Process"). 

At the same time, I was impressed with Charlie Kreitzberg’s 

concerns about so many usability professionals struggling to stay 

working in the usability field (see: "Crisis in the Profession" in 

Usability Interface, October 2002). I was influenced by my work 

with the Carolina Chapter survey and our effort to evaluate the 

impact of our local economic downturn on the employment situation 

for our STC members. Consequently, I wanted to include questions 

on demographics and employment status for Usability SIG 

members. 

The survey grew to cover five topics (below), and offered 

respondents the opportunity to skip over questions or sets of 

questions if they wanted: 

• SIG (satisfaction and member requirements), 

• Newsletter (satisfaction and requirements), 

• Web site (satisfaction and requirements), 

• Comparisons / rankings for the SIG’s offerings, 

• Member information (demographics and employment status). 

An early draft of the survey consisted of 53 questions mostly 

requiring answers in multiple-choice or numerical formats. In the 

end, the survey was edited to 20 questions with no branches. 

A number of trade-offs made this questionnaire simplification 

possible. In each case, the decision opted for letting SIG members 

express their wishes as fully and completely as possible. For 

example, one trade-off was to accept an increase in analysis time 

(required to work through the write-in responses) in order to save 

respondent time (required to work through all the detailed 

questions and response options). By decreasing the time required 

from each respondent, we hoped to increase the response rate and, 

consequently, get thoughtful feedback from more SIG members. 

Another trade-off was to accept a wide variety of write-in responses 

to each question (again requiring more analysis time) in order to 

get a full range of possible answers, rather than to quantify 

responses to a limited set of largely predefined answers. 

Using SurveyMonkey 



I took out a one-month professional subscription to SurveyMonkey 

using the online form at their Web site. Within minutes my account 

was automatically activated, and I started entering both surveys. 

Although I had never entered an online survey before, I entered all 

the questions for both the Usability SIG survey and the Carolina 

chapter survey in one day—that amounted to 20 questions for the 

Usability survey and 64 questions with several branches for the 

Carolina survey in just a few hours. 

Had either survey been 10 questions long or less and had we 

expected no more than 100 responses per survey, I could have 

taken a basic subscription with SurveyMonkey and run the surveys 

at no cost. The basic subscription does not offer some advanced 

features, such as requiring an answer to a question before 

respondents can proceed to the next question, branching over 

groups of questions that are inappropriate to a specific respondent, 

filtering sets of responses based on specific questions (to aid in the 

analysis of results), and managing the appearance of the survey by 

including an identifying logo or customizing the colors of the survey. 

For readers interested in trying an online survey, I recommend 

going to www.SurveyMonkey.com and creating a free survey. 

When the Usability SIG survey was online, we conducted a usability 

test of members of the Usability SIG team to evaluate the question 

and answer formats, usability of the survey, and length of time it 

took them to complete the survey. We fine-tuned the welcome and 

some of questions. When the survey was ready for distribution, I 

clicked on the SurveyMonkey Collect function icon. SurveyMonkey 

created an HTML link giving a unique hyperlink location to announce 

the survey and direct respondents to it. My job was almost done; all 

I had to do was take the data files down at the end of the survey 

and send the files to the Usability SIG leadership team for analysis. 

The responses are presented in Results of the STC Usability SIG 

Membership Survey. 

Disclaimer Neither STC or the Usability SIG endorse any survey 

service. 







The Harmonics of Usability: 

A Trio of Implications for 

Software Interface Design 

by Adele Sommers 

In the world of usability, Thomas Gilbert, human performance engineer; John 

Bowie, information engineer; and Genichi Taguchi, quality engineer, are singing a 

three-part harmony. Exemplifying different generations as well as three distinct 

but overlapping domains, these experts converge at a vantage point from which 

they should be jointly capable of conducting the whole orchestra. This article explains 

the contributions each individual has made, directly or indirectly, to the domain of software 

development. 

While distilling the philosophies of these three experts, the article illustrates how the 

advice from each individual applies to user interface design and ultimately presents some 

recommendations for transforming our processes. For example, our experts address a 

number of the underlying whys that we may not have fully explored, may have taken for 

granted, or may not have associated with routine customer experiences with software. 

Viewing interface design through this unique lens can help the entire software development 

team—and technical communicators in particular—focus on priorities and goals for 

improving customer experiences and enhancing business results in the workplace. 

Gilbert’s Libretto 

As a pioneer in the field of human performance, Thomas Gilbert demonstrated throughout 

his distinguished career that modifying human beings to suit their environments 

poses a much greater system investment than adapting the environment to suit the people. 

In other words, in the big scheme of things, designing and fine-tuning both tools 

and working conditions entails far less effort than asking people to learn new skills. 

As Gilbert observed in his masterwork, Human Competence: Engineering Worthy 

Performance, training is one approach that can help people become more proficient 

with tools; however, the expense and inefficiency of training will likely outweigh 

the costs of simplifying the tools. In a discussion of several factors Gilbert 

34 www.ispi.org • AUGUST 2003

Figure 1. Our Three Master Conductors. 

believes are capable of enhancing individual performance, 

he comments— 

Finally—though not least in importance—look at 

training as a means to achieve greater competence. It 

is often a powerful strategy, but usually very expensive. 

It is well to make sure that we don’t end up 

training people to use tools that could be redesigned, 

or to memorize data they don’t need to remember, or 

to perform to standards they are already capable of 

meeting and would meet if they knew what these 

standards are (1996, p. 91). 

One explanation for the cost phenomenon may be that 

learning entails a highly transient and ephemeral process. 

Per Gilbert, one must set conditions for learning using a 

methodical training design, a realistic practice strategy that 

may involve performance aids such as checklists and quick 

reference guides, and ongoing feedback and reinforcement 

within the performing environment. The effort required is 

not trivial, and the results are not guaranteed without the 

use of mutually reinforcing methods. 

Gilbert notes that the complexity within the environment 

determines much of our need for training. He contends that 

if the potential for improving performance “is still large 

after we have tried manipulating the environmental variables, 

we can conclude that we really do have a knowledge 

problem, and that perhaps improvement in training will be 

worth it” (1996, p. 91). Yet if one takes into account the 

speed with which training information deteriorates in 

human memory and considers the intellectual drain due to 

attrition that persists in today’s transitory workplaces, one 

can see the shortcomings of training as a hit-or-miss, onesize-fits-all 

solution for performance gaps. 

If we agree with Gilbert’s assertions that training is a costly 

and time-intensive method of improving performance, and 

that simplifying the environment can reduce the need for 

training, we would do well to follow his recommendations 

to focus on environmental variables first. He observed that 

once such variables are optimized, people are capable of 

performing with fewer, if any, training requirements. 

As a case in point, imagine designing a minimal maintenance 

vehicle with the fewest possible features, and only 

features that are labeled, shaped, grouped, and positioned 

in an optimal way. In such a vehicle, we 

can expect new drivers to have far earlier, 

easier, and safer driving experiences 

than in a vehicle with many 

complex, enigmatic gadgets. If drivers 

need extensive training in how to use 

the controls, and also must perform a 

series of maintenance tasks before taking 

to the road, they will need many 

more hours of preparation before 

becoming competent performers. 

A software interface also represents a set of environmental 

variables that, if properly designed, can carry us on a productive, 

carefully planned journey from the moment we 

turn on the ignition. We can thus apply Gilbert’s philosophy 

to the design of software interfaces that will enable customers 

to become competent and efficient performers without 

extensive training and preparation. 

To summarize: Achieving user competence through a means 

other than training will be well worth the effort spent to 

develop the alternatives. By exhausting all opportunities to 

optimize environmental variables before forcing people to 

extend their knowledge repertories, you will save time and 

money, and may substantially boost morale! 

Bowie’s Aria 

From the standpoint of information management, in his 

excellent 1996 treatise, Information Engineering: Using 

Information to Drive Design, John Bowie insists that the singular 

goal of software should be to help people do their primary 

jobs. Primary jobs consist of the functions people were 

performing, or trying to perform, before turning to the software 

for assistance. He refers to these functions as Job 1. 

By enabling people to perform Job 1 efficiently and effectively, 

software can help us achieve something faster, better, 

or cheaper than we can otherwise accomplish it on our own. 

Beyond enhancing our success with Job 1, all else that software 

requires of us is what Bowie labels Job 2. This is new 

work created by the software itself, and usually entails 

installing, setting up, configuring, learning, troubleshooting, 

and maintaining the system. By definition, anything 

related to Job 2 represents a waste, as it distracts us from 

accomplishing our Job 1 mission. 

In his observations about system design, Bowie touches on 

a commonsense explanation of what system engineers 

already know. When you contemplate the full spectrum of 

functions required to operate a system, for example, one that 

involves hardware, software, and people, you must decide 

which functions will be performed by each aspect of the system. 

You must determine which operations the hardware 

will perform, which operations the software will perform, 

Performance Improvement • Volume 42 • Number 7 35

Glossary 

Best practices: A set of exemplary methods, variously 

defined as continuously improving processes, activities, and 

programs in keeping with the best evidence about what 

works in a particular context, and practices that lead to 

superior performance 

Computer-based training: An all-encompassing term used 

to describe any computer-delivered training, including CD- 

ROM and web based 

Context-sensitive help: A software feature that offers 

assistance related to the specific program, command, or dialog 

box that is currently open 

Decision support: A type of user assistance that helps to 

identify the action that is appropriate for a particular set of 

conditions 

Domain knowledge: Knowledge required to carry out typical 

responsibilities in a particular field, such as accounting, 

forestry, or nursing 

Embedded assistance: User assistance embodied 

directly within the software user interface rather than in a 

separate application that floats above or behind a software 

application 

Online help: User assistance provided in a program or application 

that is typically accessed in a separate section of that 

application 

Scenarios: A narrative or story that describes the activities of 

one or more persons, and includes information about goals, 

expectations, actions, and reactions 

Tool tips: A method for embedding small snippets of information 

into a user interface. A tool tip usually displays an 

object’s name or function whenever the user’s pointer rests 

over that object on the screen. 

Tutorial: A program that provides instruction for the use of a 

system or of software 

Usability: The ease, speed, and pleasantness with which 

intended people can use a product 

Use cases: A set of scenarios that are tied together by a 

common user goal. A use case specifies all possible interactions 

between the user and the system with respect to those 

scenarios. 

User interface: Physical representations and procedures, 

integral to a software system, that enable users to view and 

interact with the system functionality 

and which tasks will be relegated to people. In an ideal 

world, such a process should aim continuously to reduce or 

eliminate the cognitive burden on humans. Too often, however, 

a lazy system design process hands the system users a 

disproportionate share of Job 2 tasks that could have been 

elegantly incorporated elsewhere. 

Early Rehearsals 

To emphasize this point more dramatically, consider that in 

the inaugural days of computing, people with expert knowledge 

painstakingly performed the functions that today’s 

computers make completely transparent. Early logic circuits 

required humans to prod their actions with highly detailed 

instructions that itemized every register accumulation and 

task to perform. The programming effort was enormous and 

the requisite skill level correspondingly high. In effect, no 

distinction existed between the programmers and people 

using the system; they essentially were one and the same. 

Over time, with the increasing sophistication of hardware 

and software, the burden of knowledge and responsibility 

began to shift from people to computers. This trend has 

since enabled vast segments of our population to successfully 

have computers perform myriad useful tasks. 

Compared to earlier times when computer interaction 

required expert knowledge of electronics and logic systems, 

today’s computer users face comparatively few obstacles. In 

any given domain, knowledge held by a few experts can be 

translated into system information, making it possible for 

people with far less expertise to exploit that wisdom once it 

is embodied in hardware, software, and other components. 

Waiting for the Curtain to Rise 

By extension, our current technological trends should be 

leading us toward systems that involve a diminishing 

requirement for human learning. In the ultimate state of 

software design, Bowie predicts Job 2 will become all but 

invisible (1996). Software should transparently install, configure, 

troubleshoot, and maintain itself with little or no 

input from users, as well as intelligently provide us with Job 

1 knowledge on a just-in-time basis. 

In practice, however, we can observe that software design as 

a whole has not matured sufficiently to free us from the distraction 

of Job 2 tasks, much less render software use transparent. 

By withholding the effort required to eliminate Job 

2, software developers conspire with our traditional expectations, 

helping us remain mired in our resignation regarding 


the current state of affairs. Whether we are working with 

behemoth enterprise resource planning systems or small 

software utilities, our collective mindset seems to dictate 

that software systems follow familiar patterns. 

Economic Cacophony 

From a purely business standpoint, even a cursory examination 

will reveal that every minute a person spends 

wrestling with a Job 2 task is a minute not spent doing Job 

1. No software user can generate a profit from Job 2 activities; 

it is a losing proposition for any customer. Those who 

are capable of benefiting financially are software vendors, 

unless customer dissatisfaction with Job 2 becomes so great 

that it begins to destroy sales. Others who may benefit monetarily 

are the intermediaries paid to reallocate the information 

imbalance. The latter are people or organizations 

whose jobs entail reducing the delta between customer 

knowledge and information or functions missing from the 

software interface. 

For example, technical communicators routinely receive 

assignments to bridge the conceptual gaps in poorly 

designed systems via cognitive bandages offered in manuals, 

online help, and tutorials. Similarly, telephone support 

centers sustain customers through all sorts of questions and 

problems, many of which can stem from inadequate features 

or system bugs. Perhaps largely out of necessity, the training 

industry further remedies the weaknesses of software by 

designing courses to offset missing information and by 

teaching people how to work around system idiosyncrasies. 

Octaves of Distraction 

Each new interface a person encounters poses a new information 

imbalance, regardless of how much expertise or 

experience that person may have. Given that relatively few 

interfaces are completely self-explanatory, some sort of 

Figure 2. A Spectrum of User Assistance Options. 

assistance is in order. Figure 2 suggests a spectrum of user 

assistance and task support, with some methods resulting in 

greater efficiency and less distraction to performers than 

other methods. 

Figure 2 illustrates that the least distracting methods are 

also the most efficient for performers. The left-side options 

exact far fewer interruptions than those on the right. The 

key lies in their proximity of use and degree of integration 

with the task at hand. Better support takes the form of information 

and devices that are highly relevant and accessible 

within the interface, such as tool tips, context-sensitive 

help, embedded assistance, decision-support tools, and justin-time 

domain knowledge. Less ideal support, even if relevant 

to the task, is that which requires more steps and shifts 

of attention to access. Examples include the information 

found in user manuals, online help, computer-based training, 

tutorials, and any form of classroom training. 

Offsite software training, shown on the far right in Figure 2, 

demands the most substantial departure from our Job 1 

focus. In the worst scenarios, such training both disrupts 

our schedules and fails to advance our primary domain 

knowledge. Whereas employee development symbolizes a 

valuable investment in human resources under the right circumstances, 

the concern with any learning process is 

whether we are having to learn Job 2 skills at the expense of 

Job 1, and whether the process itself detracts from our key 

priorities. If so, our adaptation in terms of time, effort, attention, 

logistics, and ripple effects becomes very expensive. 

Taguchi’s Tune 

Speaking of ripple effects, enter Genichi Taguchi, whose 

philosophy on the economics of reducing variation introduced 

a model now known as the Taguchi loss function. 

This function helps identify the nominal, or ideal, quality 

level that a manufacturer or service provider must maintain 

to prevent or minimize economic losses to 

individuals and society. The mechanics of 

the model are most powerfully summarized 

in simple language: The farther 

product or service performance strays 

from perfection (where the producer’s and 

customers’ needs are balanced), the 

greater the negative impact on society. 

As revealed by Phillip Ross in Taguchi 

Techniques for Quality Engineering 

(1996), Taguchi’s brilliance emerged in his 

ability to demonstrate how imperfect performance 

in products and services can 

affect society at large. This situation 

occurs whenever the ensuing consequences 

and damages exceed the net 

losses to individual consumers. 


The effects may be partly measurable in terms of cost, which 

is where Taguchi’s model becomes valuable. Beyond the 

costs to remedy an individual product or service defect, ripple 

effects can incur indirect losses to society through product 

or service breakdowns, delays, or other operational 

problems. Losses might manifest as anything from missed 

opportunities and inconveniences to large-scale disasters. 

According to Ross, 

If someone steals $10, the net loss to society is zero; 

someone has a $10 loss and the thief has a $10 gain. 

If, however, the producer causes an additional loss 

to society, everyone in society has suffered some 

loss. A producer who saves less money than a customer 

spends on repairs has done something worse 

than stealing from the customer (1996, p. 7). 

All too often, the ripple effects of less-than-perfect performance 

have subtle and far-reaching implications, and can 

involve domino effects of incalculable magnitude. 

Although Taguchi’s work focused on products other than 

software, the ripple effects he exposed are equally plausible 

with software systems. Imagine the following scenario: 

You are the plant controller for the Acme Widget Company. 

You are planning to install and set up a business-critical 

productivity system over the weekend, per the vendor’s 

standard procedure. The vendor has assured you that by following 

the instructions and prompts, you will have a simple 

and error-free installation. 

Time is of the essence because your company’s fiscal year 

will end in 10 days. At that time, all support for your current 

productivity system will cease because you are planning to 

discontinue the annual service agreement with the existing 

vendor. Instead, you intend to make a clean switch to the 

new system with the start of the new fiscal year. Further, all 

plant attention will be shifting to year-end closing and reconciliation 

activities as the fiscal year transition approaches. 

If anything goes wrong with this installation, there will be no 

opportunity to attempt re-installation for another two 

months, and you will have missed a time-, cost-, and schedule-critical 

deadline for replacing the old system. 

You start the installation procedure at 5:00 Friday evening 

using the standard installation instructions. After two days 

of work, by 10:30 Sunday night you encounter missing 

instructions, several installation errors for which there are 

no explanations or off-hours technical support, and an 

unidentified set of historical data that was accidentally 

overwritten. Working late at night with incomplete information 

and under great pressure to complete this job, you are 

left with a gut-wrenching decision: 

Option 1: Give up—Undo everything you have just done by 

reloading Friday night’s system backup, at which point you 

would consider the whole weekend a waste of time. Risk of 

loss: Most of your weekend, the time you will ultimately 

spend talking with technical support, and time you will 

need to try reinstalling the system two months from now. 

You also may face an unforeseeable set of problems once 

your current system support ceases in 10 days, and a number 

of disadvantages and setbacks from being unable to start 

the fiscal year on the new system. These costs cannot yet be 

quantified but will be substantial. 

Option 2: Hedge—Wait until 8:00 Monday morning to contact 

technical support in hopes of salvaging the current 

installation. Risk of loss: Most of your weekend, plus you 

will have production downtime while finishing the installation—if 

you are lucky. If you are unlucky, you must proceed 

as explained in Option 1. 

Option 3: Gamble—Forge ahead until 7:00 Monday morning, 

hoping that through trial and error, you will figure out and 

solve the problems before the production staff arrives. Risk 

of loss: All of your weekend, plus the production downtime 

if it appears you cannot resolve the problems and will need 

to contact technical support at 8:00 a.m. Even if you think 

your gamble has paid off in that you are able to fix all obvious 

problems, the following pitfalls are still possible: 

• System corruption may occur if you resolve the apparent 

issues and assume everything is okay when it is not. 

Once you finally detect the corruption, you will need to 

contact technical support to discuss and fix the source 

of the problem, possibly with the help of a paid consultant 

and certainly with more downtime. 

• In one worst case scenario, the system corruption begins 

to introduce subtle errors in areas such as billing that no 

one can detect for several weeks. After the symptoms surface, 

the correction procedure will require that you reload 

the last good system backup from the Friday before your 

weekend installation. Several of your office staff will be 

paid overtime for a time to recreate hundreds or even 

thousands of transactions from hard-copy records. 

• Your company may need to smooth out billing errors 

with customers. Your staff will have a hard time explaining 

to customers any invoices that show they have been 

undercharged for products for which they actually owe 

more. In fact, several new customers do become irate 

about this and stop doing business with you. Of course, 

they will not be referring any new sales your way. 

• Your outside network management company will be 

billing you many extra hours to work alongside the paid 

consultant to rectify the series of snafus. Ultimately, 

Acme Widget will require three months to fully recover. 

The get-well effort will cost tens of thousands of dollars, 

not including lost business. Ironically, the software 

itself was relatively inexpensive; you paid less than 

$4,000 for eight licenses. Note that the manufacturer 

explicitly avoids liability for any of these problems in 

your software license agreement. 


From the above example, it is not difficult to see that a 

poorly designed or unusable software interface can cause 

missed project deadlines, lost sales, an exodus of existing 

customers, an inability to acquire new customers, excessive 

overtime, lost revenue, fees for troubleshooting experts or 

consultants, catastrophic accidents, mission failure, or even 

financial ruin. Software licensed at bargain-basement prices 

cannot begin to compensate for the overt or hidden costs 

levied by these consequences. Such possibilities are the stuff 

of nightmares, and definitely tend to grab one’s attention! 

In contrast, elegant user interface design automates installation, 

setup, and other time-consuming and error-prone tasks 

while making verifications mistake-proof and easy to perform. 

Our professional goal should be to create interfaces 

that reduce or eliminate all possible Job 2 distractions and 

hazards with their annoying to disabling ripple effects. By 

researching the range of conditions under which our customers 

will be using our products, we can focus on accommodating 

nonoptimal circumstances that lead to 

unsatisfactory outcomes. Working under tight deadlines, in 

off-hours situations, and in remote locations—these are just 

a few of our customers’ scenarios. 

The Final Score 

As we move into the grand finale, we realize that our three 

master conductors have succeeded in composing a compelling 

and engaging arrangement with unforgettable lyrics. 

But will the intended audiences pay to attend opening 

night? Software usability, or a lack thereof, involves sufficient 

economic and social ramifications to make it worth 

spending more than the price of an opera ticket. Yet aside 

from the few progressive companies moving toward interface 

transparency, many seem content with the status quo. 

Combining a vigilant Job 1-Job 2 perspective with performance-centered 

design principles can offer a powerful formula 

for transforming customer experiences with software. 

According to Gloria Gery in her timeless article “Attributes 

and Behaviors of Performance-Centered Systems” (1995), a 

few of the many notable characteristics of performance-centered 

systems include the following: 

• Helping the performer establish goals 

• Embedding knowledge into the interface 

• Reflecting a best practice approach to completing a job 

or task 

• Providing options, next steps, and resources 

• Automating the tasks required to accomplish the goals 

• Observing, advising, and providing contextual feedback 

to the performer 

• Providing alternative views of the interface, resources, 

or both 

Whereas even this subset of Gery’s prescription may seem 

like a tall order for the average software design project, the 

development team may elect to incorporate elements of the list 

in an incremental fashion. A large part of the challenge resides 

in how to think about what the performers need to know to carry 

out their Job 1 functions. Significant preparation that entails 

rethinking and gradually making improvements to existing 

user documentation, online help, and training may be one way 

to conceptualize a stellar interface redesign at a later date. 

Recommendations for Transforming Our 

Approach to Interface Design 

Technical communicators, software developers, and performance 

specialists may now be asking what they can do to 

begin making a difference in their environment. Following 

are four suggestions for influencing your own situation, from 

progressively revising information to participating extensively 

in a new product design. Note that the first three recommendations 

are subsets of the fourth recommendation. 

1. Rework the Current Emphasis Toward Job 1 

Analyze the ratio of Job 1 to Job 2 material in your existing 

user information. That is, compare how much information in 

the system guides the performer in carrying out real tasks and 

responsibilities in a particular field (Job 1) with how much 

tells the performer how to install, set up, configure, learn, 

troubleshoot, and maintain the software itself (Job 2). If the 

information ratio heavily favors Job 2 over Job 1, you may 

have considerable room for improvement. The improvement 

might occur in at least two ways: by increasing Job 1 support, 

perhaps by adding more domain knowledge and task guidance; 

and by reducing the need for Job 2 support, such as by 

redesigning the interface to minimize or eliminate Job 2 tasks. 

Even if the system interface design cannot be modified, consider 

what you can do to refocus on Job 1 in the area of task 

information. The process may involve entirely rethinking 

the information content, such as in the user documentation, 

and coming at it from a very different angle. For example, if 

the user guides concentrate mainly on functional operations 

such as how to use menus, buttons, and fields, you might 

consider redesigning the user guides to focus on those operations 

in the context of Job 1 roles and responsibilities. 

Example. Imagine a system that was designed to collect data 

from social service agencies about the community support 

services they provide. The system aggregates data from all 

sources and reports nationwide statistics on the types of services 

rendered and the populations served. A simplistic 

approach to designing such a system would be to mold the 

interface around functional operations that people perform 

to get data into and out of the system. 

In this system, the functional operations are the focus of all 

input activity. To enter information, users must research 

descriptive codes that identify the types of services they 


have provided, correctly enter data into fields, and check for 

data entry errors. Performers typically depend on a combination 

of classroom training, computer-based training, 

online help, and user documentation for guidance on the 

following: how and where to look up system codes, which 

codes are compatible with other codes and for what services, 

and how to tell when a record is complete. This represents 

quite a lot of Job 2 activity, much of which can be 

distracting from the task at hand. Also absent from the system’s 

current design are contextual aids that would help 

performers more directly relate the data entry tasks and 

codes to their primary roles and responsibilities. In other 

words, the current system lacks Job 1 support. 

This example illustrates a system with a high ratio of Job 2 

to Job 1 emphasis. How can the situation be remedied, especially 

if a complete system redesign does not appear on the 

near-term agenda? 

A complicating factor in this example is the fact that the system 

has been in use for several years. During that time, 

many social service agencies have painstakingly crafted 

adaptations to the existing interface and have incorporated 

them into job aids and training programs. Unfortunately, a 

major interface change could actually be disruptive, as these 

groups have invested so much effort into customization. As 

counterintuitive as it may seem, improvements to support 

information might suit this particular situation better than a 

plan to completely redesign the interface. The new 

approach can employ a strong Job 1 orientation as part of the 

process of explaining Job 2 in user guides, animated 

overviews, training aids, and the like. 

Suggestions. Regardless of whether your situation resembles 

the one above or your software interface is due for a major 

overhaul, you can apply the ideas below to rework your user 

documentation, online help, overviews, training, interface, 

or a combination. You can embed new benefits by incorporating 

best practice guidance into the material and helping 

performers develop solid mental models of the system, 

focusing on Job 1 activity. Each suggestion will harness 

more power if you apply it in a consistent, unifying way 

across the system’s components. 

a. Create case studies, storytellers, or advisors based on 

personas. Personas comprise a blend of the core characteristics 

of certain individuals in the expected audiences. 

For example, one or more personas might reflect 

the composite traits of novice performers; others might 

reflect more sophisticated performers. Each persona can 

convey authentic Job 1 activities to which similar performers 

can relate. 

In the social service data collection system example, 

an information redesign exercise introduced a Job 1 case 

study into the user guides. The persona in the case 

study represents users with minimal computer skills 

who are experienced in community advocacy, fairly 

typical of many service providers. The case study illustrates 

realistic, job-related circumstances that help supply 

a richer context for data-entry tasks. For example, 

various vignettes describe meetings that our character 

held with community agencies, services she provided to 

local youth, and materials she disseminated at various 

events. Each story ends with specific examples of how 

she entered the information into the system. 

b. Provide overviews, advance organizers, and sequencing 

aids to explain the rationale, concepts, processes, procedures, 

and flow for each section. These tools enable 

performers to discover how the work relates to their primary 

roles and responsibilities, and to estimate the 

time, complexity, and commitment required to perform 

each task in the context of the big picture. Examples: 

• Use diagrammatic overviews to denote how information 

feeds into and comes out of each stage of a 

process or procedure. 

• Show sample outputs from each activity, such as a 

completed plan, form, or report, to help performers 

envision at the outset what they will be producing. 

• Provide an optional Overview or Why Do This? button 

or link that displays a printed (or printable) 

rationale, description, diagram, or checklist. 

• Use sequencing aids, such as You are at Step X of Y, 

at the outset of each procedure or task to depict the 

user’s progress through the system. 

c. Incorporate terminology support and additional information 

in the form of a glossary, examples, and links or 

references to resources. The more closely these can integrate 

with the task at hand, the less distracting a user’s 

research will be. 

2. Relocate Existing Information 

If a product update is in the works, assess ways to repackage 

the most relevant user information into the more efficient userassistance 

options. You might combine this effort with reworking 

the content to emphasize Job 1 support. Evaluate ways to 

minimize the number and magnitude of attention shifts 

required to access the information, as Figure 2 suggests. Engage 

with the development team to reformat and relocate information 

into the least distracting and most highly usable forms. 

3. Write Specifications 

If plans exist for an all-new or redesigned system, opportunities 

will soon emerge for contributing to the interface 

design. Get ready! As a technical communicator, you possess 

solid qualifications to help develop and influence crucial 

specifications in concert with the rest of the design 

team. Specifications that you might prepare or contribute to 

include, but are not limited to, the following: 

• Analyses of the performing audiences (the anticipated 

customers or users of the software), including their 

needs, goals, tasks, and circumstances of use 


• Feasibility studies, business analyses, and requirements 

analyses, using well-defined, structured methods such 

as those described by Pardee (1996). 

• Nomenclature and database design, including a rigorous 

data dictionary of all terms and labels to be used in 

the database and throughout the interface. Unlike 

downstream derivatives like glossaries, the data dictionaries 

should surface at the start of the design process 

and dictate precise, unambiguous identifications for all 

system elements. Such tools thereby instill rigor and 

consistency across the entire product, preventing the 

usability problems that would otherwise arise when 

multiple identities exist for the same function, value, 

field, and so forth. 

• System design documents, including functional 

overviews and use cases. Use cases, for example, describe 

scenarios of intended interactions between the customers 

and the system. Essential to the design process, use cases 

evolve directly into test cases, which spell out the corresponding 

scenarios that should be tested in the system. 

For more information, see Cockburn (2000). 

• Interface design documents, including storyboards, 

interface and information (embedded assistance) specifications, 

and interface prototypes. 

• Test specifications, including usability and system test 

plans and procedures. System test specifications, for 

example, typically describe the setup required, the 

types and sequences of test cases to be used, descriptions 

of the tests, the data to be run through the tests, 

and the expected results. 

4. Participate Fully in the Interface Design Process 

With a new system you can take a lead role in the following 

activities, which involve all major aspects of the first three 

recommendations: 

• Conduct user, task, and process analyses to gain a thorough 

understanding of your intended audiences’ Job 1 

roles, activities, and terminology. Encapsulate these 

into best practice models whenever possible, and reflect 

the best practices in all specifications. 

• Promote the integration of Job 1 best practices into the 

interface. Squeeze as much relevant information as possible 

out of what would otherwise become user manuals, 

tutorials, online help, computer-based training, or 

classroom training and into the interface in the form of 

Job 1 task flows, best practice guidance, explanations, 

definitions, simulation tools, and resources. Contribute 

to and critique the interface designs. 

• Lobby to eliminate all possible Job 2 distractions from 

the product. 

• Conduct or participate in design reviews and usability 

tests. 

Example. The year 2005 marks the anticipated release date 

of your company’s newest productivity software package. 

All wheels are in motion to produce a vastly improved and 

completely redesigned system that hardly resembles your 

company’s existing product. 

The existing product line depends heavily on third-party 

consultants and technical support to explain its many complexities. 

The system documentation is voluminous and 

function driven, making it difficult to follow. A major impetus 

for redesigning the system has been the lack of referrals 

and repeat business from existing customers. Many customers 

have spent considerable dollars on consulting assistance 

to set up their systems, and have since found the 

archaic interface laborious to use. 

In contrast, the new product will advance an entirely different 

approach to system information and functionality, as 

follows: 

• Job 2—Every conceivable type of Job 2 task will be automated, 

removed, or redesigned in the new system. Your 

team had conducted a lengthy Job 2 hunt during the 

requirements analysis phase and diligently categorized 

each finding. By combing user group bulletin boards 

and archives, technical support call logs, and survey 

results, the team was able to pinpoint dozens of annoyances, 

which they grouped, analyzed, and converted 

into system requirements. The resulting reductions in 

installation, setup, configuration, and troubleshooting 

requirements will exemplify a state-of-the-art model 

once the new system is released. 

• Job 1—Much of the information users need to know 

will be incorporated into the system’s interface via 

embedded procedures, task guides, and carefully 

designed overviews, checklists, and simulation tools. 

Many tasks will be automated based on user selections 

and preferences. Information will be closely integrated 

with the tasks at hand, and will help performers identify 

which aspects of their primary roles and responsibilities 

the procedures represent. Tutorials and user 

documentation related to Job 1 activity will not be eliminated 

but included as a supplemental set of information. 

For example, the printed (or printable) portions of 

the user guidance will provide portable information for 

customer planning purposes, group discussion, and 

evaluating specialized scenarios. 

You have already spent two years carefully researching the 

needs of your current and anticipated customers. After completing 

a series of interviews with and surveys of the customers 

of your existing product line, you and your team have 

derived a solid set of requirements around which to design 

the new interface. All this time you have been diligently 

helping to develop specifications. Among the specifications 

to which you have contributed to are: needs, goal, and task 

analyses; use cases; a data dictionary of all terms and labels 

to be used in the database and throughout the interface; 

functional overviews; and various requirements documents. 


Next, you will be working with the development team on 

preparing or finalizing the interface, information, and system 

design specifications; storyboards; interface prototypes; 

usability and system test plans; and test procedures. 

Additionally, you will help conduct usability testing of the 

earliest interface design prototypes. 

From this point forward, the schedule calls for a year of 

development, then a year or more of beta and usability testing, 

iterative refinements, and phased, modular releases. 

With so much effort, much depends on accurately researching 

the Job 1 requirements of the anticipated customers. The 

resulting product must ensure fast, competent performance 

with little or no training and must levy the fewest possible 

Job 2 demands, to earn customer allegiance and industry 

accolades! 

The Audience Response 

By steadfastly focusing on these suggestions and the worthy 

advice of our three master conductors, we can fast forward 

The answer is, YES! 

to the final bows. As the momentum builds to expose our 

achievements, the suspense melts into long-awaited gratification. 

Our audiences, who for years have kept silent or 

have offered our productions only mixed reviews, now fully 

reward our efforts with thunderous applause and sold-out 

performances! 

References 

Bowie, J. (1996). Information engineering: Using information 

to drive design. Intercom, 43(5). 

Cockburn, A. (2000). Writing effective use cases. New York: 

Addison-Wesley. 

Gery, G. (1995). Attributes and behaviors of performancecentered 

systems. Performance Improvement Quarterly, 

8(1), 47–93. 

Gilbert, T.F. (1996). Human competence: Engineering worthy 

performance (tribute edition). Silver Spring, MD: 

International Society for Performance Improvement. 

Pardee, W.J. (1996). To satisfy and delight your customer: 

How to manage for customer value. New York: Dorset House. 

Ross, P.J. (1996). Taguchi techniques for quality engineering: 

Loss function, orthogonal experiments, parameter and 

tolerance design (2nd ed.). New York: McGraw Hill. 

Are you in the business of improving human performance? 

Do you want to receive cutting-edge research and information? 

Should you sign up for a subscription to 

Performance Improvement Quarterly? 

Discounted rates available to ISPI members. 

Call today 301.587.8570 to start your subscription to PIQ. 

Adele Sommers, PhD, is a performance generalist and a specialist in the field 

of technical communication. She has spent the last two decades studying and 

applying process improvements in a variety of organizations, from small software 

firms to large aerospace companies. She currently helps organizations 

implement performance improvement objectives in the areas of information 

design, usability, instruction, and performance support. Her professional experience 

also includes software project leadership, systems analysis, and process 

management. 

A strong proponent of variability prevention and reduction in products and 

services, Adele seeks to apply these principles in a variety of ways. Her interest 

in usability, for example, stems from observations that the commercial software 

industry is beginning to adopt performance improvement principles in the interface 

design arena, but as a whole has not attained the exemplary standards for 

performance-centered systems. Because software usability affects many 

aspects of business success, its importance cannot be overemphasized. 

Adele received her doctorate in Education with an emphasis in 

Performance Technology from the University of Santa Barbara, and her master’s 

in Management from University of Redlands. She is the 2002–2003 president 

of the San Luis Obispo, California, Chapter of the Society for Technical 

Communication. Adele may be reached at adelesommers@earthlink.net. 


Attending an STC Conference on a Shoestring Budget Page 1 of 3 




printed in the August 2003 

issue (Vol 10, No. 1) 

About the Author 

Kathy Bine 

(kbine@icfconsulting.com) 

documents software 

solutions for ICF 

Consulting in Fairfax, 

Virginia. 

Attending an STC Conference on a Shoestring Budget 

by Kathy Bine, Washington DC chapter 

Let’s face it, companies are reducing their training budgets. During 

these austere times, the technical writer must get more creative 

than ever to participate in the annual conference. An informal 

survey of attendees at the 50th Annual Conference in Dallas showed 

that many people paid their own way to the conference. There are 

numerous ways to reduce the cost to attend the conference. 

The most important tactic: start early. If you want to go to a 

conference, tell your boss as soon as possible, and explain how the 

knowledge you gain will change his or her life. Explain how you plan 

to shop early for tickets and hotels, and even propose a 

presentation which, if accepted, will further reduce expenses! 

Present her or him with a list of the expenses if you made no effort 

to cut costs, and the expenses you anticipate after all your costcutting. 

If your manager is still uncertain, consider offering to pay 

for the airplane ticket if the company pays for the hotel and 

registration. 

Here are ideas for cost-effective transportation, lodging, 

registration, and meals, and desperate measures if you cannot 

attend at all. 

Transportation 

• Shop for your plane ticket early. Start looking for bargains in 

November or December. Be sure to compare the cost of 

arriving Saturday and staying Saturday night versus arriving 

Sunday—it’s nearly always cheaper to arrive on Saturday, 

even when you consider the additional night in the hotel. Web 

sites to check include Expedia, Orbitz, and Travelocity. 

Students and faculty at educational institutions can check 

Student Universe (www.studentuniverse.com/orbitz) for 

deals. 

• Ask friends and family members to bring you to the airport. 

Travel to the airport with members of your STC chapter so 

that you can split the cost of cab fare. Use the World Wide 

Web to determine whether public transportation can get you 

from the airport to the hotel. Check days of the week and 

times of day to verify that public transportation is available. 

Just be sure to set aside some money in case your ride backs 

out! 

• Avoid renting a car. Car rental fees, parking fees, gasoline, 

and parking tickets add up very quickly. How badly did you 

want to get lost, anyway? Public transportation, cabs, and 

your feet can take you all over town, and you’ll learn more 

http://www.stcsig.org/usability/newsletter/0308-shoestring.html 9/23/2003


Lodging 

about the place. 

• Shop for a budget hotel. Staying at the conference hotel is 

wonderful but expensive (average $160 a night, excluding 

taxes and fees). You may find a bed and breakfast near the 

conference for half that cost, and save on food costs! Ask 

your friends and colleagues, even the host chapter to 

recommend a less expensive hotel. Once you find that hotel, 

reserve a room immediately. Web sites to check include 

Expedia, Orbitz, and Travelocity. Students and faculty at 

educational institutions can check Student Universe 

(www.studentuniverse.com/orbitz) for deals. 

• Share the cost of a hotel room with a friend from your 

chapter. 

Registration 

Food 

• Propose a presentation to give at the conference. Besides the 

opportunity for you to share you knowledge and skills with 

your peers, speakers receive a discount on the registration 

fee. August is the deadline for submitting presentation 

proposals. 

• Register a day or two before the early registration period 

ends. This gets you the best price, and you keep your cash in 

hand longer. 

• Pick your day to go. This is a tough solution, because 

presentation descriptions are often unavailable until a few 

weeks before the conference and you may find that Tuesday’s 

sessions are just as compelling as Monday’s. If you are 

looking to save on the registration costs, though, this is an 

option. 

• Attend all the free events. These include the regional 

reception on Sunday evening, the general reception on 

Sunday, and the international reception on Monday evening. 

The vendor exhibition is usually good for a cup of coffee and a 

snack. 

• Bring breakfasts and snacks. The conference no longer 

includes continental breakfast. A box of granola, energy bars, 

and bananas are nourishing and inexpensive. 

• Pick conference lunches and dinners to attend. I enjoyed the 

SIG luncheon and the networking luncheon because of the 

opportunity to meet with renowned members of our 

profession. The Awards Banquet is a chance to network. This 

year it was $40, though, which is about what I paid for a 

night out with the Lone Writers at Dick’s Last Resort, even 

including the cab rides there and back. This year’s conference 

location had limited off-site dining options (other hotels and a 

Denny’s). Another option is to just bring more granola bars. 



If All Else Fails 

• Arrange for an attendee to buy and ship to you the 

Proceedings on CD-ROM ($20 plus about $0.80 postage). 

• Write to the presenters whose sessions appear interesting and 

ask them for their materials (free!). 

• Check out the conference web site and download information 

from the Uploaded Session Materials 

(www.stc.org/50thConf/sesMaterials.asp). These often 

represent the handouts that speakers provided and are not 

included in the Proceedings (free!). 

Looking Ahead 

The 51st annual conference will be held May 9-12, 2004 in 

Baltimore, Maryland, near the Inner Harbor. There are a number of 

hotels and restaurants in the area. The closest airport is BWI, which 

is known locally as the best value of the three airports in the area 

(Dulles International and Reagan National being the others). For 

more information about the 51st conference, go to 

www.stc.org/51stConf/index.asp. 







Thoughts on Publishing Our Newsletter - STC Usability SIG Page 1 of 1 






Thoughts on Publishing Our Newsletter 

By David Dick, Editor 

Many of STC’s chapters and SIGs publish their newsletters online, 

either as PDF or HTML, to reduce time, effort, and costs. Publishing 

the newsletter online, allows Editors to publish more articles, and 

make better use of graphics and color, which increase publication 

costs. 

In our member survey we asked how you would like to have the 

newsletter delivered to you. Eighty-one people replied to the 

question: 

• 33 replied that they would like a printed and mailed 

publication with simultaneous posting on the web. 

• 13 replied that they would like a downloadable PDF file. 

• 23 replied that they would like a web version with notification 

by e-mail. 

• 12 answered "Other" (undecided). 

Our budget is based on an allocation from STC of $4 for every SIG 

member. This year, that gives us a budget of $7,896. Last year, our 

costs, primarily for printing and mailing, was $13,539. We recognize 

that many members still prefer hardcopy, reducing costs is not an 

option, but a necessity. 

We have two choices: 

1. Publish a four-page newsletter. The consequence is that it will 

have only one feature article and advertise articles published on our 

web site. The benefit is that we drastically lower production and 

mailing costs. 

2. Publish an e-newsletter, which contains highlights and links to 

articles published on our web site. 

We will do both and select the best and economical solution. 






http://www.stcsig.org/usability/newsletter/0308-editorial.html 9/23/2003

The Search for Well-Defined Usability Discipline - STC Usability SIG Page 1 of 3 






The Search for Well-Defined Usability Discipline 

by Karen Bachmann, SIG Manager 

The STC annual conference in Dallas included many sessions on 

usability, and the number of attendees in those sessions suggests 

that information about usability is valued and needed. Several of 

the sessions highlighted how technical communicators are finding 

innovative ways to add value through usability techniques. The 

message that "usability matters" is definitely spreading. 

The message about usability is reaching other, general audiences as 

well. However, sometimes the message is garbled and sometimes it 

is overlooked entirely. Some recent examples of this that I have 

encountered include: 

A seminar that included usability in its title but, in its description, 

derided the usability practices followed and recommended by most 

practitioners and experts, offering what was claimed to be an easier 

approach. 

A couple of articles that explained business woes that clearly arose 

from usability problems, but never mentioned usability practices as 

the solutions or mentioned usability in very limited terms. 

Narrow, short-sighted definitions of usability in job descriptions and 

by related professions. 

A more general example is software project managers who dismiss 

the need for explicit usability work because the programmer is an 

expert with the GUI programming tools and, therefore, considered 

qualified to "inject" usability into the end-product. All of these have 

the danger of trivializing the scope and contribution of usability, 

thereby minimizing its effectiveness. Examples like these have led 

some usability professionals to lament that the usability community 

is not doing a good job communicating the value and importance of 

usability. Others have argued that the message is fractured and 

unfocused, exemplified by the number of possible job titles given 

usability professionals. Still others point out the 

incompatibilities of the language used by usability advocates and 

the language of management. On the other end of the spectrum is 

the frequent use of "usability" as a buzzword, the latest quality of a 

product to serve as a product differentiator. Certainly, usability is 

among the top qualities that users will begin demanding from 

products. Good usability will help differentiate winners from losers 

in the marketplace. However, the shallow definition and lip service 

paid to buzzwords can have harmful repercussions. 

http://www.stcsig.org/usability/newsletter/0308-discipline.html 9/23/2003


Consider the fates of CRM (customer relationship management) and 

even B2B (business-to-business) e-commerce. Both disciplines 

became buzzwords that were detached from their fundamental 

requirements for success: understanding the underlying processes 

and the people involved with those processes. Instead, software 

tools that failed to account for human factors were released, and 

when those tools failed to provide a silver bullet, companies blamed 

the whole idea—not the poor implementation. Those disciplines are 

only now starting to recover some credibility but have a long way to 

go. Usability advocates need to be careful to avoid a similar deathby-hype 

fate as we continue to spread the "right" message to our 

employers, clients, and professional colleagues. 

How do we make sure that the right usability message is heard and 

wins out? 

First, we need to agree as a community of practice on a common 

definition of usability as a discipline—not exactly an easy prospect, 

but a number of our sister organizations are tackling these issues in 

key initiatives. The Usability SIG must support these efforts, 

providing our input and communication skills. 

Second, we need to find ways to address those sending out radically 

different messages in a diplomatic, constructive way. Educate— 

don't argue. 

Third, we need to deliver the message to our employers in the way 

that they can identify its value to their unique company goals. That 

means changing the presentation of the message, not the core, 

commonly agreed-upon content. Applying our communication and 

usability skills to our own message is essential to its success, but 

too often we do not take the time (or simply do not have time in 

jobs where one person does the work of many) to craft our selfpromotion 

as carefully as we do our project deliverables. 

In the Usability SIG survey at the beginning of the year, many 

respondents asked for better tools to promote usability. Developing 

a consistent, positive message about the benefits and realities of 

usability is a first step in developing such tools. Usability 

practitioners (corporate and academic professionals) and advocates 

must work together to mindfully craft a unified message and to 

establish usability as an essential element to development. Those of 

us who have trained as communicators are well-qualified to help the 

usability profession craft and deliver a clear, useful, and usable 

message. 

You also asked for information about usability techniques that you 

can apply to your work—whether you are writing user 

documentation, conducting usability tests of company web sites, or 

designing the user interfaces for software and web applications. The 

efforts to better define usability include defining the core 

competencies and practices for the profession. Reaching agreement 

about these foundation components will better support learning the 

profession and applying it to our jobs and deliverables. 



As the usability community continues to develop a stronger, more 

consistent message, the Usability SIG will support and report the 

work of our sister usability organizations, and we will use the 

findings to improve our services to members. In the meantime, we 

will continue to provide the services some of you pointed out as 

especially valuable, including: 

• Publishing case studies and applied techniques in Usability 

Interface 

• Updating and enhancing the usability toolkit and bookshelf on 

our website/ 

• Providing a community for discussion and support through our 

online discussion list. 

We will also be working to provide new information that you 

requested and to address the concerns and needs that remain. The 

Usability SIG volunteers greatly appreciate the time and effort you 

put into your survey responses. We welcome your continuing 

feedback, suggestions, and experiences promoting the right 

usability message. 







Letter to the Editor about "Crisis in the Profession" Page 1 of 2 






Letter to the Editor about "Crisis in the Profession" 

I wish to respond to your article about "Crisis in the 

Profession" (www.stcsig.org/usability/newsletter/0210-crisis.html). 

My comments are based on some personal experience. 

In your list of points delineating where you felt the usability 

profession has failed to make its case, point one asks," I put this 

question to my wife who, as an academic, has an inside view of one 

the most likely sources for such a study. It appears that CIS 

(Computer and Information Sciences) and MIS (Management 

Information Systems) departments within universities are often at 

war with each other over curriculum issues. Perhaps the studies are 

discouraged in one discipline because it would involve the other. It 

certainly seems unlikely that collaboration would exist. 

As to the issue of making the case for usability’s return on 

investment, I fear that it is the software industry itself that presents 

the biggest barrier. I became interested in usability as a User 

Interface/Web Designer. I came to user interface/web design from 

the profession of graphic design. Originally, like many designers, I 

was on the opposing side of "those usability people." But, within the 

last year, I began to see the merit of the usability argument. I also 

recognized how usability issues in software and on the web mirrored 

legibility issues in graphic design. In my early professional career, 

trends in graphic design had moved to a "fractured" approach. 

Graphic design had become part of the post-modernist, 

deconstructionist movement. The low, to me, was attending a much 

anticipated AIGA (American Institute of Graphic Arts) lecture, and 

hearing a renowned designer explain the virtues of making the 

printed page harder to read, as if the amount of cognitive struggle 

was proportionally equivalent to the amount of reader interest. I 

decided then that the "movers and shakers" of graphic design were 

out of touch with the real world. My membership to AIGA expired 

and I did not renew it until years later. I decided the best way to 

effect change towards a reasonable approach was to try to add my 

voice to the organization by continuing to participate. 

I am beginning to feel like the software industry (and web) is 

suffering from a similar kind of blindness. 

Many years ago, when personal computers were exploding onto the 

scene, using software was an acquired skill. Like icing on the cake, 

it was that extra skill that could get you hired. Contending with a 

learning curve came with the territory. The software designers and 

developers created the system and the expectation was on the user 

learn it. Since that time, computers have become virtually 

ubiquitous in society. Computer software is being used in almost 

every aspect of business functionality. People who already have 

http://www.stcsig.org/usability/newsletter/0308-letter.html 9/23/2003

Letter to the Editor about "Crisis in the Profession" Page 2 of 2 

enormous demands in their professional careers must use software 

to accomplish their tasks. Using software is no longer just an 

additional skill, but part of the very core of their profession. With 

such a shift, the expectation should be on the software industry to 

make the software as intuitive and easy to use as a traditional "land 

line" telephone. Sadly, I see little evidence of this industry 

redefining its relationship with the users. 

In meeting after meeting, I hear assumptions of what the users 

should already know and what they are expected to learn. The 

value of adding usability is sacrificed to adding new features to the 

product. Competitors add as well and the race to the moon of 

features is well underway. Software companies get locked into an 

endless cycle of making release deadlines with as many features as 

possible and usability gets placed on the back burner until "when 

we get the chance" finally comes. The end result is software user 

interfaces become overloaded. But, instead of recognizing the 

clutter, software companies euphemistically promote the upgrade as 

"robust." I have yet to see a software upgrade promotion say, "We 

added nothing new, we just made it much easier to use." 

The IT bubble has burst. Software companies (the ones that 

remain) are virtually on the ropes. Yet, software "business as usual" 

paradigms from over a decade ago still persist. Like the cliché of the 

frog placed in water, slowly coming to a boil, the industry is facing 

disaster without recognizing it. In a flagging economy, users will not 

sacrifice their careers or, indeed, their businesses to a learning 

curve. It is up to those of us involved with usability to continue to 

be a voice, even if in the wilderness, for making software as easy to 

use as possible. 

Your idea of getting usability groups together is commendable 

because resources need to be pooled. CHI2003 was held in April in 

Ft. Lauderdale. There were a few sessions on promoting usability. 

Yet, I saw no major effort in addressing how to shift the current 

business paradigm in either of the plenary sessions. With a 

conference of this scope, it would have been a great place to start. 

Sadly, I was unable to attend. I hope it was discussed, somewhere, 

at the conference. 

- Jim Griesemer, User Interface/Web Designer. 






http://www.stcsig.org/usability/newsletter/0308-letter.html 9/23/2003

STC Usability SIG News: August 2003 Page 1 of 2 






SIG News 

Scott McDaniel Speaks to Washington DC Usability SIG 

(March 2003) 

Scott McDaniel presented "Planning Usability Into Your Product — 

The How and When of Usability Evaluation" and "Usability Tests and 

Heuristic Reviews — Planning and Estimation Worksheets." Scott’s 

PowerPoint slides (as a PDF) and a handout is available at 

www.stcwdc.org/program_handouts.shtml. 

Usability NJ Local Chapter Summer Picnic 

On July 18, members of the Central New Jersey Usability SIG 

gathered at a park by the Raritan River to socialize and take part in 

two mini-workshops. Presenters Donna Timpone (principal of 

UserEdge Technical Personnel, http://useredge.com/) and Ilise 

Benun (Self-Promotion and Usability author, 

www.artofselfpromotion.com/) discussed career directions and selfpromotion 

topics. 

Donna Timpone is active in STC, and her personnel firm has placed 

many technical communicators, instructional developers, and 

usability specialists in New Jersey jobs. Donna’s presentation was 

on "Career Options and the Secrets of Personality Type." Using a 

quick version of the Myers Briggs Type Indicator, participants 

determined their personality type and received a list of possible 

other occupations for their type to investigate when the usability 

market gets tight (reference: "Do What You Are" by Paul Tieger and 

Barbara Barron-Tieger). 

Ilise Benun is active in UPA’s local NYC chapter, with specialities in 

graphics design and self-promotion. Ilise’s presentation was on 

"Promoting Yourself and Usability." Participants worked on their 

"blurb"— initial introduction of 15 or 30 words. If you don’t promote 

yourself and usability, your recommendations and results won’t 

make a difference. The trick is to learn to understand who your 

audience is, what their needs and concerns are, then use that 

information to present usability, yourself, and your 

recommendations—all without resorting to jargon. 

Combined with the culinary talents of group members and a break 

in New Jersey’s monsoon season, the picnic meeting was judged a 

success by all the attendees. 

http://www.stcsig.org/usability/newsletter/0308-signews.html 9/23/2003

Print all of the articles in this issue - STC SIGs

Create successful ePaper yourself

Delete template?

Save as template?