• View
• Edit
• History
• Print

Design

Assigned Reading

• Terry Winograd, Shifting viewpoints: Artificial intelligence and human–computer interaction, Artificial Intelligence 170 (2006) 1256–1258
• Herbert Simon, The Science of Design, Chapter 5 in The Sciences of the Artificial, MIT Press, 1981 (2nd edition), 129-159 [31]
  ”...Everyone designs who devises courses of action aimed at changing existing situations into preferred ones. … Design, so construed, is the core of all professional training… Schools of engineering, as well as schools of architecture, business, education, law, and medicine, are all centrally concerned with the process of design.” -- Herbert Simon, The Sciences of the Artificial, (1969)
• Richard Buchanan, Wicked Problems in Design Thinking, in The Idea of Design, MIT Press, 1985, pp. 3-20 [18]
• Winograd and Flores, Chapter 12: Using computers: A direction for design. pp. 163-179 [17]

Additional Reading

• Daniel Fallman, The Design-oriented attitude from In Romance with the Materials of Mobile Interaction: A Phenomenological Approach to the Design of Mobile Information Technology, Doctoral Thesis, ISBN 91-7305-578-6, Umea University, Sweden, 2003, pp. 77-100
• Giorgio De Michelis, The contribution of the language-action perspective to a new foundation for design from HCI Remixed, MIT Press, 2008. [5]
• Terry Winograd, Discovering America: Reflections on Henry Dreyfuss, Designing for People. HCI Remixed, MIT Press, 2008.
• S.R. Klemmer, B. Hartmann, and L. Takayama, How bodies matter: five themes for interaction design. Proceedings of the 6th conference on Designing Interactive systems, University Park, PA, USA: ACM, 2006, pp. 140-149.

Comments Before Class

Wicked Design Thinking - Mark Schar

A Contrast of Design Approaches - Seng Keat Teh

The Computer Could Use Your Constructive Criticism - Jeff Wear

Two Diverging Harvard "Schools" of Design - Matt Garr

In reading this week about design, I thought of a conversation I had over the summer with a friend who is a recent graduate from the Harvard School of Design, and a newly practicing architect. Enthusiastic about learning more about the applications of virtual design and construction tools in my new PhD? program, I attempted to put forth the point that architecture’s merits might someday be evaluated using computer algorithms. Essentially, I was told that this was nonsense; no matter the quality or extensiveness of the algorithms, a computer would never be able to determine what qualified as an inspiring space, nor if a digital representation of a building would be regarded as a work of genius. We ended our conversation with neither of us significantly changing our viewpoint—I still believed it was only a matter of time until architecture firms would yield to computer-based architects.

Throughout this course, my view has become quite a bit more refined, and I now find myself occupying a middle ground. As Herbert Simon argues in “The Science of Design,” many professions have seen formal design processes codified and formalized. The design process thereby created contains the professional knowledge experience of those who participated. It is clear to me that certain “best-practices” in any design profession can be formally represented, and often used productively to arrive at good solutions that satisfy a design space. Perhaps using such guidelines, a computer can in fact determine when a space has a good chance of qualifying as inspiring and even create one of its own. Just as a beginning architect learns to design good spaces by studying the work of her predecessors, a computer could likely draw upon previously established clichés to assemble its own work.

However, the computer remains largely blind; it can never be truly inspired to create something unprecedented. This suspicion was reinforced in a recent talk by Kostas Terzidis, also of the Harvard School of Design, at a recent presentation to the Stanford HCI group. His brand of algorithmic architecture was remarkably good at finding the “right” designs in a design space. In one example presented, a bathroom was efficiently and cost-effectively designed by evaluating all possibilities of arrangement of a sink, toilet, door, and shower in a two-by-two grid. This type of architecture is indeed useful, and perhaps threatens the job security of junior architects who are forced into such mundane tasks during their professional training. However, it is fundamentally different than the creativity or genius that Dr. Terzidis suggested it might someday subsume. Scaling the operation up could certainly allow an architecture firm to be brutally efficient in generating sufficing designs that are heuristically evaluated against a set of well-understood criteria. But something outside the algorithmic design space will forever remain outside pending the intervention of a software developer.

