Introducing HD (Help Design)

One day a long time ago, in our staff meeting, our new manager referred offhand to our new mandate: that help systems shall be our primary deliverable. Print manuals shall take a back seat. Or maybe I referred to it when I said we should have topic templates. Or maybe that was when someone suggested that we streamline some of heading phrases that we use throughout our documents. What I clearly remember is that our manager asked for a few volunteers to meet as a committee and come up with suggestions as to how we could optimize our content for online help.

This week, I went digging through our old SharePoint site to figure out exactly how long ago that was. I was afraid to look, and rightly so. In March, it will have been a year and a half. Oh, and we will still be going in March, meeting with team members as they start to implement the new format and designing training exercises. We’re presenting a prototype to clients and programming this week, and we’re finally in implementation phase, but—a year and a half!

So begins the story of my first time leading a group project. Three SharePoint sites and roughly eighty meetings later, the project that has come to be called “HD” has taught me so much. From the outside looking in, the pace may have seemed glacial, some of which is a result of our inexperience and some of which is just the standard pace of change in a large, hierarchical company when many departments are affected, but we have had our hands full the entire time. I don’t think the same project would take us as long today, and I’d like to figure out why—where did we stumble? What did we learn?

I had some general ideas, but I wanted to know what other people on the committee thought. Jason Burke pointed out that our scope increased quite a bit: we were originally tasked to come up with some formatting and maybe minor content changes that would make our content work better online. We ended up pitching topic templates, a structural overhaul, custom documentation, and Flare Feedback server to clients and management. Plus trainings and implementation guidance for the team. “There as a real focus on doing it right,” he also said.

None of these were things any of us had much prior knowledge of. There was a ton of research and trial and error. Everyone went down their own pet research rabbit holes at one time or another, which took time. Our manager admitted that she wondered at times whether she should have placed a deadline on more things in the project; she wonders how that would have changed our outcome. We used consensus rather than having a decision maker, and we were very thorough, she pointed out. Those things take time, and their products are different than a process where the group leader sets hard deadlines and makes the final call on ideas.

I have plans for a series of posts about this project, but for now I’ll just list the skills I improved during the course of it, with the goal of linking back to this list as I write the posts:

• Project management for group projects (how to keep all the notes)
• Influencing without authority (50 ways to not end a meeting)
• Fostering collaboration (how to kill your darlings)
• Collaborating with SharePoint sites (if you really must)
• Developing topic templates sans DITA (because it’s easier than asking for CMS)
• Internal selling/getting buy in (the clients want what?)
• Scheduling with clients (is far easier than scheduling with senior management)
• Demo scripts for multiple presenters (so people don’t hate their lines)
• Developing surveys (how to beat around the bush)
• How committees can keep larger teams happy (!)

I’m looking forward to these posts. It was worth examining what took so long, partly because in the process I was reminded of how well the HD group works together, now. There is more trust, we build on each other’s ideas, and we’re more efficient at producing those ideas. That experience of being on a strong team will serve us after the topic templates are long obsolete.

Why I Blog About Work

One day at work a year or so ago, I was reading Intercom at my desk on my break. Someone (a manager) asked me, “Don’t you ever shut off? You know, just do something else?” Actually, those might not have been the exact words, but it’s close. Reading that magazine was relaxing for me, though. I wasn’t reading about anything we were working on. We don’t use DITA. I wasn’t taking a break from drafting a formal communication policy. It was basically daydreaming. It was a fifteen minute break, not a vacation day.

I’ve been thinking of that remark when I count the weekly hours it should take to do this blog right. I think it’s worth it. In fact, that’s beyond obvious to me.

When I decided I wanted a blog, it was pretty simple to settle on this topic, technical communication. It was the only subject about which I felt sure I would always have something to say. At the time I was starting to appreciate movies and good television shows the same way I had always appreciated books. I considered a blog about being a newbie to television. I thought blogging about television would make me watch good shows and prevent me from mindlessly consuming programs. And I wouldn’t run out of things to say, I thought, since there is no shortage of programming.

