D log

DEMO FAQ part 2:

Q: Are the teams split between planners and other tracks?

A: No, at least for the DEMO section I am teaching, I encourage all “tracks” to sign up. Please realize, however, that I will not be giving you detailed product and communication feedback – my feedback is (as it should be, since I do not have a background in product or communication deign) is focused on research and planning. In the past, product and communication designers have taken my DEMO section, and generally been successful. I prefer to teach mixed teams. However, you will not be ultimately responsible for designing “something you can draw a section through” (Dale’s litmus test for a product DEMO). Instead, you will end up with rough prototypes and a business plan.

Q: Do projects have to be “sponsored?”

A: Yes. It is a much better learning experience for the students when there is a real client with real problems. Some of our clients are companies, and other are non-profit organizations.

Q: Do you have a sense of what the projects will be for Fall 07?

A: Yes. At the moment, the following projects are likely.

> Cath Lab of the future (Sponsor = GE healthcare)
> The creative city (Sponsor = CEOs for cities)

There are several others, but since they are not yet final and this is posted publicly, I cannot announce them. However, they will deal with new payment models for healthcare and reinventing services for large cities (sponsored by a city). There will likely be five projects to choose from. At the moment, the projects will fit into two themes: the future of the city and fixing healthcare in the US.

Q: We want to propose a project on our own, is this possible?

A: Maybe. I want to caution students against this. Finding and scoping a project on your own adds a tremendous amount of work. Also, if there is no real client, your project will feel even more ambiguous and frustrating than other ID projects. However, if your project fits the following criteria, then game on:

> Connection to and commitment from a real organization (a commitment of both resources and time).

> A meaningful problem, but not a problem the organization needs solved by the end of the semester. We are not in the business of consulting (meaning the project results should be variable). This does not mean that the outcome cannot be implemented, it just means you should not sign up for fixing a mission critical problem.

> The topic should be aligned with the overall themes of the class (the future of the city and fixing healthcare in the US), and / or be sponsored by an organization that is of strategic interest of the school.

Q: How do we form teams?

A: On the first day of class, we will meet as a group and I will briefly describe the projects. Then, we will form teams based on interest in the different projects. Unlike most ID classes, where teams are assigned randomly, teams should be based on who you like to work with and what type of project you want to work on.

Q: What is the difference between DEMO I and DEMO II?

A: In this DEMO section, DEMO I is focused on research and initial concept development (giving you plenty of time for both) DEMO II is focused on creating and testing prototypes, and building your business case.

Q: What are the deliverables, and when are they due in Fall 2007?

A: They are as follows:
Problem reframing paper: September 7
Ecosystem research: October 5
User insights: November 16
Concept paper: November 30
Concept paper: December 7

Q: What is expected in each deliverable?

A:

For all papers:
• All papers should be between 15 and 25 pages (except for the problem reframe paper which should be one or two pages, the concept paper may also be longer, if required)
• Papers should contain new, unique content. Plagiarism will result in academic probation and potentially expulsion.
• All references should be cited using end notes.
• Papers should be a mix of text, diagrams and pictures.
• All papers must be 8.5” x 11” and be submitted in accordance with school standards in vertical or horizontal format.

Ecosystem Paper
The purpose of this paper is to research, organize and present contextual information on the specific project area. It should reference your problem re-frame, and will help you design effective field research. Successful papers will go beyond restating existing information and include analysis and interpretation. Successful papers will also include detailed references and a complete bibliography. The data for this paper should come from literature searches, databases, and material from the client. A successful structure for this paper may be:
1. Purpose of this document (what it is and how to use it)
2. Review of problem reframe
3. Synthetic diagram that summarizes findings (this should help structure the remainder of the paper).
4. Support for the primary synthetic diagram.
5. Claim or finding
6. Clear definition of claim or finding
7. Supporting evidence and facts
8. Supporting diagrams and pictures
9. Description of next steps (how this research has helped you frame your user research)
10. End notes / bibliography

User Insights Paper
The purpose of this paper is to identify, organize, analyze, summarize and present field research findings. In general, it will include photographs or video grabs, text and diagrams and will serve as a preliminary framework for the project. It will identify specific issues and objectives critical to the proposed research project. Speculative concepts that will be developed in subsequent phases of the project must respond to needs observed in the field. A successful structure for this paper may be:
1. Purpose of this document (what it is and how to use it)
2. Review of problem reframe
3. Review of findings from ecosystem paper
4. Description of research methods and approach
5. Synthetic diagram that summarizes key findings (this should help structure the remainder of the paper).
6. Detailed description of each finding (remember to use as many pictures and diagrams as possible)
7. What was observed (facts)
8. What was learned (insights)
9. What it means for the organization (implications)
10. Description of next steps (how these insights will drive concept development)

