The Design Squiggle
- ââDesign skirmishesââ
- ââWonder Plotsââ
- ââEmbracing the messââ
- ââThe Design Diagramââ
- ââOn Greatnessââ
People get confused, companies get confused. When they start getting bigger, they want to replicate their initial success, and a lot of them think that somehow thereâs some magic in the process that theyâve created. And so they start to institutionalize process across the company. And before very long people get very confused that the process is the content.
In my career Iâve found that the best people are the ones who really understand the content. And theyâre a pain in the butt to manage. But you put up with it because theyâre so great at the content. And thatâs what makes great products. Itâs not process, itâs content.
Get embedded in the team. Designers should use sprint planning, grooming, standup, and retro as opportunities to provide design to â and receive feedback from â the rest of the team. Designs can take the form of written or verbal descriptions, not just wireframes and high-fidelity mockups.
Only design whatâs needed. Use constant communication between engineering and product partners to understand what your collaborators will need next. Then, plan on delivering only what is needed, and nothing more. Use the agile process â grooming, planning, and retro â to find any shortfalls or excesses.
Avoid creating a backlog of designs. Designs donât age well. In the time between finishing design and shipping code, itâs likely that youâll learn something new that changes your understanding. If youâre producing more design than can be implemented, focus more on the quality of each design.
it is apparent that the unfolding of the design process assumed a distinctly episodic structure, which we might characterize as a series of related skirmishes with various aspects of the problem at hand.
As the scope of the problem became more determined and finite for the designer, the episodic character of the process seems to have become less pronounced. During this period a systematic working out of issues and conditions took hold within the framework that had been established. This phenomenon is not at all surprising when we consider the fundamental difference between moments of problem solving when matters are poorly defined and those with clarity and sufficiency of structure.
Within the episodic structure of the process, the problem, as perceived by the designer, tends to fluctuate from being rather nebulous to being more specific and well-defined. Furthermore, moments of "blinding" followed by periods of backtracking take place, where blinding refers to conditions in which obvious connections between various considerations of importance go unrecognized by a designer.
It actually doesn't matter whether you actually have a formal retrospective. It doesn't matter whether you have four or five labels of things on your retro board, or exactly how you do the retro. What does matter is the notion of thinking about what we're doing and how we can do better, and it is the team that's doing the work that does this, that is the central thing.
Holistic technologies are normally associated with the notion of craft. Artisans, be they potters, weavers, metal-smiths, or cooks, control the process of their own work from beginning to finish. Using holistic technologies does not mean that people do not work together, but the way in which they work together leaves the individual worker in control of a particular process of creating or doing something.
The opposite is specialization by process; this I call prescriptive technology. Here, the making or doing of something is broken down into clearly identifiable steps. Each step is carried out by a separate worker, or group or workers, who need to be familiar only with the skills of performing that one step. This is what is normally meant by "division of labor".
Today's real world of technology is characterized by the dominance of prescriptive technologies.
The temptation to design more or less everything according to prescriptive and broken-up technologies is so strong that it is even applied to those tasks that should be conducted in a holistic way. Any tasks that require caring, whether for people or nature, any tasks that require immediate feedback and adjustment, are best done holistically. Such tasks cannot be planed, coordinated, and controlled the way prescriptive tasks must be.
Prescriptive technologies eliminate the occasions for decision-making and judgment in general and especially for the making of principled decisions. Any goal of the technology is incorporated a priori in the design and is not negotiable.
Direct Management does not include or permit the concept of profit to occur. The management is fee-based, or based as a fixed salary, and all construction costs are fixed ahead of time, and the building design is modified during construction, to make up any over-runs. The manager is not able to move money around at will, or put it in their pocket. At the same time, the design is approximately fixed, but with the understanding that it may be changed, during the evolution of the building, so that subtle adaptations can be included in the emerging building. In the Direct Management method it is the architect themselves and the direct manager who together manage the building works and all on-site construction for the owner.
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
In software development deadlines are a necessary evil. It is important to understand when they are necessary, and it is important to understand why they are evil.
This Eames drawing, often referred to as the Design Diagram, was created for a 1969 exhibition at the Louvre entitled, What is Design? Charles and Ray mailed it to the exhibition curator to augment their answers to a series of questions she had posed.
Design, it seems, is not only becoming more methodical but also more scientific. This is not surprising. Design as a discipline has moved from âproduct beautificationâ to being a central part of product development. It has incorporated methodologies from human-computer interaction, sociology, and anthropology as well as advertising and management. And with the rise of design thinking, a wider range of professional disciplines are using creative methods.
I donât want to criticize design methodologies. But against the backdrop of an overly structured design process, it is important to remind our community that there is one fundamental aspect to design that cannot be formalized in a methodology. And that is intuition.
Many have become so focused on the process and methodologies that theyâve forgotten the fundamentals of why we started focusing on the user and what we hope to achieve with that focus.
The Pursuit of Lossless Design-Development Handoffs.
There is a disconnect between product design and product engineering.
The big misconception Iâve seen designers and developers often fall victim to is believing that handoff goes one way. Designers hand off comps to developers and think their work is done. That puts a lot of pressure on the designer to get everything perfect in one pass.
Instead, great collaboration follows what Brad Frost and I call âThe Hot Potato Process,â where ideas are passed quickly back and forth from designer to developer and back to designer then back to developer for the entirety of a product creation cycle.
Fight the Waterfall
Start all of the pieces of work a little bit earlier. The key to starting work early is not succumbing to the pressure of having to finish the work. Donât worry about finishing. If youâre a developer, you can start doing things while your design or information architect are working because a lot of your work actually isnât dependent on their work. Some of it is, so you probably wonât be able to finish, but that shouldnât stop you from starting.
Share Work-in-Progress Early and Often
When you share work-in-progress, share it with the caveat that no feedback is needed at this point. Youâre simply sharing it to let people know where you are. For example, if you have to make 12 wireframes, share it when you finish 2 or 3. Rather than spending a whole week to drop 12 wireframes, share 2 â 3 wireframes every 2 days. The more often you do this, you start to build rhythm, and rhythm builds momentum.
We do say ânoâ very quickly, not just to designs, but to everything. That led me into thinking about the psychology of software engineers and what makes us the way we are.
"By making it possible for the photographer to observe his work and his subject simultaneously, and by removing most of the manipulative barriers between the photographer and the photograph, it is hoped that many of the satisfactions of working in the early arts can be brought to a new group of photographers. The process must be concealed fromânon-existent forâthe photographer, who by definition need think of the art in taking and not in making photographs. In short, all that should be necessary to get a good picture is to take a good picture, and our task is to make that possible."
â Edwin H. Land, co-founder of Polaroid
So much about [Gerhard Richter's painting process] reminds me of designing and building for the Web: The unpredictability, the peculiarities of the material, the improvisation, the bugs, the happy accidents. There is one crucial difference, though. By using static wireframes and static layouts, by separating design and development, we are often limiting our ability to have that creative dialogue with the Web and its materials. We are limiting our potential for playful exploration and for creating surprising and novel solutions. And, most importantly, we are limiting our ability to make conscious, well-informed decisions going forward. By adding more and more layers of abstraction, we are breaking the feedback loop of the creative process.
"If you develop a program for a long period of time by only adding features but never reorganizing it to reflect your understanding of those features, then eventually that program simply does not contain any understanding and all efforts to work on it take longer and longer.â â Ward Cunningham
It was clear that [Hewlett-Packard] recognized that its true value was in its employees.
How do you learn to run a company at 21 with no business experience?
Throughout the years in business I found something, which is, Iâd always ask why you do things, and the answers you invariably get are âoh thatâs just the way itâs done.â Nobody knows why they do what they do, nobody thinks about things very deeply in business. Thatâs what I found.
Iâll give you an example. When we were building our Apple Is in the garage we knew exactly what they cost. When we got into a factory in the Apple II days, accounting had this notion of a âstandard cost.â Where youâd kind of set a standard cost and then at the end of the quarter youâd adjust it with a variance. And I kept asking, âwhy do we do this?â And the answer was just âwell thatâs the way itâs done.â And after about 6 months of digging into this what I realized was the reason you do it is because you donât really have good enough controls to know how much it costs, so you guess, and then you fix your guess at the end of the quarter. And the reason you donât know how much it costs is because your information systems arenât good enough.
But nobody said it that way. And so later on when we designed this automated factory for Macintosh we were able to get rid of a lot of these antiquated concepts, and know exactly what something costs, to the cent. And so in business a lot of things are what I would call âfolklore.â Theyâre done that way because they were done that way yesterday. And so if youâre willing to ask a lot of questions about things and work hard you can learn business pretty fast. Itâs not the hardest thing in the world. Itâs not rocket science.
I think everyone in this country should learn a computer language because it teaches you how to think. Itâs like going to law school â I donât think anyone should be a lawyer, but going to law school could be useful because it teaches you how to think in a certain way. So I view computer science as a liberal art.
The technology crashed and burned at Xerox.
What happens is, like with John Sculley, John came from PepsiCo, and they at most would change their product maybe once every ten years. To them a new product was like a new size bottle. So if you were a product person you couldnât change the course of that company very much. So who influenced the success of PepsiCo? The sales and marketing people. Therefore they were the ones that got promoted and they were the ones that ran the company.
Well, for PepsiCo that might have been ok, but it turns out the same thing can happen in technology companies that get monopolies, like IBM and Xerox.
If you were a product person at IBM, or Xerox, so you make a better copier or a better computer? So what? When you have a monopoly market share, the company isnât any more successful. So the people that can make the company more successful are sales and marketing people, and they end up running the companies. And the product people end up getting driven out of the decision marking forums. And the companies forget what it means to make great products. The product sensibilities and the product genius that brought them to that monopolistic position gets rotted out by people running these companies who have no conception of a good product vs. a bad product. They have no conception of the craftsmanship thatâs required to take a good idea and turn it into a good product. And they really have no feeling in their hearts, usually, about wanting to really help the customers.
So thatâs what happened at Xerox.
People get confused, companies get confused. When they start getting bigger, they want to replicate their initial success, and a lot of them think that somehow thereâs some magic in the process that theyâve created. And so they start to institutionalize process across the company. And before very long people get very confused that the process is the content.
In my career Iâve found that the best people are the ones who really understand the content. And theyâre a pain in the butt to manage. But you put up with it because theyâre so great at the content. And thatâs what makes great products. Itâs not process, itâs content.
Whatâs important to you in the development of a product?
One of the things that really hurt Apple was that after I left John Sculley got a very serious disease. And that disease â Iâve seen other people get it too â itâs the disease of thinking that a really great idea is 90% of the work, and if you just tell all these other people âhereâs this great idea,â then of course they can just go off and make it happen.
The problem with that is that thereâs just a tremendous amount of craftsmanship in between a great idea and a great product. And as you evolve that great idea it changes and grows. It never comes out like it starts, because you learn a lot more as you get into the subtleties of it, and you also find there are tremendous tradeoffs you have to make, there are just certain things you canât make electrons do, there are certain things you canât make plastic, or glass, or factories, or robots do. And as you get into all these things, you find that designing a product is keeping 5,000 things in your brain, these concepts, and just fitting them all together and continuing to push to fit them together in new and different ways to get what you want. And every day you discover a new problem or a new opportunity to do it a little differently. And itâs that process that is the magic.
What Iâve always felt that a team of people doing something they really believe in is like, is like when I was a young kid, there was a widowed man that lived up the street. He was in his 80âs, and a little scary looking, and I got to know him a little bit â I think he paid me to cut his lawn or something â and one day he told me, âcome into my garage, I want to show you something.â
And he pulled out this dusty old rock tumbler. It was a motor and a coffee can and a band between them. And he said âcome out here with me,â so we went out to the back and we got some rocks, just some regular old ugly rocks and we put them in the can with a little bit of liquid and a little bit of grit powder, and he turned the motor on and said âcome back tomorrow,â as the tumbler was turning and making a racket.
So I came back the next day and what we took out were these amazingly beautiful and polished rocks. The same common stones that had gone in â through rubbing against each other, creating a little bit of friction, creating a little bit of noise â had come out as these beautiful polished rocks.
And thatâs always been my metaphor for a team working really hard on something theyâre passionate about. Itâs that through the team, through that group of incredibly talented people bumping up against each other, having arguments, having fights sometimes, making some noise, and working together, they polish each other, and they polish their ideas. And what comes out are these really beautiful stones.
People are being counted on to do specific pieces of the puzzle. And the most important thing I think you can do for somebody whoâs really good and whoâs really being counted on is to point out to them when their work isnât good enough, and to do it very clearly, and to articulate why, and to get them back on track. And you need to do that in a way that does not call into question your confidence in their abilities, but leaves not much room for interpretation.
Microsoftâs orbit was made possible by a Saturn V booster called IBM.
The only problem with Microsoft is they just have no taste. They have absolutely no taste, and what that means is â and I donât mean that in a small way, I mean that in a big way â in the sense that they donât think of original ideas, and they donât bring much culture into their product. And you say âwell why is that important?â Well, you know, proportionally spaced fonts come from typesetting and beautiful books, so thatâs where one gets the idea. And if it werenât for the Mac they would never have that in their products.
And so I guess I am saddened, not by Microsoft's success â I have no problem with their success. They have earned their success â I have a problem with the fact that they just make really third-rate products. Their products have no spirit to them, no spirit of enlightenment about them. They are very pedestrian. And the sad part is that most customers donât have that spirit either. But the way that weâre going to ratchet up our species is to take the best and to spread it around to everybody so that everybody grows up with better things, and starts to understand the subtlety of these better things. And Microsoft is McDonaldâs.
So thatâs what saddens me â not that Microsoft has won, but that Microsoftâs products donât display more insight and more creativity.
As we look back 10 years from now, the web is going to be the defining technology, the defining social moment for our generation.
I think itâs going to be huge.
I read an article when I was very young in Scientific America. It measured the efficiency of locomotion for various species on the planet â you know, for bears and chimpanzees and raccoons and birds and fish â how many kilocalories per kilometer did they spend to move? And humans were measured too. And the condor won, it was the most efficient. And mankind, the crown of creation, came in with rather an unimpressive showing about a third of the way down the list.
But somebody there had the brilliance to test a human riding a bicycle, and it blew away the condor, all the way off the charts. And I remember this really had an impact on me, I remember thinking that humans are tool builders, and we build tools that can dramatically amplify our innate human abilities.
And to me â we actually ran an ad like this, very early at Apple â the personal computer is the bicycle of the mind. And I believe that with every bone in my body, that of all the inventions of humans, the computer is going to rank near if not at the top as history unfolds and we look back. It is the most awesome tool that we have ever invented, and I feel incredibly lucky to be at exactly the right place in Silicon Valley, at exactly the right time where this invention has taken form.
How do we know whatâs the right direction [for computers to take]?
Ultimately it comes down to taste. It comes down to trying to expose yourself to the best things that humans have done, and then trying to bring those things in to what youâre doing.
Picasso had a saying: âGood artists copy, great artists steal.â And we (at Apple) have always been shameless about stealing great ideas. And I think part of what made Macintosh great was that the people working on it were musicians and poets and artists and zoologists and historians who also happened to have been the best computer scientists in the world. But if it hasnât been for computer science, these people would all be doing amazing things in life in other fields. And they brought with them â we all brought to this effort â a very liberal arts air, a very liberal arts attitude, that we wanted to pull in the best we saw in these other fields into ours.
There was a germ of something there. And itâs the same thing that causes people to want to be poets instead of bankers. I think thatâs a wonderful thing, and I think that same spirit can be put into products, and those products can be manufactured and given to people and they can sense that spirit. If you talk to people that use the Macintosh, they love it. I mean you donât hear people loving products very often. But you could feel it, there was something really wonderful there.
So I donât think that most of the really best people that Iâve worked with have worked with computers for the sake of working with computers. They work with computers because they are the medium that is best capable of transmitting some feeling that you have that you want to share with other people. And before they invented these things, all these people would have done other things. But computers were invented, and they did come along, and all these people did get interested in them, either in school or before school, and said âHey, this is the medium that I think I can say something in."
I observed something fairly early on at Apple, which I didnât know how to explain then, but Iâve thought a lot about it since. Most things in life have a dynamic range in which [the ratio of] âaverageâ to âbestâ is at most 2:1.
For example, if you go to New York City and get an average taxi cab driver, versus the best taxi cab driver, youâll probably get to your destination with the best taxi driver 30% faster. And an automobile; whatâs the difference between the average car and the best? Maybe 20%? The best CD player versus the average CD player? Maybe 20%? So 2:1 is a big dynamic range for most things in life.
Now, in software, and it used to be the case in hardware, the difference between the average software developer and the best is 50:1; maybe even 100:1. Very few things in life are like this, but what I was lucky enough to spend my life doing, which is software, is like this.
So Iâve built a lot of my success on finding these truly gifted people, and not settling for âBâ and âCâ players, but really going for the âAâ players. And I found something⊠I found that when you get enough âAâ players together, when you go through the incredible work to find these âAâ players, they really like working with each other. Because most have never had the chance to do that before. And they donât work with âBâ and âCâ players, so itâs self-policing. They only want to hire âAâ players. So you build these pockets of âAâ players and it just propagates.