As Simon noted, it is impossible to generate the best solution due to computational limits, but a pretty good one is certainly possible. However it remains that the new design represents only a recombination of elements previously inspired in a less-constrained, more human design space. The computer would never have the insight that Frank Lloyd Wright had in designing the Hanna House, on Stanford’s campus, on a hexagonal grid. Wright argued, quite phenomenologically, that the hexagonal grid allowed humans to better function in the space, and that the 19” wide hallways and low ceilings were better proportioned to guide residents to the spaces in which they spent most of their time. An algorithmic design application, it is certain, would have never considered using a hexagonal grid and small hallways unless the software design team explicitly programmed in that design process. The computer would be equally clueless on how to evaluate the hexagonal grid. Whereas people can intuitively comment on whether they find the Hanna House to be claustrophobic or a work of genius, a computer unschooled in the ways of hexagonal grids would just output “illegal geometry input.”

Simon argues that we do not need to “return or retreat to the cookbook methods” of design, as many kinds of design processes have been fully specified. However, all his examples of such processes represent design spaces that have continued to evolve since the paper was written. Evaluating highway designs, for example, requires more and more environmental studies each year, the results of which must be considered as criteria in the design space. Perhaps then, the role of the master designer is evolving from continually designing buildings or products to continually redesigning design spaces to represent new inspirations and evaluation criteria, while sticking the computer with manual, boring, and inefficient tasks.

Nate

An interesting phenomena is how negatively people seem to react to familiar interfaces changing on them. When Facebook recently updated their GUI there was a small movement in favor of reverting to the old more familiar one. When Apple updated to OS 10.5 they changed the menu bar to be transparent. I was pretty surprised that such a simple change could be met with so much discontent. Almost immediatly someone found a trick to turn it back to opaque (although Apple did not make it easy). Do these problems arise from designers not truly understanding the domain in which they are designing--the domain where people live?

Phenomenology teaches us to be aware of the domains in which one designs. As a result designers must make an effort to be aware of how people exist in the world. But of course this is very hard. "In writing a program, try to think of everything that can go wrong." Because of this difficulty rapid prototyping makes sense. Figure out what will go wrong as you build for a specific task. If users can do their task great, if not, see what can be changed. In addition, this process allows designers to overcome blind spots not just fix problems. Perhaps a designer did not realize that their software was being used for something unintended, yet had positive effect, the next iteration could add more support for this new task. Klemmer points out that by working through a problem rather than thinking through it, a dialog is created between the designer and the domain. The designer receives useful backtalk that may have been difficult or impossible to predict. Similarly, Fred Brooks author of the Mythical Man-Month states that software should be grown not built. We engage in a conversation with the environment.

I like the metaphor of thinking about things in terms of conversations, conversations between machines and people, machines and machines. We can think of GUIs? as a new form of language that we use to "talk" to computers or to each other. Emotocons are a new form of language developed exclusively for communication through computers. They are an interesting example of an unintended behavior emerging from a design flexible enough to allow it to emerge. People will use things in unexpected ways. The best designers can facilitate these uses. The domain is the conversation. Conversation is not about transmitting a colon and a right paren : ) its about meaning, and action. Even at a low level when a simple object sends a message to another object, the purpose is to change the state of the other object--to make something happen.

I'm not sure i understand the parallels with design and Maturana. Are you suggesting the process of design is autopoietic?

 -- Nate

Energy Management as a "Wicked Problem" - Chris Anderson

Over the past summer, I worked for a company called iControl, located just off of California Ave. Their vision is to connect in a useful way the various devices in the home that are increasingly gaining wireless connectivity. One particular application of this vision is to the burgeoning field of home energy management. The actual process of collecting a home’s energy data is simple, but the prospect of transforming that data into a visual that presents a call for action is daunting. It fits well the "wicked problem" model of Horst Rittel:

• The problem is ill-formulated: What does it mean to present energy data that "calls to action?"
• The information is confusing: No one, including CEOs? of pure energy-management companies, seems to know what customers want or need.
• There are many clients and decision makers with conflicting values: The companies selling the energy management products are not always the ones making them, and even within companies doing energy management, who decides what features are included is a muddy problem.
• The ramifications of the whole system are thoroughly confusing: What does it mean for your interface to work for a particular consumer, as opposed to working for consumers as a whole? What actions should you want your customers to take?

So, without explicitly knowing that we were faced with a question of applied design thinking, what did we do? We got trapped in the tension of the different modalities of approaching design problems: industrial design, engineering, and marketing, to use Buchanan’s words. Rather than exploring each modality's contribution and integrating them during the design process, we often dealt with one aspect (i.e. the engineering necessities) until they were done to death. We lost individual bits of each way of thinking throughout our process.

