Tools
All sorts of ways to use the machine
Stretching the product
The reflective craftsman
The inventive process was often a nonverbal one
Maybe I should sharpen soon
When our tools are broken, we feel broken
In his piece [for Time] Lev Grossman correctly noted that the iPhone did not really invent many new features, it just made those features a lot more usable. "But that's important. When our tools don't work, we tend to blame ourselves, for being too stupid or not reading the manual or having too-fat fingers...When our tools are broken, we feel broken. And when somebody fixes one, we feel a tiny bit more whole."
A minimum size to fish
There is the famous story by Eddington about some people who went fishing in the sea with a net. Upon examining the size of the fish they had caught, they decided there was a minimum size to the fish in the sea! Their conclusion arose from the tool used and not from reality.
You can almost tell which software they were designed in
Tatiana von Preussen, cofounder of London practice vPPR Architects, says that certain software comes with constraints that encourage a particular style:
“Something I’ve noticed with new buildings is that you can almost tell which software they were designed in. For instance, if you take Revit, it’s very hard to freely create non-orthogonal, non-linear geometries, and it’s very easy to create repetitive elements, so it lends itself to a particular way of building.”
So insufficiently palimpsestic
I worry that unlike Kahn's process and tools, the processes and tools we use are aimed at helping us satisfy the demand for moving fast and breaking things, not to be good, or to better ensure the doing of good work.
My son Gerrit told me about a YouTube video from a conference where the presenter asked for a show of hands from video game developers in the audience who could produce or successfully compile their own code from the previous quarter. Or from the previous year. Or from two years ago. And by that time the point had been made: nobody had their hand in the air.
The teleology of tool-building
The teleology of tool-building suggests that the real value lies in the end use of the tool, rather than in its origins
The computer creates a distance
Computer imaging tends to flatten our magnificent, multi-sensory, simultaneous and synchronic capacities of imagination by turning the design process into a passive visual manipulation, a retinal journey. The computer creates a distance between the maker and the object, whereas drawing by hand as well as working with models put the designer in a haptic contact with the object, or space.
Humble servants
Our electrical appliances should be humble servants, to be seen and heard as little as possible. They should ideally stay in the background, like a valet in the old days, that one hardly noticed. — Erwin Braun
They should accompany an individual over a long period of time without hindering or disturbing through ‘extravagant forms, loud colors or flashy proportions’.
Michaelangelo's hammer
A young man named Michelangelo stands in front of a huge granite monolith. He stands there at a time in history before the technologies that brought us the hammer and chisel have occurred. He gazes at the rock. He dreams his dream and the best that he is able to say is, What a wonderful stone you are.
…
Michaelangelo now stands in front of the same rock. Thrust into his hands are a hammer in one and a chisel in the other. He looks at his hands, at the technological tools that they hold, and gazing at the same stone, with epiphanic zeal, says I must let Moses out.
Employs nothing at all
The man of today planes to perfection a board with a planing machine in a few seconds. The man of yesterday planed a board reasonably well with a plane. Very primitive man squared a board very badly with a flint or a knife. Very primitive man employed a unit of measurement and regulating lines in order to make his task easier. The Greek, the Egyptian, Michaelangelo or Blondel employed regulating lines in order to correct their work and for the satisfaction of their artist’s sense and of their mathematical thought. The man of today employs nothing at all and the result is the boulevard Raspail.
But men live in old houses
It is not right that we should produce bad things because of a bad tool; nor is it right that we should waste our energy, our health and our courage because of a bad tool; it must be thrown away and replaced.
But men live in old houses and they have not yet thought of building houses adapted to themselves.
When Movable Type ate the blogosphere
Here’s the crux of the problem: When something is easy, people will do more of it.
When you produce your whole site by hand, from HEAD to /BODY, you begin in a world of infinite possibility. You can tailor your content exactly how you like it, and organize it in any way you please. Every design decision you make represents roughly equal work because, heck, you’ve gotta do it by hand either way. Whether it’s reverse chronological entries or a tidy table of contents. You might as well do what you want.
But once you are given a tool that operates effortlessly — but only in a certain way — every choice that deviates from the standard represents a major cost.
Movable Type didn’t just kill off blog customization.
It (and its competitors) actively killed other forms of web production.
Tools of the digital age
The myriad tools of the digital age that provide quick ways to capture words, images, and data have added to the perception that handwritten field notebooks are passé. As someone who routinely encounters objects that can speak to us over millions of years, I may have a bias towards things that have stood the test of time. That said, it is clear that there is still much to recommend preserving records and information in traditional paper field notes.
Over the course of my career, I have developed a habitual field note protocol in which a paper notebook is used both to record information and to integrate records made on standardized data sheets, in computer files, and in photographs.
On Tools
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.
Sublime tools
Getting better at using tools comes to us, in part, when the tools challenge us, and this challenge often occurs just because the tools are not fit-for-purpose. In both creation and repair, the challenge can be met by adapting the form of a tool, or improvising with it as it is, using it in ways it was not meant for.
The all-purpose tool seems a special case. In its sheer variety, a flat-edged screwdriver admits all manner of unfathomed possibilities; it, too, can expand our skills if only our imagination rises to the occasion. Without hesitation, the flat-edged screwdriver can be described as sublime—the word sublime standing, as it does in philosophy and the arts, for the potently strange.
Resonances
The resonances arising in workmanship are often very subtle. The fact that the material itself guides the tool differently in different processes of working introduces changes in the overall relationship of curvatures. The smooth curves of surfaces approaching the edge of a jade axe that come about from innumerable abrasive particles moving against a slightly yielding and mechanically unconstrained backing would seem incongruous if other surfaces or outlines were present that had come from cleavage or from the geometric motions of a machine. These could be produced easily enough, but the eye would not establish larger resonances among them.
When all you have is a hammer
The success and spread of a particular tool – and this tool can be organizational or administrative as well as mechanical – has another consequence. Any task tends to be structured by the available tools. It can appear that the available tools represent the best or even the only way to deal with a situation.
Thus is may be wise, when communities are faced with new technological solutions to existing problems, to ask what these techniques may prevent and not only to check what the techniques promise to do.
Three Perfect Tools
An Article by Tim BrayThere is a particular joy in a product that just does what you need done, in about the way you expect or (thrillingly) better, and isn’t hard to figure out, and doesn’t change unnecessarily. Here are three to learn from.
How can we develop transformative tools for thought?
A Research Paper by Andy Matuschak & Michael NielsenConventional tech industry product practice will not produce deep enough subject matter insights to create transformative tools for thought.
...The aspiration is for any team serious about making transformative tools for thought. It’s to create a culture that combines the best parts of modern product practice with the best parts of the (very different) modern research culture. You need the insight-through-making loop to operate, whereby deep, original insights about the subject feed back to change and improve the system, and changes to the system result in deep, original insights about the subject.
The tools matter and the tools don't matter - Austin Kleon
An Article by Austin KleonThough you might not think it from the comic, I’m actually sympathetic to questions about tools and process, as I myself am a kind of process junky. I love hearing about how other writers work.
I’m also not someone who dismisses questions about tools with the line “the tools don’t matter.” In fact, I think tools matter so much that if you don’t talk about them correctly you can do some damage.
...What I love about John Gardner and Lynda Barry is that they believe that the tools you use do matter, but the point, for them, is finding the proper tools that get you to a certain way of working in which you can get your conscious, mechanical mind out of the way so that your dreaming can go on, undeterred.
You have to find the right tools to help your voice sing.
So many little design helper sites!
An Article by Chris CoyierI’m sure y’all find these things just as useful as I do. They don’t make us lazy, they make us efficient. I know how to make a pattern. I know how to draw a curve with a Pen Tool. I know how to convert SVG into JSX. But using a dedicated tool makes me faster and better at it. And sometimes I don’t know how to do those things, but that doesn’t mean I can’t take advantage. Fake it ’til you make it, right?
In ways you didn't anticipate
A Quote by Patrick HebronI always have a hard time wrapping my mind around some of the classic user questions: What is this thing for, is it for novices or professionals, etc? I do my best to avoid these questions, because the best thing you can possibly accomplish as the maker of a tool is to build something that gets used in ways you didn’t anticipate. If you’re building a tool that gets used in exactly the ways that you wrote out on paper, you shot very low. You did something literal and obvious.
Forget the computer — here’s why you should write and design by hand
An Article by Herbert LuiIn the middle of the 2000s, the designers at creative consultancy Landor installed Adobe Photoshop on their computers and started using it. General manager Antonio Marazza tells author David Sax:
“Overnight, the quality of their designs seemed to decline. After a few months of this, Landor’s Milan office gave all their designers Moleskine notebooks, and banned the use of Photoshop during the first week’s work on a project. The idea was to let their initial ideas freely blossom on paper, without the inherent bias of the software, before transferring them to the computer later for fine-tuning. It was so successful, this policy remains in place today.”
Hacking is the opposite of marketing
An Article by Tom MacWrightOne of my favorite definitions of “hacking” is the creative reuse of tools for new and unexpected purposes. Hacking is using your email account as a hard drive, using your bicycle seat to open a beer, using Minecraft’s red bricks to create a calculator in the game.
The opposite of hacking is marketing. Marketing tells you that this particular non-stick pan is the pan you’ll use to make omelettes, and you’ll do it in the morning dressed in fashionable clothing in a nice kitchen. It includes a photo and inspirational copywriting to drive this home. Marketing dictates a style, context, and purpose for even the most general-purpose products. This narrative needs to be specific so that you can readily imagine it: it’s you, in an Airbnb, laughing with friends.
The return of fancy tools
An Article by Tom MacWrightTechnology is seeing a little return to complexity. Dreamweaver gave way to hand-coding websites, which is now leading into Webflow, which is a lot like Dreamweaver. Evernote give way to minimal Markdown notes, which are now becoming Notion, Coda, or Craft. Visual Studio was “disrupted” by Sublime Text and TextMate, which are now getting replaced by Visual Studio Code. JIRA was replaced by GitHub issues, which is getting outmoded by Linear. The pendulum swings back and forth, which isn’t a bad thing
René: A Product Design Tool
A ToolWeb Brutalism, seamfulness, and notion
An Essay by Brandon DornHow a tool for sensemaking reconciles two distinct software design ideologies.
- Seamful vs. seamless
- Reveling in infrastructure
- The brilliance of notion
- How our understanding is working
The Design of Design
What's Wrong With This Model?
A ChapterDesign process models: A summary argument
- A formal design process model is needed, to help organize design work, to aid communication in and about projects, and for teaching.
- Having a visual, geometric representation of a design process model is crucial, for designers are spatial thinkers. They will most easily learn, think about, share, and talk in terms of a model with a clear geometric picture.
- The Rational Model of design occurs naturally to engineers.
- The linear, step-by-step Rational Model is highly misleading. It does not reflect what real designers do, or what the best design thinkers identify as the essence of the design process.
- The bad model matters. It has led to the too-early binding of requirements, leading in turn to bloated products and schedule/budget/performance disasters.
- The Rational Model has persisted in practice despite its inadequacies and plenty of cogent critiques. This is because of its seductive logical simplicity, and because builders and clients needs “contracts."
- Several alternative models have been proposed. I find Boehm’s Spiral Model the most promising. We need to keep developing it.
The spiral model
The spiral shape certainly suggests progress. It associates successive repetitions of the same activity. The geometric shape is easily understood and memorable. The model emphasizes prototyping, starting with user-interface prototypes and user testing long before an operational prototype is possible.
Since a development model is principally used by developers, I believe having it designer-centered is entirely appropriate. With Boehm and against Denning and Dragon, I advocate frequent but not continuous interaction with representative users, with successive prototypes as the vehicles.
I strongly believe that way forward is to embrace and develop the Spiral Model.
A grossly obese set of requirements
Who advocates in the requirements process for the product itself—its conceptual integrity, its efficiency, its economy, it’s robustness? Often, no one. As often, an architect or engineer who can offer only opinion based on taste and instinct, unbuttressed as yet by facts. For in a classical Waterfall Model product process, requirements are set before design is begun.
The result, of course, is a grossly obese set of requirements, the union of many wish lists, assembled without constraints. Usually, the list is neither prioritized nor weighted. The social forces in the committee forbid the painful conflicts occasioned by even weighting, much less prioritizing.
Requirements proliferation
Any attempt to formulate all possible requirements at the start of a project will fail and would cause considerable delays. — Pahl and Beitz, Engineering Design
As Project Manager, I had to reject the requirements document as totally impractical, and have a quite small team of architects, marketers, and implementers extract the essence.
Requirements proliferation must be fought, by both birth control and infanticide.
The architectural contracting model
It is the necessity for contracts, whether within an organization or between organizations, that forces the too-early binding of goals, requirements, constraints. The pressure for a complete and agreed-upon set of requirements run into the hard fact, that it is essentially impossible to specify any complete and accurate set of requirements for any complex system except in iterative interaction with the design process.
How have the centuries-old building design disciplines handled this perplexity? Fundamentally, by a quite different contracting model.
- The client develops a program, not a specification, for the building.
- He contracts with an architect, usually on an hourly or percentage basis, for services, not for a specified product.
- The architect elicits from the client, the users, and other stakeholders a more complete program, which does not pretend to be a rigid contractable product specification.
- The architect does a conceptual design that approximates the reconciliation of program and the constraints of budget, schedule, and code. This serves as a first prototype, to be conceptually tested by the stakeholders.
- After iteration, the architect performs design development, often producing more detailed drawings, a 3-D scale model, mockups, and so on. After stakeholder iteration, the architect produces construction drawings and specifications.
- The client uses these drawings and specifications to enter into a fixed-price contract for the product.
Notice how this long-evolved model separates the contract for design from the contract for construction. Even when both are performed by the same organization, this separation clarifies many things.
The rational model of design
Engineers seem to have a clear, if usually implicit, model of the process of design. It is usually an orderly model of an orderly process as the engineer conceives it.
The notion that the design process should be modeled as a systematic step-by-step process seems to have first developed in the German mechanical engineering community.
Herbert Simon independently argues for design as a search process in The Sciences of the Artificial. He was motivated to lay out a strictly rational model of design precisely because such a model was a necessary precursor to automating design. His model remains influential even if today we recognize the "wicked problem" of original design as one of the least promising candidates for AI.
In software engineering, Winston Royce independently introduced a seven-step Waterfall Model to bring order to the process. In fact, Royce introduced his waterfall as a straw man that he then argued against, but many people have cited and followed the straw man rather than his more sophisticated models. Even if ironically, Royce's seven-step model must be considered one of the foundational statements of the Rational Model of Design.
Design process models
Any systematization of the design process is a great step forward compared to "Let's just start coding, or building." It:
- Provides clear steps for planning a design project
- Furnishes clearly definable milestones
- Suggests project organization and staffing
- Helps communication within the design team
- Is readily teachable to novices, and tells novices facing their first design assignments where to begin.
The Rational Model in particular brings yet more advantages. The early explicit statement of goals, secondary desiderata, and constraints helps a team avoid wandering, and it breeds team unification on purposes. Planning the whole design process before starting coding or formal drawings avoids many troubles and much wasted effort. Casting the process as a systematic search of a design space broadens the horizon of the individual designers and lifts their eyes far beyond their previous personal experiences.
But the rational model is much too simplistic, even in Simon's richly developed version.
The dual ladder
The first task for growing designers, as opposed to managers, is to craft a proper career path for them, one whose compensation and sociological status reflect their true value to the creative enterprise. This is commonly called the dual ladder. It it easy to give corresponding salaries to corresponding rungs, but it requires strong proactive measures to give them equal prestige: equal offices, equal staff support, reverse-biased raises when duties change.
Why does the dual ladder need special attention? Perhaps because managers, being human, are inherently inclined to consider their own tasks more difficult and important than design and need to deliberately assess what makes creativity and innovation happen.
A platonic ideal
As the architecture design progressed, I observed what at first seemed quite strange. For the architecture team, the real System/360 was the Design Concept itself, a Platonic ideal computer. Those physical and electrical Model 50, Model 60, Model 70, and Model 90 things under construction out on the engineering floors were but Plato’s shadows of the real System/360. The real System/360’s most complete and faithful embodiment was not in silicon, copper, and steel, but in the prose and diagrams of IBM System/360 Principles of Operation, the programmer’s machine language manual.
I had a similar experience with the View/360 beach house. Its Design Concept came to be real long before any construction began. It persisted through many versions of drawings and cardboard models.
The design concept
Is there positive value to recognizing an invisible Design Concept as a real entity in design conversations? I think so.
First, great designs have conceptual integrity—unity, economy, clarity. They not only work, they delight, as Vitruvius first articulated. We use terms such as elegant, clean, beautiful to talk about bridges, sonatas, circuits, bicycles, computers, and iPhones. Recognizing the Design Concept as an entity helps us to seek its integrity in our own solo designs, to work together for it in team designs, and to teach it to our youth.
Second, talking frequently about the Design Concept as such vastly aids communication within a design team. Unity of concept is the goal; it is achieved only by much conversation.
Thus, moviemakers use storyboards to keep their design conversations focused on the Design Concept, rather than on implementation details.
The Idea
The design is thus the mental formulation, which Sayers calls “the Idea,” and it can be complete before any realization is begun. Mozart’s response to his father’s inquiry about an opera due to the duke in three weeks both stuns us and clarifies the concept.
For most human makers of things, the incompletenesses and inconsistencies of our ideas become clear only during implementation. Thus it is that writing, experimentation, “working out,” are essential disciplines for the theoretician.
The boldest decisions
In retrospect, many of the case studies have a striking common attribute: the boldest design decisions, whoever made them, have accounted for a high fraction of the goodness of the outcome. These bold decisions were made due sometimes to vision, sometimes to desperation. They were always gambles, requiring extra investment in hopes of getting a much better result.
Intuition and systems
Systematic design excluding intuition yields pedestrian follow-ons and knock-offs; intuitive design without system yields flawed fancies. How to weld intuition and systematic approach? How to grow as a designer? How to function in a design team?