Chapter 1 for Improvising Design book has been uploaded. The first chapter discusses why we need better models and methods for design … and why design is improvisational. Doubtless, stuff will be shifted around a little, as I complete my write-up of research findings chapters. But this is a good introduction to why we need to change our approach to design.
When attending a boundary-spanning design meeting the other day, I was reminded of how important pattern sensitization is to design. When we explore a new problem-situation, we structure it according to the patterns that we perceive in that situation. This is why experienced designers are so much better at design than novices. It is not that experienced professionals are sharper, or better at design — but just that they have a wider repertoire of patterns to call upon. As they recognize familiar elements of the situation, they fit partial solutions to those elements. Problem decomposition is not hierarchical, in the sense proposed by Alexander (1964), but convergent. The problem-space and the solution-space co-evolve, as designers explore these in tandem (Maher and Poon, 1996; Maher and Tang, 2003).
Back to the meeting.
A group of strategic managers (including the systems people and the business process change manager) were examining how to revise business process support for a routine workflow. The problem that they faced was that this had been adapted by several workgroups (whose representatives were present) over time. So each of these managers had a different perspective of the problem, depending on what each group was trying to achieve. The customer support group were frustrated that they could not access all of the customer information in the system, but had to call another group to obtain missing information. The order-processing group were frustrated that they could not track the progress of an order without having to run three separate IT applications. The sales and marketing group were incensed that not all of the latest products and services were publicized on the website. None of these people – including the IT group managers – could see that these were related problems. They spent hours debating the fields to be displayed on the screens and the detailed reports needed, without realizing that the workflows were related.
The breakthrough came by accident, when the Process Improvement Manager was mapping the “requirements” on a whiteboard. He started to link two of the requirements, stood back and then said “So this step is also related to this one, isn’t it?” Then the Marketing Manager said “That comes just before the promotions stage.” As the Process Improvement Manager drew a process diagram, each individual kept adding in pieces of the puzzle, with how they were related.
Design as bricolage.
Bricolage involves repeated “trying out” and experimentation until a pattern is discerned that is useful. (The word derives from Bricoleur, a French term meaning “handy-man” or “jack- of-all-trades.”) Claudio Ciborra described bricolage as “the constant re-ordering of people and resources that is the true hallmark of organizational change.” But Bricolage is not random experimentation. It is based on leveraging the world “as defined by the situation” (Ciborra, 2002). Pattern sensitization adds another dimension to bricolage. It can now be seen as an ordering of situation elements until they make sense according to previously encountered patterns. So design is like a jigsaw. Each person carries around a partially-completed set of jigsaw pictures in their heads. The core problem of design is to use a problem-representation that can allow people to communicate the structures in their “mental jigsaw picture” to others.
Alexander, C. Notes On The Synthesis Of Form. McGraw Hill, New York NY, 1964.
Ciborra, C.U. The Labyrinths of Information: Challenging the Wisdom of Systems Oxford University Press, Oxford UK, 2002
Maher, M.L., and Poon, J. “Modelling design exploration as co-evolution,” Microcomputers in Civil Engineering (11:3) 1996, pp 195-210.
Maher, M.L., and Tang, H.-H. “Co-evolution as a computational and cognitive model of design ” Research in Engineering Design (14:1) 2003, pp 47-64.
As I ruminate on design processes, I can’t help but reflect on the similarities between research methods, processes and outcomes, and design methods, processes and outcomes. I read an article which argued that there were two types of people: people with tidy offices and people with untidy offices1. Tidy-office people are organized and so can find anything they need. These are the people who work top-down, creating an outline then writing or designing according to that scheme. Untidy-office people are disorganized, spend a great deal of time searching for things, but also tend to be more creative because they are inspired by things which they bump into, while looking for other things. These people work bottom-up, assembling elements into a coherent whole. The article argued that there are cognitive rewards in both styles of working, that lead people to subconsciously adopt one or the other style consistently.
I was reflecting on this as I try to make sense of the piles of material that I have assembled for the book. I am definitely an untidy-office type and I wonder if this has something to do with introvert/extrovert personalities? [My project management students and I just explored an online Myers-Briggs personality test; as expected, I was an INTP type.] Perhaps introverts just prefer a “life of the mind,” where we can construct inductive models of the real world?2.
My semi-organized and shifting piles of research data, models and representations, interim findings, academic articles, and books provide a three-dimensional, systemic representation of design processes that can be reorganized as I comprehend different patterns. Of course, they are both preceded and supplemented by painstaking (and frequently revisited) processes of categorization, synthesis, and validation. But the kaleidoscope of patterns that they reflect is invaluable in suggesting different views of my findings. The same is true for design – we create the patterns that we perceive as relevant in the problem situation. As our perceptions shift, so do the design patterns that we follow.
I would argue that innovative design is neither deductive or inductive, but consists of cycles of induction and deduction. It follows a hermeneutic circle of sensemaking, as designers attempt to work from problem to solution and to reconcile those fragments of a solution that they understand back to a meaningful problem definition. The combination of deductive and inductive thinking has been described as abductive reasoning, but reasoning about design is more disciplined and rigorous than most descriptions of abduction [a hunch] would indicate. I prefer Thagard and Shelley’s (1997) argument that hypotheses about reality are layered, incomplete, and too complex to be comprehended easily3. Often, the only way to comprehend complex, interrelated elements of behavior and context is to use a visual, systemic representation.
As someone who has spent a good portion of their career as a systems designer, I have never considered design creative. Design is more about synthesizing from preconceived elements than creating from scratch4. But I wonder if – just as in research – the greatest inspiration in design derives from the serendipity of location?
Footnotes (click on ↩ to return to post)
If anyone knows the reference for this paper, please let me know. I saw an NYT article on the subject, but I can’t locate the academic paper again – which was published in an information science journal, if I recall correctly … ↩
Paul Thagard and Cameron Shelley (1997) “Abductive reasoning: Logic, visual thinking, and coherence.” Available at http://cogsci.uwaterloo.ca/Articles/Pages/%7FAbductive.html (last accessed 11/27/2009). ↩
Like sex, design seems to be 30% inspiration and 70% perspiration … ↩
People have been commenting on the change of font used by IKEA for their catalogs since August, when the new catalog came out. IKEA had used the Futura font for 50 years, but made the decision to adopt Microsoft’s Verdana font this year. Apparently, because it translates well to numerous languages. Take a look at the two catalog examples in this picture. Ignoring that the too-busy 2010 cover looks like they are trying to appeal to the attention-deficit generation, the 2010 catalog could be anybody’s while the 2009 catalog is distinctively IKEA. If you took the brand-name off the catalog, you’d know exactly whose it was.
This is important because design is about more than a satisficing appearance. We tend to mock style over substance, but style plays another role in design. It reinforces the emotional response to artifacts that we have and it provides us with clues (affordances) that tell us how to respond to those artifacts. There is an aesthetic to design that makes the difference between something that is a joy to use and something that just does the job. Sometimes that aesthetic is as simple as the tactile response to a Pilot G2 pen (one of the mundane artifacts that tends to rouse a lot of passion in its users). Sometimes it is the lack of cognitive effort in being able to distinguish the utility of one artifact over another because of its appearance. Sometimes, it is just the comfort of recognizing a familiar artifact, that one knows how to use.
For all of these reasons, IKEA’s decision seems stupid. They had a brand recognition that people would die for, based on the use of the Futura font. Yes, this may be a sad thing to obsess over. But the familiarity and distinctiveness of the IKEA catalog is gone. And I, for one, mourn its passing.
The collaborative design of system solutions for wicked problems seems to follow a trajectory of goals, as the group’s understanding of the design progresses. The key to making (and evaluating) progress is understanding what triggers the changes in goal-direction.
From my research studies, it seems that goal changes are triggered by breakdowns in individual buy-in to the group’s consensus definition of the design vision. Both the breakdowns and the most important parts of the vision are concerned with how the design problem is structured and defined — not (as we usually assume) how the designed system will work. Of course, the solution is important: individual group members constantly test their understanding of the problem against the emerging solution, then realize that the design goals need to change. But it is the consensus problem-vision that drives design goals.
An important implication of this design model is how to manage design effectively. We need to keep influential decision-makers in the loop, when design goals are redefined, or they just see the start and end points. The natural response is “what took you so long?”. Managing external expectations is key to design success.
I have posted a Table of Contents for the new book, at http://www.improvisingdesign.com/book.html
Contents are liable to change, but I feel a sense of achievement, having defined what the book is about … 🙂
This blog discusses how we design information system solutions for real-world problems.
The focus of IS design has moved “upstream” of the waterfall model, from technical design to the co-design of business-processes and IT systems. This focus requires an improvisational design approach. IT-related organizational innovation deals with wicked problems. Wicked problems tend to span functional and organizational boundaries as business process and information management problems are intertwined. There are clusters of interrelated problems: these cannot be defined objectively because the problem is defined differently, depending on who you ask. IS designers cannot analyze this type of problem in isolation – we need to involve diverse groups of stakeholders in negotiating suitable problem definitions and boundaries for change. But wicked problems also involve distributed knowledge, where understanding of the problems is stretched across (rather than shared between) stakeholders. So design goals evolve, as designers and stakeholders learn more about the context and the problems facing the organization by engaging in incremental change. This is often approached by means of agile design methods. But our lack of understanding about how to establish a “common language” for this type of design means that information system innovation tends to be pretty hit-and-miss. Most design initiatives spend more time arguing about process definitions than achieving change.
We need a new approach that focuses on the co-design of business (process) and IT systems: a collaborative process that involves problem stakeholders as collaborators in analyzing change. This is the basis of improvisational design.