My Blog has Moved

I bought a new URL, WhyTechComm.com, hired a web designer to style it and add some features I was wanting. I’ll be polishing and tweaking there, still, but I’m pretty pleased with the transformation. I’m aiming for less focus on my professional foibles and more discussion of how tech comm supports business goals.

I moved all my old posts there, so if you’ve commented on a post, your comments were also moved there. Please let me know if you don’t want that, and I will remove them.

This will be my last post over here. Hope to see you on the other side.

A Mini-Workshop: Grassroots Documentation Testing

My presentation proposal for the STC 2011 Summit was accepted! It’s a mini-workshop in the Usability track called “Grassroots Documentation Testing.” I just got the email from Lloyd Tucker, STC’s Deputy Executive Director. I’ve mostly interacted with Lloyd over email, but he’s so thoroughly pleasant that it’s especially enjoyable to get a congratulations from him.

So, yay.

I’ll be leading an exercise and a discussion, and I’ll follow up with a blog post to summarize our ideas.

For the exercise portion, we’ll practice writing scenarios to test user assistance content on hypothetical co-workers. Then we’ll have a brainstorming session to share success stories and discuss solutions for the most critical challenges to do-it-yourself documentation testing.

Hats tipping all over the place to Steve Krug and Tom Johnson.

When I got a copy of Rocket Surgery Made Easy by Steve Krug, our tech comm department adapted Krug’s do-it-yourself website testing method to test documentation, with an important variable–we tested on co-workers. The resulting benefits were not the ones I expected, nor were the challenges quite the same as the ones covered in Krug’s book.

The reading I’ve done as a novice helps me justify the “why” for testing. Now I want to provide a forum to discuss the “how.”

This discussion is an opportunity to supplement the expert resources on usability with some grassroots collaboration. I’m not an expert, but as a group, we’ll work through an exercise to demonstrate some challenges, then discuss solutions for the most severe issues; a debriefing à la Krug. After the Summit, I’ll blog our group solutions. (This part of the session was inspired by Tom Johnson’s collaborative posts over at IdRatherBeWriting.com.)

I think this will resonate with tech writers and usability novices who need to overcome some obstacles and start somewhere with testing.

Sometimes technical communicators come into a department that has established formats and standards, and it can be difficult to find a point of entry for improving upon those. Or, basic audience analysis may be lacking from a tech comm department’s processes and body of knowledge. In some environments (and also depending on one’s experience level), it can be difficult to make the case for professional usability testing, or for direct access to users. Employers may be more open to low-budget, internal testing.

I’m expecting this to interest creators of users assistance who are already testing their docs or those who want to know how to get started. I expect a mix experience levels in the tech comm field.

What I’m hoping to accomplish:

Otherwise known as the “key learning objectives” part of the session proposal.

• Gain awareness of the process and challenges of writing test scenarios for user assistance
• Gain awareness of what is working and not working for our colleagues
• Increased confidence in the ability to test our content
• Increased proficiency in using collaboration as a problem-solving tool
• Produce a list of solutions that can be shared with the STC community

Hooray! Also, feedback.

What would attract you to this session? What would make you skip it? Do you have any tips on presenting? Do you have a testing story? Please share down in the comments area.

The Old School Itch

I am thinking of going back to school. Again.

Some of you might remember last year when I failed calculus pretty decisively during my first semester of what was possibly going to be a computer science degree. I think I left out the actual failing part, but that’s what happened. That was an online class, though–I know I could have done it in a traditional class.

I’m driven by a couple of things–I want to keep advancing in tech comm or just build something new, and I just plain want to keep learning. I know there are other ways to avoid career plateaus than by going back to school. There are other ways to get technical skills. I can dream up plenty of innovative projects that don’t necessitate me taking a class, right? The thing is, I keep feeling this nagging limitation.

What if I want to build something completely different?

It’s like when I was trying to write songs, and I could sing, but I can’t play an instrument. I know there are singers who do it, but for me it was frustrating. I could find musicians to play with, but I wanted more input. So I learned enough guitar to sketch some songs.

Is it me or the tech comm industry that is at a plateau?

At the companies where I’ve worked (and from talking to people, this doesn’t seem uncommon) documentation is a by-product that is approached later in the product cycle, when the product is stable, and past the point at which people have any energy for the all the benefits it can offer if one is innovative.

When I talk about personas, and sales opportunities, they look at their watches and wonder why I am not just writing it, already. I’m becoming pretty well-versed in the benefits of good user documentation that is part of a larger strategy, but there simply doesn’t seem to be much space for making the argument.

So, I’m going to need more credibility.

And more technical skill. Where I’m at now, the product people and even some of the marketing people are engineers. My impression is that they think personas are cute, at best.

