iteration
So that you can get feedback on it and make it better
Fascinatingly, one of the other big complaints people had about agile is no iteration. I don't understand how being in an agile environment makes people less iterative, but somehow that seems to be the case. And I think it's because people misunderstand and think that agile is just about putting features out faster, and not about the important part, which is getting something in front of users faster so that you can get feedback on it and make it better.
The most rewarding iterations
Initial designs for sophisticated software applications are invariably complicated, even when developed by competent engineers. Truly good solutions emerge after iterative improvements or after redesigns that exploit new insights, and the most rewarding iterations are those that result in program simplifications.
Evolutions of this kind, however, are extremely rare in current software practice—they require time-consuming thought processes that are rarely rewarded. Instead, software inadequacies are typically corrected by quickly conceived additions that invariably result in the well-known bulk.
To anticipate all the uses and abuses
Success depends wholly on the anticipation and obviation of failure, and it is virtually impossible to anticipate all the uses and abuses to which a product will be subjected until it is in fact used and abused not in the laboratory but in real life. Hence, new products are seldom even near perfect, but we buy them and adapt to their form because they do fulfill, however imperfectly, a function that we find useful.
When we make a model and realize it's rubbish
Much of the design process is a conversation, a back-and-forth as we walk around the tables and play with the models. He doesn't like to read complex drawings. He wants to see and feel a model. He's right. I get surprised when we make a model and then realize it's rubbish, even though based on the CAD renderings it looked great.
He loves coming in here because it's calm and gentle. It's a paradise if you're a visual person. There are no formal design reviews, so there are no huge decision points. Instead we can make the presentations fluid. Since we iterate every day and never have dumb-ass presentations, we don't run into major disagreements.
Building is never a straight line
You might think that Mario 64 was built with tickets and sprints, but, according to interviews, there was no master plan, only the principles that the game should feel good and be fun. They started with just Mario in a small room, and tuned his animations and physics until he felt nice and responsive. After that, the levels were also created as they went, with the designers, developers, and director going back and forth using sketches and prototypes.
Building like this is never a straight line. Ideas and code get left on the cutting room floor because part of innovation is questioning whether what you made should exist. The process is cyclical and iterative, looking something like this.
Between the two spaces
It is widely accepted that creative design is not a matter of first fixing the problem and then searching for a satisfactory solution concept; instead it seems more to be a matter of developing and refining together both the formulation of the problem and ideas for its solution, with constant iteration of analysis, synthesis, and evaluation processes between the two “spaces” – problem and solution.
The game discovering itself
We like to think about this process as the game discovering itself over time. Because as iterators, rather than designers, it’s our job to simply play the game, listen to it, feel it, and kind of feel out what it seems to want to become - and just follow the trails of what’s fun.
Deciding what to design
We Don’t Really Know the Goal When We Start
The most serious model shortcoming is that the designer often has a vague, incompletely specified goal, or primary objective. In such cases, the hardest part of design is deciding what to design.
I came to realize that the most useful service I was performing for my client was helping him decide what he really wanted.
Today, we recognize that rapid prototyping is an essential tool for formulating precise requirements. Not only is the design process iterative; the design-goal-setting process is itself iterative. Knowing complete product requirements up front is a quite rare exception, not the norm. Therefore, goal iteration must be considered an inherent part of the design process.
Embracing the mess
Design is non-linear. At Figma, we often talk about “embracing the mess,” and that really means leaning into the chaos and complexity that makes the design process what it is. Even once you have the seedling of an idea, you need to explore and iterate, then pull back and evaluate to see what’s working and what’s not. Sometimes you’ll scrap an idea after a brainstorm session, and other times you’ll get pretty far with a concept, but still need different perspectives and input to move forward.
Models and iterations
Every month or so, Manock and Oyama would present a new iteration based on Jobs's previous criticisms. The latest plaster model would be dramatically unveiled, and all the previous attempts would be lined up next to it. That not only helped them gauge the design's evolution, but it prevented Jobs from insisting that one of his suggestions had been ignored.
The surprising effectiveness of writing and rewriting
An Article by Matt Webb- The act of writing the first draft creates new “essential data” that feeds the imagination and makes possible figuring out the second draft.
- Or: In your head, ideas expand until they max out “working memory” – and it’s only be externalising them in the written word that you have capacity to iterate them.
- Or: Good writing necessarily takes multiple edits, and the act of writing and act of rewriting are sufficiently different that performing both simultaneously is like rubbing your tummy and patting your head.
Asynchronous Design Critique: Getting Feedback
An Article by Erin CasaliGetting feedback can be thought of as a form of design research. In the same way that we wouldn’t do any research without the right questions to get the insights that we need, the best way to ask for feedback is also to craft sharp questions.
A City Is Not a Tree
- Strands of life
- Impending destruction
- The right overlap
- The difficulty of designing complexity
- Political chains of influence
Strands of life
For the human mind, the tree is the easiest vehicle for complex thoughts. But the city is not, cannot, and must not be a tree. The city is a receptacle for life. If the receptacle severs the overlap of the strands of life within it, because it is a tree, it will be like a bowl full of razor blades on edge, ready to cut up whatever is entrusted to it. In such a receptacle life will be cut to pieces. If we make cities which are trees, they will cut our life within to pieces.
Impending destruction
In any organized object, extreme compartmentalization and the dissociation of internal elements are the first signs of coming destruction.
The right overlap
Overlap alone does not give structure. It can also give chaos. A garbage can is full of overlap. To have structure, you must have the right overlap.
The difficulty of designing complexity
Designers, limited as they must be by the capacity of the mind to form intuitively accessible structures, cannot achieve the complexity of the semilattice in a single mental act. The mind has an overwhelming predisposition to see trees wherever it looks and cannot escape the tree conception.
Experiments suggest strongly that people have an underlying tendency, when faced by a complex organization, to reorganize it mentally in terms of non-overlapping units. The complexity of the semilattice is replaced by the simpler and more easily grasped tree form.
Political chains of influence
In Chicago, formal chains of influence and authority are entirely overshadowed by the ad hoc lines of control which arise naturally as each new city problem presents itself. These ad hoc lines depend on who is interested in the matter, who has what at stake, who has what favors to trade to whom.
This structure, which is informal, working within the framework of the first, is what really controls public action. It varies from week to week, even from hour to hour, as one problem replaces another. Nobody’s sphere of influence is entirely under the control of any one superior; each person is under different influences as the problems change. Although the organization chart in the Mayor’s office is a tree, the actual control and exercise of authority is semilattice-like.
Same name in the same basket
Does a concert hall ask to be next to an opera house? Can the two feed on one another? Will anybody ever visit them both, gluttonously, in a single evening, or even buy tickets from one after going to a performance in the other?
In Vienna, London, Paris, each of the performing arts has found its own place, because all are not mixed randomly. The only reason that these functions have all been brought together in Lincoln Center is that the concept of performing art links them to one another. The organization is born of the mania every simple-minded person has for putting things with the same name into the same basket.
Separation of concerns
Another favorite concept of the CIAM theorists and others is the separation of recreation from everything else. This has crystallized in our real cities in the form of playgrounds. The playground, asphalted and fenced in, is nothing but a pictorial acknowledgment of the fact that ‘play’ exists as an isolated concept in our minds. It has nothing to do with the life of play itself. Few self-respecting children will even play in a playground.
Play itself, the play that children practice, goes on somewhere different every day. In a natural city this is what happens.
Structural complexity
The idea of overlap, ambiguity, multiplicity of aspect, and the semilattice are not less orderly than the right tree, but more so. They represent a thicker, tougher, more subtle and more complex view of structure.
Neighborhoods
We cannot get an adequate picture of what Middlesborough is, or of what it ought to be, in terms of neighborhoods. When we describe the city in terms of neighborhoods, we implicitly assume that the smaller elements within any one of these neighborhoods belong together so tightly that they only interact with elements in other neighborhoods through the medium of the neighborhoods to which they themselves belong. Ruth Glass herself shows clearly that this is not the case.
Cities which are trees
Columbia, Maryland
Greenbelt, Maryland
Greater London Plan
Mesa City, Paolo Soleri
Tokyo Plan, Kenzo Tange
Chandigarh (Le Corbusier)
Brasilia, Lucia Costa
Communitas (Percival and Paul Goodman)
Roman town evolved from military campsIn the worst cases, the units of which these cities are composed fail to correspond to any living reality; and the real systems, whose existence actually makes the city live, have been provided with no physical receptacle.
In a tree structure, it means that within this structure no piece of any unit is ever connected to other units, except through the medium of that unit as a whole.
Sets and systems
When the elements of a set belong together because they cooperate or work together somehow, we call the set of elements a system.
From a designer’s point of view, the physically unchanging part of this system is of special interest. I define this fixed part as a unit of the city.
Whatever picture of the city someone has is defined precisely by the subsets he sees as units.
Natural and artificial cities
I want to call those cities which have arisen more or less spontaneously over many, many years natural cities. And I shall call those cities and parts of cities which have been spontaneously created by designers and planners artificial cities. Siena, Liverpool, Kyoto, and Manhattan are examples of natural cities. Levittown, Chandigarh, and the British New Towns are examples of artificial cities.
It is more and more widely recognized today that there is some essential ingredient missing from artificial cities.
Trees and semilattices
The tree of my title is not a green tree with leaves. It is the name of an abstract structure. I shall contrast it with another, more complex abstract structure called a semilattice.
Both the tree and semilattice are ways of thinking about how a large collection of many small systems goes to make up a large and complex system.
A collection of sets forms a semilattice if, and only if, when two overlapping sets belong to the collection, the set of elements common to both also belongs to the collection. That is, if [234] and [345] belong to the collection, then [34] belongs to the collection.
A collection of sets forms a tree if, and only if, for any two sets that belong to the collection either one is wholly contained in the other, or they are wholly disjoint. Every tree is trivially a simple semilattice.
We are concerned with the difference between structures in which no overlap occurs, and those structures in which overlap does occur.
The semilattice is potentially a much more complex and subtle structure than a tree. It is this lack of structural complexity, characteristic of trees, which is crippling our conceptions of the city.