Concept Development Paper
The Concept Development paper should summarize, organize and present a range of concepts either as concept sketches or concept prototypes. Concept Sketches are two-dimensional representations of concepts for a product, communication, interface, environment or system. Concept Prototypes are interactive representations, often three dimensional, of a product, communication, interface, environment or system. These prototypes help to explain concepts and facilitate understanding of core relationships and principles. You should explore various representation forms, including maps, diagrams, sketches, models, pictorial drawings, collages, etc., to help explain concepts and to clearly address issues and objectives identified and defined in the User Insights Paper.

Concepts should also address “Ecosystem” findings and position new idea concepts relative to current trends. It is desirable to produce many different concept directions early in your project.

A successful structure for this paper may be:
1. Purpose of this document (what it is and how to use it)
2. Review of problem reframe
3. Review of findings from ecosystem paper
4. Review of the User Insights Paper
5. Outline of methods used to generate concepts
6. Solution architecture
7. A single page / spread for each concept
8. Initial stakeholder review / feedback
9. Concept evaluation (risk, value, achievability)
10. Next steps

The design planning skill-set

“The man who grasps principles can successfully choose his own methods. The man who tries methods, ignoring principles, is sure to have trouble.”
- Ralph Waldo Emerson

ID is a method-focused school, but we cannot lose sight of the fact that methods alone have no value. Only when a principled designer (with the right skill set) applies them will they yield any value. This week’s discussion centered on the skill set and principles of the successful design planner.

It is not just about methods, we need to develop skills and principles:

It is worth taking a moment to talk about design planning, and what we mean when we say “we are a planning school”. Planning is the opposite of doing. For most of its history, design has been focused on the “doing” part, which usually meant making things (like products and communications). Recently, however, the economics of the profession have changed, due to global logistics and technology, and solely focusing on the “doing” side of the equation is no longer (in many cases) a viable business model for design firms and designers.

Even though we are a planning school, that does not mean we aren’t interested in the “doing” side. The result of our work should be a tangible product, communication, or experience. We recognize, however, that to survive as a profession, we need to participate in the “what to make” conversations, and not just be satisfied to acquiesce when told: “go make this”.

I have been fortunate enough work with IIT’s business school (Stuart School of Business) recently on curriculum development. The AACSB (the board that gives accreditation to business schools) has a set of guidelines for what skills and knowledge an MBA student should have upon graduation. As an employer, you are getting a known quantity. This is a first attempt to produce something similar for design planning graduates.

So, what are the skills and principles required to be a successful design planner?

We started by showing the following diagram, which demonstrates how design planning pulls knowledge and skills from several disciplines:

As a result of the lecture, Albert Wang put together a set of diagrams that furthers this thinking:

1. Design planning does not cover all the knowledge in these disciplines

2. It is not something totally new

3. It is about integration (Darn you Rottman for trade marking Integrative Thinking!)

4. Our challenge is to determine what is inside our scope and what is not

We went on to identify the following skills:

> Designing and facilitating effective collaboration
> Communicating and clarifying ambiguous / complex ideas and data
> Storytelling (visual / verbal)
> Problem framing
> Flexible Response
> Modeling
> Scenario Planning (if/then/multiple possible solutions)
> Dealing w/ a Constantly Changing Landscape
> Observational (as opposed to Ethnographic) Research Techniques
> Conditioned Optimism – don’t kill quickly
> Bounded Naiveté
> Principled Problem Solving
> Reasoning by Analogy
> Seeing connections
> Getting Disparate Parties to Work Together

When finished talking about skills, we went on to discuss the principles of our work, captured in the following diagram:

The final topic of discussion was whether we should change the name of “Design Planning”? Should it be “Innovation Planning”? “Innovation Management”? We know there is a big backlash (mainly in the design community) about the word innovation. Any thoughts?

11 things you should have learned in “Economics and Design”

