At least five times a week, a client will email me something that’s worth printing out to review. I might be in my kitchen, reading on my phone, and with two taps the document is printing out. The only thing that might go wrong is if there’s no paper in the printer. This is one of dozens of things we all do every day that programmers and engineers have made incredibly simple for us.
In my last role, I would go from one web interface to another, then to a FileMaker client, then to a 1970s-vintage green-screen emulator to access our warehouse system. None of this was optional, of course. Books needed to be edited and laid out, websites needed to be kept up to date, title information needed to be curated, sales reports needed to be shared, and inventory needed to be checked and replenished.
It is this necessity of editorial, production, and back-office work that compels people to work on systems that often frus- trate users and make them feel less than productive. Mainframes still exist in areas such as warehousing and distribution because switching them out never costs less than millions of dollars. Publishers have helped keep FileMaker in business because database development skills are very expensive—and if a FileMaker application works, there isn’t always a compelling reason for publishers to move on.
It’s one thing to understand why the problem exists, but not everyone is patient with the status quo. Users notice, and users complain. Industry numbers suggest 30%–40% of users express dissatisfaction with business software. Of more concern are the users who are openly unhappy with software. They can slow and even hamper adoption, draining momentum from technology projects and leaving both the technologists and the other users dispirited.
Short of replacing whole systems and tools, there are ways to improve the status quo. Part of the answer lies in technologists spending more time with users—understanding and documenting their workflows and the specific ways that software helps them and doesn’t. This requirements analysis—more often referred to as use cases or user stories—helps both the users and technologists break down and document how they would prefer things to work.
Examples abound. One client was trying to develop keywords for a large project to digitize parts of their backlist. They started with spreadsheets populated with titles, subtitles, authors, and other key data points. This was all good, but what was lacking was an easy ability to look at some of the text. Short of having the many physical books at hand, the team was at a loss when it came to working productively.
The first improvement came when the technologists created a workflow that allowed the editorial team to call up the newly digitized PDF files side by side with a form that included the key title information and fields to enter keywords.
As the work progressed, the technical and editorial team came up with a second improvement—an addition to the interface that suggested keywords based on the title, subtitle, jacket copy, and front matter of the book. While this required a considerable bit of programming, it sped up the pace of the tagging work. In the end, the newly digitized books were ready for licensing to aggregators ahead of the original schedule. The shorter time-to-revenue balance was good in and of itself—and justified the additional programming work.
While technology spending often is proposed where something is broken and needs to be fixed, publishers should look for opportunities to improve on things that aren’t broken. Consider an area such as sales reporting: Chances are, your current sales reports are satisfactory, but they can almost always be improved on. Users may not yet know exactly what Tableau and other such tools are, but they see excellent data visualization every time they open their phone and tap on their banking, weather, or news app.
It does come down to the users—they do all of the editorial, marketing, sales, and back-office work, after all. And while publishers will almost never put the elegance of the best smart-phone apps in users’ hands, they can work more closely with them—and improve on how well and how productively the work can be done.
Bill Trippe is a technology consultant in Boston and is a founding partner of Publishing Technology Partners.
