Building a Stronger Designer and Developer Collaboration

Miranda Bouck
The G&M Journal
Published in
7 min readOct 14, 2015

I am a designer by training and a self-taught developer. As someone who speaks both “languages,” I feel that I can offer some insight to help other designers and developers make their collaborations even more effective.

There is a lot of talk about the need to bridge the gap between designers and developers, and I agree. However, to me, the most important thing isn’t that one should learn the opposite to replace the other, but instead that designers understand the development process and developers understand the intent of design. To do this well, we must be willing to learn from each other. But learning requires us to stretch beyond our comfort zone. Designers can take the first step by considering development needs from the moment a project begins. Here’s a little insight to how I work with my developers to make a better product.

My Process

Development starts when I’m wireframing the design.

With any new website or app project, I begin in the wireframe stage. At this early point I am already thinking about its functionality. How will this work? How will this break down? Why will it respond this way? Will the user understand how to use this? Is there any special functionality?

You don’t need to be development-savvy to ask yourselves these questions. You only need to be planning ahead for the consequences of your design — planning for the next stage before you get there.

I address development hurdles before I choose my color palette.

This is not because I’m amazingly altruistic and selfless; I’m planning how to deliver something great for my client. By joining a conversation with the developer at this early stage, there is a guarantee my client will receive a better end product. Often the developer can offer a better, faster, smoother option to replace what may have seemed like an obstacle to me.

On the flip side, letting that question sit until you’re deeper into the process risks not having enough time to accommodate your intention, and it may force you to compromise the design. Save yourself the heartache and figure out solutions to potential hurdles before you even get there.

I collaborate with my peers to push my designs further.

I’m well aware my personal skill set ends at a certain point. There are things I consider strengths and things I know I need help with.

By collaborating with my fellow designers and developers, we give our clients a better end product. We can deliver something better as a result of the network of talent I have alongside me — whether that is talking with my co-workers or tapping into a wider support base.

My Perspective

I will always be a designer first.

I can and do enjoy both design and development, but if you were to give me a choice to do only one for the rest of my life, I would choose design. I feel one can be skilled in both, but no matter how skilled you become, you are one thing instinctually. For me, it’s design. That is my passion. I don’t think when I design; I just “do.” And as much as I enjoy development, I am forced to think because it’s not intuitive to me.

The developers I work with are firing code all the time. When we’re problem-solving, development is their perspective even if they are fluent in design or another discipline.

No matter how many skills you develop, there is always one that is your primary, intuitive, “this is who I am” skill that informs your perspective.

It helps to speak an expert’s language.

Although it’s possible to be knowledgeable in multiple areas, most people have expertise in one primary discipline.

Just because you have the capacity to tackle a problem multiple ways doesn’t mean you should. Or more importantly, you shouldn’t do it alone.

You don’t have to be the hero who can do everything. It’s enough to be able to articulate your point of view as a designer or a developer. With that you can build a team that can make even better versions of whatever you’d do in isolation.

It’s possible to use a difficult or unusual request as an opportunity to grow. I believe saying “no” is not productive when you’re part of a collaborative effort. While there are instances my gut reaction may be “no,” I try to explain why the request is not possible and provide alternate ways to achieve the goal. This “no but” approach makes it possible for us to give our clients a better product and to educate one another.

Work together and showcase the best of both sides. When you collaborate, you use multiple talents to deliver the best end result.

Build trust.

Reaching out to partner with someone, especially if it’s your first project together, can be scary. How can you be sure you can trust them? What if they don’t have the same standards as you? What if they work best burning the midnight oil and you reach your creative groove after your morning run?

Build checks and balances into your shared process by creating a timeline with milestones to review progress. Check in with each other regularly to discuss potential obstacles before they become problems. And when possible, work in close proximity. It helps to have periodic work stretches in the same space, but a phone call can get the same result.

Collaboration is a skill.

We don’t come at collaboration naturally. We all remember instances when we were required to work as teams — maybe for a class in high school or college — and it always ended up with one person carrying the load or communication blunders that left people with hurt feelings. Even if you got an “A” on the project, the experience was so unpleasant you swore you’d never share credit with anyone again.

But I’ve learned there is a way to collaborate that allows you to focus on what you do best, to learn from your partner and to deliver something you can be proud of.

  1. Develop a bigger vocabulary.
    Take the time to learn the basic terminology for the other’s field. Avoid descriptive language and stick to instructive language and examples you can actually reference. Then, agree as partners on a common language to move forward.
  2. Adapt your process to accommodate your collaboration.
    For a designer, there is no reason you can’t integrate development conversations into your process. Have a conversation with your developer to find out what he/she needs at different stages to remain on track. Would they benefit with project assets exported in a particular way? Is an early wireframe review useful? Allow for “nitpicking” and don’t be offended. Designers are going to fight for 4px rounded corners. Developers are going to insist on writing compliant, clean code with as little bloat as possible. Those little details aren’t irrelevant, they make the custom experience and ensure quality.
  3. Explain your expectations.
    If you clarify at the beginning what you expect, how you expect it, and when you expect it, many potential obstacles can be avoided.
    Take time to walk through the design before development fully begins. Explain your thought process behind the design. Discuss at length the expected functionality and any small details to make the experience unique. The extra time you spend planning together upfront, the more awkward conversations you’ll avoid down the road — with your partner or the client.
  4. Review together.
    Before anything goes to the client, go through the site and review each page. The designer will catch things the developer may have overlooked and vice versa. This is your opportunity to make improvements or educate your collaborator on why certain decisions were made along the way. Don’t be annoyed by questions — it’s much better to field them from your trusted partner than your client.
  5. Celebrate together.
    Take time for high fives along the way and be sure to recognize each person’s contribution and project milestones. You learn just as much about another person’s field this way — what may have seemed like routine development to you may actually have been a major obstacle to overcome for the developer. Plus, there’s success that should be equally congratulated like delivering on time and coming in under budget. It’s all an opportunity to cement your working relationship.
Animation in collaboration with Bryan Findell at Grain & Mortar.

Tools to Get Started

A short list of tools for anyone in design interested in learning the basics of development or anyone in development interested in learning the principles of design.

Designers can get a better understanding of developing with:

  1. Team Treehouse
  2. CodeAcademy
  3. jQuery, Java, JS, and UX meetups

Developers can get a better understanding of design with:

  1. AIGA, the professional association for design
  2. Lynda
  3. Design for Hackers

Like what you read? Subscribe to The G&M Journal for upcoming articles and short essays from me and the rest of the Grain & Mortar team.

Miranda is an Art Director at Grain & Mortar, current chapter president for AIGA Nebraska, preservationist, and happy to be an imperfect human.

--

--

Miranda Bouck
The G&M Journal

Product Owner, Lead Designer | Building Uniform @Hudl • president emeritus of AIGA Nebraska