It is spring break this week, so no DEMO class, and no discussion to add to this blog. So I have decided to post the “eleven lessons” from my Economics and Design class. A more descriptive title for this course would be Economics for Design. The goal is to introduce the students to important topics from the field of economics, and then demonstrate how these topics are relevant for designers. This class is followed by Professor Chris Conley’s “Economics of Design”, which takes a more micro view, focusing on the economics related to running a design firm, as well as design projects in a corporate setting.

In NO particular order, below are the eleven things I hope students learn in the class:

Incentives matter. A lot
Economists look at the world through the lens of incentives. Most outcomes, good and bad, can be explained though the application (or misapplication) of incentives. And, they believe, if you want to change behavior (invest more, commit less crime), you can create a set of incentives to trigger this behavior change. As designers, our work is also concerned with behavior change (making things easier, trying something new). We rarely, if ever, consider how to apply an incentive strategy along with our new design, or how our new design may work/not work with an existing incentive strategy. Design of incentives is a powerful new frontier for our profession, and should be integrated into our everyday work.

Gravity works the same everywhere. Market forces do not.
Much of Western economic thought was developed with the belief that, like gravity, basic economics formulas will work in any culture and for most problems (this is a gross oversimplification, but true none the less). Unfortunately, while gravity relies on fairly stable naturally phenomenon, economics relies on the individual decisions of people (which have proven, over time, to be less stable). This is not to say that free markets and free market theory can’t be applied everywhere, only that the applications have to be tuned for each culture. Designers can play very important role in the new global economy. Innovations in logistics have made it possible to get new products and brands anywhere in world (as well as be produced anywhere in the world). Our role is to ensure that these products and services are appropriate for each culture and country. We can’t assume that markets and products will work the same other places as the do here (in North America), we need to design these markets, interactions, and offerings to and for each market.

Cash is king
If your great new idea cannot produce enough cash to pay for its own development, plus a little extra for you and your friends, it may not be such a good idea after all. It is critical for designers to understand that businesses run on cash (meaning earned profits above expenses, or EBITDA for the accountants). Our job (as a professional designer) is to make things that make cash.

People do not always make “rational” choices
Quite a bit of recent economic research has focused on defining the “irrational” (irrational does not mean bad, just not driven by math) choices people make under uncertainty. There has been the dominant (although always challenged) thought in economics that people behave rationally and that this behavior can be quantified (game theory, the Nash equilibrium). But, we have come to learn, through the development of Prospect theory (as well as other advances in behavioral economics): people do not always make rational choices. For example, recent declines in the stock market have lead many to note that the market does overreact to current events. Wall street may be the only market where, when they put on a sale, all the shoppers leave. As designers, we should pay close attention to this convergence of psychology and economics; it can provide insight into the adoption and use of our offerings.

But somehow, over time, markets appear to be rational and most things regress to the mean
Despite the fact that markets are made up of millions of people making potentially irrational choices, from 40,000 feet, markets seem rational (the DJE has gone from 66 to over 12,000 fairly steadily over the last century). Regression to the mean is a powerful force (it is why, although average height has increased over the past century, people are not ten feet tall).

How a company is finances itself shapes its options and strategy (and how it approaches design)
Designers are not often interested in how the companies they work for are financed. However, financing choices lead to how willing (and able) a company is to take risks and spend money. We would prefer to work for companies that have plenty of available cash and are willing to take calculated risks. We have all worked for companies that seem stuck in the past, and are unwilling to innovate. It is important for us to know the financial condition and financial structure of the companies we work for. Too often, we propose design solutions that have no chance of being developed, not due to interest, but due to available investment money. We should adapt our design solutions to be compatible with the financial context of the company.

Design both creates and mitigates risk
Design is seen as a risk for companies. Moreover, it seems like a risk that the company cannot manage (compared to changes in exchange rates). As designers, we need to recognize that we are seen as a risk, and them demonstrate how our work can actually mitigate certain types of risk. In fact, the most potentially devastating risks a company faces (changes in customer preference, market forces, and technological change) can all be managed within the scope of a design project. We need to shift our position from creating risk to managing it.

Design creates and destroys value
Every time we put pen to paper, we are either creating or destroying value for customers and businesses. We destroy value by designing things that can never be implemented, or do not solve for real user needs. We also destroy value by creating “shelfware”, or design briefs that only serve to weigh down file cabinets. We create value by identifying opportunity spaces, and then providing real options for taking advantage of those opportunity spaces. We also create value by energizing and inspiring the organizations we work for. Designers should be obsessed with creating value; this frame of reference should guide everything we do.