The greatest insight that occurred was the recollection that what we were designing was for someone, who had preexisting notions about what it meant to save energy, and were responsive to particular nudges in the right direction. In particular, every consumer we talked to said that he or she wanted a graph of their energy usage over time. However, when actually presented with one, the consumer promptly ignored it and asked for something else. We had assumed that our understanding of signs and things – our set of placements – well matched our situation. This was not the case, and we stopped trying to force our ideas into the situation.

In this situation, I absolutely agree with Buchanan and Rittel that design problems have no true or false answers, only good or bad solutions. Specifically, my example illustrates for me that understanding that the quest for a great product was not finding the set of features that truly solved a problem, but rather the search for a good solution that worked within the bounds of a problem. The particular manner in which you do that evades specification, but knowing how we can describe the process makes it more intuitive and useful.

Forest comments

The implications of Ch 12 for issues of project monitoring in the construction engineering field is straightforward. I did not read the other readings since I became intrigued by Ch 12 and wanted to read this in detail rather than the usual skim reading of intro and conclusion necessary for this type of reading. Like Terry said he purchases a book and skims it then later may grab the same book and devour it, I devoured Ch 12.

The authors specifically mention two topics dear to my field, spreadsheets and civil engineering. At the intersection of these two topics is where my work, both scientific and professional resides. If not for excel neither would be much of an issue. Talking with older engineers (70+ years) they tell a narrative about a world of engineers traveling from the main office to multiple project locations to record the monitoring measurements in a bound paper journal, with rows and columns. The metrics collected at that time were minimal, typically those memorized by on-site superintendents and recorded from invoices. The "old timer" engineer said we did nothing that is anywhere near what you younger engineers do to monitor project progress. We were amazed at the simplicity of those times.

Today with machines (both physical and software) we monitor projects at a level of detail unimagined even around the time this book was written. Excel is the number one driver of this capability. The second are software tools such as scheduling that at one time were too slow to provide practical real-time forecasts. It once took 12 hours to process an updated schedule, therefore the dependence on whiteboards that exists even today (~15% of large projects). Even in 2002 with typical low-end desktop machines typical in office trailers, at that time the hardware barely supported the use of multi-tabbed spreadsheets using functions and cross linked cells would function at a scope necessary to prove time-efficient to outdo paper-based analysis. Same with scheduling.

At the authors project, the breakdown point and readyness to hand are important considerations. In hindsight these were the critical points that determined if a software tool or process was shelved or used. Even then it was highly dependent on the machine operator. Would the tool survive under pressure from changes, uncertainty and short (minutes) reconfiguration/update windows. Most did not under typical operators.

Thoughts on Music, Design, and Wickedness, and another on Music and AI - Luke Dahl

Simon ends chapter 5 of ‘The Sciences of the Artificial’ by noting that all the problems of design apply also to “music, its composition or its enjoyment.” I tend to agree and will consider ways in which that is true. I did find it surprising, however, that he would discuss music. The main point of his chapter is, it seems to me, that designers can avoid being “sloppy fellows who reasoned loosely, vaguely, and intuitively” by applying the techniques of statistics and optimization to their problems. However as Buchanan points out true design problems are “wicked”, and really cannot be addressed only by optimizing some function. In fact the in the act of framing the problem and its possible answers in a way that is amenable to computation we must already solve the true problem in all of its wickedness.

I don’t see musical performance as a design problem, but other musical acts are: Composing a piece of music involves specification of the activities and organization of the performers (Buchanan’s third broad area of design.) The design of new tools for music creation, including creating new performance instruments as well as designing software for recorded music production, requires creating material objects, symbolic visual communication, and environments for playing (Buchanan’s other three categories.)

In all of these activities I see no way to formulate the problem such that mathematical optimization would be useful, and as I read through the ten noted characteristics of wicked problems, each one seems relevant to musical design problems.

I’d like to speak more about each in turn, but I do not have time to do so and get these thoughts submitted online in time! I hope to explore more details in my final paper.

--- An unrelated note on AI and Music : There is a field called “Music Information Retrieval” (or MIR) in which people apply machine learning techniques to the analysis of music and its social uses. In a recent discussion I’ve noticed both claims and difficulties that remind me of the history and difficulties of GOFAI. One claim is that recent developments will have the same impact on musical behaviors as the invention of written music and the invention of recording. However music is a human activity and so has the same problems as language. Consider an algorithm that tells you how similar two pieces of music are, and take as examples a recording by Ella Fitzgerald and another by Billy Holiday. To a jazz aficionado these represent opposite sides of the spectrum of jazz vocalists. But to a young Britney Spears fan these are almost identical in their difference from what the listener is familiar with. As usual the problem of similarity requires knowing “to whom, and for what purpose?”

