Lessons Learned: Procedure Written in Twitter

Last week, I thought I’d experiment and write a quick procedure in Twitter. This goes right along with my thoughts that new methods should be used for creating docs. Given that microblogging is here to stay, as is real-time, I decided to give it a try. There were two main thoughts in play: see if it was possible to condense a procedure into steps of 140 characters or less, and test a real-time situation, as trending topics always appear in Twitter and it may be necessary to write something there. Plus, I thought it would be fun. Which it was.

Thus, my exercise in microblogging a procedure began – and evolved immediately into a real-time writing event. I learned plenty in the process, as you’ll see below.

Content Development

Twitter-Specific Considerations

- Read from bottom to top

- No bold, italic, or formatting of any kind

- Tweets might get interrupted by other tweets, as new ones come in continually. Hence, you can lose continuity.

Writing Approach

- Included numbers in all the procedure tweets. This included the title tweet to set off the series.

- Combined steps when possible

- Abbreviated content and used snippets instead of full sentences

- Wrote procedure immediately, posting one tweet as soon as the previous one posted. This was to limit the possibility of new tweets coming in which would break up the procedure.

- Wrote very quickly. I used an existing procedure written in more detail. Took the steps and modified content (as noted above) to fit in tweets. Did this on the fly; not beforehand. You have to edit as you go to fit steps into tweets and determine what to include in each.

Input from Users

I actively asked for input. First, it was when I initially published the tweets. I wondered what other tech writers thought about it, not really knowing what to expect. Then, I asked for comments as I went, and incorporated some and updated accordingly. I continued to ask for and incorporate suggestions as appropriate.

What was really great was the amount and depth of input that came in. That immediately changed the situation from a one-writer task to a collaborative effort of a makeshift team, in effect. It was as though an ad hoc team formed for a moment in time, discussed items, and then immediately disbanded. It was completely virtual, and people didn’t know each other, really. How cool is that? What potential there is. I suppose that’s the nature of virtual communication these days, but it’s still interesting on a real-time basis.

Of course, the flip side is that you may end up with too much input. That’s where triage mentality will come into play. You’ll have to decide what to include and incorporate right then and there. Also, you may want to address some items immediately, and others later. Some you may need to review more, depending on content and whether or not you think the input would be applicable or not. There will be many, many such decisions to make on the fly.  My thought is that you still want all the input you can get, even if you can’t get to it at the moment, or if it’s not something you’ll eventually integrate. If there’s too much, perhaps you could write a tweet that says something to the effect of “Addressing input as quickly as possible. Please keep sending comments.”  Then review everything when things calm down, or enter a revised procedure afterward.

Also, if you were in the midst of a rush to get out information, wouldn’t you want to know of anything you missed? If it’s critical, if it’s a negative viral situation, then you want to hear what people are thinking. And then you need to address it. Either you fix it right then, or write a new item for your FAQs and have a link to it in a tweet.

Just as there’s no such thing as a stupid question, there’s no such thing as bad input in today’s world. Ignoring input could prove disastrous. You have to be open to suggestion.

Managing the Process

If possible, I would definitely have an entire procedure already written, or at least sketched out. This enables you to input tweets one after the other (as noted above), editing as you go. It may not be perfect – there may not be time for that, but you’d have a base from which to work.

Deleting and Revising Tweets

You can’t really delete a tweet and rewrite it, or insert a revised one in the exact location. Well, OK – technically, you could delete one. However, you would lose continuity and break the procedure. Plus, the tweet is still there, archived somewhere, so could show up at a later date if someone looks for it.

This begs the question: when do you leave a tweet as is, even if not completely perfect or correct, and when do you rewrite the entire procedure? My gut response is that if it is not correct in a major way, then it must be rewritten. My belief is that accuracy is still the most important aspect of tech writing. That may be old-school, but it’s still my mantra. Makes sense to me. However, I’m all for lightening up a bit with the rules of tech writing. When you’re working in Twitter, I think you need to bend them once in a while.

