As a technical writer, I focus on simulating what users would like to know or likely stumble upon when using a product or service and present the solution in simple yet accurate manner. Think communication is something that I believe in and also something that I should have been focusing more. For me it says “Solve problems before they become problems.” In other words, make sure the users can operate the product WITHOUT reading manuals at all.
In my real life, it means if a product requires 7 operational steps to activate it, instead of sweating my brain over using bullet / numbered points or squeezing them neatly into a single page, I would (should) go to the lead engineer and demand a big, red Power Button. Two pages are gone from my portfolio and salary, but also from users’ heads, which is what matters. I will present a well-known example which embodies Think communication philosophy.
Like thousands of designers out there, technical writers also look up to Apple for inspiration and example (especially the managers love this approach – think/do/look like Apple is the new black for them). But do their manuals work as a golden sample for aspiring technical writers? Yes and No (It depends is a cop-out solution but also is true…). No because their manuals do not cover the entire aspects of their product and – they are not beautifully designed (dare I say it). Yes because these manuals do just enough of their job. Installation, configuration, technical specifications, they are there. There is one more: a big part of their manuals are embedded in the product itself.
What the sentence above means is that they refine the design of the product until it becomes intuitive enough so users do not need to read manuals, or they can learn on their own by using the product itself. I guess their lead technical writer spends more time feedbacking to product designers than writing warning notes and operation steps. As a result they have far less glorious manuals compared with their products, but they all work brilliantly.