Accountants have a hard time accounting for design
There are two reasons that accountants have a hard time thinking about design. First, like most R&D dollars, design is an expense, and as such, needs to be shown as a cost on the balance sheet in the year it was incurred. Compare this to a new machine for a factory, which can be “depreciated” over time, so a percentage of the cost is taken each year of the life of the machine. So, even though your design project may create insights and a product that has a life of ten years, the entire expense needs to be taken in the year the work was originally done. Second, accountants do not recognize value creation until a product has been ordered or shipped. Usually, by that time, design is long gone from the equation. The current practice of accounting makes it difficult to argue for the economics value of design.

The source of design value creation has shifted
Most design firms that I know of are trying to get into the “strategy” game. This means they want to have more input into product definition, not just product design. This trend results from a shift in economics – design development and production/construction drawings are not as lucrative (or time consuming) as they once were. Faster software and global competition are driving this change. So, in order to continue to remain in business, firms have had to shift the bulk of their billings to strategy work, which requires less “horsepower”, and more knowledge and domain expertise.

There is an investment curve for design
The old adage “you need to spend money to make money” is unfortunately relevant in the design profession. “Investment curves” are used to demonstrate the relationship between investment in a certain capability, and the return on that capability (unsurprisingly, it is rarely a linear relationship). In the case of design, companies will rarely see a great return on their investment if they just hire a designer firm every now and then. There is rarely true knowledge transfer, or enough time to really change a process, in this case. It is not enough just to show our managers the design investment curve, we need to make a coherent argument about why they should invest more in design, and clearly articulate the outcomes and benefits.

Reading list:
If you happen to still be awake, I recommend the following books for further reading:

Naked Economics: Undressing the Dismal Science by Charles Wheelan

Against the Gods: The Remarkable Story of Risk by Peter L. Bernstein

Micromotives and Macrobehavior by Thomas C. Schelling

Why Most Things Fail: Evolution, Extinction and Economics by Paul Ormerod

On The Wealth of Nations (Books That Changed the World) by P. J. O'Rourke

Making Globalization Work by Joseph E. Stiglitz

Getting unstuck using the strategy table

This week was ID’s annual recruiting event, Recruit ID. The school was buzzing with nervous, well-dressed students and inquisitive, busy (due to the number of interviews) potential employers. Since most of the Demo students were tired from several days of interviewing, this week’s lecture was somewhat shorter than usual, and included a recipe for Chili…

A solution to overly long team meetings?

During a walk through the fifth floor at ID (and perhaps a walk through the offices at most companies), you will likely see a team engaged in debate. They are facing each other, trading ideas and concepts. But, all is not well at this meeting – you can see frustration in the faces of the participants: they feel stuck.

There is perhaps nothing more frustrating than to be part of a team debating half-baked, ambiguous concepts. There are no clear alternatives on the table (only opinion and conjecture), so there is nothing to evaluate, and no decision can be made. In this case, there is a way out of the woods – a tool called the strategy table.

I first learned about the strategy table while working with Cynthia Benjamin from SDG (Strategic Decisions Group www.sdg.com). SDG is a strategy-consulting firm that helps large organizations make complex decisions. In order to make these complex decisions, SDG must know all the alternatives available (possible choices, strategies, and actions). This allows consistent evaluation of the options.

I have adapted the tool for use during the design process. A method used to help companies choose where to drill an oil well is surprisingly (or unsurprisingly, I guess) effective when used to address issues that designers face, especially during synthesis and concept development.

The strategy table in practice

The primary purpose of the strategy table is to facilitate the evaluation of real (meaning you can do them) options, not debating ambiguous concepts. Teams waste a tremendous amount of valuable time in conversation. This tool helps define alternatives and then evaluate them according to project objectives and design criteria.

There are some warning signs that you may need to use the Strategy table:

> Meetings last more than an hour and are spent in discussion without the use of a whiteboard or framework

> Everyone generally feels that "we don't know what to do next"

> There is consensus through attrition

At this point in the lecture, Zach noted that these “warning signs” are often on teams where there are no constraints, processes and no set leader. There is a balance that needs to be struck between having too large of a set of options (we can do anything) and a set that is too constrained. Remember, reductive reasoning is the path to mediocrity.

Making chili with the strategy table…

The strategy table works because it is not only a framework, but also a specific process for development. First, the team needs to decompose the issue a set of functional / descriptive categories. So, if we plan to build a new factory, and want to understand your options, you would created categories like location, size, configuration, technological stretch, cost, and so on.

