The way designers and developers work together today is broken. It’s too siloed and separate; “collaboration” is a fantasy that few enjoy.
The state of advertising in the 1940s was similar. All of that changed when copywriter Bill Bernbach met art director Paul Rand. Their collaborative working style led to the birth of the idea of “the creative team,” the mutual respect and partnership between art director and copywriter that tended to yield unique results. Bob Gage, an art director that worked for DDB, the agency Bernbach co-founded, described it like this:
“Two people who respect each other sit in the same room for a length of time and arrive at a state of free association, where the mention of one idea will lead to another idea, then to another. The art director might suggest a headline, the writer a visual. The entire ad is conceived as a whole, in a kind of ping pong between disciplines.”
Isn’t that what we all strive for in our jobs? True collaboration with equals and partners? Ideas that build off one another? Why does this seem so far away for some of us?
The big misconception I’ve seen designers and developers often fall victim to is believing that handoff goes one way. Designers hand off comps to developers and think their work is done. That puts a lot of pressure on the designer to get everything perfect in one pass.
Instead, great collaboration follows what Brad Frost and I call “The Hot Potato Process,” where ideas are passed quickly back and forth from designer to developer and back to designer then back to developer for the entirety of a product creation cycle.
Start all of the pieces of work a little bit earlier. The key to starting work early is not succumbing to the pressure of having to finish the work. Don’t worry about finishing. If you’re a developer, you can start doing things while your design or information architect are working because a lot of your work actually isn’t dependent on their work. Some of it is, so you probably won’t be able to finish, but that shouldn’t stop you from starting.
Share Work-in-Progress Early and Often
When you share work-in-progress, share it with the caveat that no feedback is needed at this point. You’re simply sharing it to let people know where you are. For example, if you have to make 12 wireframes, share it when you finish 2 or 3. Rather than spending a whole week to drop 12 wireframes, share 2 – 3 wireframes every 2 days. The more often you do this, you start to build rhythm, and rhythm builds momentum.
More than ever, people are choosing how to spend their time based on the amount of attention they can garner—and you and I are no exception. Everyone is susceptible to this logic. But what I want to argue in this piece is that tech startup founders are particularly susceptible to this tendency.
Working at and around startups for several years, I’ve noticed many founders prioritizing culture, visibility, and perception over product, customer development, and strategy. Maybe this is to be expected in a time where culture moves faster and is perceived as more important than ever. But I find it unusual that the tech industry seems unaware of a whole class of typical mistakes founders make in pursuit of cultural relevance.
Early stage companies often deal with questions like “Why don’t we have as much adoption as we’d like at this time?” “Why aren’t we driving enough sales?” “Why is our churn rate so high and how do we raise retention?” and my favorite, “Why do we have no users?”
There are many ways to address these issues, but I find that companies frequently—and incorrectly—identify their public presence as the way to solve them.