Some of that will be alleviated by me getting more experience. People out there are doing these innovative things with tech comm, and seeing the benefits, and it’s the company that’s missing out when I fail to get the message across, or when they just don’t have ears to hear it. But when the rest of the features in the product are being built based on intuition and domain expertise, why should I expect the help to get treated to more empirical methods?

I’m not oblivious to the fact that I got all wound up like this last time, and that it might pass as soon as I get another project that’s shiny to me.

For now, it’s giving me plenty of blog post ideas.

This is the question I want to answer: do advanced degrees (or additional degrees) for technical communicators pay off?

This can be broken into several parts/posts: how much do technical communicators make with various bachelor degrees or less, how much more do they make with additional degrees, how is that different in different parts of the U.S. and in different parts of the world? How do the degrees contribute to other factors of job satisfaction? Which degrees help the most for which jobs? Do other skills or circumstances play a bigger role in salary and satisfaction?

In the meantime, I’m looking at Illinois Institute of Technology or Illinois State for one of these degrees:

• Graduate Certificate in Systems Analysis
• MS or BS in Information Architecture (not sure which makes more sense, yet)
• BS in Computer Science

Squee!

Self Employment, Meet Family Planning

I have a COBRA letter sitting on my desk, and it’s been there for weeks, pressuring me to decide whether I’m 100% sure I want kids. And if so, like, when?

I quit my job this summer, moved to Chicago, and took contract positions. I’m so glad. The timing was pretty good as far as my skill level, and I’m working plenty. I can definitely afford health insurance, but maybe not health insurance with a pregnancy rider. I’ve got to spend more time comparing the prices to my budget.

So, COBRA seems like it might be a good choice. If I want to get pregnant within the next five months.

18 months of coverage, minus nine months of pregnancy, minus the three months that will have already passed by the time I make this decision, minus a month for whatever I’m not considering.

Five months to figure it out, or else I’ll have to wait a year to be eligible for the coverage I’d be paying out the nose for with a pregnancy rider. I’ll be 32 in December. I want to stay independently employed for a while and maybe launch a company next year.

I’ve been thinking about these things for a month or so, but this weekend, a shit storm erupted online over Penelope Trunk’s TechCrunch post, “Women Don’t Want To Run Startups Because They’d Rather Have Children.”

It’s really a remix of previous posts (I’ve been a reader of hers for a year or so) about how women do not need to put off children for their careers, plus news about her startup’s recent move, wherein she chose to stay put and be with her family.

I tried looking up research to determine how valid Penelope’s assertion is regarding the genetic cliff of age 35, but I didn’t find much. Only a couple articles related directly to the question, one of which contained a grammatical error that would make me want to scrutinize the site a bit more before I would trust anything on it. (Here’s the better one.) I checked Mayo Clinic’s site, and age was mentioned as a factor in fertility.

Look, Penelope’s strengths are not careful use of statistics or diplomatic wording of her ideas. Her strength is juxtaposing career-related trends in innovative ways, or in pragmatic ways. Like, maybe Power Point slides about your sex life are not as bad as people are making them out to be, or maybe it’s really not worth reporting sexual harassment. Except she usually leaves out the “maybe.” I walk away from her posts with a look-up list, not a to-do list.

So, the TechCrunch article lacks nuance, and it doesn’t apply to everyone. But for those of us who do want children, who weren’t anywhere near the top of the ladder by 27, and who are considering starting our businesses and our families at the same time, it’s a point of reference.

Exactly how hard is this going to be? From a project management standpoint, am I scheduling my newborn sleepless nights at the same time as my 100-hour weeks? If I’m not with my husband or my future husband yet, am I leaving myself enough hours in my week for a social life that will let me find him? Where are my hacks for these issues?

I’m simply not going to stand for anyone telling me it’s taboo to discuss these questions on the internet. I don’t care if they are women entrepreneurs with kids.

The “worst article on the internet ever”? “You’ve taken us back 50 years”? Let’s take it down a notch, people. By reacting with such vitriol, you could be shutting down women for whom these issues are relevant. By reacting with hysteria, you are not representing yourselves well to the venture capitalists you’re so concerned about.

If feminism were that fragile that one article could set it back so much, we would have bigger problems than one author. Are people really angry because it’s detrimental to the cause, or because it cuts on a personal level?

I’d like to see more discussion about how to structure a startup that works better with a family. I know that people end up losing their marriages and being heartbroken over missing their kids. Please, please don’t make them jump through PC hoops of fire to share those experiences.

I don’t want to hear about how “but she shouldn’t speak for all women, so that gives me the right to curse at her on Twitter or call her a disgrace.” That’s high school, and I don’t have time for it. I want to hear about what works.

The Story-Telling Trend

I was having coffee with someone yesterday to talk about his project, and I mentioned my background in creative writing, which led us to the current craze about story-telling.