I recently friended freelance writer Amy Vernon on twitter, who has a TV blog. It’s not from a newbie perspective, but it’s sort of what I had a in mind—an independent spouting off about shows. Eric Deggans does The Feed in association with the St. Petersburg Times that is enjoyable even though I didn’t end up becoming a connoisseur of quality programming. I’ll watch almost anything, in fact.

So, I wrote a couple of sample posts in Word and then I got bored. Writing about tech comm, I never get bored. I get blocked, I get “too busy” to post, I get worried that I’ve said to much. I don’t run out of things to say.

I blog to stay engaged. I blog to sort out what I think about an issue I’m experiencing or to get my thoughts straight about a project. Every post I finish is one more thing I have to talk about with people in my field. I blog so that I have a reason to ask those people questions. Right now, I ask senior tech commers questions, and they refer me to their blog posts. Eventually I’ll be able to do that.

I blog to have writing samples. I’m working on an article about business analysts, for example, with interviews and research. I blog so I can link from my resume to show that I helped solve work problems. Do I know Flare? Why, yes I do, and here are some posts about advanced project linking to prove it. I haven’t actually rigged up my resume like that, yet, but I will.

I blog because I spend more time tech writing than just about anything else, and if I still have something to say about it when the day is over, it’s part of my proof to myself that I’m in the right field. If I still have something to say, it means that I’m processing my work experience and moving forward, not just cranking out projects without reflecting on I’ve learned.

A blog post can be a postmortem for a project, it can be venting, or a request for conversation, or just a blip out into the world that I was here and I imported something into Flare today, even if it was only to produce a .chm.

I blog about work so that I never have to type about tech writing what I had to type about job coaching; so that I never have to say I wasn’t a very good tech writer.

What I’m after here is mastery. I think blogging is one of the roads to mastering a subject. Since I’m at work all day, and I’m in the right field, why not do all I can to be good at it?

How Job Coaching Prepared Me for Technical Communication

My first “professional job” was as a job coach. A job coach, or an employment specialist (my official job title) is the front line worker in the field of supported employment. Supported employment is a way of supporting people with disabilities in work situations.

The main work situation for a job coach to support is an individual with a job in the regular workforce. I helped the person find a job and get training that worked for them. Our team usually worked with developmentally disabled people, but supported employment is also helpful to people with physical disability and mental illness.

The assumption behind all of this is that most people with disabilities can work if companies, job coaches, and the individuals are doing their part. I love this assumption. I love the idea of having this goal that all three parts of that job equation have to keep working towards. Because it’s true, most people can work. And it’s good for everyone if they do.

I’m not talking about people who have taken disability for some reason after having been in the work force—I don’t know much about that. I’m talking about people who have gone through their lives watching other people take jobs for granted. There is a whole largely untapped pool of potential employees.

Some of the benefits to employers are employees who are less likely to job hop, tax benefits, improved co-worker moral and company image. And if a company looks at its positions and processes to see how they could be modified to hire someone with a disability, work flow can be improved.

I was not a very good job coach.

Looking back, it would have been so much better if I had learned more about task analysis so that I could recommend better job modifications and accommodations. I had some training on that, but I couldn’t imagine asserting myself as the expert to the companies I was trying to convince to hire my consumers. That’s business analyst stuff. Now it sounds fun; then, it was overwhelming.

It would have been so much better if I had had the outgoing, energetic oomph of one of my co-workers. She couldn’t help but network, and she was always on the beat, zooming in and out of the office in a whirl of interviews and first days on the job. Her sunny, hard-working attitude reflected well on the potential employees she represented. Hiring managers were helpless before it.

Job coaches generally spend a lot of time with the new employee during their first weeks on the job, providing extended one-on-one training that would be expensive for the employer to provide. It was intuitive, rewarding work for me. I like the problem-solving, and responding to what the person needed in order to do well. Sometimes it was a job aid, or an extra break, or retraining on a skill. But, often it was something more elusive. My inexperience frustrated me.

Still, I learned a ton. Here’s a short list:

1.Redirection isn’t just for kids.

I learn redirection when I was trained as a daycare teacher and used it throughout my job coaching experience–instead of scolding, redirect misbehaving kids to other activities without acknowledging the bad behavior. I constantly learn new ways to apply this. Change the subject. Stop talking about what someone shouldn’t do and talk about what they should do or what they are doing well.

