---
title: Blurred Lines
teaser: |
Great software design teams
hire designers who implement,
developers who care about design,
and by blurring the lines between their roles and responsibilities.
tags: design,prototyping
author: Kyle Fiedler
published_on: 2015-08-27
---
In order to design their iconic furniture,
[Charles and Ray Eames](https://en.wikipedia.org/wiki/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.
Courtesy of Flickr user
Wicker
Paradise
The Eameses had a well-known
[philosophy for learning by doing](https://en.wikipedia.org/wiki/Charles_and_Ray_Eames#Philosophy_2).
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.
Courtesy of
Wikipedia
---
"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](https://en.wikipedia.org/wiki/Waterfall_model).
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.
