Article Summary
In this article, we’ll cover:
1. Three examples in media of characters using technical writing to help improve their situation.
2. Real-life lessons technical writers and end users can learn from these examples.
We’ve been running the #TCFilmFriday posts on our socials for a couple of years now (check out our LinkedIn and Facebook pages), and there are plenty of examples of good and bad documentation in our favourite films, TV shows, and even some video games. But today, we are going to discuss a much rarer beast – the fictional characters that actually read documentation and improve their situation by doing so.
There are plenty of examples of characters that don’t read documentation. One of my favourite films and TV series, The Evil Dead, should just be renamed main character Ash doesn’t read instructions and nearly causes the downfall of humanity. So much so that it’s a common trope in media. You’ve seen it before: characters ignore warnings or simple instructions, do something wrong, and hilarity or horror ensues, depending on the genre of media you are watching.
However, there are some examples of characters reading instructions, taking note, and making their situations much, much better. Characters save the day by actually reading the documentation, to the delight of technical authors everywhere. As well as being uplifting fictional tales, these examples can also teach us lessons about the importance of technical writing in the real world. So, in this blog, I’m going to run through some of my favourite fictional characters that read documentation, why they work so well, and show what real-life lessons technical authors and readers can learn from them.
Please note, this blog contains spoilers for the Gravity Falls TV show, the 1982 version of The Thing, and the 1985 film Commando.
Want to find out more?
Gravity Falls
Gravity Falls deals with the adventures of Dipper and Mabel, a brother and sister duo who are shipped off to spend the summer with their ‘Grunkle’ (great uncle) Stan, who owns a curiosity shop in the fictional town of Gravity Falls. Gravity Falls also happens to be the epicentre of many paranormal phenomena, with each episode seeing Dipper and Mabel tangling with vampires, dinosaurs, time travellers, and most spectacularly, living garden gnomes.
While any ordinary pre-teens would find these circumstances overwhelming, Dipper and Mabel are always somewhat prepared for these encounters, as they discover a mysterious journal that explains some of the unnatural occurrences within Gravity Falls. Dipper is especially diligent in studying the journal. Several episodes see him identifying potential dangers before other characters are aware of them and coming up with strategies to overcome them.
In fact, the show goes one better, and in the episode Scary-oke, Dipper manages to get himself into trouble because he doesn’t fully read the journal. In his haste to prove the validity of the journal to two government agents, he reads a random incantation without checking the warnings. This then leads to him accidentally resurrecting the dead in Gravity Falls, which completely ruins Mabel’s karaoke party.
So, what lessons does Gravity Falls teach us about documentation? Well, for technical authors and product managers, it shows users do well when you ensure they have access to the right information in a format that works for them. Dipper and Mabel are able to anticipate and overcome situations thanks to the information contained within the journals, no matter how outlandish. The show demonstrates that giving your users access to good information can help them achieve great things. For end users, it shows in nearly every episode that stressful situations can be overcome by reading the instructions, taking note of warnings, and following processes set out in well-written documentation.
The Thing
John Carpenter’s The Thing is famous for being a tightly crafted horror film that explores themes of isolation, paranoia, and some famously gruesome special effects. I would argue that it should also be famous for being one of the first examples of an interactive help centre on film, but more on that later.
When an American research station in the Arctic comes into contact with two members of a neighbouring Norwegian research station chasing a dog, a lack of a common language and a violent outburst lead to the death of both Norwegians. Trying to understand what happened to their counterparts, the Americans retrace the fallen researchers’ steps back to their base and find that the Norwegian team have found something buried in the ice for thousands of years. Those of you who haven’t seen the film can probably guess that it doesn’t end well.
When the Americans return to their base, they give what they find to the camp’s doctor, Blair. One of the items is a very futuristic – for the film’s 1982 release date – interactive help program. Blair quickly installs it, and using a combination of interactive diagrams and a question-and-answer chatbot, he is immediately able to understand what the Norwegians have discovered and just how dire the circumstances are. Armed with this knowledge, Blair disables the base’s helicopters, snowmobiles, and radio, which ultimately dooms the inhabitants of the base but saves the rest of the world from being overrun by ‘the Thing’ at least temporarily, depending on how you interpret the ending.
So, what lessons can we learn from this example? For technical writers, this time it’s how quickly you can communicate complex information by using a combination of different help systems and documentation. The character Blair, and by extension the audience, is able to quickly understand what ‘the Thing’ is. He learns how it ‘works’, and exactly what threat it poses by looking at videos, interactive diagrams, and asking questions to a chatbot. Remember, this film was released in 1982, so it was way ahead of the curve on chatbot functionality. While Blair doesn’t save himself or the Arctic research team, he does arguably save life as we know it, so we can say that the Interactive help and documentation did a fairly good job.
Want to find out more?
Commando
While Commando is a great example of mid-80s action excess and explosions, it also has a great moment of showing the power of good technical documentation, amid the carnage and classic Arnold one-liners, with my personal favourite being the ‘He’s dead tired’ pun.
When Arnold Schwarzenegger’s character John Matrix finds himself arrested and in the back of a police van, it’s up to airline steward Cindy to help him. Despite having no military training, she expertly uses a M202 FLASH rocket launcher to not only disable the van, but also do so without blowing up John, who was handcuffed in the back. When John emerges from the wreckage unscathed and asks Cindy how she managed this impressive feat, she simply replies: ‘I read the instructions’.
Although we can’t condone the action of using advanced military hardware to free police suspects and ignoring the fact that Cindy initially has the M202 rocket launcher pointed the wrong way around, the scene does prove how effective good instructions are at informing people how to use complex equipment in stressful circumstances. I may have touched on some real-world examples of this in a previous blog, but this example is an exaggerated telling of what 3di knows to be true: well-thought-out and easily accessible technical writing can quickly help novices get to grips with complex machinery and use it correctly in less-than-ideal circumstances.
End Credits
Thank you for reading my article. I hope the slightly humorous look at film and TV examples of people using technical writing has helped inform you of some of the real-world advantages of not only providing your end users with great technical writing, but also being a scrutinous consumer of technical writing yourself. And even though we may not have to solve the mysteries of Gravity Falls, avoid an alien apocalypse of The Thing, or rescue Arnold Schwarzenegger from the back of a police van (at least, not yet anyway), we can ensure that end users get the most from the products and services they use by providing good quality documentation, whatever form it takes. Making sure it is easy to find, access, and use can be the difference between success and failure, and I’m certain you’d like the characters in your stories to succeed, right?
If you’d like to talk to us about how you can set up your end users for success, feel free to contact us here, or give us a call on 01483 211533. And watch out for more examples on our #TCFilmFriday postings.
Related articles

Localization in film: the good examples
In this article, we look at good examples of localization processes in films and tv…

Technical communication in film 2: The bad examples
We list our favourite examples of technical documentation in film and TV

A 3di tools evolution – learning to harness the potential of AI
In this article, we discuss the ways in which we are using bespoke AI tools…