The world is mourning the death of Steve Jobs, founder of Apple. He has been hailed, quite rightly, as a creative genius, a brilliant and revolutionary designer, and a bold visionary who completely transformed the world of personal technology. (Full disclosure – my first computer was an Apple IIc, way back in 1985. It was also my last.)
As brilliant as Jobs was, he was also stubborn, arrogant, and an extremely demanding perfectionist who was openly abusive towards his employees. In fact, his arrogance and hubris probably killed him. He refused medical treatment for nine months, insisting on treating his cancer with diet, acupuncture, herbal remedies and a psychic. This delay most likely shortened his life.
Jobs was influenced by Buddhism, which explores the connection between mind, body, and soul. Given how cruel he could be to others, and his frequent violent rages, one could say he had a “cancer of the soul”. Buddhism suggests that a disease of the soul can morph into a disease of the body. It’s a medical fact that some diseases have a psychological basis. Whether this was the case for Jobs, we will never know, for he now resides in the iCloud.
(Speaking of life and death, we now know why Apple devices don’t have an on-off switch. Jobs felt that an off switch represented death. It symbolized for him the terrifying prospect that we’re all machines that simply “power off” at the end of our lives.)
These observations are not meant to criticize or judge, but to point out that no-one is perfect, and that there is more to a person than their technical abilities.
An Untechnical Communicator
A technical communicator may be a technical genius, like Jobs. They may have extensive experience managing a wide variety of complex documentation, thorough knowledge of all the major tools, and can speak twelve languages, human and computer. But if that person comes across as arrogant, obnoxious, highly critical of others and emotionally unintelligent, they will not succeed at job interviews. Even if they do land a job, they may have a tough time keeping it. Jobs himself was fired from Apple, and it was a long road back for him to regain control.
I’ve had the misfortune of knowing a few individuals like these. In the end, they either change or they go, or else every who works for them goes!
All of this means that you can win a job in an interview even if you are not the most technically qualified. The truth is that most software apps can be learned in about a week or two. The more difficult skills to acquire are non-technical:
- interviewing and listening
- working well with others
- oral communication/public speaking
- time and project management
- objectivity, seeing the “big picture”
- being open to criticism
- handling change, conflict and stress
- creativity, flexibility and adaptability
If you can show that you have these skills, and a genuine passion for the job, this will greatly increase your chances of getting it.
Research? We don’t need no stinkin’ research!
It’s interesting to note that Apple conducted no market research – no focus groups, no interviewing, no surveys – nothing. They simply designed products that they thought were cool and useful, then unleashed them on the public.
This seems to contradict to one of the tenets of our profession: to actively design with the end user in mind based on their needs and wants. Presumably, this involves working directly with our readers and having them test our documentation to see if it’s useful.
The problem is that we often don’t have the resources to do this. The good news is that we don’t have to, for reasons that are similar to those at Apple.
Users ‘R Us
The fact is – we are users. We should have a good idea of the kinds of information our users want, and the way it should be presented.
When you need information, you want it to be clear, understandable, and easy to find and use. That is precisely what our users want.
Jobs believed it was meaningless to ask customers what they wanted because they didn’t know what they wanted! This was true because the products Apple created were so different from anything that the users had previously experienced. How could users be asked about something for which they had no form of reference?
In many cases, our customers may not know exactly what information they are looking for. The example I always like to give involves the mail merge process.
That Mail Merge Thingamabob
If you were documenting the mail merge process for a novice user who had never even heard of it, you couldn’t simply create a topic called Mail Merging, with a corresponding mail merging index entry. Instead, you’d need to think about all the ways a user could refer to what they want to do, and then frame the topic accordingly.
For example, you might title the topic: Creating Multiple Personalized Copies of Letters and Other Documents or Personalizing a Document that is Sent to Several People. Your index entries could include:
- addressing one document to several people
- copies of one document, customizing
- customizing a document to be sent to several people
- different names, entering on a document for several people
- documents, individually addressing to several people
- mailings, sending customized documents to several people
- mass mailings, performing
- multiple copies of a document, personalizing for each person
- names, changing each on several copies of one document
- personalizing one document sent to several people
- sending one document to several people
- single documents, changing the name on several copies of
- specifying different names on several copies of one document
You should be able to develop an extensive list of index entries like this without having to ask the user first.
But take great care with each entry – because one bad Apple can ruin the whole bunch.