Inductive design and the ‘primary generator’

Fallingwater in Pennsylvania

Fallingwater in Pennsylvania

When Jorn Utzon conceived his quixotic design for an Opera House in the antipodes, where did the essence of this designerly master-stroke come from?  When Baron Haussmann reconceived New Paris and Walter Burley Griffin arranged Canberra, how did they select one central organizing principle to collapse the complexity and permeate the multiple layers of these cityscapes?  What seed of an idea did Frank Lloyd Wright have in his genius mind when he sketched the concept plan for Fallingwater as his apprentices looked on in amazement? 

Each of these designers employed a central principle, a conceptual anchor, to demarcate one of the unquantifiable numbers of options and to navigate the seemingly infinite solution space.  Can a ‘seed’ of an idea generate a complex but coherent design?  And if so, what kind of designerly thinking creates such a seed and how does the design process unfold in its presence? 

In the late 1970s Jane Darke analysed recorded interviews with British architects on their personal accounts of designing to a brief for a public housing master-plan.  She found the architects’ common strategy for dealing with complexity was to latch onto a relatively simple idea early in the design process, and then experiment with a candidate design based upon this central structural pattern.  Darke argued, alongside a number of other young design cognoscenti-in-the-making (John Thackara, John Chris Jones, Peter Dormer and Nigel Cross to name a few) that the incumbent view of design as analysis-synthesis was disconnected from observed practice, and that an alternative subjective model based on designer intuition, experience and tacit knowledge was closer to the truth. 

Bryan Lawson in his book ‘How Designers Think’ summarises Darke’s ‘primary generator’ hypothesis as follows:

‘…first decide what you think might be an important aspect of the problem, develop a crude design on this basis and then examine it to see what else you can discover about the problem’. (p. 45)

The term ‘generator’ became recognised by design theorists to describe the use of a single unifying concept, idea, analogy or configuration that drives the design’s structure at its most abstract level through to its detail.  A generator may be simple (a pattern of squares, concentric shapes, arches) or arbitrarily complex (helix, multi-dimensional lattice or laminar flows).  The influence of a generator may be perceivable from the design’s macro level to its minutiae.  A strong generator may be taken as an indicator of design purity and the designer’s strength of vision, insight and skill. 

Some generators define a designer’s oeuvre, signature style or in a few cases, career period.  Frank Lloyd Wright based his prairie houses on a consistent geometry of long, horizontal planes for floors, roofs and decks, anchored heavily to the flat mid-west prairie ground, with balancing cantilevered eaves and terraces, exemplified by Robie House and the fanciful Fallingwater.  Bjorn Utzon conceptualised the design of the Sydney Opera House using geometric slices through a sphere, at the same time brilliantly working in a mirage of the First Fleet’s billowing sails on Sydney Harbour.  Not all designers embody genius, and not all generators are as inspirational as these. 

It can be argued that good software products are similarly shaped by generators, each operating at different levels of the system’s architecture.  A portal, a desktop metaphor, a common way of interacting with heterogeneous resources, are all potential design generators.  A primary generator aids the designer in creating the concept, not the mechanism of the solution.  The primary generator does not dictate the design of the solution, just as Utzon’s treatment of his conceptual sphere constrained the macro design problem but offered little guidance on how to solve the substantial engineering problems presented by the remarkable building’s enormous concrete shells or its waterfront foundations.  Under the covers, at the software-architectural level, software design patterns provide mechanisms to implement the primary generator’s concept.  But this is where architectural design ends and engineering begins.  Generators and design patterns are more like cousins than twins. 

In software design, architecture and engineering come together.  Software designers may use generators of a kind as inspiration for their architectural abstractions in the form of everyday or familiar analogical objects or concepts.  The term ‘abstraction’ has different uses and meanings in software design to those of its use in classical architecture where it describes the selective omission of detail from a building’s facade or visible features.  Physical fabrics and artefacts exist at only a few levels of abstraction, and an architect or designer’s plans or specifications typically address only two levels of abstraction. 

Software architecture is abstraction, and a software architect’s abstractions correspond to the components and elements that are synthesised in a solution.  Abstraction enables software architecture by providing a mechanism for the designer to impose a conceptual structure.  Abstraction is supported by most programming languages, particularly object-oriented languages, which provide for a high level of software structuring, allowing systems of millions of lines of code to be thought of in separate modules and successive abstract layers.  

Some years ago, I worked on a large telecommunications system using C++ and an object database.  As designers, we settled on a deceptively simple metaphor – collections and filters – and then instantiated this generator across the solution architecture.  A collection was a group of business objects and a filter a device to select from its underlying collection a subset of the objects relevant to the particular task.  Collections could be passed with workflows, attached to events, even serialised for transmission between nodes.  We used Gang-of-Four patterns to implement the collections and filters in a flexible and adaptable fashion.  The generator caught on and the architecture quickly sprouted collections of network events, alerts, notifications, statuses, audit reports, schedules and work activities. 

In use, the generator shone through the user interface and provided a conceptually simple, intuitive and consistent model for the users.  The underlying software architecture benefitted equally, as common elements could be separated and implemented in the framework layer, leaving behind domain concerns and a layer of common infrastructure services.  ‘Collections and filters’ guided what the solution would be — it provided the central organising structure for both the user’s conceptual model and the software architecture.  The result was a code base that was simple, minimal and maintainable. 

Jane Darke’s contribution to design thinking is the notion that a designer’s conjecture can form the basis of a viable personal design process.  Other work contributed further evidence for an inductive model of design thinking, highlighting the ways that the expert designer pre-structures problems, negotiates aspects of the brief, and fits known patterns to complex and challenging real-world contexts and design briefs. 

Primary generator is a useful way of thinking about how expert designers selectively choose a structural element of a solution and by exploring and elaborating this central pattern, understand the problem and design the solution at the same time.  By artificially constraining the solution space, a primary generator frees the designer to reach a candidate design quickly and test it for suitability. 

Jane Darke, 1979.  The Primary Generator .

Bryan Lawson, 1997. How Designers Think .


2 thoughts on “Inductive design and the ‘primary generator’

    • Interesting that I didn’t use the term ‘abductive’ in this post. I refered to inductive design as a mechanism for managing complexity — Darke’s designers latched onto a central feature and then elaborated it, dealing with complexity by first simplifying it to its essential structural idea. Roger Martin writes about ‘abductive’ design as something else again, the ‘opening up’ and negotiation of a given problem before the designing even begins. So, an abductive design process goes further than Darke’s account did. Great point!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s