Producing an application has many similarities with content production. So much so that we thought it would be interesting to start talking about it in a series of notes (“Your content is your source code”).
At the heart of development (software, web, mobile,..) there is a text. The source code. Whatever the technology used, whatever the language used, everything can be reduced to one thing: lines of text that tell a machine what to do.
This text “tells” the behaviour of the machine according to the interactions it will have either with human beings or with other machines. Just like a brand “tells” what it is in interaction with the different audiences it addresses.
And as surprising as it may seem, the source code of an application, like communication, carries meaning and values: will I respect or exploit the privacy of my users? Will I adapt or not to disability situations? Will I be accessible to people who do not benefit from high speeds?
A code is not “cold”, it is not a set of mechanical parts nested with each other, it is a text written by human beings, which can suffer from cultural biases, benefit from atypical personalities, be fair or unfair like any editorial production.
Well written lines of code will be effective, the machine will never make mistakes when reading them, the objectives will be achieved. Poorly written they will slow down the machine which will misunderstand what needs to be done or even make it fail and the objectives will move away. A bit like a 10-page newsletter that no one will read.
Producing brand content is the same challenge. All the texts that the brand will “broadcast” to the public must function as lines of code. Either to convince, sell or attract talent.
A badly written text, badly thought out, will have more or less effectiveness to reach the objective even will make “crash” the machine. We will then speak of “crisis”, the “bug” of content producers.
On the background source code and editorial content are identical: text, written by human beings (therefore fallible), to the attention of an audience.
Same tools ?
Writing this code is very complex, not because of the computer language itself (grammar and spelling are common), but because it often requires several hands.
The source code of an application is “broken down” into hundreds (or thousands or more) of written, validated, multi-handedly corrected documents. It is necessary to find an organization, workflows and validation relevant not to lose the thread of what has been done, what will have to be done.
Faced with this growing complexity, there was no other choice but to use dedicated tools and common methods. One of the tools considered an indispensable “pillar” for this production is[version management system] (https://fr.wikipedia.org/wiki/Logiciel_version_management). His mission? : “storing a set of files keeping the chronology of all changes that have been made to them “*. It has become literally vital in code production.
Today nobody can develop an application with Word documents that we would exchange by email and without a version management system. That is unthinkable.
However, if we maintain the parallel between code production and content production, we realize that this is what is practiced today in editorial production: hundreds of Word documents circulating between the mailboxes of agencies, departments that validate, freelancers that translate, SR that correct. We try to centralize on servers shared by necessarily accessible to all. Anyway, we do a lot of tinkering.
One of the consequences is the opacity of the production for the person who manages the whole team and who must therefore have a permanent mental inventory of what is being done. And which thus becomes a “critical” link in the chain. No time to get sick.
So no, for such basically similar businesses it is obvious that content producers do not benefit from the same tools, the same serenity, as developers.
Strategy and design
A content production, like the development of an application, is thought upstream with a more or less important step of conception. We talk about content or design strategy but it comes down to the same thing: who am I talking to? how? For what purpose?
While the communicators will choose the tone to use the developers will weigh the pros and cons between such or such technology according to the objectives. Everyone will have to choose their “tools” and define the most efficient way to achieve the goal.
On both sides we will determine, among others, the persona as will do UX designer because we do not design an identical interface for all audiences, as we do not write the same way for all its targets.
Although these steps are very similar for the two professions, it is clear that they are often not allocated the necessary time in editorial or web projects (but this is a very personal analysis).
An application is “read” before being “used”.
The world of content production is totally similar to software development in the field of interface: a poorly chosen word, a poorly worded sentence and it is a feature that is not understood, that is not used and that can generate errors with regard to the user.
With experience application producers realize (we first) that their work will ultimately be read as one reads a poster, a book or an article. You have to be careful with typography, layout, tone, rhythm to “speak” correctly to your audience, say what the application will do, can do.
Similarities, so what?
We are convinced that many bridges are possible between trades that can enrich each other. Tools, methods, editorial skills and the ability to think text to be read (a button, an error message) can be exchanged.
Content strategists often work closely with development teams not only to write the content but also the interface.
It is a first “bridge” between trades, many others can be imagined.