Details matter. In life, in art, and in technical writing.
It’s hard to think of three better action movies than the Bourne trilogy, in which the protagonist — Jason Bourne, played by Matt Damon — spends a good bit of time being chased by bad guys. Bourne hopscotches across Europe, eluding his pursuers in Paris, Berlin, Moscow, and London. Finally, Bourne arrives in a city where I know my way around: New York. And that’s where it gets weird.
Spoiler alert: If you don’t want to know details about how The Bourne Ultimatum ends — if you want to cut to the chase, as it were — skip down to “get the details right.”
In midtown Manhattan, Bourne receives word that he can unravel three movies’ worth of plot twists by getting himself to East 71st Street. Of course, the bad guys are out to stop him. First they challenge him at the Port Authority bus terminal. Not the way I’d choose to get to East 71st, but at least it’s near his starting point. Next we see him running for his life in lower Manhattan, in the vicinity of South Street — and totally in the wrong direction if you’re trying to get uptown. Has the canny and clever Jason Bourne suddenly lost his bearings?
Fortunately there’s little time to worry about that: Bourne miraculously reaches his destination on East 71st. After a climactic scene, he leaps into the East River, submerges, and comes up for air near the Williamsburg Bridge. After that invigorating and superhuman four-mile swim, it’s hardly surprising that the bad guys throw in the towel.
Of course this isn’t the only film where the geography doesn’t add up. I’ve seen much worse. And in this case it only got in the way of the story a little bit. For many audience members, probably not at all.
But how hard would it have been for the screenwriters and the director to get the details right?
There’s a lesson here for all technical writers. It’s no good to write relevant, task-specific, audience-appropriate content if you don’t get the details right. Details like the names of widgets in a user interface, and like realistic examples. Miss those details, and your readers will (if you’re lucky) have a good chuckle. Or (if you’re less lucky) scratch their heads in confusion. Or (worse) lose their trust in you, the writer. It’ll be a long time before you win their trust back.
It’s hard to find good examples to put into technical content. Even when I do, I sometimes hear from SMEs that the examples aren’t realistic. On the surface I hate hearing those comments, but secretly I’m very appreciative.
There are no shortcuts to getting the details right. You have to become knowledgeable about both the subject matter and the audience’s perspective. And as my friend Alan Pringle insists, you must never, ever say “I’m just the writer.”
Yup. You’re the writer. Part of your job is to get it right. All of it.