It has been so interesting to work through workflows with a variety of publishers. I’ve learned a lot from this process but there are two core learnings that keep coming back to me
- publishing workflows aren’t that complicated
- don’t design systems from the point of view of an article, design through the eye of the people involved in the process
Probably both of these need some explanation. First, I have worked with a number of publishers that cannot see their workflow clearly. That is actually quite normal and understandable as publishing workflows seem to take on a life of their own, each department soon is doing things few others understand in detail. But when considering building or adopting a new publishing tool, the software folks (often) talk to everyone in the organisation and carefully document all that needs to be done, in the order it needs to be done, and by whom’. This leads to a very crazy complex plotting of the journey of an (eg) article from submission to publishing. They then proceed to grapple with what appears to be a complex logical flow, with many eddies and cul de sacs, parallel processes, and contingencies. It all appears hopelessly complicated.
But publishing workflows aren’t as complicated as this kind of process will suggest. For example, I made this slide to describe the general workflow for a Journal:
This is pretty much the workflow for almost every journal. It is not that complex. If you take a specific journals flow and map it onto this you can see the workflow much more clearly and simply. For example, the following image maps the workflow of the Collabra Psychology journal onto the above:
You can see it’s pretty simple. However, if you went through the process of ‘auditing’ the workflow by querying all parties and trying to see what the path of the article was in system, and working out all the touch points and forks etc, you may imagine the workflow to be a lot more complicated than it actually is… in fact, you may even feel that the flow is so horribly complex it’s impossible to get a good handle on it.
Which leads me to the second point… I think it’s a bad idea to develop a system from the point of view of an article following a logical path. As per above, the system will become hopelessly complex and full of exceptions and if-then dependencies. This will lead to a system that is very complex, prescriptive, and hard to optimise. Instead, look through the eyes of the people involved in the workflow and imagine how you could make their job as simple as possible.
To help you get there try this exercise – imagine if all roles involved had just one browser window where they could do what they needed to do. What would the workflow look like then? Literally draw out these spaces on a single sheet of paper per space. Discipline yourself to this one space per role. Once you have done this, challenge yourself to imagine if two or more roles could use the same space… what would you need to change in order to achieve this? You might be surprised how much overlap there is…
For an example of what I mean, have a walk through this slideshow:
You can see we have encapsulated the entire workflow in a series of just 5 spaces, we may even collapse this to four.