There is even a med school program with a focus on storytelling for physicians, narrative medicine, which I think is such a great idea. Most doctors I’ve had couldn’t even listen long enough me to give them one sentence of information about my symptoms.

The gentleman yesterday had come to me knowing little about tech comm. In fact, he asked me about the term, “tech comm,” which he had seen sprinkled liberally throughout my blog. “Tech comm” is jargon for the industry of technical communication. Or, if you prefer, stories about using products.

He and I even laughed about his ad agency, which, sure enough, was touting story-telling as their focus. So is story-telling for products a stretch? Actually, no.

A five-step procedure might be technically accurate and pass QA, but a story-teller looks for signs that her audience is engaged. A good story is remembered and can be retold. This could be as simple as writing a short description that places the procedure steps in context. It could be examples. I’m excited to see what else it could be. I think this trend is gaining momentum.

All things being equal, hire the person who can write or speak the best. By definition, that means in story format. I recommend this for two reasons: a person who can tell stories can communicate with and motivate others, they can help define the narrative of the work they’re performing and plan to optimize that narrative, and they can do the same for themselves.

For me, that’s the main benefit of this blog: I tell myself the story of my career. When I take the time to articulate my experiences to myself, I can learn the most from them.

So, I’m a believer in the power of story-telling, even for specs and instructions. It’s just amusing to me that this isn’t obvious, and that companies can generate so much buzz by juxtaposing the term with their own industry jargon.

Testing Documentation on Co-workers: Part Two

You can find the first part of this post at Ben Minson’s blog, Gryphon Mountain Journals.

In the first part of this post, I talked about how our biggest challenge in adopting Steve Krug’s method of do-it-yourself usability testing was that our team was testing the documentation on co-workers. There were some other challenges, too.

Incredibly Specific Scenarios

People with a wide range of job titles use our software. They work in the same facility, but their domain knowledge, education level, influence, and familiarity with the system differ wildly. Wide variations between facilities can determine what types of job titles and tasks that our users have,too. I created a draft table of user roles, at one point, and I was looking at nine potential personas.

This meant that our time was limited for exploring scenarios specific to each user type. We had three users for 20-30 minutes each once a month. If the scenarios were not well-vetted and specific, who knows who our proxy users were pretending to be when we tested them?

At times, testers said things that made me realize that they were approaching the testing tasks not as if they were a customer, but an internal employee using the documentation. Sloppy scenarios could mean incorrect conclusions. As I improved scenarios, I started adding instructions like, “Pretend you are a system administrator in hospital laboratory.” I did this for each scenario to prevent testers from slipping “out of character.”

If I were continuing this project, my next step would be to identify the most critical types/personas and focus on scenarios pertinent to those. I hadn’t gotten that systematic, yet, but to a certain extent, I did use some educated guesses to focus on important users.

As I discovered the complexities of writing scenarios that didn’t flop, often what we used on test day was what I had discovered the most about during the course of preparing for the session, rather than scenarios that focused on the most important things to test in the content.

Recommendations, Meet Lunch Hour

I mentioned that we had about an hour and a half for testing each month. After the testing session, we had an hour for discussion over lunch, which Krug refers to as the debriefing. Our schedule was a modification of Krug’s recommendation, which is an hour per participant. As it was, people found it difficult to commit to 2 1/2 hours, and many skipped the noontime debriefing, even though we had the option to take a late lunch afterward.

The approach that my manager preferred was to make the testing sessions optional, but to have the outcomes of the discussions be binding. I thought this fit well with the idea of letting the benefits speak for themselves. It also meant that people we needed for some discussions were not present, putting a slight crimp in creating action items. That can be an issue in many meetings, though.

A Fuzzy To-do List

Ah, the outcomes of the debriefing, the post-testing discussion. Krug’s process is to go around the room and ask each observer to name the most severe issues he or she observed. From that list, then the group chooses the most severe issues and discussed solutions right then. The focus is on solutions that can be implemented that month.

This worked for us the first time, sort of. In our world, a month is a short, short time. It was hard to list anything that could definitely be done within the month, except for things like, “Add it to the department meeting agenda,” and, “Contact Jim to get more information.”

So, a good proportion of our next steps involved getting more information or prioritizing the issue on the to-do list where it already lived. The testing served as future ammunition, which was important, but not very exciting.

Testing the Content vs. Testing the Application

In our first testing session, we tested the application that our co-workers use to enter release notes, as well as the help system for that application. The next session tested our new help format and navigation. But for the most part, our sessions were to focus on testing the content of the help systems—do the instructions work?

So, when we set about testing the content of our release notes, I didn’t think there was need to give much a heads up to the writer on our team who helps develop that application. We were strictly looking at release notes written by various members of the team.

Except, people still got bogged down in the application. My scenarios started them too early in the process, where they had to use the application to find the notes. I thought I would pick up some peripheral information that way, but that’s where people got stuck giving feedback.

