Fig. 2 A Guide to Effective Teams

Love The One You're With

How designers and developers can actually work with their other halves to create great products (without the stress and frustration).

Written by Ryan Buttrey October 28, 2015

Every product team inevitably contains two roles core to the experience of the user and the success of the product: designer and developer. As central as this dynamic is, over our time working at multiple agencies and companies this is actually the single relationship that is most fractured in most teams.

This isn’t surprising, really, since designers and developers have very different goals in mind, and often have very different personalities, preferences, and communication styles. Regardless of their differences, they’re both of equal importance to the success of a product and learning to work together can not only lead to better results but can make your lives as equal parts of the same team fun.

Ryan Clark, Andy Rossi, and I have worked together in some capacity for almost 10 years. That’s a whole decade (also it makes us feel old). Over that time, we’ve learned small things that have helped us stay sane and work well together despite our extreme differences in skill set and personality—and ultimately craft products and solutions that are better for it.

Nothing is Easy

“This should be pretty easy,” is a phrase you hear a lot around a product team, especially from the people not doing the work. Never assume anything is easy. Ever. This is applicable to anyone working on a team, but especially between designer and developer (middle-management can be given a pass, sometimes, maybe).

Over the years Ryan and I have established the habit of asking questions like, “When could we get this done?” or, “How can we do this?” instead of assuming a task is simple and should require minimal effort. Expectations exist whether we realize it or not, and can only be cleared up when the whole picture is in mind. Surprisingly, these discussions about complexity and scope can be some of the most fun parts of a project. Is it more complex than expected? Maybe it can be solved with a different design or different approach to the code, maybe it’s not even necessary at all. Asking these questions and deferring to the other person allows us to craft the appropriate solution together.

Give & Take

Like most relationships, successful designer-developer relationships are very much a give and take. Most of the giving and taking in our relationship centers around our core goals. For Ryan, it’s the narrative—what story are we telling? How can we say the right things in a captivating and clear way? For me, it’s the functionality—how does that story work? How can we get it to the most people on the most devices?

In a perfect world, these goals will align in every project, but sadly this isn’t the case. In certain instances, the things that communicate best may be the hardest to implement or require a bunch of heavy-handed Javascript to implement. Choosing a strategy that meets the user’s needs and respects their context can require nuance, and (most of the time) compromise.

Being Right

The biggest hurdle to compromise is when we’re more concerned about being right than doing it right. When you’re focused on being right it’s all about personal pride. When you’re focused on doing it right it’s about team pride.

Everyone’s been in that meeting where you’re discussing a feature or implementation and ideas are getting tossed around. The most interesting parts are people’s reactions to their ideas being challenged. On teams that work well together challenges are accepted and worked through.

In the early days of working together there were lots of times that we wanted our own individual ideas to win out, but after years of working together we’ve learned (sometimes the hard way) that we’re a team for a reason. By trusting each other we can be more than the sum of our parts. Challenges to an idea are challenges to make it better. Ideas aren’t our own, they’re the groups to mold and change and build on with each of our skill sets and perspectives. We quit caring if we were right. Instead we want the idea to be right.

Pixel Perfection

The single greatest source of tension in a development team is usually the implementation of the work itself. Too often we hear stories about designers onion-skinning a staging server and adding GitHub issues for pixel edits. And too often we see developers who sloppily implement a design to the point it’s not remotely representative of the initial design.

Here are some quick things that we do to keep from killing each other while developing a layout:

  1. Pixel-perfection isn’t a goal worth chasing. It’s not that it isn’t possible, it’s that it doesn’t matter. The differences between viewports and default browser settings make the idea of everything being perfect a fleeting reality. Most of Ryan’s pixels become ems or percentages in my CSS, so I’m looking to him more for a basic style guide to how things should be implemented and interact with one another in any given layout. Instead, our goal is to craft something together that we are both proud of and that achieves the goals we set out to do in a beautiful and functional way. In the end, that has little to do with the original pixel counts.
  2. Nit-picking is important. Let it happen. On the flip side, there is a time and place for specific revisions (and pixels, like icons for instance). As a developer, set aside time at the end of a project to sit down with your designer (in the same room on the same computer) and let them nit-pick all the little details. They’ll love it. Just look at what you’ve created together in a real browser and make it look as good as it can possibly be. By allowing this process to take place and creating structure around it you can minimize the interruption while still allowing your designer to ensure the implementation is true to their original designs.
  3. Communicate your expectations up front. It really is that simple. By establishing expectations up front you can avoid a lot of tension when it comes to the implementation of a design. Create a real plan for the design and code handoff. Talk about underlying frameworks being used on both sides. Don’t waste time trying to bend a design or a browser to your will when it’s a small detail. Don’t be afraid to punt something to future-you. Embracing the messiness of our craft and the possibilities of iterative change can make this whole process much simpler and less stressful for everyone.

Empathy for…Each Other

Designers love to talk about empathy—and the importance to understand your audience. We’ve realized it’s equally important to understand the developers helping build that story—and the other way around. Here are some ways that we defer to each other’s flows, processes, and personalities:

  1. Give in to each other’s workflows and feedback mechanisms. Developers: if your designer wants to use Sketch or Illustrator (or Powerpoint?!), let them. And learn how to take that and build from it. (Okay if they’re using Powerpoint you have much bigger problems.) Designers, let your developers decide how they are going to build your design and learn their preferred method of code feedback (we <3 Github issues). This is a simple way to avoid unnecessary conflict.
  2. Communicate your timelines. It’s obvious that time is precious—your time, your client’s time, your customer’s time. Talk to each other about what you’re working on and how long things will take. Designers, if there’s a part of a design that needs more thought, tell your developer to avoid it until it’s fully designed. Developers, if there’s something that’s a design blocker that can be easily addressed, ask if the designer can change focus to allow you to maximize your efficiency. Being courteous with each other’s time will allow you to work at maximum efficiency and get your jobs done faster and with less stress. And that helps everyone.
  3. Know the limitations. One of the things that makes our team work so well together is that we’ve taken the time to understand each other’s complimentary roles and skills. Ryan knows how to wrangle CSS. Andy can design. We all overlap enough to make educated decisions about what’s best for a project and help guide each other to appropriate solutions. That’s not to say that we don’t create fun challenges for one another, but we know how to be creative within the team’s boundaries.

Most product teams exist in high stress environments already—the pressures of your business goals and project timelines are hard enough to achieve. Realize that your most trusted ally is your other half—both are equally valuable to your success. Stop trying to be right all the time, and defer to each other. Focus on making something that everyone can be incredibly proud of, as a team, because you might end up working with those same designers and developers a decade from now.