It was a refresher to spend a friday evening listening to Leah Guren sharing her insights acquired from a 30 year old career in Technical communication. She talked about the fundamentals that lay at the core of Technical Writing. The focus was on what process is followed, what are the right questions to be raised, how well the information is analyzed rather than any particular tools or domain. The talk was titled “The Golden Rules (Technical communication theory and application)”.
She discussed 10 Golden rules that work for all types of TC projects and provide a practical methodology. These golden rules are a result of Leah’s own experience and research.
#1. Paper is Permanent
It’s about owning what I am writing. It says “I am responsible for what I am writing”. So its important to write correctly, proof read and edit the documents properly and provide a proper structure to the content.
Lets see why is it so important…..
Get your grammar and punctuation rules correct so as to give logical explanations to developers.
#2. Know you Audience
Who is the user, its essential to know who is going to use the document, include demographics, take into consideration the technical and product knowledge of the users, analyse the language skills of the users. Make safe assumptions.
Who Am I?
Have you heard about FOGG Index? It tells you how good or bad is your writing and does it match the learning level of your audience. Check out FOGG Index
#3. Highlight Hazards
Watchout for things that need special attention of the user, Figure out the pain points, high risk things and use proper means to clearly specify the hazard.
As a Technical Writer your job includes:
#4. Break it Out
Do you know 7 years ago it was known that users spend 30 secs on a page to look for information. What’s crucial for a Technical Writer is giving proper structure to the content so that its easier for the user to find the information.
What can you do?
#5. Don’t write blind
If you don’t understand do not write, it’s your job to know what you are writing. Important to know the product you are writing about. Do not rely on second hand information. Explore the product, see it, use it, touch it because if you cannot perform the action you are writing you cannot explain it correctly.
Ask open ended questions to get the right information from the SME.
#6. Be Consistent
When you are writing the same thing in three different places in the document do not write it differently each time. This is exactly the opposite of what we are taught in school. But that’s the rule here. Take care of technical terminology and pick one term. It’s even important for localization.
Use signposts to direct the user to the correct information at the appropriate place in the document. Provide proper references wherever needed. Use layout and typography to indicate relationship of elements. As part of a documentation suite make all parts aware of each other.
#8. Don’t violate (legitimate) standards
#9. Contemplate before you illustrate
Make a rational decision when you must have graphics. Sometimes you may not need it at all or maybe you may need only a part of it.
What to do,
#10. Cut the fluff
Flowery, vague language is fluff also. Fluff is a serious issue with usability. So Keep it simple and short (KISS)
So, these golden rules are intended to provide a user centric approach to documentation, help to justify editorial choices, and provide the analytic decision tree for all projects.
The topic was not only interesting but her approach to presenting the topic and her style of engaging with the audience made the experience even more enriching.
Note: Main points are taken from Lean Guren presentation handout notes shared with the audience.
I am new to the world of technical writing and had to accomplish the challenging task of getting a job as a Technical writer with a good organization with all my experience in the IT industry. I went in a strategic way and thankfully things fell in place. So, here I am sharing my experiences with the community.
The three-pronged approach:
We all know the first interface of a job seeker is the résumé and hence its an essential tool that needs attention to detail. I happened to create a decent resume by getting feedback from my friends while I was working on the résumé template and the content. Their comments and suggestions were very helpful in setting aside a good resume. Fortunately this exercise has actually taught me how to create better resumes and I am glad I am able to help two of my close friends to set up their resumes now.
Most of the communication is through emails and hence a message body describing about my professional experience in a nutshell along with the a reason of why I am interested in their profile increased chances of hearing from interested recruiters. So a nicely written cover letter definitely helps.
A job seeker’s destination is mainly job portals, but lets admit they are not your best bet for a Technical writing job. This domain in India largely thrives on referrals as I have noticed and makes professional networking indispensable, but a newcomer needs a different approach in absence of a professional network of friends and colleagues. For me, my presence on the web helped. I am a fairly active user of the professional networks and hence the power of linkedin helped me. A lot of good jobs are posted on linkedin, so don’t undermine its potential, to share you a secret I am where I am because of it :).
Few good places to look for latest jobs directly from companies are:
In my case, to my pleasant surprise the blogs earned me a great deal of help. I never knew when I started personal blogging it could turn to be of interest to professionals. That’s the key these days, the interview patterns are changing as I noticed, it’s not only your knowledge and attitude that will get you through, people have started to show interest in the overall personality of the person they are hiring and somewhere lost values are finding their ground again. I liked Red Hat approach of hiring and I am indeed glad that I am able to be a part of it.
Not to forget, good preparation, a level headed approach and a bit of trust are enough to help you sail through.
If your deliverable is a .doc file along with the .pdf. some tricky scenario that can happen is, the TOC links are not functioning in the PDF output.
Here are a few pointers that may be useful in troubleshooting the problem.
Tip 1: When you insert the TOC in the word file, in in Table of contents dialog box make sure the checkbox that says “Use hyperlinks instead of page numbers” isselected.
Tip2: While saving the .doc file using Save as PDF or XPS, On the “Publish as PDF or XPS” dialog box. click Options.Select options Create bookmarks using: Headings
This adds a TOC in the PDF file under a bookmarks tab, and you can navigate seamlessly in the document.
It’s quite likely for a Technical writer to work as the sole contributor towards the documentation needs of an organization. I had this recent experience on a work assignment with a Software company in Pune. While my journey of 3-months was smooth as my reporting manager, SMEs, CTO and CEO were very cooperative and understanding and it proved to be a wonderful learning experience. But as a writer it does becomes bumpy as you are the only person with the reins in your hand.
In this scenario, the writer is his own Boss with ample freedom to carry out the tasks. This gets tricky, as you find yourself at sea initially and at the same time the sense of responsibility is huge as you are the single owner of the work. So, in a way you are your guide and mentor simultaneously. A few impressions out of the experience are shared here:
Not a straw of support
Human habits are tough to break and when you are used to discussing work scenarios with your peers you have to fight your way out to break that habit. Be ready to face problems such as choosing the right Tool, or resolving a tool error, finding the best solution to a recent problem, and so on for a task. Nevertheless, one tends to learn more, by self-exploring and trying. Trust that internet is your best friend.
All in One Role
I am a Technical writer but not anymore, now I am the reviewer, editor, self critic all in one. It is impossible to do justice to these roles by the same person. So a simple trick is to pipeline the documents such that the writing, language reviewing and editing of the same document do not follow the same sequence. My sincere apologizes that I just screwed the DDLC.
Discover the Manager in you.
Gone are the days when I had the luxury of a Documentation manager. Now I need to self plan the project, decide the timelines figure out the deliverables, set up the Technical review process with the Teams. Be ready with answers for the reporting head, sometimes to defend and justify your position. A key is to be proactive in reporting the status, pointing out glitches, informing in advance that you may need more time rather than waiting for the final day. Importantly keep the reporting head in loop for the delays that are happening to keep a clear picture.
Some useful suggestions from personal experience:
It’s beyond doubt that working a lone writer one gains many insights and maturity as aTechnical writer, This further builds up confidence to work single-handedly. Initially the trail proves a little difficult to crawl but finally one learns to walk.
On Saturday 19-may-2012 I attended a one day workshop on CMS and cloud based authoring with Author-IT as part of the Technowrites Connect Learning Sessions. The session introduced us to the concept of Content Management System, Cloud based authoring, and collaborative reviewing using Author-IT.
Rajdeep Gupta, the Business head of Author IT Asia conducted the seminar. It was an informative and interesting session as this was my first interaction with a CMS Tool for Technical Documentation. As I have used a Software Configuration Management Tool called Rational Clearcase from IBM for 4 years I could draw many parallels, but Clearcase is extremely huge in that sense.
The session focused on the benefits of a CMS and its need for organizations to efficiently manage content, increase content reuse, single sourcing and achieve faster time to market. The Author-IT CMS offers the features of:
The Author-IT on premises version of the Tool packs configuration capabilities for administrator that offers a flexible approach to manage the documentation projects with comprehensive control mechanism for the projects and access privileges for project members or groups. The UI of the Tool has been smartly designed to resemble Microsoft Office Suite, this is indeed smart enough to make the users feel confident on their first interaction with the Tool.
Author-IT follows Object Oriented Design methodology wherein all the elements or components of a document are treated as individual objects in relation to each other. All these Objects are contained in a higher level Library. A library will also consist of all your project working folders, templates, styles and so on. For one organization it’s recommended to have one Library although importing content among different libraries is permissible.
The Author-IT cloud based model is customized to organizations with limited budget or short duration requirements for a help authoring solution. The distinguishable feature of the cloud based model is its faster ramp-up and implementation time along with the other benefits of cloud based solutions from anywhere anytime access to lower operational costs. A one-hour hands on with the application helped us to get ourselves familiar with the Author-IT cloud.
The Author-IT solution sounds convincing for organizations with huge documentation needs and greater need for single sourcing along with shortened and faster review mechanism. So if your documentation workload is huge and involves large and multi location teams you may consider exploring the Author –IT platform.
An interesting take away from the session was on the nuances of evaluating a Tool for your organizations. Rajdeep shared some useful insights drawn from his experience as a Usability Expert like focusing on the Usability aspect of the Tool, amount of integration effort required to deploy the Tool, Cost, and so on. The concept of taking out surveys within the organization and different users, collecting, consolidating and analyzing their feedback is also crucial for the success of a new Tool to be introduced in the organization.
All in all it was a very valuable session esp for me when I am trying to understand this field and its vastness, challenges, solutions each day. It introduced me to yet another frontier of Technical Communication.
This is my first post and I could not resist the temptation of starting my blog with the most predictable and customary question. So here I am in my maiden attempt to understand the meaning of Technical Writing.
Technical writing, in general means to present technical information in a user understandable form to a selected set of people, like the user manual that accompanies your water purifying system or the manual that is handled to you while you board an aircraft.
Technical Writing is a sub branch of Technical Communication and as diverse and broad is the field of communication, same holds true for technical communication. So, from writing documents to creating user oriented information using various audio-visual aids like graphics representations, software simulations, video-audio instructions to transmit crisp and precise information for software or a machine falls into the category of Technical Communication.
The aim of technical writing is to help users identify, familiarize with a new product, making life easier for them. Technical documents are also an important tool to help users in troubleshooting a problem, it acts a knowledge base, while people may seek guidance for a particular problem or feature in the product/application. Technically written material also enhances user productivity.
Sometimes people new to the field of Technical writing may confuse it with Technology writing. Under such circumstances it is even more important to develop a clear understanding of Technical writing and its nuances. Some of the distinguishing features of technical writing include:
These characteristics help to differentiate technical document from an article that describes the latest gadget and its features.
Few examples of technical writing are may help further.
The installation manual, the user manuals or the manual explaining the working of the solar cooker refer to as technical documents, whereas the manual about the product features, significance, advantages is not classified under technical writing.
On the other hand, medically qualified professionals use the operator’s manual of medical devices such as a MRI scanners. Such a manual qualifies as highly technical document and is intended to use by a skilled professional only.
If you are a software developer, the programmers guide or the API guide that you refer are also examples of technical writing.