I think it’s easy to get distracted by giving feedback on a tangible window in an application, especially for our co-workers who help develop software. To test the content, I would need to skip the part where they have to deal with the interface, and just have them use the instructions I’m testing to perform tasks in the system.

Unexpected Benefits: Communication, Audience Analysis, Bartering

I’ve mentioned that we didn’t always get kick-ass to-do lists out of our testing sessions. We did get support for our ongoing improvements that we were trying to get sponsored, and we also got something else: communication with other teams.

We invited product people to watch the release note testing, and that gave us an opportunity to ask them more questions about our audience. It gave us a chance to demonstrate why sometimes we make the requests we make for them to improve the notes they write.

While writing the scenarios, I had to ask many people from other departments to vet them. “Would a customer do this? Would they know that?” I picked up quite bit of peripheral information about our audience that way.

Finally, the testing can be a way to offer benefits to other teams. Do you want upgraded software for the knowledge base? Let us test it so you can take metrics to upper management. Do you need to train a couple of your employees on the release note application? Have them come and watch how people use it. It’s one more way for the technical communications department to add value.

Two Weeks Notice > One Year OJT

Some of you already know that I gave notice at work and I’m moving to Chicago this week. I actually gave conditional notice a couple of months ago. Among other things, I asked to work on different projects.

The roles for technical communicators are pretty set at our company, but other departments do change and restructure quite a bit. I wanted to work on internal and external audience research and content strategy. It was a long shot, but not inconceivable.

My manager asked me, in several different one-on-one meetings, about what I wanted to work on. She took notes, and took those notes to her managers, but nobody ever said anything more about it, beyond my manager apologizing for the delay, and eventually it became clear that my long shot was out of range.

The Gauntlet is Not Just an E-Book

My manager explained that if I were to stay, one of my main focuses would be on mentoring.

What I heard was that I would work on .chms and WebHelps in a Tech Comm department silo until it was too late to break free into the next tax bracket.

This, of course, was an overreaction. But to call the mentoring role a cul-de-sac probably wasn’t an exaggeration, and that was hard to face. It was a skill set I wanted, but it wasn’t the time or the place.

I was intrigued, though, by her insistence on the team’s autonomy, and by my reaction to it. Consequently, it seemed everything I read or heard in the following weeks was related.

I had already seen this RSA white-board animation, actually, of a talk by Dan Pink, in which he says what people want most is autonomy. Okay, but how does that translate into a successful team?

I heard a bit on NPR about Frank Oppenheimer’s hands-off running of the Exploratorium in San Francisco, and the brilliant research that was produced in that environment. I’m having a hard time finding that July 13 story on NPR, but here’s an interview with his biographer. Anyway, I thought, “Well, but maybe you have to have people with the right experience and talent.”

In a nutshell, I picked at my blind spot. I could tell that I had an irrational resistance to something that I was fundamentally misunderstanding. Then I heard a podcast that, when it reminded me of work, made me wonder if I might be pushing the healthy limits of thinking on a work problem. I’ll share it with you anyway.

A Great Department Takes Time, and Manuals Aren’t Babies

One of my favorite radio shows is “This American Life” on Chicago Public Radio. Four months after the 2009 earthquake in Haiti, they did a show about the lagging relief efforts there.

The show outlines the obstacles in a program for helping mango farmers, a history of failed aid efforts in Haiti, and the contrast between a long-running missionary hospital and the Haitian-run clinic to which a doctor from the missionary hospital has transferred.

The doctor could be much more effective, in the short term, at the missionary hospital. The site was equipped for many more procedures than the Haitian-run clinic, and the American staff were trained to run in an efficient manner that was not the case at the Haitian-run clinic.

The trade off was the level of control and paternalism. Until recently, the wife of one of the founding doctors had worn the key to the medicine closet around her neck. One night when she was ill, they’d had to carry her out of her bed to unlock it for an emergency surgery.

The doctor ran the American clinic. At the Haitian clinic, he was one doctor among many. He was not in charge of anything. He had to watch people with injuries–including babies–that were relatively simple to treat suffer inefficient care, travel great distances from facility to facility to get their needs met, and sometimes die as a result.

It was frustrating, but perhaps less so than having the Haitian people resent the help they were receiving. The doctor was rejecting the “benevolent dictatorship” of the missionary hospital, which he saw as a failed model.

“The choice to then go the other extreme; to purposely work hard at not becoming a dictator for the sake of building community means that people are going to suffer, people are going to die. Goods will not be provided; services will not be rendered.”

In our case, no one is likely to die. Deadlines may not be met. Clients may not be impressed. They might be so unimpressed that they never press F1 again. Maybe those things will happen, and if we’re not measuring, we’ll never even know.

It’s a risk I’ll train myself to take.