Skip to:

Creating illustrated books is an Agile process

Years ago I worked at Dorling Kindersley producing illustrated four-colour books - that is to say, with pictures on every page, and the text often wrapped around the pictures. Whatever the subject, cookery, health and wellbeing, or DIY, Dorling Kindersley’s working methods were the same. Designers and editors sat at desks facing each other. To communicate or to explain a concept, the designer would create a quick pencil rough, and the editor would comment on it. Or the editor would explain his or her idea and the designer would visualise it. Some of the ideas inevitably led nowhere. But for most, following a process of iteration, a final diagram would emerge. By the end of the process it was impossible to say that either the designer or the editor was solely or even mainly responsible for the completed graphic – the visual representation and the idea were fused. Was this Agile without being aware of it?

<--break-><--break->

I don’t know if Dorling Kindersley still operates in the same fashion, but the method they followed, of designers and editors working side by side, is the most likely way to create a genuinely visual content, where the illustrations genuinely contribute to conveying the meaning. I’ve worked for several publishers creating illustrated books, but this method is the only one I have experienced that really works. It is only by methods like these that the magnificent diagrams celebrated by Edmund Tufte in his The Visual Display of Quantitative Information and other books.

Observing Agile development, with the way it brings developers and other stakeholders closer together in regular meetings, giving each the opportunity to comment on and to shape the work of the other, reminds me of the illustrated book process. Agile at its best recognizes that people are not very articulate. When I try to describe what I want, whether it’s a picture or a piece of software I usually explain it poorly. Even when I carefully listen to what users want and then give them a chance to see the requirements I have captured, I still see that there are gaps in what I have described. It’s only when users see the result in front of them they can start to say “I didn’t exactly mean that!” At its best, Agile brings the user and developer closer together.

Nonetheless, it still doesn’t always work. After all, not every editor or every designer is capable of working in this highly interactive way to create graphics. The editor has to able to describe a concept, and the designer has to be able to listen. The same is true of software development. The developer has to be able to empathise, to see what the user is trying to achieve; the user has to be able to realise the limitations the software developer has to work within. The best software developers, in my experience, have been able to explain the framework they have to work within, in other words things the code can or cannot do. The best users have a tolerance which means they are able to appreciate there is more than one way of solving the problem. That situation sometimes needs the help of outsiders, shall we say interpreters, to bring minds closer together. When there is a culture of mutual learning, great things are possible.