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.
Rethinking Repair
This chapter is an exercise in broken world thinking. It asks what happens when we take erosion, breakdown, and decay, rather than novelty, growth, and progress, as our starting points in thinking through the nature, use, and effects of information technology and new media.
The modern infrastructural ideal
The form and possibility of the "modern infrastructural ideal" is increasingly under threat, as cracks (sometimes literal ones) show up in our bridges, our highways, our airports, and the nets of our social welfare systems. For these and other reasons, broken world thinking asserts that breakdown, dissolution, and change, rather than innovation, development, or design as conventionally practices and thought about are the key themes and problems facing new media and technology scholarship today.
Attached to this, however, comes a second and more hopeful approach: namely, a deep wonder and appreciation for the ongoing activities by which stability (such as it is) is maintained, the subtle arts of repair by which rich and robust lives are sustained against the weight of centrifugal odds, and how sociotechnical forms and infrastructures, large and small, get not only broken but restored, one not-so-metaphoric brick at a time.
The fulcrum of these two worlds
Here, then, are two radically different forces and realities. On one hand, a fractal world, a centrifugal world, and always-almost-falling-apart world. On the other, a world in constant process of fixing and reinvention, reconfiguring and reassembling into new combinations and new possibilities...the fulcrum of these two worlds is repair.
A creature of bones, not words
In building connections, [articulation work] builds meaning and identity, sorting out ontologies on the fly rather than mixing and matching between fixed and stable entities. Articulation lives first and foremost in practice, not representation; as its proper etymology suggests, it's a creature of bones, not words. When articulation fails, systems seize up, and our sociotechnical worlds become stuff, arthritic, unworkable.
The world is always breaking
So the world is always breaking; it's in its nature to break.
A side that goes unrecognized
Edward Burtynsky, Shipbreaking #4.
Burtynsky's [shipbreaking] photos tell us important things about the themes of breakdown, maintenance, and repair raised here. The first is the extent to which such work is rendered invisible under our normal modes of picturing and theorizing technology. Burtynsky's photos share, in exquisite detail, a side or moment of technological life that goes for the most part unrecognized.
If we are to understand maintenance, repair, and technology more broadly, scenes such as Burtynsky's must be made empirically and conceptually familiar, even normal.
Turned into other things
Ask yourself this: for all the representations of great ships in history you've encountered, at what times and in what forms have you seen such vessels? In almost every instance it will be at moments of birth, or at the heights of strength and glory: the christening before the maiden voyage, rounding the cape, facing down the Spanish fleet, and so on. But what happens (or happened) to these ships? Save for the special cases of hostile sinking, shipwreck, or honorable retirement and preservation, it was this: they were disassembled, repurposed, stripped, and turned into other things.
An engine of technological difference
Whether at the level of national "technological styles" that shape and differentiate the nature of "same" technologies in different national contexts, or the simple but consequential variations by which industrial commodities are brought into, enlivened, and sustained within the circumstances of individual homes and lives, repair may constitute an important engine by which technological difference is produced and fit is accomplished.
The internet grew by breaking
The Internet grew by breaking, bumping up against the limits of existing protocols and practices and working around them, leaving behind almost by accident some of the properties that we now enumerate as key and distinctive virtues of the Internet as infrastructural form. Far from being a generalized cultural tendency or a property of individual minds, innovation in the technology space, as in culture more generally, is therefore organized around problems. This makes innovation simultaneously specific and in some measure collective in nature. And its engine is breakdown and repair.
What the fixer knows
Can repair sites and repair actors claim special insight or knowledge, by virtue of their positioning vis-à-vis the worlds of technology they engage? Can the fixer know and see different things—indeed, different worlds—than the better-known figures of "designer" or "user"?
Tool-being
Take Heidegger's notion of "tool-being", built around the central distinction between tools that are "ready-to-hand" versus "present-at-hand".
In the former state, technologies function as anticipated, do and stay where they're supposed to, and therefore sink below the level of conscious reflection. In the latter, the material world resists, obstructs, or frustrates action, and therefore calls attention to itself (precisely because we must now work to figure out and overcome barriers in our no-longer seamless world).
An ethics of mutual care
Foregrounding maintenance and repair as an aspect of technological work invites not only new functional but also moral relations to the world of technology. It references what is in fact a very old but routinely forgotten relationship of humans to things in the world: namely, an ethics of mutual care and responsibility.
To love deeply a world of things
Care brings the worlds of action and meaning back together, and reconnects the necessary work of maintenance with the forms of attachment that so often (but invisibly, at least to analysts) sustain it.
...What if we care about our technologies, and do so in more than a trivial way? This feature or property has sometimes been extended to technologies in the past, but usually only ones that come out of deep folk or craft traditions, and rarely the products of a modern industrial culture.
...Is it possible to love, and love deeply, a world of things?
We live in the aftermath
So do we live in later modernity, postmodernity, alternative modernity, or liquid modernity? Knowledge societies, information societies, network societies, or risk societies? New media, old media, dead media, or hypermedia? The world of information, the world of search, the world of networks, or the or the world of big data?
The answer is simple: like every generation before, we live in the aftermath.