- Marie Kennedy is the Serials & Electronic Resources Librarian at Loyola Marymount University in Los Angeles, CA. This blog is about organization, librarianship, and sometimes monkeys and/or bananas.
Archives
Categories
writing a step-by-step guide to a task one does every day is difficult. imagine i’ve just asked you to write down how you make a pot of coffee: you scoop, pour some water, press the button. you don’t even think about it, right? now imagine that i’ve never made a pot of coffee and don’t know where to put the scooped grounds, or how much water to use. it’s important for you to tell me explicitly. this is the approach i take when i direct somebody to write a procedural document: imagine that i’ve seen a coffee pot, but never actually used one. perhaps i’ve had a monkey butler bring me my coffee all my life but i’ve now fallen on hard times and must learn to make it myself. i need your help.
start your document with a one or two sentence introduction of the task you’re going to describe. be sure to note which computer software is used to perform the task, if any. if there’s anything you want your reader to consider while they’re performing the task, include it in the introduction, before you launch into the steps. commit to using no acronyms or jargon throughout the document.
in an ordered list, write each step of the task on its own line, in its own number. consider that each step should be small. if you find yourself writing more than a sentence or two per step, you’re probably describing two separate steps.
the last step of a document should be a summary of the completed action. for example, you may say, “once you’ve pushed the brew button twice, the machine will start to brew the coffee and will be ready in about five minutes.”
i’ve reviewed documentation over the years and have not been able to discern the provenance of the file, which can be important if there are two documents in a folder with similar file names: how does one distinguish which is the current document? by inserting date information into a footer or header of the document, the metadata travels with the document. note in the footer the author and on what date the document was written (include year) and what the path is if the document is stored on a shared drive. include the document name in the path.
example: written by Marie Kennedy 2/26/2009. G:\Acquisitions\Documentation\make_coffee.doc
if that document is reviewed or revised, keep a copy of the original in an archive folder. G:\Acquisitions\Documentation\Archive\make coffee.doc. on the new document, include the review [no changes made] or revision date in the footer.
example: written by Marie Kennedy 2/26/2009, reviewed 2/27/2010. G:\Acquisitions\Documentation\make_coffee.doc
finally, here is a small example of how a document can be written:
This procedure describes the steps for making coffee in the Braun coffee maker in the Acquisitions office. The coffee drinkers in the office prefer spring water to tap, so use the bottle of water underneath the sink to make the coffee. Extra cups are next to the water bottle.
love monkeys? yes.
want to see pictures of the latest pictures uploaded to flickr with the tag “monkey”? yes.
drop this url into your favorite feed reader: http://api.flickr.com/services/feeds/photos_public.gne?tags=monkey&lang=en-us&format=rss_200
let’s say you want to see the latest pictures uploaded to flickr using some other search term than “monkey.” for example, try using “organize” to see what people think something organized looks like. here’s how:
here’s a screen shot of what to look for at the bottom of the page:
“uh huh, i see.” “and then what?” “what do you do when that window pops up?” “and what does she do with it once you put it on her desk?”
it recently occurred to me that i’ve been an anthropologist in my own office since starting my new job. the position i fill is brand new for the library, and i’m spending quite a bit of time figuring out where my skills enhance the work already going on here. in order to be sensitive to the culture already established in the library i’ve been asking a lot of questions and gathering data before actually defining what it is that i will do here. the least obtrusive way i could think to begin the process of evaluating existing workflows (part of my official job description) is to write a documentation manual.
i’ve been asking people in my department to write down the steps they take to accomplish a specific task in a draft form, and then sitting with them to talk through those steps one at a time. what an eye opening process! in addition to finding out how they do the work they do, i’m getting bonus information: how they wish things could work; they always get stuck at step 5 and writing it down helps them remember; or they’re not really sure what happens once they finish their portion of a multi-person task. once the task has been documented and discussed, i’m having them train me to do that task using the documentation. the training process brings up all other kinds of issues: forgetting that we actually do step x before step y; thinking on the fly of more efficient ways to do things; gaining confidence in knowing that they really *do* know their stuff.
all in all, gathering documentation has been a success. we started this process by creating a student manual, and that has come in handy a number of times as students refer back to what is written down as they are trained to perform a new task.
leave a comment if you’ve done this yourself, or if you think of other things to try.
i’ll be in seattle next month for acrl and have been saving my $ for a giant splurge at archie mcphee. i hope eagledawg has time to meet me there to geek out.