What motivates you to work most likely motivates most of your users in their jobs, too! You still need to know your audience, their tasks and background, but the good news is that you have some basic motivators in common. And these can help you understand what makes you happy at work – and what makes your users successful in their work with your documentation.
The three motivators
I take my cue from Walter Chen’s post “The science behind what motivates us to get up for work every day“. I want to focus on three motivators Chen quotes from Daniel Pink:
The 3 real reasons that motivate us to work hard every day
Pink explains … that there are in fact just 3 very simple things that drive nearly each and everyone of us to work hard:
- Autonomy: Our desire to direct our own lives. In short: “You probably want to do something interesting, let me get out of your way!”
- Mastery: Our urge to get better at stuff.
- Purpose: The feeling and intention that we can make a difference in the world.
The motivators for technical communicators
Pink’s model resonated with me, and I think this is exactly what motivates me to do good tech comm work and try to get better at it:
- Autonomy for me means to find something good in the benign neglect that often meets my efforts. Of course, I have specific products, deliverables and deadlines to comply with, but our documentation team is lucky enough to be able to define its own standards and processes as long as they’re feasible.
- Mastery is the challenge to write better documentation. When I revisit obsolete documentation that I’ve written some years ago, it makes me smile: Seeing where I’m coming from and what I wouldn’t do anymore gives me a sense of progress. I’m still using task orientation and topic-based authoring – but I wouldn’t awkwardly mix concept and task in the same topic like this anymore.
- Purpose for me is my reward that my readers can be more successful or simply faster in their work if and because I’ve given them the right information at the right time.
So in a very personal, non-scientific way, I could validate these three motivators.
The motivators for documentation users
I don’t think I’m all that different from my readers in this regard. I believe they get motivated by the same things – they’re just in a different job.
So I try to keep in mind the motivators when I structure and write my documentation:
- Autonomy is tricky, of course. Someone looking up documentation has just given up the autonomy of a self-directed life and needs instruction or information. But I still try to acknowledge this and follow Pink’s advice above: “You (dear user) probably want to do something interesting (or important), let me (give you what you seek and) get out of your way!”
- Mastery is where tech comm can really excel. By presenting essential information concisely and clearly we can make it easy for our users to master their tasks and their use of our product. For this mastery, it doesn’t matter whether users learn from the documentation and internalize a skill or whether they simply know where they can look up again quickly what they don’t need to remember.
- Purpose is frequently neglected, I think. Often documentation focuses on the how, and forgets the why. But there is no sense of purpose without a why. Granted, not every topic can address the big questions of life and the universe. But as long as there is an elegant and possibly noble reason for why our product and its tasks are this particular way, it’s worth sharing it. It will give our customers an extra motivation – and make them more loyal users.
Is this what motivates you? Does it work for your readers or do they have other motivations? Please leave a comment.
Filed under: cognition, creativity, motivation, productivity, technical communication, users | Tagged: Daniel Pink, Walter Chen |
Kai's Tech Writing Blog 
Hi Kai,
thanks for that post. It made me think about jobs in the past where I lost motivation after some time – and one of these factors was always bad (most of the times “autonomy” or “purpose”). So for me the model seems to be true 🙂
“Purpose” would be indeed a great motivator for a tech communicator but one hardly gets user feedback. I guess a lot of writers have that uncomfortable feeling of not knowing if these help articles help at all. Also you get to hear that “No-one reads the manual” cry all the time from colleagues.
Cheers
Marijana
Thanks, Marijana, for your comment (and your patience – conference season delays my commenting unduly…).
Indeed, “purpose” can get tricky if user feedback is lacking. I’ve found it helps if you can get behind the product you write about even if it’s a fine line to tread, because I think we should avoid sounding like marketing and sales.
And once I’m confident that my manual is actually pretty good, I sometimes tell colleagues: “Well, maybe you SHOULD read the manual for a change – you’ll find it quite helpful…” 🙂
Hi Kai,
Respecting the reader’s desire for autonomy is indeed a challenge for writers. On of the themes on my blog is Writer vs. Reader — the interests of readers and writers are often antagonistic, which is reflected in the way we talk about “capturing” and “holding” the reader’s attention and in the way we worry about readers skipping and skimming and getting distracted.
Perhaps it is our desire for mastery and purpose that manifests itself in a desire to take charge of the reader’s reading experience and to keep them focused on the curriculum we have laid out for them.
But, as David Weinberger points out in Everything is Miscellaneous, the power to organize content has passed from the creators to the consumers, from writers to readers. The Web give the reader autonomy over their reading experience.
For many writers, the response to the new found freedom of readers has been to try to roll the clock back, to reestablish the writer’s position of power over the reading experience. Such attempts are ultimately vain — the power is all in the reader’s hands now. What we should be doing, if we really want to serve our readers, is to start writing in a way that cedes control of the selection and ordering of content to the reader, and facilitates them in selecting and ordering content for themselves.
Thanks, Mark, for your comment! Maybe it’s just me, but I see most of my documentation as a “modest proposal”. It’s there if you want it, I tried to structure it, so you’ll find it convenient to use. I don’t mind readers skimming and skipping, if that’s the way they want to navigate. But if they’d rather ask a colleague or call customer support, that’s fine, too (we charge for customer support… 🙂 ).
And I don’t feel this diminishes my purpose or the value of my documentation, I still think I create and add value to our product, but it’s up to the users to take advantage of that.
Maybe that’s why I’m so keen on creating documentation which is seductively meaningful – see my previous posts on meaning in tech comm…