New Simplified Design Framework (Draft)

Here's a stab at it, this blog seems as good a place as any to take a try. This is a bit of a draft, with no images yet. I will add them later. Feel free to ignore this for now, just felt like throwing it up early.

The Old Process/Product Models
Here's the part of my design framework you need to understand to get what I'm getting at here. First, I see design as an information gathering process. Basically you are trying to learn about 1) the outcomes that will satisfy all of the stakeholders of the design situation, and 2) the designs that will lead to those outcomes.

[Basic image of design space and outcome space]

So lets look at the design space first. A design is a representation that can be translated into an outcome. A blueprint is a design, the building is an outcome. The design space is the space of all possible designs.

We also have a space of every outcome that could be possibly conceived, and when a given design is executed, it will result in an outcome. A given design is assumed to be interpreted according to some professional standard, but there is always some wiggle room in the exact outcome that will be realized by a given execution of the design. Sometimes, a design is preliminary, and might result in a great many outcomes. If I sketch a building on a napkin and say "build it", there's a lot of ways you might interpret my sketch, and a lot of buildings that might result. If I give you a full blueprint, I have a lot more confidence about what outcomes I'm going to see. You still might make certain choices about materials, brands, numbers of nails, but I can be assured of certain dimensions and qualities.

[Image of stakeholders and outcome spaces]

This constraining is important because we want to ensure that we achieve outcomes that are desirable. Among all the stakeholders in the design process, each has some concept of what makes them happy. The client who contracts the opera house says "make it reflect the grace and generosity of my family". The city says "obey these zoning laws and we get to sign off on whether it fits our vision of the city". The architect himself says "I want this to reflect my genius, to be a true Bob Buildington Building". There are certain outcomes that are going to meet all of these needs and keep everyone happy, and some that are not. You want to be assured that your design is "desirable" that is, that it meets the desirability standards of all your stakeholders.

Now, of course, this may not be possible, there may not be any outcomes that truly make everyone happy, so you might need to be flexible. Some of these desirability spaces might be a bit fuzzy. Furthermore, you need to consider which outcomes are feasible. That is, you might design a skyscraper on a thin glass pillar, which is a vision that everyone envisions as a desirable outcome, but you can't build it. Its not a feasible outcome.

So you need to make sure that, when you create a design, all of the ways it might be interpreted are desirable. Therefore, it might be a good idea to be specific, and ensure that the enactor of your design doesn't haul off and create some awful shit that your design didn't tell him not to.

In short, design is all about learning about what outcomes you want, and what kind of designs will achieve them, and then settling on a design that leads to the outcomes that you want. To put it another way, if you knew everything, you could just say "Aha! Here's the design, I will hand it off, and any way its interpretted, that design will make everyone happy". Or at least you would know if that was impossible, and what comprimises could be made. Designing is about gathering enough information to approximate this kind of omniscience, learning enough about the situation at hand to slam down a design and say "this'll do it".

Now, I have a process model that also describes the information that feeds into this process of creating designs. In short, you have Ideas about what form your design should take, Knowledge that spans projects but that can be applied to the situation at hand, Goals that tell you what Ideas and Knowledge should be used and which should be passed on, and Representations, your link to the outside world, your way of passing information between people and learning about how things actually work.

Representations

[Rep as abstraction image]

The main pertinent point here is Representations. Basically, you can use a representation intentionally and exploratoraly. Intentionally: someone put some information in this representation, and now you can get it out. It might be a note to yourself, a conversation with someone, or a design document. Its the way we take the purely mental ideas, knowledge and goals and let them move from mind to mind. Exploratoraly: This is the key one. We can create physical objects that are approximations of real-world situations, and they can give us insight into fitness of outcomes, and the design-outcome connection.

For example, if I create a sketch of a building, I can look at it and go "huh, that doesn't look right", and maybe create another sketch (if I can merge this reflection and action into a single action of Reflection in Action, I can start a hallowed Reflective Conversation with Matertials, as described by Schon, which is sort of a design-representation-related version of a Flow state as described by Csikszentmihalyi). This sketch tells me some things, but it leaves out others. I might not have a sense of the shadows the building will cast on the surrounding populace based just on a sketch. So I might create a scale model with the surrounding areas. Then I can look at that and think about where the problems are, what does and doesn't work. I might later create a full-scale facade of what the building is going to look like, to get a feel for the materials and the appearance.

In this running building example, I'm creating an approximation, an abstraction. It isn't practical to create a whole building and decide if it's right, and then tear it down and try again if not. Instead, I make a tradeoff between ease of creation and realism. I can use a very easy sketch to tell me some things. I can spend a little more time to create a scale model to learn others, and so on. Generally, those approaches that are strictly more difficult than others, while providing similar information, have been weeded out from common practice, and the common approaches present a pretty smooth tradeoff along these dimensions.

So this is our way of learning about the outcomes we make. We have some ideas, we create approximations of them, and then we evaluate those approximations, and therefore those ideas. We keep the ideas that seem promising, we discard those that don't, and we slowly learn more and more, hopefully generating ideas that are better and better, until we are satisfied, or get pissed off and give up.

That is, because some fields are harder than others. In the next section, I'll describe some actions that I see as fundamental to the design process, and explain how some fields have a harder time with some of them than others. When certain actions are difficult, trying to execute them can hinder the designer's basic creative flows, and the designer must find ways to adjust their process and their state of mind to creatively attack the troublesome problems. But now its nearly 3.