Design Thinking - Robert Graebert

It is interesting to see the meaning of design and design thinking to spread from the traditional appearance aspect to also encompass placements, functions and organizational makeup. A lot of the work in the Civil Engineering department is going into coming up with more scientifically rigorous definitions and processes for design and construction processes. The goal is to channel the indeterminacy out of the process to produce better results. This could mean better cost control, more detailed requirements, less schedule risk. Simon is making a case that this is a common trend in Engineering departments, trying to become more scientifically viable and valuable.

Now, design thinking appears to me to be a great “middle of the road” approach. For best practice in industry to evolve we need to move away from the “cook book” and apply better defined processes. The design thinking based processes can then define strategies for how alternatives should be explored, when to stop exploring and guide analysis. At the same time, it needs to keep the process open enough for the novel ideas to be incorporated.

This appears to be less rigorous than a scientific evaluation of what the best solution to a given problem will be and provides much better generality even across industries. Current results we are seeing are often not reproducible in other markets and building types.

As some of the other commentators have mentioned, using computers to operationalize the design space resulting in guided generation and valuation of many alternatives is promising. Expecting any program to produce the best answer for such indetermined problems seems to be as fruitless as the rationalistic approaches to GOFAI.

A Contrast of Design Approaches - Seng Keat Teh

I definitely see a contrast of approaches to design between that of Herbert Simon, who takes a very empirical and quantifiable view of the field, and that of Richard Buchanan, who has a more artistic, "design-ny" view to the issue. Both sides make valid points in my opinion, but Simon's empirical ideas about design would not be effective for the "wicked problems" in design that Buchanan highlights, problems of the nature where satisfaction conditions are far more complicated and chaotic. Simon's empirical view of satisfication also contrasts with that of Winograd & Flores, in which satisfaction is determined not by the world, but by the declaration on the part of the requestor or user that a condition is satisfied, thus resolving a situation of irresolution with regards to the needs of the requestor.

Simon's view would possibly be applicable to design problems in which the needs are far more straightforward, in essence, the wickedness of the problem has been taken out, either through a clearer and more lucid specification of needs and expectations of the stakeholders in the design solution. Problems that are much more utilitarian in nature with simple needs such as a clear, large highway to ease congestion or the design of a diet of consumption to reduce a user's cholesterol, because of the narrow set of goals of these situations, are amenable to Simon's methodology and view of design.

Buchanan's view of design fits often with problems that are complex in nature, such as having characteristics of many differing demands/preferences of the end-users and/or attempting to achieve a number of end-goals for the design, each of which are also complicated and highly-ambitious. Unfortunately, these characteristics seems to apply to most of the problems/situations that really matter to us in the real world. Imagine the burdens of a designing team tasked with the design and bringing to life of a national monument or the headquarters of a renown corporation. One would imagine that the commissioners would demand the designing team to come up with something very original, very unique, very awe-inspiring and yet also depict characteristics, images and ideas that the country or corporation wish to project, perhaps an image of strength, greatness, inspiring nationalism or awe. But how do designers even begin to start conceptualizing what to do? Do they draw upon past inspiration, or start completely from scratch, from a blank slate?

This seems to also be a problem for anyone wishing to design, conceptualize and create a disruptive product, one that would truly make an impact on our world, change the way how people use things and interact in their everyday lives. Buchanan hits on all these points of concern, and he makes it clear that a simplistic, naive view of the design process will not do in facilitating a solution to these kinds of complex design problems. But while he may have touched and raised such awareness, his ideas about placements, the emphasis of repositioning along the lines of signs, objects, actions and thoughts, remain a fuzzy attempt at grounding what seemed to be a natural, difficult-to-explain flow of artistic and creative creation by design experts addressing these complicated design problems. Can we for example explain original, unique works of design as necessarily the result of the designers attempt at conceptual placements and repositioning?

The Computer Could Use Your Constructive Criticism - Jeff Wear

In "Shifting viewpoints," Terry Winograd asks, "Should we expect to communicate with the computer in the same way as we would to another human... or are there practical ... objections to encouraging people to attribute human attributes and abilities to their computers?" An answer to this is found in ''Understanding Computers and Cognition":

It seems as if Winograd suggests that the computer need not provide a rich (e.g., verbal) interface to "get out of the way" and let the user immerse himself in the task at hand. But what is the "right" coupling to do so? Shifting the discussion from cars to computers, our readings concerning the art of programming have suggested that the possibilities for action a tool allows are predetermined by the form its human designers give it. Although an interface may provide a "coupling" between the user and action in a domain, it is surely not structural coupling, for the interface will not evolve to best suit the user's needs.

