Surveys: How to Beat Around the Bush

I didn’t expect tech writing to involve creating so many surveys. One day I may go back and get another degree in math or statistics and then just specialize in creating surveys and analyzing product users—I like making surveys that much. For now, my goal is to learn about Google’s survey tool and branch out from SurveyMonkey.

Several years ago, our department achieved a coup by getting permission to pass out a survey on documentation at our user conference. We stood outside the one of the conference halls as people waited in line to file in, chatting and handing out surveys. I enjoyed getting to talk to actual customers.

We got about 40 responses out of all the folks who took surveys—not bad. But, we had no follow-up plan for using the information. Management didn’t develop one and I was too inexperienced to effectively push for such a plan. We made a tweak to release notes as a result, but the effort is largely remembered (unfairly) as much to-do about a survey that didn’t pan out to results.

I would argue that we got a baseline of responses to common questions that we can ask repeatedly over time. Besides, what can you expect from one survey? One survey does not equal user analysis. It’s a baby step.

The following year some team members took another survey to the same conference, but the surveys sat in a stack on a table. Team members remember three people taking surveys; none were returned. It was the year of no surveys.

The next round of surveys came with the Help Design project. When we were ready to show a prototype of our new help system format, our director asked us to gather responses from the focus group in a written form, such as a survey. This would be easier for us to take those tangible preferences to other stakeholders within the company in order to get our ideas implemented.

Currently, I’m involved in two new surveys: one at work to gather general information about our users and one for the Usability and User Experience SIG of STC to gather requirements for their web site redesign. As a matter of fact, it would be helpful if took that survey, if you are interested in usability; here it is.

I’m starting to see some helpful patterns, which I’ll share here:

• List your objectives.
  Once you start sending your survey questions around to a group for review, it’s easier to talk about which questions should or shouldn’t be included if you can talk about which objectives the survey supports. You can brainstorm a list of overall objectives for user analysis, then choose which handful of objectives you are focusing on for this particular survey.
• Think about how often you will solicit input from users.
  When will you do your next survey or some other form of user input?We decided to do two outreaches per year, in addition to ongoing help system analytics. It’s easier to let go of some of the objectives for this round if you know you can focus on them next time.
• Cultivate a list of contacts.
  Our current survey will go to the clients who weren’t able to be included in the help design focus group. This is the result of a few courtesy emails on my part. We sent out an email soliciting clients for the focus group, but there was limited space. For the folks who weren’t included, I emailed to let them know we didn’t have space for them and asking if I could contact them for future feedback opportunities. Not one of them said no.
• Give concrete examples to make the questions easier.
  I tend to think of this as beating around the bush. If one of your objectives is find out what types of manuals and other deliverables you should be providing, I don’t think you should ask, “What types of manuals would be helpful to you?” That’s a question for tech writers—we’re the experts on that. The survey should gather related information that helps us answer that question. Here’s something a little better: “How do you like to learn new things?” followed by some examples, “A. Instructional videos. B. From a co-worker. C. Classroom training. D. Trial and error on my own.”
• Make the questions distinct from each other and keep it short.
  Please don’t make a survey that reminds people of a behavioral-style job interview. Do you take three questions out of ten to gather demographics? Unless user demographics is one of your major objectives, cut it down and combine questions. Are your questions distinct from each other, or will respondents get annoyed by thinking they have just answered the same question twice? You might be trying to discern a subtle difference with the two questions, but that might not be apparent to someone who is quickly completing the survey.

What’s in a Label?

I work at a company that writes clinical software. Some of our products are directly regulated by the FDA as medical devices, which means all of our processes are affected by FDA standards. The way our technical communications department fits into this is that we satisfy Part 801 of the Quality System Regulation (QSR) governing medical devices–we provide labeling for the product.

We have won a few showdowns based on this requirement. If it’s required for FDA labeling, eventually developers have to make time to include the help system. If the release notes are part of the labeling, then we need to be following the established process and getting help from SMEs to get that done. Fun things like that.

I have been thinking quite a bit lately about other types of labels—field labels, button labels, task headings, labels on the books in our tables of contents. It’s an area where I think we can use some improvement. After watching us rearrange content for our help redesign, I’m realizing that you can have an elegant information structure and still make things hard to find with sloppy labels and headings.

Are You Sure You Know What’s Required?

Over the past couple of months, our department manager has been reading the entire QSR (a binder several inches thick) so that she can be as familiar as possible with our requirements. It turns out that there are two main requirements that affect us: we have to provide print manuals for our particular kind of product and we have to follow best practices for creating them, such as user analysis and validation of our tools and processes. We’re required to provide the appropriate information to use the product.

There has been a long-standing myth in our department that our FDA requirement is to document every window and every procedure in the systems. That was a standard I tried to live up to for about six whole months. Our larger products have hundreds of windows, and with customizations, many variations on workflow. When I started, several of our manuals were over a thousand pages, and they have grown even more during my time.

After a certain point, it becomes impossible to find what you’re looking for in a manual that large. People who work for us can’t find things. They call the tech writers up to find things. All because of the mistaken impression that we were on a quixotic mission to capture every field.