For this class, we took on making Chili. So, we decomposed chili into its key variables:

> meat
> legumes
> salsa
> spices
> topping
> accompaniment

Next, using these variables at the top of each column in the strategy table (see figure), list all of the different options under each column, going from "mild to wild."

You can then create various alternatives ("strategies") by combining one element under each column for all of the columns. You can choose your variables based on a predetermined generic strategy--that is, you can make "Rapid Chili," "Green Chili," or "Veggie Chili" by choosing different ingredients from each category knowing what your intended final result is. This is the top-down approach. You can also create strategies using a bottom-up approach by putting together new combinations of elements for unique strategies. For each of these strategies, consider the specific advantages and disadvantages in order to evaluate which alternative is the best to fulfill your objective.

Strategy for "Rapid Chili"

Strategy for "Vegi Chili"

Strategy for "Green Chili"

Evaluation of Chili Strategies

As far as alternatives go, when is enough enough? We offer a scale from 0% (no alternatives) to 150% (too many alternatives, values become too granular to be useful). At 80% - 100%, all strategies have advantages and disadvantages, you've created an exhaustive list of creative values, and there is opportunity to discover "hybrid" alternatives by combining strategies. You can use this to create low- and high-end systems to find multiple alternatives with different characteristics.

In summary, use the strategy table whenever you feel stuck when planning a project, planning research, developing concept systems, and developing strategies. For instance, after a workshop, when you've collected a bunch of ideas and concepts, you can cluster them using the strategy table into concept systems.

Dave gives an example of when he used a similar process to try to schedule presentations for teams in the Design Analysis class this week--he started noticing patterns and discovered problem areas (time slots) that he then was able to isolate and address independently so that further strategy develop could go on more effectively.

Dealing with Ambiguity

If you are going to design anything, you will likely need to deal with ambiguity. Simply put, this means you do not know for certain what the end result will be, and you also have to choose from several potential pathways to reach that solution. As designers, we have been trained (sometimes even explicitly) to deal with this uncertainty. However, as we increasingly bring clients into our process, we expose a whole group of people that has worked their entire academic and professional like to avoid ambiguous situations (a little hyperbole, I know).

This discussion focused on how design planners can better “deal with ambiguity”, and discussed ways to make this fact of design life easier on them.

Expectations versus reality

The discussion began by noting a graph drawn by Matt Beebe (from IDEO) that explained the difference between a design process’s actual and expected progress. At this point, Dave McGaw noted that most new designers have the same frustration--they expect progress to be linear.

The disconnect between expectations and progress:

Zach built on this idea and noted that it's not even a single-sloped learning-curve graph, but a slope with numerous, smaller rises and falls in level of ambiguity.

These issues are fairly common in any creative process, and designers need to make our clients feel better about ambiguity. At the same time, trying to force the creative process into a linear relationship with time would harm the overall design process. A slide showed some common client comments about ambiguity:

Why ambiguity is good and, in fact, necessary for innovation

A simple 2x2 diagram shows where good design programs and approaches stand with respect to level of definition for results and process; ID strives to use a defined process to arrive at undefined results, where traditional design programs use undefined processes to arrive at defined results. Undefined results are valuable because they are often the innovative concepts, but then the big questions are: how do we know when we're done, when we've arrived at that innovation?

Program types:

Hypothesis driven, fact-based is the strategic planning approach (much like the scientific process), wherein data is collect based on the premise to prove or disprove the premise. A hypothesis supported approach for innovation planning involves a hypothesis as the starting point for research, but it's understood that the initial hypothesis can and probably will change.

Classes of problem solving:

Disclaimer: Ambiguity does not mean you don't need a plan!

Ambiguity should not be confused with under-specification; we still want to have a well-defined process, clear deliverables, metrics for success, and a clear roadmap. Not all aspects of the design process benefit from some degree of ambiguity. At the same time, over-specification of the design process can be inefficient. This chart shows where open-endedness is good, and where specific definition is preferred, in the overall design process.

Under-specification:
> Poorly defined process
> Unclear deliverables
> No measure of project success
> Make it up as you go..

The problem with some Demo projects in the past is that many teams don't have a final goal in mind, and wherever they end up on May 15 is what they deliver as their final project. There are better ways to plan an innovation project:

The "meander" approach:

