Design Principles for Creative Tools
In 2005, seven researchers — drawn from MIT, Carnegie Mellon, Maryland and elsewhere — published the closest thing this field has to a founding charter.1 It is not a paper about consumer software, or even about enterprise software in general. It is about tools built for engineers, scientists, designers and architects doing genuinely creative, ill-defined work, and its central claim is one this guide takes as given rather than argues for: the tool is not a neutral pipe between intention and result. The tool shapes the thought.
A creative composition process is not a routine production process that can be prescribed, and what tools and representations people use strongly affect their courses of actions and thought processes.
Resnick, Myers, Nakakoji, Shneiderman, Pausch, Selker & Eisenberg1
The paper sets out twelve principles. Five of them bear directly on the software this guide is about, and earn a place here on that basis alone.
Support exploration before commitment
Creative work means the outcome isn't known at the outset, so the cost of trying something and being wrong must stay low.1 The paper calls this "low viscosity" — trustworthy undo, previews before execution, the ability to backtrack without penalty. This guide treats the same territory in depth elsewhere, under Provisionality and Rigidity; the point here is only that the instinct behind both has a name, and a citation, older than this guide.
Support many paths and many styles
Not every user thinks the same way. Drawing on Turkle and Papert's distinction between "hard mastery" (planned, abstract, systematic) and "soft mastery" (negotiational, concrete, opportunistic), the paper argues that tools built only for the former alienate users who are, by any fair measure, just as capable.1 Its proposed metric for success is blunt and useful: if every output looks like every other output, the tool has failed, whatever its efficiency numbers say. Wide walls — room for many kinds of work — matter more than a high ceiling on any one kind.
Support collaboration
Most creative work happens in teams, and the paper is unambiguous that tool design should assume this rather than bolt it on afterwards: each contributor should be able to work in the mode their own talent suits, not the one the tool happens to have been built for first.1
Support open interchange with other tools
No single application carries a creative process from end to end. The user orchestrates a set of tools, each covering part of the task, and the paper treats this as a design requirement rather than an integration afterthought.1 For DCC software in particular — where a project routinely crosses three or four applications before it's finished — a tool that assumes it is the whole pipeline is a tool that will be worked around.
Choose primitive elements with care
The most consequential decision in any creative tool is the choice of what the user is actually allowed to manipulate.1 Pick primitives too close to the machine — matrices instead of movement, RGB triples instead of colour — and you've handed the user your implementation instead of their material. The next chapter takes up this same tension from a different angle, under Simple to Operate, Sophisticated to Investigate.
None of these five principles is fully worked out here, and that's deliberate. Later pages in this guide develop several of them into concrete design guidance: what it means to make an object, rather than a command, the thing a user manipulates directly; and what it means to let a tool be extended without letting the extension undermine everything the rest of the tool has taught the user to expect. Consider this page the charter. The rest of the guide is the case law.