Technical Authors are normally seen as masters of writing user documentation, but their skills are not often applied to other areas of the business. For example, it’s usually the case our clients for software documentation are different from our procedures writing clients.
However, we’re currently working for a client where we began by editing a white paper, and this has led us on to other projects across departments. Work has included developing customer journey maps, a terminology database, as well as the online Help. The role is morphing into that of a content editor role: checking for consistency, spotting errors in marketing copy, rewriting copy, and so on.
So what is different? What has led to this wider scope? It may be due to us being recommended to them by word of mouth, and they had greater confidence in our abilities. It may be because they are a start up. It could be because many of the staff are not native English speakers.
We suspect it’s because the first project was the white paper. They had something that was very useful to them, for promoting the company. They also included us in their in-house chat system, which meant we could see other areas where they had issues with content. This led to us intervening more than usual, making suggestions in a proactive way. The growth of chat systems, such as Slack and Socialcast, within companies could open up other opportunities for other Technical Authors, as long as they take the initiative.
One of the trends in both data and content management is the move away from silos. In data management circles, there is a trend towards the collection and aggregation of customer data into “data lakes”. According to Margaret Rouse, a data lake is:
A storage repository that holds a vast amount of raw data in its native format until it is needed. While a hierarchical data warehouse stores data in files or folders, a data lake uses a flat architecture to store data. Each data element in a lake is assigned a unique identifier and tagged with a set of extended metadata tags. When a business question arises, the data lake can be queried for relevant data, and that smaller set of data can then be analyzed to help answer the question…Like big data, the term data lake is sometimes disparaged as being simply a marketing label for a product that supports Hadoop. Increasingly, however, the term is being accepted as a way to describe any large data pool in which the schema and data requirements are not defined until the data is queried.
“Content lake” isn’t a word that’s used in the content management or technical communication sectors yet, and whilst it seems unlikely end user content will grow at the same rate as other forms of data, there’s a fair chance this phrase could catch on.
A content lake is likely to have similar attributes to a data lake:
Content will be stored in a native format that is then changed into other formats.
It will use a flat architecture to store data.
Content will be stored in some type of structured format. Perhaps XML, JSON or plain text (with AsciiDoc-like attributes assigned to certain sections). However, user documentation does not require the rigorous structure of other forms of content.
The content lake can be queried for relevant content, and that a smaller set of information can then be extracted to help answer questions. This might not mean publishing content on-the-fly, but generating PDFs, CHM files and web-based content from a single source.
Rather than content being simply archived, it will deliver the right information in very short timeframes.
Earlier this week, we were helping a large company finalise a bid document where they were required to use a Word file sent by their client. This involved taking content from the company’s repository of standard documents on SharePoint, and from emails, plus writing down information provided verbally by the Subject Matter Experts. The bid writing team had to cut the relevant content from a Word document (and emails, Excel spreadsheets, Visio files, Microsoft Project files and PowerPoint presentations), and then paste it into the bid document.
Before we started to work on the document, this had resulted in it containing a large amount of different formatting styles. For example, the content pasted from emails was in Calibri 10pt. font, and the content posted from Word was in Arial 11pt. This meant the bid writing team had to spend a lot of time remedying the formatting.
This method also meant there was no reliable way to embed content, like there is, for example, in Excel – if you change a cell in Excel, related cells in other places can update themselves automatically to reflect that change. For the bid document, any changes to the source content could trigger a further round of copying and pasting into our master document.
At the TCUK 2015 conference, Rachel Johnston mentioned the idea of a content maturity model. We thought we’d take this idea and ask:
Could we develop a model that illustrates a hierarchy of needs for users of technical communication (and in particular, User Assistance)?
A model of what?
We suggest calling this model a technical communication user’s hierarchy of needs. This is because we’re considering the different points where a user interacts with technical communication content, the information they need, and value it gives to them.
It takes a similar approach to the content maturity model Rachel suggested (shown in the photo below), with the least mature organisations providing just the legal minimum, and most mature content systems contributing to branding and evangelism.
A user’s hierarchy of needs also enables us to compare this model to similar models from content marketing and product design. For example, the categories in our model’s hierarchy roughly correspond to Peter Morville’s “User Experience honeycomb”, as well as the key elements in product design.
I was one of the presenters at last week’s Technical Communication UK 2015 (TCUK) conference. TCUK is the Institute of Scientific and Technical Communicators’ (ISTC’s) annual conference for everyone involved in writing, editing, illustrating, delivering and publishing technical information. It’s an opportunity for Technical Communicators from the UK and mainland Europe to meet up and mingle, learn and present.
It was fun and challenging, going through the questions.
ContentHug’s Vinish Garg is interviewing a number of consultants involved in technical communication and content strategy, and asking them essentially the same questions. By reading the interviews, you can see where there are areas of agreement and where there are a variety of opinions. In general, there is a fair bit of consensus. They are worth reading.