What was I Saying about Field Labels and TOC Books?

I’m not suggesting that field labels and TOC book labels are regulated by the QSR. I’m saying we are responsible for being thorough about making things easier to find. Labels are a huge, huge part of that.

If I am browsing the help system, the book labels help me know whether I’ve clicked in the right place. If the labels are vague or jargony, I don’t trust that and I have to go back and click all the other books to be sure. I can never be sure whether the information simply wasn’t there or whether I didn’t click enough places.

If I’m searching, labels help me pick the correct topic from the list of results. The task headings should be rooted in the user’s world, not the system’s world. “Resending Results,” not whatever method the programmers used to implement that task, such as “Resubmitting the XYG Widget in the ABC Option.” That way the user doesn’t already have to know where and how the task is performed in order to find the steps.

A Beginner’s Adventure in Field Labels

Labels and headings are fundamental writing skills that can always use honing, I think. I think it’s so much a core skill of tech writers that it’s something we have to offer the programmers who are designing the interface. They have these same issues and responsibilities when they’re naming the fields that we have to describe in the manuals.

I recently started documenting a smaller product that is developed by just three men who happen to all be in-house. I thought this might be an opportunity expand our role into interface improvement. I still think it could be, but it will take some finesse. Our first exchange went like this:

“Would you like suggestions for field and option labels? I am updating the manual and I could send them as I go.”

“Sure you can.”

“How would you like to do this? I can send tables like this:” (insert table with five columns: current name for the option, field, or button, plus the suggested name, and a column for marking whether the new name was accepted.)

Silence. Guess I got a little too excited.

I Want to Talk About Whether I’m Underpaid

To justify my earlier post about commuting by bus, I referred to low salaries for entry-level tech writers in companies that don’t fully value their tech comm departments. Then I proceeded to dig for statistics to back up that reference. I had some trouble with that. In fact, I found all kinds of indicators that tech writers have valued, well-paid positions. So now I’m on a mission to find out why that doesn’t resonate with me.

As soon as I realized that my question was whether I am underpaid, it occurred to me that I might not want to explore it on my blog. Like many companies, mine does not permit me to disclose my salary. But I think it’s gotten to the point that letting in a little sunlight can only help things.

My main concern is that my current salary is going to be the starting negotiation point for any future salary. If I’m truly at a disadvantage, I have the right to start thinking about how to handle that. I’m going to do that here with all the respect and caution that is due to my current employer.

If It’s Not Me

I work at a software company that has not stopped growing during the recession. I’m actually not entry-level—I’ve worked in the department four years and I educate myself about the industry. I am knowledgeable about our company’s internal processes and about several of our software systems. I document the new development of our flagship product, and I led the group that developed the new structure for our help systems.

The STC salary database gathers salary information from employers—it’s not a survey of technical communicators. The statistics are broken down geographically in several different ways. The one I always flip straight to is yearly compensation by metropolitan area (Full List of MSAs by State – Annual).

Average ages are given for each percentile group. The percentile groups are supposed to roughly correlate with levels of experience. If I look at the average annual salary for 10th percentile and the 25th percentile for 2008, for Tampa – St. Petersburg – Clearwater, I do not make either of these figures.

I’m in one of the highest paying industries, according to the salary survey (Other Information Services). And according to STC, over 90% of writers in my geographical area make more than me. Browsing technical writer salaries for Tampa on Glassdoor.com seems to support this, as well. What gives?

And It’s Actually Not Just Me

I am Vice President of our local STC chapter, and a significant portion of our group is looking for work. Some of them have been looking for months. Our last two chapter presidents were laid off during their terms. When our company has been hiring, I have felt confident telling people to apply because I feel our department is relatively secure. Is that the tradeoff? Or have I set the bar too low?

Recently, an entry-level position came open in our department. I am working with a student on a chapter project, and I wanted to recommend him for the position. He’s currently a manager with the company he’s working with while he’s in school. Accepting an entry level position with our company might well be a pay cut for him. Is that an unusual situation in tech comm?

I’ve only worked at one company as a technical communicator. Salary databases and word of mouth are all I have for making comparisons.

What if STC Already Has What Gen Y Wants?

I’ve been wanting to write about this since Ben Minson posted about it and gave his take on what the next generation, Gen Y, wants from the Society for Technical Communication (STC). I think Ben hit on some good points, and I wanted to explore some of the gut feelings I’ve gotten from the general rejection of STC I have experienced by younger writers. Something just isn’t clicking for them in their perception of our group.

I am usually the youngest person at the Suncoast STC meetings, and I am technically Gen Y by some definitions, although not by McCrindle’s.

The last generational quiz I took, though, I did not score highly as a millennial. And I am sometimes baffled by people just a few years younger than me. Like how most of the people my age and younger almost fall asleep after my first sentence about STC. What is it about my message that doesn’t sound valuable to them?

Time Magazine says Gen Y wants flexibility during the workweek and they want to be with their friends.

