Please note: this post has moved to Medium.
Like, I would guess, many people, I’ve been using print-on-demand services to present work-in-progress on projects. I thought I’d share a bit of that experience here, and with a few dispatches from the trenches to set the scene, try to articulate why it might value in design work.
I started a couple of years ago with a book I produced with my team at Arup, detailing work in progress on the “smart services” (aka urban informatics) aspects of Low2No project, in Helsinki. I just posted this to the Low2No website, and I’ve discussed a little of why we made it a book.
In the world of architecture and urban planning projects, most “formal” information passes back and forth through Word documents, Excel spreadsheets, CAD files sometimes. If it’s really bad, these things are locked in the eternally woeful Sharepoint or burrow into the dark heart of Outlook in-boxes, never to be seen again. Or, increasingly, it’s locked in BIM systems, which is potentially effective for some aspects of the project but hardly accessible to all the people that need to be involved.
In-progress reports are also produced in this way, in very basic standardised formats, and only really ‘jazzed up’ for competition submissions or the final reports, whereupon the PDF reigns supreme. Often intended to be printed out, it rarely is, and so is awkwardly emailed about, clogging inboxes whilst simultaneously getting lost in the flood, or lodged in outgoing mail folders, often too large to fit through email’s pipes. For competitions, things are still often presented on boards, which—at A2 or A3—are even more cumbersome to communicate afterwards. Video submissions and presentations can be used if you're an OMA (and sometimes an Arup) but these are still the exception. They're also tricky to work with in multiple contexts; the lengthy, intensive, open-ended workshop, for instance.
Despite the static formats implied above, though, little on a project is permanent, until those final submissions. (Even then, the project usually unfolds upon different lines.)
Most of these reports are rarely, if ever, read by their intended audience: the client, or the other key members of the design team. This is such a leaky process that only an extraordinarily inefficient industry—aka architecture, planning and construction—could get away with it.
The fact that things could be emailed, which is a prerequisite, also meant they were too easy to ignore. By making something easy to disseminate via email, you were also placing it in a fast-flowing stream of other objects. Almost anybody with an inbox should stop to question the efficacy of making something that fits into inboxes.
We wanted to exploit the fertile middle ground of “work in progress” with something that was a little more engaging, that would pull focus onto the discussions at hand, yet not so over-produced that the thing couldn’t iterate or evolve. Something that could be thrown around in a workshop—literally!—accessed in linear or non-linear fashion, carry visual and textual information, carried on the person, or remain guiltily within sight on someone’s desk. Something physical and digital' which might have an allure over simply digital, at least at the form of artifacts.
In other words, a small book. So a simple InDesign template later, and a not-quite-so-simple PDF upload a little later, a bunch of A5 books emerged via Lulu’s print-on-demand (POD) service.
(I was inspired of course by various precursors going from digital to print, such as the pioneering Newspaper Club, the Magcloud publication Strange Light (discussed here), produced after the Great Sydney Dust Storm of 2009, and particularly the fantastic “Dear Lulu” project produced by the great James Goggin and his students when he was at Hochschule Darmstadt.)
It took a trial run to get the layout right—especially the margins, where one should err on the side of caution with Lulu. The book’s name along the spine is particularly vulnerable, and so it’s worth playing extra safe here. You’ll see my layout is conservative, partly befitting the project context, but it works, I think. It also deliberately pushes and breaks Arup’s brand and style guidelines, which I tried to do whenever I could; for entirely positive and strategic reasons, I hasten to add (that's another story.)
Lulu’s process is also a little tricky to figure out. The workflow needs a lot of refinement. In fact, if anyone’s looking to do a start-up this morning, this would be a sector ripe for some service innovation. The interfaces are not good, particularly around uploading and previewing your book and the inability to track packages coherently (leaving aside their pointless attempt to make a “marketplace” for content; just get it in Amazon et al.) They also don’t have a good spread of printers (though they hide this information.) Newspaper Club has a more scalable model here. Blurb may be nicer to use (haven’t tried it) but by focusing the platform on photo-books so much it’s limited in its applicability, and is left at a high price-point. So, disrupt away.
Still, Lulu works, just about, as you can see via that entry on the Low2No site.
We did two versions of this book a few months apart, as the work had developed, partly in response to feedback from the first book. There are version numbers for the book, as if it were code, but also different covers (what I called the “skateboard edition” and the “strawberry edition” (see image at beginning of this post.) The different covers become essential later on in terms of differentiation at a glance. It's also a good idea to make a clear statement in the credits as to what this version is about, and what’s to come in the next version (again, a bit like comments in code.)
The advantage of presenting work via print-on-demand is that it gets noticed. I know this small book was read within the client group and the project team, more than if it had been simply a PDF. Although, ironically, I would guess its impact was greater within Arup than anywhere else. This wasn't intended, but in retrospect, I was helping to build a new business area (what we called “Urban Informatics” at the time) and this distillation of work from Low2No was very useful there. It made the work real. It helped turn an idea for a new area into something akin to a new discipline within Arup. The book become a token in that exchange. This is an entirely necessary process in any large organisation, and you usually need all the help you can get. (I also recall making a form of stationery—logos, document layouts, email signatures—as if the team existed. Until it did.)
Still, copies did disappear rapidly throughout the project team, and it was used in workshops with Experientia in Turin, and still gets used. (Copies continue to disappear; we still have to place orders from time-to-time, though I suspect we’ve still only ordered a few dozen, total. A good feature of using POD is that you only order what you need; with a project aimed at low-carbon outcomes, this, combined with the ability to print local to the recipient, was a clear benefit,)
The book format, sized to fit into handbag or briefcase, also suggested a more evocative presentation of the work. As I mention at Low2No, it seemed natural, useful to end with a photo-essay of sorts. (More on the rationale behind these spreads.)
The book’s interface means this doesn't get in the way of the more technically-inclined readers. It’s easier to skim and dip into than any other format; and so it draws the reader in. These are all obvious statements, but in terms of UI, those monks got it pretty right. Although one could play with the navigation in the book, to make visible the idea that it’s print-on-demand, for this project that would be too obviously getting in the way.
The physicality of the thing was also important—pulling the book out of your bag was almost the platform for a conversation, a bit of a show, the introductory token (no more) for what is actually the most important outcome; the dialogue and the relationship.
What's different with POD is this ability to iterate within a format, making it particularly valuable for lengthy, often stop-start built environment projects, which require punctuating with statements of progress every few months. Combined with the ability to print rapidly, locally, this also works well for global teams (our project was spread across teams in many timezones.) And we did make a PDF version that could be emailed and uploaded to Basecamp (you can download that at Low2No.) (Incidentally, this was the first time, I believe, that Arup had used Basecamp on a major project, across a distributed design team and client group. That's another story too.)
This ’work-in-progress’ document was actually turned into a ‘properly printed’ book by our colleagues at Experientia. The design principles were outlined in the Lulu version I knocked together, and then polished beautifully into shape by Experientia. This is another advantage, and unforeseen by us; it becomes the early sketch in another iterative process, for the final “deliverable”. (And since I left Arup, I know my colleague Michelle Tabet in Sydney has used the same format, more or less, on at least two other projects. It's designed to be be picked up and adapted by others; another reason to keep the layout simple and malleable.)
For this layout, there was to be another fork in the road too, as we used an iteration of the template for Sitra’s booklet on street food in Helsinki in March: Helsinki Street Eats.
I originally laid out this new book based on the “Workbook” template above, but then moved it from an Arup-oriented layout towards a more “Helsinki Contemporary Modern” feel, akin to the popular We Are Helsinki listings booklet/magazine that could be spotted in every bar, shop and venue in town. We wanted the book to end up in similar situations, as well as on politicians’ desks. Of course, it would also stand out on the latter too, amidst all the printed out .docs.
I switched the type from Meta Sans and Meta Serif, which were just right to extend the Arup brand, to Kris Sowersby’s Metric and Newzald, as a subtle nod in this direction. Bryan and I then kicked the design back and forth, including having to absorb some ill-fitting Low2No branding guidelines at some point (see call-out box below, and colourscheme), until the thing emerged.
As with Experientia/Low2No, we got some printed at a local printers too, and so we have a POD version and a “properly printed” version, which we use in slightly different ways. We use the “baseload” of printed books for key mailouts and meetings, and top up with Lulu.
We also tried to ‘hack’ Lulu a little with this version. Bryan’s written up an excellent little post on our experiment in more detail. Essentially, we're imaginging a bunch of inserts which can be added to the printed book, via rubber band. The first such insert is a map Bryan designed, based on work from a local food researcher indicating how a Helsinki “hodari” (hot dog) comes to be, in terms of global supply chains.
We produced four different covers this time—same layout, different photo—which is something POD makes easy. The buyer can choose their cover, and at the moment there’s a clear winner (top right—the hot dog eater—funnily enough, this was the photo I casually chose when dong the first version of the cover, so perhaps the layout inadvertently works for this one best?)
With food as the subject matter of course, we might make upcoming versions relate to the seasons a little more; or to particular points in the wider project’s realisation.
Again, we only have to order what we need; this means we can iterate the book layer and the insert layer independently. I call little inserts like this “the wonka”, in honour of the legendary golden ticket – each subsequent iteration should have a wonks of its own. (The first wonka was the bookmark for “In Studio”.)
Now our food work is moving on, from active if scene-setting research to an actual project in Kalasatama later this year, we can iterate the book again with a postscript pointing at the new project. (More on that soon.)
As with the earlier book, the value of the physical artefact cannot be underestimated. It's been distributed quite widely across Helsinki now, and we’ve given it to colleagues within the city government, like their food culture impresario Ville Relander, who can use it for their own projects. Ville’s been through loads already. I have even used the map and book to sneakily cover up a distracted politician’s mobile phone, focusing attention on the conversation in hand.
It's difficult to trace the effects of the books, just as its difficult to trace much of our work in this area. We don't know how far they've gone, and who’s read them, and to what effect. We simply know that they are having some effect, as people tell us so, and things seem to change. In this sense, we see it as a “dark matter” probe (Bryan expands on that here), sent in to different contexts flush out responses and reactions.
It would be nice if we could track it, perhaps via the kind of near-invisible, GPS-enabled implanted sensors that produce the real-time maps seen frequently in CinemaOS. That might take a while, and this is where the book’s resolute physicality is limiting. For now. We'd love to actually figure out how to get richer transmissions back.
Despite this limitation, these very small, very simple books are proving invaluable. I wouldn't want to overplay what’s going on here – "Area Man Finds ’Book’ A Useful, Engaging Format" – but the idea of using print-on-demand for work-in-progress, and thinking through what hybrid formats this suggests, seems to have mileage.
It pulls focus.
Postscript: the other day, I belatedly saw Craig Mod’s great Blurb book documenting the building of Flipboard. I realised he was doing something similar, though as a summary of the project’s iterations at the end of the process, rather than in-progress.
This lends itself well to code-led projects, with its tangible and trackable “commits” and other checkpoints, but otherwise often imperceptible activity. It creates a trace of something essentially transient and ephemeral, and makes it resoundingly physical in order to do so. A poetic response, and the resulting book is wonderful (as is Craig’s essay on the Christo-inspired thinking behind it.) The small Lulu books we’re making above are more throwaway, or iterative perhaps—based on project that don’t have “commits”, actually—and so are designed explicitly for work-in-progress (version 1 of the Lulu book still has big blank spaces in it).
Craig’s book is a more of a portrait of essence of the work itself, not the work’s output. It’s a eulogy to patterns in cruft and craft, freezing activity to enable reflection upon achievement and activity, to make legible the character and identity of the work itself, as opposed to its subject (which needs little help to pull focus.)
Funnily enough, then, it might shares an instinct with my ideas around creating “new smokestacks” for places of work where work is increasingly intangible, to help make knowledge work convey its patterns, its seams, its character, its identity—to define a place and a people through the work itself, and so set up potentially usefully feedback loops or affordances around such work. I see something similar in James Bridle’s recent thinking, as described by Ben Terrett, around performing code.
City of Sound 
Leave a comment