For this first post, Sally Bagshaw and I sat down to discuss how Author Experience and Style Guides can work together; if they complement each other, or are going to create conflict…
Rick: Maybe I am being a little simplistic here. Correct me if this is wrong. Isn’t a Style Guide just a set of writing guidelines that can be defined as a combination of grammatical rules and narrative structure? As such, isn’t this already answered in the book? I covered both the design pattern for narrative (p127), and the idea of a customised grammar checker (p91), which the likes of Acrolinx already make available.
Sally: Acrolinx integrates with many systems: documents, CMS, etc. and applies common rules to all your writing. I think that idea – being able to run it like a spell-checker – is cool. But it misses much of the point of Style Guides; not so much the purpose, but the reality of them.
Rick: What, then, is a Style Guide? What should it achieve? How should it work?
Sally: A Style Guide should be a living concept: a baseline for communication processes. Not the technology of process, but the human element. How do we communicate, and why? The reason behind the style, which gives all our communication a consistent feel. It is an educational experience, intended to impart an understanding of, and passion for, the brand’s personality. (I will often refer people to the Mailchimp Voice and Tone site as a way of getting people to understand why you do things.)
We want our authors to appreciate the brand’s voice. We want them to champion it themselves, without software telling them when they are right and wrong.
Of course, there will be times the authors are referred to the Style Guide. Then, the instructions should be in context: this field needs to follow certain principles, be written in a certain way, because it is used here, here, and here. It needs to fit into these particular contexts, and align with all the content around it.
When we are reusing content heavily, that becomes vital. Especially when different sources are mashed together.
With the WYSISMUC authoring (p129) you talk about – the out-of-context, re-usable content creation process – we will need contextual guidance. Writing in the right Voice and Tone, without seeing how your content will be used, is hard. How do we incorporate meaningful guidance alongside the input area? That is the big challenge.
Rick: That makes sense. But how do Voice and Tone differ from other Style Guide principles? Are they not simply more grammar? I would think we could encode those aspects in the same way we can specify that something should be sentence or title case.
Sally: I think… anything’s possible. Voice and Tone are far more subtle than general grammar. I don’t know how well computers can do that. Some things you can capture with rules; some things are too human – it’s about feel.
If Voice could be encoded, it certainly wouldn’t be cheap. So it would depend on the scale of your system. You would need a lot of content, and a wide range of authors, to justify the expense.
Rick: Very true. I would expect, at least in the first instance, that it would be easier to manage a small team of authors, in a small organisation, and help them buy in to the Style Guide. So a need to automate Style Guide compliance checking would be more relevant in larger organisation, where there are more authors – more sources of content.
Sally: Yes and no. I’ve worked with clients who have beautiful authoring teams. You give them tools, guidance and information, and they embrace it. They’ll do wonderful things. And then you have a bunch of people who just don’t care; they look for work-arounds for anything they don’t want to do. And they account for 80% of your time.
It’s not a technology problem. It is a culture and a change issue. Inherently, people are the complex part of this whole question.
Rick: As you said, it’s the human factor. Even those perfect authors can have bad days. They can be exemplary for six month, a year. Then something in their life throws them off stride, and they can’t focus. It’s as though they don’t give a damn. That one blip can do irreparable damage to the organisation’s image.
Sally: Yes. You just eroded all the trust.
Rick: Might we solve this by embedding the Acrolinx-style grammar checker, expanded to Voice and Tone, configured with appropriate rules and guidance per field, within our authoring interfaces? I don’t only mean when the author hits a button to request the check, but all the time. Nor am I suggesting putting squiggly red and blue lines under everything – that just makes it harder to read. I am thinking more subtle highlighting. Soft backgrounds that are noticeable, but can be ignored while crafting the words themselves.
The areas that need attention would provide not only the rules, but the contextual reasoning. And integrate that with feedback to editors, who can provide additional, personal, guidance. I think people would learn that way. And if they don’t, then maybe writing shouldn’t be part of their role.
Sally: Yes. A more scaled approach to approvals: assistance, education, and the human touch.
Whatever you do, people will choose the path of least resistance. Even the power users who loves the business, the technology, the content – the poster child for everything we’re trying to do – will find a different way if you make it too hard. You can’t bend people to a cumbersome process just to tick some rule boxes.
One of the projects I am working on has that challenge. We’ve developed the content model and taxonomy, both of which are complex. Creating the model was the easy part. Getting the users – even our engaged power users – to maintain the environment we’ve set up… that’s a challenge. As soon as they start using it, it degrades. We might be able to automatically generate some data, but authors will struggle with categorisation choices.
Applying a complex model – not just choosing an option, but knowing why you are choosing that option – is tricky.
Also, with such complex models, or very distributed authoring systems, maintenance of the rules becomes an issue. You might end up killing yourself with rules; can they be maintained successfully in a system rather than having some offline process…?
Rick: Maybe what we need is not so much to surface the grammar and style check within the authoring interface – though that would be useful for training, and as an on-demand reminder – but to embed those rules within the publication process.
Once an author has earned enough reputation to be trusted to handle their own work without it being delayed by an editor, the publication process can run it through the grammar and style checker. Only if it raises flags does it divert to an editor, who can then provide constructive feedback.
It means changing how people think about the CMS as a process and workflow tool; adapting it to serve the processes that work for the people.
Sally: As a broader statement, I think the work you’re talking about with Author Experience – the next evolution of content management – is a foot in each camp between technology and the people. It will change the tools we, as content strategists, us to do our work. How that looks… everything changes so much. But gone are the days of the Style Guide being a PDF on the intranet, which explains why you should write a link a certain way.
I think there should be a lot more embedded help, and link that to something that’s much more the heartbeat of an organisation.