My mower broke last time I used it. Payback for all the times I have mistreated it, yanked its handle, tilted it on 2 wheels over a gutter, or banged it roughly into a tree stump. The chassis rusted out where the handle attaches, so much so that the handle on the left side pulled off, taking with it a nicely rectangular chunk of rusted mower. So I did what any self respecting man would do. I left it in the shed and ignored it.
‘Design thinking’ is being sold as a methodology for sticky problems. It is also being sold as a process that just about anyone can use to solve ‘wicked problems’. Either something is slightly inconsistent between these two claims or it’s one hell of a method.
‘Contrary to popular opinion, you don’t need weird shoes or a black turtleneck to be a design thinker’ Tim Brown writes (HBR, June 2008). ‘Nor are design thinkers necessarily created only by design schools… many people outside professional design have a natural aptitude for design thinking, which the right development and experiences can unlock’.
The virtual presses are understandably full of accounts of Steve Jobs‘ significance and magnificence. Many raise mystical questions of what made Jobs special and whether others will ever be able to reproduce his success. Great stories from Apple insiders about Jobs are being told. Without wishing to cast the slightest dispersion on Jobs’ obvious genius in any way whatsover, I do find myself wondering what embellishments are being applied as his former disciples spin these yarns. Continue reading
We are all enculturated in the mythology of the master architect, the grand designer, the silver-haired visionary. Stories from design history depict larger-than-life figures, towering over grand designs, by virtue of their superior designerly powers, like design deity. Some historical figures were indeed geniuses. It is said that Frank Lloyd Wright’s reticence in revealing his concept for Fallingwater was making Kauffman (his client) increasingly nervous. With just hours before Kauffman was due to walk through the studio door, Wright apparently gathered his apprentices around the drafting table and sketched the concept in all its cantilevered glory before their eyes, narrating his thoughts as he drew. What this story says about Wright’s power of mental conceptualisation is inspiring. Myths are built on the exceptional, not the mundane.
Donald Norman just posted another piece in his annals on pragmatic design. Act first, do the research later implores designers not to waste time on prescribed research before the designing starts. This is the latest missive in the assault on ‘proper design methods’ he kicked off in late 2009 with Technology first, needs last which raised a blogospheric frisson when published. Norman’s central premise in that piece was that innovation breakthroughs result from technology developments and are independent of user need. In simple terms, the technology juggernaut rolls on and innovation occurs at the nexus of technological capability and pre-existing user need at a particular time and place. Norman consistently broadsides at some sacred cows including ethnographic design research (discovering previously un-articulated user needs) and user needs as a primary innovation driver. Just as Nicholas Carr declared that ‘IT didn’t matter’ in 2003, Norman declared that user needs don’t matter in 2009. This is roughly equivalent to telling a software development conference that requirements don’t matter.
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 .