Cristina Belli shares her experience of implementing a content strategy in a non-native English company.
This article was published originally in Communicator. Communicator is the authoritative, award winning, journal for UK technical communicators. It is home to high quality, objective, and peer-reviewed features – current, relevant, and in-depth.
This article contains my part of a presentation given at the Technical Communication 2016 (TCUK 16) conference together with my colleague, and fellow technical writer, Maja Engel. Our presentation, “Adding strings to your bow: Branching out into content strategy and usability design” focused on how we used our skills as technical writers and our personal talents to forge new careers within our company after a reshuffle left us without much scope for career growth.
A bit of context
For those of you who attended the Technical Communication 2014 (TCUK14) conference, you may remember the workshop held by Doug Kim of Microsoft. I certainly do. It was my first time at a technical communication conference and, even though I had been writing for years, I don’t think I really knew what technical writing really was until then.
Mr Kim’s presentation and workshop not only got me thinking about the words I use and how I use them but got me thinking about how others read my words and process them. What was particularly interesting to me was that he didn’t just focus on the words. He also talked about images, videos, layout, format, structure and the when and the why of content. Little did I know at the time that he sowed a tiny seed in my mind that would revolutionise my documentation and lead me on a content strategy crusade within my company.
When I got back from the conference, I took a step back and looked at our company’s documentation. Everything was different: different writing style, different voice and tone, different structure, different typography, different visual composition, different CSS and different glossary. The same went for all the company’s content. Reading it, you would never think it came from the same company.
The problem quickly became apparent: our company had zero content strategy. Everyone, the technical writers, the marketing department, the support team, were all doing their own thing. There was no thought in how and what we were writing. Our technology is best-in-class but our content doesn’t reflect that. We spend a lot of money on logos, colours and visual branding but absolutely nothing on content. That’s when I started thinking that I could try my hand at content strategy.
Part of this “branching out” has been discovering the online and flesh and blood technical communication community and getting access to information and expertise that is not readily available here in Italy where I work. Technical writing in Italy is only just starting to be recognised as a career. Job listings are few, and knowledge of what technical communication actually is and what it can do is quite limited.
I am the only native English speaker in my company, a manufacturer of engineering software. All our content—documentation, marketing and software content—is written in US English. And that “English” is sometimes quite “Italian”. We all know that stereotypes often arise from reality. Take the stereotypes of Italians: they are dramatic, they talk a lot and hand gesture with gusto. Well, imagine all that in writing and translated into English, with unrestricted, enthusiastic use of a thesaurus. It can be a bit chaotic, certainly dramatic and quite funny at times. On the serious side though, it doesn’t always fit the image of an innovative engineering software company.
I know first-hand what it means to write in a language that is not your own. It’s hard. It’s not enough to know your grammar. You have to get the tone and the words just right. It’s cultural as well.
Establishing a content strategy goes a long way toward helping right the wrongs of writing in a foreign language. With the company opening branches in the US and India, I felt there was an even greater need for content strategy that could be applied to the whole company.
So, what is content strategy?
Defining content strategy is something of a thorny problem. Looking around the Internet, I could not find a definition that everyone agrees with. The definition that best fits in with my idea of content strategy is “planning for the creation, delivery, and governance of useful, usable content” (Kristina Halvorson, Content Strategy for the Web).
Content is everywhere and is everything. It isn’t just words. It also includes images, videos, and anything that has the ability to project a meaning and influence understanding. Content Strategy puts them all in order.
Content strategy meets technical writing
If you are a technical writer, you know that there is so much more to doing what we do than just writing procedures, user guides etc. Our skills go far beyond just knowing how to write well. We know how to code, we make videos, we do graphics, we know how to be patient, we can put ourselves in other people’s shoes, we are not afraid to ask stupid questions, we are great team workers and we can use the products we document. The list goes on. We also know how to plan and create content with a purpose. We know how to make content usable and have a clear strategy from the outset. Writing and planning documentation is content strategy on a minor scale. In my mind, content strategy is a natural extension of what we do all day, every day.
Putting a strategy into place
When I pitched the idea of a content strategy to management, it couldn’t have been at a better time. The company’s chief technical officer was setting up a User Experience (UX) team to deal with the problem of getting the look and feel of our product up to the standard of our technology. I created a roadmap that detailed the different stages of development and implementation of a content strategy. The idea was to concentrate on documentation first and then address all other content at a later stage.
The first step in the roadmap was to create a single CSS stylesheet. Subsequent steps involved identifying our voice and tone, writing a technical documentation style guide and holding workshops to get people using and following the style guide.
Getting the right look and feel
To achieve a consistent visual style in our documentation, we (the technical writers) created a brand new CSS stylesheet that reflected our company and product branding. We use the MadCap Flare authoring tool and had always had separate stylesheets for each product documentation project, creating new classes as needs arose — often without logic. We redid everything: fonts, styles, image formatting, headings, colours, home pages etc.
To prepare for this apparently simple task (it would take us two months to perfect), we read up on golden ratios and vertical rhythms, researched the best fonts for online and printed output, worked with CSS experts in the company to get a clean, uncluttered stylesheet that could be used by all technical writers. We also nominated a CSS stylesheet administrator to ensure that it remains that way.
For our online output, we switched from tripane to top navigation and introduced infinite scrolling using Bootstrap Scrollspy. The final product is fresh, easy to read and in line with the company’s branding.
Creating a style guide
First things first. What is a style guide? A style guide is a set of standards for the writing and design of documents. It helps establish and enforce a style to help communication, ensures consistency and enforces best practices in usage, language composition, visual composition, terminology, spelling and typography.
There are lots of style guides out there, one for every taste. You can adopt an existing style guide, write your own from scratch or adapt existing guides to suit your needs.
![Esteco style guide](https://www.istc.org.uk/wp-content/uploads/2018/03/write-style-guide-300x232.png)
I chose the latter option. I didn’t reinvent the wheel. I took bits and bobs from the style guides I thought best reflected our products and adapted them. Inspiration came from the Microsoft Manual of Style, the Gnome Documentation Style Guide mixed with bits inspired from 18F Content Guide and the Mail Chimp Content Style Guide, to name a few. Side note: our style guide is called “write.” It went online on our company network in July 2016 and is accessible to everyone in the company.
Tone and voice
An essential part of the style guide was establishing what our company voice was and the tone to use for different kinds of content. Voice is an expression of a brand’s personality whereas tone can change based on factors such as audience, situation and channel. Again, there are many definitions. To put it in more relatable terms, you have your own unique voice but you probably use a certain tone when you are talking to friends or family, and an entirely different one with your boss.
Identifying what our company voice was tricky. I am no expert, so it took a lot of research to find a way to identify our voice. I opted against bringing in a professional as it was too costly and, anyway, finding one in Italy was impossible. I decided against holding a long series of meetings with stakeholders to discuss and debate the issue. In the end, I took the quicker and debatably more superficial route of giving a thorough presentation on what voice and tone is and then taking a survey of company founders, project managers, product owners, the marketing department and other key people in the company.
The results of the survey were an eye opener for everyone involved, and marked a new direction in the content strategy roadmap. Until then, my content strategy was just a list of things with dates on a shared document. The survey sparked a lot of debate and reflection on who we are as a company and how we should “speak” not only in our documentation but also across the board. For the first time in any company I’ve worked for here in Italy, people were aware of how important content is. It was immensely satisfying.
We talked about our company values, our strengths, how we wanted to sound to our clients, whether we were formal or informal, innovative or traditional, hip or conservative. The outcome was our voice described in four adjectives: professional, innovative, straightforward and engaging. The chapter on voice and tone matches each adjective with style tips on how to achieve that voice. Further style tips are given for achieving the right tone for the right situation.
Workshops
I would never have thought it, but finding our voice and writing the style guide was the easy part. Interest in and enthusiasm for the guide aside, people found it hard to put it into practice, mostly because they would say, English isn’t their language. They understood what the guide was getting at but needed a more hands-on approach to really absorb it. The best solution I could think of was to hold a series of workshops that target specific content-writing groups: the marketing department, programmers and Agile story writers, the support team who hold training courses and researchers who write scientific papers and articles.
I have just completed my first workshop with the marketing department and the results are encouraging. They have abandoned the much-loved thesaurus and excessive jargon in favour of a clear and concise style that reflects the style guide and communicates our often complex technology in a straightforward, uncomplicated way.
Content strategy and UX
Proof that content strategy is now enjoying the respect it deserves is its inclusion in the pattern library developed by the UX team. A pattern library is a collection of user interface design patterns that provide templates for recurring elements in the user interface.
The style guide covers how to write for the user interface but not in detail. In the pattern library, things get more specific. This is a new project so I have a lot of research to do and things to read.
Conclusion
Branching out into content strategy while still doing documentation has given me a new lease on my work life. Things were unappealing in terms of future prospects but good timing and a still-growing passion for content strategy have helped me out of a rut and onto a new career path. I’ve discovered that, as Benjamin Disraeli said, “the best way to become acquainted with a subject is to write about it”. Writing a style guide has helped me become a better documentarian. Learning about content strategy and sharing what I’ve learnt with colleagues has been mutually beneficial. The best thing of all is that now my company takes content as seriously as it does everything else. It is no longer just an accessory to everything else.
I hope this article inspires anyone who is looking to change careers or to simply start a side project like I did to do so. I still don’t see myself as a fully fledged content strategist; I have a long road ahead of me with much to learn. And I’m really looking forward to it.
Reference
Halvorson K (2009) Content Strategy for the Web
(Voices That Matter) New Riders.
Cristina Belli is a technical writer at ESTECO, an Italian company that
makes engineering software. She has recently joined the company’s user
experience team as product content strategist while continuing to write documentation.
E: belli@esteco.com