Hill climbing: determine a goal and work backwards to figure out how to get there from where you currently are. This approach is good for engineering projects, where the end product is already established.

Hill climbing

Efficient diversity: know where you're starting, determine a clear goal, but throughout the process you will make a series of decisions in order to get there. This is a more organic process that may be more fitting for innovation planning.

Efficient diversity:

Finding a balance

Ultimately, designers need to understand what you can control about the process, what they need to learn more about, and what can be eliminated in order to deal with ambiguity. You can deal with ambiguity by doing what you have been doing so far, but only changing one small part instead of changing everything and facing a completely unprecedented situation that is to unfamiliar and ambiguous.

Several techniques were offered:
1. Have a clear work plan and stick with it

2. Aim for short term wins -- Can we deliver some quick insights to the client to prove that we are on the right track? This instills trust and gives designers "a free hand" in moving forward.

3. Reason using analogies – how has this problem been solved before in other industries? How have we solved other problems like this at our own company?

4. Create information structures, a la structured planning -- This is a powerful way to deal with big topics and ambiguity because it places everything in a larger context, and ensures the client that the designer has considered many facets of the problem.

5. Holding frequent update meetings -- never surprise your client! Dave comments that this is the one that is hardest to implement even though it seems really easy. The only way it really works is to get a project manager who rules with an iron fist and enforces that, because a designer is not going to spend as much energy making sure it happens.

6. Focus on building trust -- "There are two types of people in this world: those that do what they say they're going to do, and everyone else."

Elegant systems

This week’s lecture was certainly a surprise for most of the students, since it focused on a topic that we often do not address at ID (elegance). We spend a lot of time talking about process and methods – this discussion was a case of “and now for something completely different”.

In the end, however, I think the class agreed that if we use our tools and methods appropriately, we would create elegant solutions for businesses and customers. These solutions may or may not “look” elegant, but their logic, structure, and systems will “be” elegant.

I am happy to report no ID students were harmed during this debate of intellectual history, and we also managed to have a discussion where no one channeled Derrida our Foucault. Next week, we will go back to our ID methods focus, and will talk about how to modify the insight matrix to allow for 10,000 variables (not really…)

Enough pre-ramble, here are the notes from the discussion:

First, I tried to define elegance:

Elegance? The definition of this term has changed over time and can vary from person to person. My grandmother might call a late-1900s-era Showboat-style southern Victorian home "elegant," while I might consider that too ornate to qualify. In the end, it all depends on people's values and identity; my definition of elegance is associated with modernism. To me, elegance means simplicity, efficiency, a lack of complexity, and an ease of understanding.

For many people, elegance is something that, as Potter Stewart (associate justice of the United States Supreme Court) said about hard-core pornography: it is hard to define, but "I know it when I see it." (referenced on "Law & Order: SVU" this week) (Note: thanks to Joyce for getting this reference right – although SVU has been known to be wrong, but who can argue with Ice T?)

Elegance vs. Simplicity/Complexity

Complexity is not usually elegant. For example, airlines: flying American Airlines is a terribly complex experience that involves a lot of headache and responsibilities for the user; in contrast, by simplifying the process, Jet Blue has created a more elegant solution to flying.

Simplicity can be an element of elegance, but too much simplicity can border on blandness or boredom. There is a fine line--elegant doesn't mean "simple." Cletus (the slack jawed yokel from “The Simpsons”, who is simple, is not elegant. In fact, he is the opposite of elegance.

There is the old aphorism “simplicity is at the far side of complexity”. Perhaps we would be more correct to say “elegance is at the far side of complexity”.

In sum: elegance is:
Smallest number of elements creates the greatest impact
No unnecessary elements
Makes sense as a whole

There are 3 types of elegance:
1. Formal/aesthetic elegance
2. Structural/systemic elegance
3. Logical/idea-based elegance

The last two are what we focus on in this school, and they may also be easier for us to distinguish what is and is not elegant.

Some examples of elegant systems:
> Chipotle
> Abbott and Costello's "who's on first" comedy routine
> Bach symphonies
> Airplane wings
> Google

Final thoughts:

Our challenge as design planners is to make our ideas and concepts elegant. We don't want to reduce the richness, and we do not want to oversimplify things. Time after time, we see people executing work, but not being insightful. It's about what you derive from the 100x100 matrix, not that you completed it.

