Notes on Designing Programmes by Karl Gerstner

“Here the designer must intervene, he must in a sense aim at a larger whole; he must not continue to carry out the single task so much as create structures from which single solutions can be derived.”

Consider photography. For a crap photographer like me, there are two paths for improving your photo output. You can do it the right way: spend a lot of time studying photographic composition; the rule of thirds; foreground, midground, and background; focal lengths; and all of that. Or you can also just take a lot of photos, and skim off the few that happen to turn out okay. It’s less reliable, but quantity often begets quality, and hey, it might even be good practice.

In 1964, the designer Karl Gestner laid out a similar method for graphic design in his book Designing Programmes: one can move up a meta-level, and design a machine that does the design, and then you get lots of designs for free. Essentially: you can write a procedure to cheaply produce many solutions to a design problem, then select the good ones. Gerstner calls such a procedure a programme (we’d probably just spell it program these days, but I’ll keep the fancy spelling to refer the specialized concept) and it presaged some computerized design methods just getting traction decades later: generative design, design systems, and the like.

It’s an old design book, recently reprinted, that came to my attention as being the favorite design book of a high-ranking Airbnb designer, or something like that. I love mining old, mystical literature instead of getting actual practical experience, so let’s go!

Does the programme give us anything the concept of generative design doesn’t already give us? And can we use the programme concept to shed new light on familiar practices like design systems?

What is a programme?

The book is a collection of essays approaching the idea of programmes, each of them more or less a treatise in what we now call generative design, and so you could see it as part of the “design methods” literature.

To give it a familiar reference point, we could say that a programme is the unit of generative design: it’s the set of rules and constraints that you come up with to carve out a solution space for a design problem, which you can use to generate many individual solutions. It’s close to what you’d call an algorithm, and can be implemented as an algorithm, though a programme is more than just an algorithm or procedure: I’d argue it also encompasses any set of constraints on the output, which might exist independently of any procedure for getting there. A grid system, without an algorithm for placing content, is still a programme.

How is this any different from generative design?

I think there’s actually a difference here. The idea of a programme subtly shifts the focus of generative design by emphasizing the generative system itself as an artifact of interest, rather than just an opaque process you sweep under the rug after you make something cool with it. It’s the difference between “I used generative design to make this painting” and “I have a thing that generates paintings”; it’s something you have rather than something you do, and seems to be a word that’s lacking in the practice of generative design. What, after all, do you call the actual tool that you built?

What do you gain, though, from recasting the process as a thing? I’m not sure I have amazing answers, but it feels worth investigating. Refocusing attention on the systems and their properties might give us a better vocabulary for analyzing them and creating better ones. We do this already in music and sound design: that’s what synthesizers are. And we do it when we study programming languages. The language around generative graphic design seems underdeveloped by comparison, or at least a lot more niche. The stuff I’ve read centers on questions of “how do I get this effect?” or “how do I implement this technique?” rather than “how do I characterize generative systems?” or “how do I make a more expressive system?” Tyler Hobbs’s essays are probably the furthest along this path.

Programmes and expressive power

My first thought about the properties of programmes is that you could classify them by the their expressivity, the diversity of potential solutions they can generate. You could have a programme with few rules that generates only a handful of similar-looking outputs. Or, at the other end of the spectrum, you would have a Turing-complete programming language, able to specify anything you wanted. (Code is the ultimate programme.)

I’d expect the shelf life of the programme to be proportional to its expressive power—only, to be honest, I’m not sure which way the relationship goes. A more powerful programme can serve you a long time, by becoming useful for making many different kinds of artifacts, while a less powerful one might have more cohesive and recognizable output. Yet it’s that cohesion that might make the thing more sticky. It feels like moving up and down a specificity gradient of sorts here, where different levels of power correspond to different use cases. At the more expressive end, you get developer tools; moving the other way you get single artifacts that can reconfigure themselves (think a generative logo for a company). In the middle there are sweet spots to be found; think the NES: powerful enough for many, many different games, but programmable by a small team, and with instantly recognizable output. There, too, is an interesting threshold crossed when a system becomes expressive enough that two different people could express their own different styles in the output.

Another thing you can do when you embrace the programme as the tangible unit of generative design: hand it to someone else to make stuff with. There’s a bit in the beginning of the third essay, “Making pictures today?”, where Gerstner proposes that the designer may produce a programme for a picture, and leave it up to the onlooker to configure, according to their mood. ¹ I am not sure that this would be that compelling if it worked at the level Gerstner proposes, like, a single picture. You could imagine getting tired of it, or having it feel gimmicky. However, take things up a couple of notches in power, and then you start to have a tool for creativity.

Generative design on the web

Has generative design found traction in the web industry? I’m leaving aside architecture and industrial design, of which I can’t speak, and just focusing on web design here and adjancent fields. From what I’ve seen, there seem to be no shortage of “generative brand identity” projects out there on Pinterest, Dribble, and the like. One example: Generative logo for the City of Bologna

But you would hope there are other use cases than this. Part of me suspects that this might be downstream of a connotation that generative design is limited in scope to graphic design. And there aren’t that many purely graphical components in this kind of project: there’s the logo, and a brand identity, and the rest is copywriting, information architecture, and typesetting. I wonder if looking at this again through the programme lens wouldn’t be a way to dissolve this and find other applications for the programmatic design method.

Programmes and design systems

Are design systems programmes? You could argue they have many similarities. A design system arguably comprises a system of rules for how to structure a given design, and has cohesiveness in its output such that you can recognize a design as being a product of a design system, just like you can recognize a design as the product of a programme.

Things lost in translation

A few words about the book itself. Reading this thing was, at least for me, a maddening experience. The text is very clipped and breezy, and it’s hard to tell how much of this is a translation issue and how much is just swinging 60’s modernism. One feels like an important method is lurking in the text but it’s often hard to get at just what the text is saying. It’d have benefitted from more worked examples.

Sometimes Gerstner can’t fully characterize the programme behind some of his examples. But the examples are treated briefly and some of them are fairly complex. There’s a bit about gothic cathedral windows that would be the most compelling thing in the book, but ultimately he can’t come up with a programme to completely characterize these. That there’s a pattern is clear, but the complexity of the lines defies easy geometric description.

Further speculation

Gerstner’s book applies only to the arts, with music and literature getting a passing mention, but I’m curious if the procedure could apply in other domains as well. Imagine a programme for doing information architecture, for example. If you had a static website about a given domain with many dimensions, you could create a programme to play with different ways of organizing the material. The output from such a thing might be terrible indeed, given that no actual reasoning from user needs takes place, so I can’t recommend that anybody actually do this. But maybe you could use it as a type of oblique strategies for getting unstuck and exploring new ideas?