Category: Work

Last year I read the book Made to Stick, in which the phrase “The Curse of Knowledge” makes an appearance. The authors of the book will be delighted to know that the phrase stuck in my head and I can be heard applying it in all sorts of scenarios.

The principle is quite simple:

Once we know something, we find it hard to imagine what it was like not to know it. Our knowledge has “cursed” us. And it becomes difficult for us to share our knowledge with others, because we can’t readily re-create our listeners’ state of mind.
Made to Stick

For example, during the course of an average week I will have several conversations with people who have a lot more knowledge of a specific thing than I do. Typically these will be software developers who have an in-depth knowledge of computers, how they work and most specifically how they thingmajig they are currently building works. There is a lot of presumed knowledge in these discussions, some rightly (I do know the principles of object-oriented programming) and some wrongly.

And, of course, I do exactly the same when talking to others. Everyone does it, it’s human nature. Where it really starts to hurt is when the Curse descends upon your technical writing.

I’ve fallen into this trap myself, and we do try and peer review our output to make sure a non-expert is looking at the documentation (non-expert in the specific area but still within ‘target audience’ boundaries of knowledge) and, largely, that’s the best you can expect to do with the typical resource and timescale limitations we all worked within.

There is another aspect to technical writing which falls prey to this Curse. There is sometimes a level of disassociation at play as we focus in on word usage and the grammar of what we write, rather than trying to use our information as a user would. It’s a fine distinction but using the software and documenting it is not the same as using the document to use the software.

You may, or may not, have heard the phrase ‘Tipping Point’ used to signify “the moment when something previously unique becomes common“. Made popular, although not created by, Malcolm Gladwell, it can be applied most recently to the explosion of people using Twitter, and previously to such web applications/social networking websites, as Facebook.

Which, rather nicely (gee, it’s almost like I planned it!) brings me to my topic. Namely, Facebook and is it starting to tip away from ‘common’ towards something else.

I’m not quite sure where Facebook is tipping towards but there does seem to be the beginnings of a swell, a murmuring of discontent as Facebook continues to grow and tries to adapt itself accordingly. Basically, on a more and more frequent basis, Facebook seems to be starting to irk some people.

In that respect, it’s very much like the noise that preceded it’s massive growth but on the opposite side of the slope, the word of mouth is heading towards negative territory. Anyone else think so? Just me?

I don’t like making presumptions, something that I learned early on in my technical writing career, but I am going to presume that anyone who reads this knows that they should be planning what content they produce before they start writing. You do, right?

A basic information plan will include knowledge about the audience, the main areas of the information that need to be covered for the project/release, as well as outlining the purpose of the documentation and any media and design considerations. Finally you’ll most likely provide a definitive list of deliverables, be they printed documents, PDFs or online help.

It’s this last area that I’m currently working on.

Our product has undergone some exciting changes, and the previous set of documentation was both very document-centric and , in my opinion, badly structured. We are shifting more towards a ‘traditional’ SDK approach and as such a lot of the existing documentation needs to be adapted accordingly.

Thankfully it’s largely an exercise in restructuring the documentation rather than completely rewriting anything, but it still warrants discussion with the audience as to how best to present the information they require. In that respect I’m lucky to have direct access to a representative portion of the intended audience as the bulk of the audience will be our own staff.

The functionality available in our development kit is broken into sections, with the documentation split along similar lines, and as such whilst the information in the current documentation is fine, it no longer makes sense to have it structured that way. Breaking down all of the documentation into smaller, more manageable chunks, before deciding how best to piece them back together is the current focus.

Thankfully, in preparation for our move towards single source, we had already audited our content and so, if nothing else, I have all the discrete sections of each of the current documents already list in a ‘management friendly’ spreadsheet.

So, with a bit of manipulation I can easily mockup a sample set of information topics, and then figure out how best to present them to the audience, be it PDF, online help, or via the web.

Once we’ve got a good idea of our final deliverables, I’ll run them past a sample of the intended audience to make sure they are both what is required and to set the expectation of what we are, and aren’t, delivering. Hopefully, gaining buy-in to our plan as early as possible will mean the information we provided is better received and may even start further discusssions around future improvements.

It begins “Dear Sir/Madam,” and, being the former, I read on.

“Objection to proposed Mobile Phone Base Station (Aqua Court/Nature Trail, O2 Cell Site: 040762)”

I pause at this point. I have an O2 mobile phone, it has a crappy signal in my house, the new cell site would be up the hill a bit, off to the side of the road (not a particularly nice site either, ignore the bit about ‘nature trail’ it’s a path between two housing estates).

YES! FINALLY a better mobile phone signal. BRILLIANT!!

Then I remember that I live in a community and, perhaps, there are good reasons as to why someone would object to having a good mobile phone signal in their house. I pause and despite some serious thinking whilst I watch an episode of Scrubs (the one where they all drift in and out of a medieval fantasy, hilarious!) I can’t think of any off the top of my head. I can only surmise that, with it being 2009, if you don’t have a mobile phone you must be ‘of an age’ that views those that carry them as suspicious, communist-card toting luddites. Or hippies. Or, god forbid, a Liberal Democrat.

So I return to the missive and read on. And on. And on. I’m less than half way through the first few sentences when I give up.

I know who has put this through my door and I’m sure he means well but I’m hungry and can’t really be bothered reading it all. However I vow to read the rest of the missive later, noting that the return address is included, figuring that once I’ve done some of my OWN research I may (or may not) sign in agreement and post it off.

I do note that there is no option to disagree with the stated objection, thereby agreeing that the erection (waahey!) of the base station should go ahead, but decide to cross that bridge later.