Jay Doblin once said "Innovation can become parasitic by increasing the complexity of our lives." It is a Victorian notion that every activity requires a separate product. This leads to increased complexity – managing all the products that are supposed to make our lives easier. Rather, we should think about "denovation" - the attempt to simplify or reduce the number of products without reducing the service performed. Denovation provides a clear path to elegance.

First set of FAQ questions

Q: Is the course really called Demo?

A: No, the full name is Research and Demonstration

Q: Who can take Demo?

A: IIT Institute of Design students in their final year of study

Q: What is Demo?

A: it is a semester or year long project for students at the IIT Institute of Design. Ideally, the students will conduct field research, and then put to use the methods they have learned while at ID (that is the demonstration part)

Q: Is Demo required?

A: No

Q: Then why would students want to take it?

A: The course is six credit hours, and allows the students more time to explore and experiment

Q: What type of projects do the students do?

A: The projects are usually dictated by a real world client.

Q: Why not call this a thesis? Isn’t that what it is?

A: Calling a project a thesis would mean following a set of guidelines from IIT main campus, few of which are relevant to a design project. Also, the projects would need to be approved by a “thesis examiner”, which adds an unnecessary layer of bureaucracy.

Q: Is Demo just for planning?

A: No, you can do a Demo in Communication and Product design

First topic: Running good workshops

Each week this semester, the planning demo class will meet as a group and discuss a topic relevant to the class (and hopefully relevant to designers in general). I (Jeremy Alexis, the Demo Advisor) will prepare a few simple slides and a structure for the conversation; the students will provide questions, stories, and challenges. We will use this web log to summarize the discussion – our goal is that it can continue the conversations we have in demo to include alumni, potential students, friends of the school, and the larger design community.

The topic last week was “running good workshops”. The students will be conducting several workshops in the near future, and this seemed like a good time to talk about what works and what does not work when trying to get a group of people to be creative.

Workshops are an increasingly common activity in the design process. They allow the design team to bring together a large group (hopefully from multiple disciplines), and then leverage the “wisdom of crowds” to create new ideas for products, services, and business models. There are many arguments both for and against holding workshops – we did not dive too deeply into this debate. Rather, we just assumed that workshops are a necessary component, and if you run them correctly, they can be very useful.

Designers have not always been seen as workshop facilitators. I am pretty sure that Frank Lloyd Wright did not have his clients and contractors to his office in Oak Park to brainstorm new ideas for houses. Paul Rand was famous for disappearing for several months, and then coming back (well, apparently the clients would have to come to him since he often did not travel) with three potential design solutions.

But as we all know things change. We were once solely responsible for developing creative, path-breaking ideas. Although we are not off the hook for this (clients still want the occasional good idea…), our role has expanded to include facilitating idea generation from different stakeholders and managers. This can actually be more challenging than creating the ideas – it can be really hard to get a group of people (often people that do not see themselves as creative), to withhold judgment, pick up the sharpie, and contribute to the brainstorming session.

Step 1: choose the right type of meeting

There is quite a bit written on how to run a brainstorming session or how to elicit creativity from the unwilling. We did not try to tackle these issues. Instead, this discussion tried to outline a practical guide for making these sessions successful. So, a good starting place is “what type of meeting should we run”. This is an important question, since “brainstorming” is often used at inappropriate times in the design process. The first challenge for planning a meeting is making sure you are planning the right type of meeting. If you need top managers to make a decision, you do not want to spend time creating ideas. This sounds stupidly obvious, but I have seen many occasions when a design team defaults to brainstorming as the key activity in a meeting, even if the outcome of the meeting has nothing to do with brainstorming.

To understand the types of meetings that a design team can run, we will use a 2 X 2 matrix (by the way, if you have an aversion to these, I suggest you never visit this page again, since you will likely see them frequently and in all their glory). On the X axis is understand / make. There are some meetings where the primary goal is learning or information exchange, in other words you are trying to create a common understanding within the group. Other times, the goal is to “do” something, either make a decision or create a set of options and ideas (for those counting, this is the “make” side). On the Y axis, we see that some meetings can be about “arrival”, meaning that at the end of the meeting, we want the whole group to have arrived at the same conclusion, idea, POV, and so on. On the other hand, you can also run meetings where the goals is departure, meaning you do not want everyone to agree at the end, rather, you want to create a diverse set of opinions, ideas, and hypotheses.

The conversation in this class centered on meetings in the “departure / make” quadrant – meetings that intend to motivate and inspire the group to create a diverse set of concepts (or brainstorm!).