But a computer can respond to user input in a more flexible fashion than most mechanical tools. The interface between the computer and the user is communicative in some fashion - there is not a one-to-one mapping between input and output, but rather the user makes requests of the computer and the computer responds in ways planned for by the designers in some sense, but whose specific nature is determined by the user.

If nothing else, the user can configure programs' settings to best leverage the interface provided by the software. I am intrigued that Winograd mentions special 'function keys' as an example of 'transparent design', because while I agree that they facilitate transparency once they have been set up and the user has learned to use them, their discovery and configuration by the user is often not a very transparent process. In my observations, most users use the mouse for things as simple as opening a new tab in the browser,

So I think there is somewhat of an active role for computers/software to suggest to users how best they might be used. (Of course it is really the designers who are anticipating user needs and soliciting feedback, but this is through the medium of the software.) In part this may be accomplished though what Loren Brichter, developer of the wonderfully intuitive Tweetie Twitter client for the iPhone, calls "discoverable, explanatory" design. But the software can also use something as simple as encouraging the user to set preferences or as advanced as machine learning techniques to enlist the user in constructing the interface. The program can "watch the user at work" and adapt. I wonder if at times it might also be appropriate for programs to actively direct the user towards something or even to submit feedback - "did you know that you could do this?" An interface that engages and actively partners with the user in its operation (what I might call ongoing implementation) would seem to be more ready-to-hand than one which took a totally hands-off approach.

Post-Class Comments - Seng Keat Teh

@Jeff, you made a good point with the general idea of having a "discoverable, explanatory" design to a software's UI. I think this would be a great ideal in UI design, though there are generally no clear design principles yet towards achieving an aspect of "discoverable, explanatory" design in UI, it's probably more an art at this point, perhaps achieved iteratively by observing user mistakes or what deters them from using other features of a software (perhaps such features are well-hidden or obscured by the UI's layout of menu, buttons, etc.)

There have been attempts by certain software to solicit user feedback or suggest to them features of software that users don't already know. Often, this is useful during the first few times, but starts to become annoying after a while. I am sure you have, in previous experiences, encountered dialog boxes with "Tips of the Day" appearing the first time you start a program, or a certain virtual assistant using the metaphor of a paperclip making suggestions like "I see you are trying to write a letter...".

I think it is an interesting fine line to walk, an issue of balance, between trying to get the software to be more pro-active and explicit in its interaction with the user, and trying to avoid the software from being perceived as obnoxious and annoying. This is actually a pretty interesting open design issue on how we can strike an ideal fine balance in fostering active interaction and participation between the software and a user.

Post-Class Comments - Forest

To follow up of Professor Winograd's comments to my posting; He noted that I did not fully grasp the domain of the readings and instead have focused on the aspect of spreadsheets. This is correct since I did not read the additional readings until prior to class and after talking with Dean at his office hours. The concept of a 'wicked problem' ties in with this since this is precisely the reason we use spreadsheets to monitor construction.

In class Reid proposed the assertion that product design but not product manufacturing or specifically product manufacturing monitoring can be a wicked problem. I countered this with the argument that the product design uniqueness creates the need for an equally unique and unprecedented, i.e., ad-hoc, process. In construction the product is a unique product, unlike assembly line production of a homogeneous item, such as an automobile. Professor Winograd countered this argument with the example of residential tract-housing, each home is the same. This is correct, each home ('component') is a sub-object of the larger project, the residential tract. The tract is the unique product since no two are the same. There may be an example somewhere that two identical tracts are built on the same geology with the same orientation, similar labor resources and the same materials, but not likely. Each residential tract is a unique product similar to all construction projects.

The proposition and arguments appear to be: Proposition: 'Integration of human resources and enterprise resource planning systems into a larger system is not applicable to the "wicked problem" discussion' Argument1: (Implicit) The human resource (HR) and enterprise resource planning (ERP) systems are an integral component of product manufacturing, the third broad area of design and specifically the integration of these is the fourth area, as given by Buchanan in 'wicked Problems in Design Thinking', (Stated) "the construction of a wicked product requires a wicked process".

In the same way the process that the project is completed is unique. The organization structure, monitoring, control, and methods used all differ. Within the monitoring aspect (my specialization) the specifics of how the process is enacted changes on every project. Details such as the forms and classifications are often created specifically for each project to match the particular attributes.