Computational design: outputs regenerated by a command, not by hand

1 October 2026Majed Alandajani

In a design project with multiple visual outputs, working by hand looks faster at first. Open the tool, compose, export.

Then the client asks for one change, and the whole set has to be rebuilt by hand.

What I did

I built an image pipeline: one command composes the output from its original sources.


node pipeline/render.mjs                 # the full version
node pipeline/render.mjs --no-labels     # the unlabelled version

What you actually gain

Change becomes cheap. Alter one source, rerun the command, and everything derived from that source updates with it.

Versions stay consistent. Since the labelled and unlabelled outputs are generated from the same source, neither one can drift away from the other.

Delivery is repeatable. When the client comes back six months later asking for another size, you produce it in a minute. No digging through old files trying to remember what you did.

What it does not do

It does not design. Every artistic decision stays human, from the composition down to the colours and the narrative. The command executes a choice somebody already made; it never makes the choice itself.

The decision I am prouder of than the outputs

In the handover document, I gave the undelivered items the same prominence as the delivered ones, each with its specific reason: this was not produced because a particular tool was unavailable in the working environment, and this one is blocked until a new field survey happens.

A client who reads what you did not finish, and why, trusts what you did finish. A handover that lists only successes sends the client hunting for the gap on their own, and once they find it they start doubting everything else in the document.

The general rule

Every visual output should have a source and a command. If a file exists with no way to regenerate it, the next change request puts you back at the start, redoing the whole thing by hand.