This even seems to work for solving a thorny problem, like improving a process or making headway on an overwhelming project. If I spend just a little time enjoying the part of the task that is going well, it usually helps me think of a way to fix the problem area.

2.It matters what I do.

I worked with one woman to get a job at a daycare center. She ended up reporting two other workers who were using excessive force with the kids. If she and I hadn’t persevered to find a daycare that could see her worth, it might have taken longer to help those kids.

That same woman later ran away from her sister’s home with an older man who was probably taking advantage of her disability. Her sister thought that if I could talk to the woman, she might listen to me. Maybe she would have and maybe not—there wasn’t a way for me to get ahold of her. But it struck me what a responsibility I had.

Now I write instructions for medical devices and programs that influence patient safety. It makes me think twice when people say no one uses the help. Of course I want them to, but it’s a big responsibility. And as soon as it doesn’t matter what I do, I’ll go do something else.

3.People need to feel capable.

I worked with a lot of people who bagged groceries and washed dishes—and those jobs transformed them. Absolutely everyone benefits when that happens.

I’m going to draw a line here between that and our software users. What’s user error? Isn’t it usually our failure to structure the information (job) so that the user can be successful? I think this also applies to teams. How can a team get more capable if management is afraid to let them make mistakes?

4.There are types of intelligence, and a spectrum of intelligence per type.

Contrary to popular snark, there isn’t an invisible line with smart people on one side and dumb people on the other. People can have all kinds of combinations of intelligences, all kinds of strengths and weaknesses.

There is a medical definition–an IQ cutoff–for mental retardation. There’s an IQ cutoff for genius, too. But people have IQs all up and down that scale. The same is true for the types intelligence that don’t have such well-known scales, such as emotional intelligence.

My customer at the day care center was a whiz at punctuality and remembering details. I, ahem, was not. I’ve gotten much better, but there it is.

5.Everyone needs an accommodation.

I’m probably not surprising any managers here, but even your best performers may have some area where you might cut them some slack or compensate for their inability somehow. People should work on their weaknesses, but sometimes a person is only going to get so much better at something. You might be surprised by how much the person can help you gauge that if you talk to them about it.

What accommodations do our audiences need? Is the manual locked in the supervisor’s office during the night shift? Is this device commonly used by people who are on medication that clouds their vision? How will we know if we don’t research?

6.Accessibility and inclusiveness benefit everyone.

In tech comm we are getting familiar with the idea that web sites and documents that are structured well, with large print and good contrast, are easier for everyone to use, not just people with disabilities. The same is true of a workplace that is inclusive.

How Waiting Tables Prepared Me for Technical Communication

I left the restaurant business three times before I finally found something that worked better for me than waiting tables and bar tending – technical writing. Restaurant schedules can be a lot more flexible than office jobs, and,in Florida, at least, if you don’t like one restaurant you can probably switch jobs until you find a restaurant you like better. It’s a living wage if you’re good at it. It can pay very well if you’re great at it.

It’s physical work, it’s conducive to meeting people and making good friends, and it teaches skills that are absolutely transferable to other fields, such as sales, which I think is helpful in any field. Here are some that have helped me in tech comm:

1. Handling Volume

Every business has a regular busy time, or rush, and a restaurant has at least one almost every shift. There’s the rush, then there is getting slammed and being in the weeds–getting your ass kicked. In a restaurant, this can happen if a large group all arrives at once for some reason, such as all the squads coming in after a cheer leading competition.

Or, the right circumstances can come together to create a chaotic level of volume: Valentine’s day falling on a Friday, for example. In times like that, we were so busy that most of our standard operating procedures were maxed out: we were running out of chairs, running out of glassware, waiting over an hour for food because we got a crazy rush after cooks had been cut for the night. I remember the computer system crashing and having to manually process a slew of credit cards, or getting so busy that we had to stop running tabs so that no one ran out on their bill.

