In order to design their iconic furniture, Charles and Ray Eames first created a new technique to mold wood, and then produced their own tools to enable this technique. Throughout the process, they were constantly learning more about the wood they were working with. How far could they bend it before it cracked? Which directions seemed fluid, and which forced? Without their intimate knowledge of the materials they were working with, the molded plywood furniture that they so carefully created would not exist.
The Eameses had a well-known philosophy for learning by doing. Charles in particular stated, “Design is a method of action.” They enjoyed action so much that they both preferred to jump directly to the prototype stage of creation instead of initially sketching. They felt it was most important to learn about the material they were designing with, and the best way to do so was to create a series of prototypes. When moving to mass production, they worked closely with the team at Herman Miller to ensure that their designs and prototypes could best be built on a large scale. The prototypes served as their best communication tool, as there was no better way to demonstrate their designs to the team at Herman Miller.
Even with their breadth of knowledge about plywood, the Eameses were very much generalists. I’m shocked by the quality and detail of furniture, video, architecture, and textile that Charles and Ray Eames designed and built together. Each time they found a new medium to work with, they bent it — quite literally — to their will.
“Architects don’t do the construction for the buildings they design.” This is an argument I often hear from designers that don’t feel as though they should be implementing their designs. My sarcastic side wants to give a witty response, but I bite my tongue. From what I know, architects deliver a blueprint or lengthy set of directions that is very well planned and doesn’t leave much room for interpretation. Once their building’s foundation is completed, architects have a difficult time altering their design from the initial plan which is why their blueprints are detailed, thought through, and take a long time to produce. Their process has clear lines of responsibility from architecture to construction to interior design. They have a rigid documentation system to ensure that communication is still able to jump over those lines and everything goes as planned.
Our industry did this once too.
I enjoy working on the web because the process is almost entirely opposite of designing a building. It is fluid, living, and easily adjusted to fit the needs (or lack thereof) of its users. It is iterative, never finished, and always evolving. Our process is much more blurry, haphazard, and non-linear because of the medium we are building for.
As a community, we constantly endure the same arguments of “specialization vs. generalization” and “should designers code?” How designers are integrated into a team depends on the team structure and the goals of that team. What makes a great team is when each of the member’s lines of responsibility blurs into that of others. Every member of the team understands enough about the other’s job that they are able to reach a high level of empathy for each other and communicate effectively.
The Eameses blurred their lines of responsibility, never handing over a spec sheet or a miniature for their furniture designs. They implemented and used their own designs before they allowed Herman Miller to mass produce them. As designers, we must pay attention to the Eameses’ process, thereby duplicating their iteration and prototyping process as the front lines of designing for screens. Like the Eameses, we need to know when the plywood might bend and break, adjusting our designs to accommodate. Without the will or knowledge to implement those designs, we’ll never be pushing the constraints of what the web has to offer. We won’t be able to build our own tools and techniques because we won’t know how – we won’t have blurred lines.
At thoughtbot we have designers who implement their own designs. They must conduct user research and usability testing, lead design sprints, and work with our clients to ensure a viable product. They must then execute this process by creating a quick and dirty prototype followed by a fully functioning application featuring a highly refined visual design. This must then be implemented in the web or mobile app. We expect them to complete this process while communicating effectively and educating our clients on design.
We ask a lot of our designers.
It’s not for nothing — designers hold a lot of power regarding the products they build and the process by which they create solutions. They are actively deciding what the product is and how it solves the problems of others, not only what it looks like. The more of these decisions the designers are part of, the better the resulting product.
This isn’t to say that designers don’t work closely with our developers and clients in order to figure out the best solution for users — in fact, quite the opposite is true. With our division of roles, there is much less chance of mis-communicating research, graphic/visual design direction, and business strategy because the designer is part of all these conversations. The designers lines of responsibility blur into everyone else’s on the team. Our designers have stronger empathy with users through research; with clients because they are working together to build the application’s business strategy; and with developers through working in the same codebase.
Our developers have better empathy for design, too. Developers participate in and occasionally lead design sprints — they can highlight great design and truly know its value. They are designers in their own right, which is important because new problems are going to arise as we work with real data and users. We rely as much on our developers as the Eameses did on the team at Herman Miller. This empowers them to make important design decisions while they program, as well as know when to ask a designer’s opinion. This mutual respect creates strong teams and a thriving culture. It means that our 2–4 person teams are flexible and meet the needs of the individual project — our lines blur together.