My troubles behind me (for such things do trouble me, dear reader) I turn my attention to more timely and important matters, namely unlocking Everlong by the Foo Fighters in Guitar Hero World Tour on the Wii. I’m midway through one of the songs in the setlist (Sweet Home Alabama by Lynnrd Skynnrd if you must know) when the doorbell chimes.

I pause the song, annoyed, and stomp to the front door. Lo and behold the very man who pushed said missive through our letterbox today is back to “collect my signed copy”.

Now, I’m a reasonable man but there are a few things that irk me greatly and one is people who make assumptions on my behalf. That just makes an ass of you and an umption of me, and there is nothing I hate more than being an umption, let me tell you!

“Ahh I’ve not signed it, not sure I will to be honest”, says I, confident that’ll put the wind up the cheeky sod.

“Ok, no problem, cheers”, he says, all too cheerful. How very dare he! Not only has he made me an umption of me, but he has the gall and sheer affrontery to be cheery about it!

I am irked, possibly even miffed, by this and am left with no other option.

I reach out and grab him by the throat and, whilst squeezing his windpipe and cutting off his air supply, I reiterate my dislike of being an umption and, just when he’s approaching his final breath, I let go. He drops to the ground and I stand over him for a moment to make sure I haven’t killed the old bugger (he’s 70 if he’s a day) and, satisfied he isn’t going to die whilst on my property, consider the matter closed.

I turn and close the door firmly, but not before he’s choked out a final “sorry to have bothered you…”.

So, dear reader, I’m sure you feel my pain. It seems I shall remain adrift in a calm sea, with no mobile signal to billow my sails.

Bugger.

For a while now I’ve been watching video presentations from the likes of the TED and GEL sessions. Largely these are delivered by people who are at the forefront of their field or who challenge common perceptions with some unique thinking.

The TED (Technology, Entertainment, Design) sessions can be a bit random but they are always entertaining as they are delivered by people with a real passion for what they do, to an accomodating audience, by experienced presenters. It’s a good combination.

The GEL (Good Experience Live) conference is, as the name suggests, focussed on good experience. Which begs the question “What is good experience?” but there are others far better versed in giving an answer to that question so I’ll leave them to it (you may find some answers on the conference website).

It was on the latter website that I recently watched a presentation by the head of OXO (Note for UK readers: this is an American housewares company, not the makers of gravy cubes). Alex Lee, President of OXO, delivered a presentation featuring some of their products and outlined some of the guiding principles they follow, one of which he stated as:

“Helping people without the stigma of being helped”

Sound familiar? Have you heard something similar when discussing why “no-one reads the documentation”?

I think the first person who I heard mention this was Matthew Ellison at one of the Digitext Help Conferences. It was early in my career and did strike me as quite fundamental and a little bit hard to fathom. As a Technical Writer my main goal is to make the life of the user better (to give them a good experience when using the software by aiding them through those process), so to hear that there was an issue like this that blocked someone from accessing the documentation I was so carefully crafting was quite a shock.

So how do we, as technical communicators, deal with this issue? How can we help our users get past that stigma?

I’m interested in hearing your thoughts on this, I have a couple of ideas in mind but nothing firm. Is this something you try and cater for in your product information? Do you have any way to influence this in other areas of the product? What techniques have you deployed that help get users ‘into’ the documentation? Is there much of anything that we CAN do??

I’m off to dig about for any research into this area, feel free to leave your thoughts and ideas in the comments, or email me direct.

I’m currently part of a cross company initiative (started at the grassroot level) that is aiming at improving our product based information, making the messaging more consistent and ensuring that our customers hear get the information they need, at the time they need it. This is from Marketing down through Sales and into the product documentation itself.

Everyone involved understands the benefits and can see the potential we have if we take this approach. Ultimately it should decrease the information silos across the company and make sure that duplicate content is kept to a minimum. It’s fair to say that, at present, our company is at Level One (with Level Two pretensions) on the Information Process Maturity Model:

“Information developers work independently, designing and developing their content in isolation from other developers in their organization.”

The common aim (and at this point I’ll point out that I’ve not mentioned the IPMM to anyone else yet, but have had it in my head as I helped start the initiative) is to get to Level Three which seems like a good place on which we can build further in the future. Level Three states:

“Information developers are encouraged to form teams to plan, design, and develop content regarding the same product or process. Opportunities for sharing content among deliverables increases because developers are more aware of the content being created by their colleagues. Developers frequently form self-organized teams to jointly produce a result.”

The good news is that, purely because some of us are already talking about the product information, there are other people starting to consider doing the same for other areas of information.

However there is something that will block us and that is the age old problem of document management, and yes the title of this post hints at what we are considering using to help us solve that problem.

The nature of the information we will be producing is very document-centric as a lot of it is written with mind to handing it to a (potential) customer. Currently there is likely to be a small group of people who will be authoring the content, and we had considered using our SVN repository to provide versioning and access control. We’d then publish the documents to a central location on the network.

Still not ideal but, given the current economic climate, it was a free solution for a grassroots level project and we all agreed it would be better to prove our approach was correct first before going cap in hand to ask for funds for a document management system (there are other reasons we shied away from that solution of course, administration and maintenance being one of them).

Then, by chance the other day, one of my colleagues mentioned that he’d just gotten in new MSDN discs and license and he spotted something called SharePoint and “hey, isn’t that something to do with documents? Can you guys use it at all?”.

After rolling my eyes a little (I thought I’d broken that ‘you are the document guys’ mode of thought already!), I realised that yes I could use it, and that it might well be ideal for our cross company initiative.

And so it is I come to find myself reading up on SharePoint installations, configurations and usage. My first port of call will be Tom Johnson but if anyone else has any good pointers please leave a comment.

I’m not entirely sure if it will meet our needs but, if nothing else, it’ll be good blog fodder. Consider yourself warned.