It takes poise and problem solving skills just to get through a rush like that without needing the manager to comp whole tables, let alone to make good tips. Some of that just comes with experience–having made it through once and seen that the restaurant keeps going almost no matter what.

In Fall of 2004, Central and Western Florida got hit with a series of hurricanes, and a lot of people lost electricity, but the Applebee’s where I worked never lost power. I remember several shifts during which the restaurant filled again and again with people who were stir crazy, starved for air conditioning, and tired of eating whatever had defrosted in their freezers.

There were several “hurricane shifts” that fall, but one that I remember particularly well. I was coming on as the night bartender, and the day bartender couldn’t go home. People wanted cocktails and commiseration about their damaged homes. We ended up with a thank-you letter for taking such good care of them.

I try to keep this perseverance in my tech writing job when the document seems never ending, and I’m finding hundreds of inappropriate screen shots that I have to replace, and I just got another request with an aggressive schedule.

Even when the volume of work seems unreasonable, it still has to get managed in one way or another. This is may be more apparent in the restaurant environment than in the office–the doors open and people sit at your tables so you have to keep going.

The work is more abstract in a tech comm department (maybe you’ll have to adjust schedules, or estimate how much help you’ll need, or suggest a compromise in what the files will contain) but the principle is the same.

2. Making it Look Easy

Servers wait for the rush like surfers wait for waves because that’s when they make money. When the rush is not happening, they are making $3.13 an hour and probably being harassed by management to clean something. But they don’t make money during the rush if they look too rushed.

Sweaty, abrupt, disheveled servers who are making mistakes because they have too many customers don’t get good tips. And they don’t deserve them. They’re not giving the customer a good experience.

I struggled with this in the restaurant and eventually got better at it, but the calibration is even more sensitive in an office environment, in my experience.

Restaurant work is physical work, so there is some discharge of the adrenaline it takes to get through the rush. In an office, people are sitting quietly, and even a nonverbal disturbance can reverberate through a large room of cubicles until every department on that floor knows that something is going on, even if they don’t know what it is.

Emotional reactions and negativity are disruptive, so every success at minimizing them is helpful to co-workers. My office job seems to offer an endless supply of lessons in self control. A challenge I have is that I can get a little over-enthused solving a problem, and I tend to think out loud, which can sound an awful lot like complaining. I like to debate, too. I imagine what qualifies as disruptive depends on the group.

Does anyone else think this might come naturally to a lot of people who are Generation Y? Or maybe is it more of an introvert thing? There seems to be a code — anything that makes your effort and exertion apparent can probably be done in a better way.

I’ve seen this carried through to a fault (passive aggression, or shunning enthusiasm for a project), but I think it is largely a pretty good rule of thumb for someone like me who is practicing restraint. I’m Gen Y too but, for whatever reason, this isn’t a code I’ve naturally adopted. I’m an extravert and I like that, but like I said, I’m practicing.

3.Watch Your Mouth, Customers Can Hear You

Out in the dining room, if you’re a server or a bartender, it’s unprofessional to swear, or complain about the cooks, or discuss your sex life. There are customers within a few feet of you at all times.

If you are a technical communicator in an office building, it’s literally almost the same situation. Your customers aren’t just the product users who are reading your documents. To some extent, the other teams are your customers–they are relying on you for the service you provide.

If you complain about the process, then someone is going to look bad for not improving it. Maybe you. Maybe your boss, which diminishes his or her effectiveness when going to bat for you.

If you badmouth a project or a tool because there was a misunderstanding, or a learning curve, or a bad day, that can snowball pretty easily. Pretty soon, someone from the Education department is saying to you, “Yeah, I heard there are a lot of issues with Flare and the new format.” And you’re thinking, There are? That was one of my favorite projects.

Gossiping falls into this category, but it’s also related to the idea of not disrupting the work environment. Someone can hear that you talk about everyone, no matter how discreet you think you are. It breeds mistrust, which is a frustrating distraction to have at work. The more people can feel comfortable at work, the better, since we rely on our job to pay for our homes and food and all.

Gossip is really common and sooner or later everyone needs a strategy for surviving it, but why be that person emitting little puffs of poison into the office?

4.Doing Things All the Way