Step 2: get your critical success factors in place

Once you have concluded that you need a brainstorm meeting at this point in the process, you next need to make you set the right conditions for the meeting to be successful. The following are “critical success factors” for any brainstorm meeting:

Right mix of people: I can’t stress the importance of this factor enough. You need to work with your corporate contacts to ensure that your invite list includes a mix of people that want to be there (people that have good ideas and will contribute) and have to be there (people that can act as barriers to implementation).

Clear goal (ideally articulated by someone important in the organization)

Good food (and army marches on its stomach, so do brainstorm participants)

Highly structured, newsworthy content

Step 3: design the brainstorm sessions

You can use any type of brainstorm method you want, but no matter your choice, there are several fundamental rules you should follow.

First, make sure that you have design the session for an appropriate idea generation pace. This means balancing the speed of idea generation (not too fast, not too slow), with the quality of output. So, you can be creating good ideas, but if they are coming too slowly, the participants will lose interest. If you create poor ideas quickly (not something to be proud of…), the team will be frustrated with the results. The following diagram shows this balance:

Second, you need to design the session to include time to generate, debate, evaluate, and communicate the concepts. Teams want to do all three; it is up to the facilitator to make sure that teams are in the appropriate mode. However, if you do not plan for all four of these modes, the team will likely go into them anyway, and your timing with be thrown off. I recommend a 45% / 30% / 15% / 10% distribution (so, 45% of any session should be filled by generation). The following diagram shows a framework for meeting design:

Step 3: prepare the manipulatives

How far you go on this step is usually determined by your approach to brainstorming. There are approaches that bring in items like beanbags, magazines, nerf products, red wine, and so on. Other approaches rely only on black sheets of paper and sharpies. I have seen all of these approaches both succeed and fail. It is best to tune you manipulitves to your audience. The following diagram shows a continuum for different types of sheets for capturing ideas:

Step 4: prepare the facilitator

If your critical success factors are in place, and you have good food and content, the job of the facilitator can be easy. However, even with all these elements in place, there is still the need for someone to energize and inspire the group, and then keep them on track. A facilitator should keep a group on target, prevent any one person from dominating, make sure people are documenting their ideas, and work to keep the group on time.

The analogy is well known: brainstorming is like popping pop corn – it starts slowly and then speeds up, but eventually slows down. To manage this, a facilitator needs to be good at asking questions. A good AI machine, asking the following four questions, may make a good facilitator:

“Say more...” The facilitator must try to coax ideas from the group. This is best achieved by saying the open ended phrase “say more...” This challenges the individual or group to further explain and think about their ideas. When asked to refine and elucidate, people need to rely on their creative side to fill in the blank space.

“Build on that” great ideas build on each other. The facilitator should try having the group “build a wall with ideas”, not just lying a bunch of individual bricks on the ground. The goal is to leverage the group dynamic to extend and challenge each individual’s thinking.

“How can we overcome that” frequently you will encounter a difficult group member that utters phrases like “we could never do that” or “that is impossible”. The facilitator can turn this around – usually these people react well when put in a position of authority – give them the opportunity to solve the problem they have stated. This usually helps turn a negative attitude into something more positive.

“One conversation at a time” it is important to not have group members talking over each other. The facilitator must retain order in the group.

Step 5: prepare the team

Often a design team consists of 4 to 10 people. These people will often be at the workshop. Generally, one person will run the workshop. This does not mean the rest of the team should be sitting in the back making fun of the participants. Each member of the team should have a jog. You may include:

Time keeper

Note taker (white board notes, visible to all)

Note taker (typing, capturing as much as possible)

Prep (people working behind the scenes to help get the next activity ready)

Plants (people near important clients making sure they are enjoying themselves and understand everything)

Step 6: finish what you have started

Often, workshops end with the participants feeling excited about the ideas that were created and happy to get to cocktail hour. Every day after the workshop, this enthusiasm fades. To keep the momentum of the project up, the team needs to produce, within one week of the workshop, a “review packet” sent to all of the participants. This should include:

> Summary of content slides
> List of participants
> Idea catalog
> Notes
> Clear next steps

Final thoughts

Designers need to be able to run workshops. For the near term, our corporate friends will expect us to do this well. The tools and techniques presented, when implemented properly, should make workshops more fulfilling for the participants and valuable for the designers. I look forward to any feedback or additional input.