Managing Input

I was very busy handling input from just several people. Also, I purposefully tried to address comments and update accordingly immediately, to put as much pressure on as possible to see what would happen. I didn’t want to think much; I wanted to react. That’s a situation I can envision occurring some day. However, I was sure enough of the procedure that I thought people would basically be able to figure it out. That was based on the audience; I assumed familiarity with using Twitter.

If the procedure had been more detailed, I would have:

- Posted a tweet that a procedure was being worked on at that moment

- Created a longer version somewhere and included a link to it in a tweet

- Put a bare-bones procedure in Twitter, as best I could

Posting Updates

I felt it was very important to provide status updates as I went. That was an important part of the exercise. It’s also one more decision to make on the fly: how often do you update people, and where do you do so? What information do you include in the update?

I added new tweets, and updated my blog post with new information for each update. After the first update, I added time information as well. There were two reasons for that: show that it was actively being worked on, and enable users to see what information they want to focus on, given the time of the update. That may prove critical in some cases, so I think I’d always include times in posts. For tweets, the timestamp is automatically included.

In my case, I posted updated tweets designated by “UPDATE” as the starting. Example:

UPDATE: Create Twitter List proc (12/29). New: step 6 > List created; add feeds by selecting in Followers list or searching (proc follows)

UPDATES: Create Twitter List proc. Update 2: fixes 12:45 pm. Update 3: thoughts 1:13 pm http://bit.ly/53eoe5

Conclusions – Recommendations

- Use Twitter for procedures in a real-time situation. Also, start using it frequently. People use Twitter to disseminate and find information. Docs should be there in one form or another. Either write procedures, or link to online docs.

- Keep the number of steps to a minimum. Keep in mind that you may need to add a step number to the title.

- Provide regular status updates.

- Set up internal processes for handling real-time situations.

- Set up a separate support feed for procedures and announcements.

- Do not even think of writing perfect procedure tweets when you’re writing something quickly. In some cases, that might be possible. However – always keep in mind that if you don’t post the tweets immediately, one after the other, they may get lost in between tweets from others. Just as it’s more difficult to follow a driver to a destination you’re unfamiliar with if a car gets in line between you and the lead car, it can be difficult to follow a tweeted procedure if tweets get in between posts.

In this situation, it’s also true that someone can select your feed on its own, and you’d see the procedure in its entirety as you intended. You can’t assume that, though. Are people likely to just switch over to your feed? Probably not at the particular time you’re writing. Later, perhaps. Don’t count on it, though. (This is another argument for setting up a separate support feed.)

Writing the Tweets

- If it’s a crisis – provide frequent status updates

- Update FAQs or base online docs simultaneously

- If it’s an immediate event, determine if a team response is necessary – or be ready for one if it escalates

Resources Required

I think that you need one or more writers to:

- Test and write tweets

- Update FAQs or main docs

- Update a blog, website home page, or other location for real-time status

- Monitor and answer tweets from users

- Line up reviewers to gauge response (per suggestion from Larry Kunz)

Plan

- Triage incoming tweets: which to address, and when?

- Triage updates: when, where posted? What if the format for each option?

- Who does what: (see Resources list above)

- Tech support coordination: set up processes

- Escalation plan: when to call in more resources or managers

That’s all I can think of at the moment. If anything else comes to mind, I’ll just update this post.

Notes

Would I do this again? Absolutely. It was fun, for one thing. There’s much to learn, for another. Finally, and most importantly, I think it’s here to stay, so we better determine how to microblog docs.

More >

To see the procedures and input, look at my feed for 12/29/09. You can also find additional comments by searching on @2morodocs.

Thanks to Larry Kunz (@larry_kunz), Julio Vazquez (@juliov27612), and David Farbey (@dfarb) for comments and offering input and suggestions real-time. That was fun.

http://www.twitter.com/2morodocs

Related posts:

Real time: it’s sooooo last second
My First Procedure Written in Twitter