Adrian Baniak has written an article (3 Ways to Engage with Today’s Empowered Consumer) about how brands can “cut through the clutter” and communicate with their customers and prospect. He states one of the key ways to do this is “Write Your Own Tale, Or Someone Else Will Do It First”.
This mantra was originally made by Lisa Shalett, a partner at Goldman Sachs, and the global head of brand marketing and digital strategy. Continue reading
At some stage or another, a technical communicator is likely to have seen this image from Kathy Sierra:
Today, we’ll be sending out the Cherryleaf newsletter for March 2013, containing news and stories on creating clear and simple information your users will love.
You can join the thousands who receive our free newsletter – subscribe here. You’ll be sent a copy of the latest edition straightaway.
Your details won’t be shared with anyone, and you can un-subscribe at any time.
Danielle M. Villegas has just pointed us towards a five minute lightning talk by Rick Lippencott on the future of technical communication, and its value. Rick covers in five minutes a great deal of the content I covered in my 45 minute presentation at the same conference – it’s worth watching.
He summarises the value of Technical Authors in three simple words :”We explain things”.
Rick added some notes to the description on YouTube:
The clay tablet “first example of tech documentation” is about ten thousand years old, not two thousand.
The odd photo at about the 4:50 mark (where I say any of us could have explained it better) was a hotel room layout map posted at the elevators. It gave room locations based on compass points, but there was no way for the reader to know which way was actually north. It was completely useless.
“All of this has happened before, and it will happen again” was originally from Peter Pan.
On Dara O’Brien’s Science Club (BBC 2) this week, neuroscientist Dr Tali Sharot explained “Optimism Bias”, suggesting that our brains may be hard-wired to look on the bright side.
Here is her TED presentation on the Optimism Bias:
Nearly everyone is optimistic they will never get divorced, and they are an above average driver, when statistically that’s just not possible. It seems reasonable to infer that users of software are also over optimistic, believing they are an average or above average user in their ability to use an application.
This has an implication for those developing user documentation and training. It seems likely that most people will believe they don’t need to read the documentation (or receive training) when they actually do.
According to business strategist Dr Alan Rae, it has been calculated that only 15% of the value of a company appears in the balance sheet. The rest is intangible value, which lies in four main areas:
Alan states:
If all of these are coded and formalised, then a financial justification can be made for the value created in the company.
So how can you code and formalise these areas? One way is to turn them into software applications, and the other is to record them. Your intangible value will be recorded in the polices and procedures, in people’s knowledge that is captured and documented.
This means the better your content strategy and content management systems are, the more in control of your business’s intangible assets and intellectual property you’ll be.
See also:
The US Presidential elections have just ended, and the big winners were the “Quants” – the statisticians such as Nate Silver, who used statistical models of big data sets to accurately predict the electoral college vote results. In competition with the Quants were the “Pundits”. These were the commentators on politics, some of whom said they were using gut feel to make their predictions. Pretty much all of the Pundits failed to predict the results accurately.
It is our experience that there is a similar difference between different Technical Publications teams.
One of the graphs posted in yesterday’s blog showed the number of people searching for IPad Help.
Here is the graph:
For a product that “just works”, there is an increasing number people searching the Web for iPad Help. However, part of that increase can be put down to the increasing number of iPad sales:
What we can conclude is that even users of products as simple and intuitive to use as the iPad search the Web for Help on how to use it. If you decide not to provide that Help, then users are likely to get the information from someone else – either in a forum, a YouTube video, blog, Web site etc. Places generally, outside of your control.
The “5 Whys” is a question-and-answer technique used to discover the root cause of a defect or problem. It is an approach used in the Lean manufacturing methodology, as well as the Six Sigma business management strategy. Here’s an example of the 5 Whys technique:
Problem: The vehicle will not start.
Solution: Start maintaining the vehicle according to the recommended service schedule.
Some consultants suggest that if you use the 5 Whys approach you’ll conclude you should fix a fault in a product rather than create reams of documentation explaining how to get around the problem. However, if the cause is of the problem is at the customer’s side (for example, their computer has an out-of-date driver), how do you fix the problem? You could control the issue by only selling to those who have the appropriate setup (or training), but, if you want to get the customer to resolve an issue at their end, then the user documentation may be the best way to do it.
Sometimes, the 5 Whys approach will identify the need for a proportionate intermediate fix. Again, User documentation is often the most effective solution, in those situations.
When reviewing an organisation’s procedures documents, there are a number of key factors we look at. These relate to the value of the document itself, how it is structured and the clarity of the content (i.e. the words and sentences).
One way to rate these factors is by a simple red, amber, green traffic light system. Using this approach means the key areas of concern can be highlighted to everyone involved in the project. Red indicates an area of high concern, amber indicates medium concern and green indicates no change is needed. Here is an example below:
How do you assess organisational operations and procedures documents?