Suncoast chapter meetings are another stop at the end of the day where I’ve got my work hat on. It’s a social work hat, because I talk to people non-stop the whole time I’m there, but it’s a work hat, nonetheless. And, if I’m not making myself talk to strangers, I’m not getting the most out of the meeting.

There is usually a presenter, so theoretically, a member could listen to the presentation and slip away with nary a conversation, but the ambassadors of our group don’t let newbies go ungreeted. By the end of the night, I can feel that I’ve exerted myself socially and mentally, but the payoff is a network of people who think of me primarily as a tech writer and who would help me find another job if I needed one.

Does Gen Y have this through other means, or is the format so far outside of their comfort zone that it prevents them from making the comparison? How can we leverage the social networks of chapter members to strengthen the group? How important is it to sponsor purely social events for the chapter?

McCrindle’s says that management style and workplace culture matter more to Gen Y than to previous generations.

I wonder if this means that one bad networking event experience can be the kiss of death for future efforts. If Gen Y is networking other places more comfortably, why try another professional group if you have been to a meeting where the group leaders seem stressed or resistant to change, or where the senior members were know-it-alls, or where the path to mentorship and benefit was otherwise needlessly obscured?

As volunteers in a dynamic group, we only have so much control over the tone of the group, but what we can tweak, we should. I’ll be taking another look at the format of our meetings.

B.NET says Gen Y wants to work with the latest technology.

Now that I’ve had time to adjust to them, I have a healthy respect for listservs. But I did shake my head in disbelief at first. I don’t think anyone has a healthy respect for our chapter’s web site, though.

STC-ers are all over Twitter. But is Gen Y? Not according to C.NET. And not if my department is any indicator, either.

Tech writers, information architects, information developers – some of us get to work with some exciting communication technology. What are some ways we could be making better use of technology to let Gen Y know that?

What STC Definitely Does Have to Offer

All the sources I mentioned say that Gen Y expects to job hop in order to find opportunity. STC offers a version of this.

You can start out as a competition judge or a phone tree caller, then be a chapter leader. Or, you can volunteer remotely in a special interest group (SIG), which are STC’s online communities. Once you have had success as a community leader, there are Society-level positions, some of which are even paid.

Call me crazy if those folks don’t get work as a result of their involvement, and they get a large group of genuine friends, too.

Many STC members work for themselves, travel nationally and internationally for work, staying with their STC friends on assignments generated by their STC associations. They have control over what they wear to work, how the business operates, and who they work with. I think we have what Gen Y wants, we just need to make sure that our message makes entry into the group palatable.

How to Handle a Total Communication Breakdown

“Sometimes, nothing works. You say something, making all the proper moves, and nothing happens. You get an icy silence, a blank look, folded arms. You try another move—you try Leveling, perhaps. And still nothing happens.”

This is a quote from the “Emergency Techniques” chapter of Suzette Haden Elgin’s book, The Gentle Art of Verbal Self Defense, the 2009 edition. In fact, the title of this post is a heading from a section in that chapter on coming to a standstill in a negotiation.

“What this means is that you are lacking some vital piece of information. You have broken a rule you know nothing about, perhaps because the other person is from a different cultural group than you are, perhaps for entirely personal reasons.”

The book describes verbal attack patterns and modes. Leveler mode, in which what the speaker says is what the speaker feels, is the ideal communication mode, but is often not safe or appropriate. For one thing, it can seem like an attack to some people. “This article is not well written” is a straightforward assertion in Leveler mode. It’s not necessarily a verbal attack if spoken in a neutral tone.

The safest mode is Computer mode; using abstract, controlled, and noncommittal speech and body language.

Here’s a paragraph in Computer mode: It’s interesting that people feel the need for a book on defending themselves in conversation. It can be stressful to have a confrontation. It would seem that it’s possible to disguise a verbal attack as friendly banter. There are statistics suggesting that these situations are possibly detrimental to people’s health.

Computer mode is deliberately passive, and should probably be even less substantive than the paragraph above, if I have read the book correctly. This mode of speech can be used to stall unwanted conversations and to diffuse tension. The point of verbal self defense, as described by Elgin, is not to smack down your opponent with your wit and sharp tongue, but to avoid verbal violence and get to Leveler mode when possible. As in martial arts, we should only use the necessary amount of force, and no more.

“In this situation you have only one appropriate response: You become absolutely silent, too. And you wait.”

I read the entire book waiting to encounter information on gossip and sarcasm, but I’m pretty sure neither word appears in the text. There was quite a bit of advice about avoiding verbal retaliation, and feeding into a confrontation. I think the gist is that we shouldn’t feed the trolls IRL any more than we should online.

“If this happens to you in a situation in where you are facing a group and you have a responsibility to fulfill . . . be sure that you make your position clear before you resort to silence.”

I’ve got more appreciation now for spoken rhetoric. It’s a skill to be honed. I love the idea that once I am proficient at it I will be confident enough to diffuse attacks and hostility without having to retaliate, and without fear that I am being taken advantage of. And now I have shared one of Elgin’s emergency techniques with you.