In a restaurant, no matter how inconsistent or forgetful he or she is, almost every server will get regular customers, or “regulars.” I was popular with little old couples, for example.

But the people who have the most regulars and get the biggest tips are the ones who do all the things you are supposed to do for the customers–they bring the right things at the right time, they don’t let dishes and napkins pile up on the table, they remember what people like to drink and what their kids’ names are, and they are fun while they do all that stuff.

There are plenty of servers who do some of those things, and they have some regulars. The few who do it all consistently have regulars who will wait for them to have an open table, or who end up taking up tables in other server’s sections.

What is doing it all the way mean in tech comm? What comes to mind for me are these things: always finding a way to not only finish the iteration, but to improve the document every time. Staying on schedule, keeping consistent communication about status with the project team and with management, consistently suggesting ways that tech comm can improve customer experience, consistently identifying ways that team processes can be improved. And making it look easy.

Screencasts: So What?

A woman in our department has been researching video for our help systems. People have been excited, but until yesterday, I must admit I wasn’t sure why. I attended a webinar about screencasts and read about how video might be a watershed skill for our industry, but the only reason I had gleaned was that YouTube is really, really popular.

I rarely watch video online. Unless it’s a funny meme I have deliberately searched for, or a show that I missed, or Netflix, I won’t press play. If a blog post is all video, I skip it. I rarely appreciate video instructions, either–they take too long, because I’m pausing, following the step, playing, pausing again. I was having trouble imagining how videos were going to improve our help systems or fit into our schedules.

Then came the product presentations. Our manager assigned us each a presentation about one of the products we document. The idea was we would learn more about our systems and how they integrated with each other. This assignment, and the results (if our training survey
is an indicator) were not joy and enlightenment. More like dread and boredom.

The writer who is researching video for us, Stacey Fiedler, does not do public speaking, or attention, or presentations. I gave her the option of leaving her name out of this post, which I’m glad she didn’t take me up on, because what she did to get around the public speaking part of the assignment was so good that she deserves major credit. She made a screencast. A badass, totally well-done screencast that I’m pretty sure everyone wished they had thought of. I wish I could show it to you here but the content is proprietary. Plus Stacey would not appreciate it.

We arrived for the presentation and Stacey pressed play. The video explained all the functionality of her product to us, at a high level, without her having to talk. And we liked it. I would have watched it again. I can’t say that about any of the other presentations, and I don’t think anyone would say it of mine. I’m embarrassed to say that my standard of watchability for my presentation was, “I don’t think anyone will lose their mind from boredom. I hope.” Like, at the most.

Another great thing: this product has historically had a bit of an image problem about being hard to use, and Stacey’s video made the product look easy. I laughed, I oohed and aahed at the graphics. I was enjoying the music and the smooth mousework, and I swear to God, I pictured myself clicking around competently in the product experiencing the same feelings I had while watching the video. What I mean is, the video evoked the feeling I get when I’m getting good work done to good music. I wanted to use the product. Hello? Major tech comm goal.

Another achievement: if I opened a help system and it had that video, I would immediately open every other help system in every other product I owned by that company. When I hear all the time, “ha, well no one is going to read this, anyway,” that is a big deal. That is key.

Okay, so obviously Stacey worked very hard on the video, and put a ton of thought into it, and the process was time consuming. She ended up with a video that–if the audio was redone with songs we had permission for– our sales manager should be proud to show prospective clients. I’m not kidding. If that video only lives in our training archives, it will be a damn shame.

So I have hope for screencasts. Not to replace our hundreds of procedures, but to do something new that we are missing entirely right now. And, I hope we are going to think about what that is and do it right. Because so far, my impression is that screencasts may be like newsletters–if the first one I open is packed with good content, I’ll probably open the next one, too. If not, I probably won’t.

***

I showed this post to Stacey at work today, and this is what she said:

I guess my Public Speaking professor was wrong when she said that I would need to become more comfortable when giving presentations because otherwise, I may miss an opportunity to get my message across. Ha!

In all seriousness, I think video is an incredibly effective tool for conveying a lot of information without overwhelming the user/audience. It’s stealth rather than gorilla. That really appeals to me.