The Designer with the Dev Tattoo

Collaborating with developers as a designer

Juan Valera
Design at Sprout Social
5 min readMar 7, 2023

--

Two fists bumping over a lo-fidelity design concept.

Developers—they’re just like us!

Once upon a time, in a galaxy far, far away, I was a software developer. I worked on teams that built websites, mobile apps, operating systems, games, you name it. These days, I’m a product designer at Sprout Social — and it doesn’t feel all that different from my coding days! It turns out designers and devs have something pretty important in common: they want to make things that help others!

I’ve worked on plenty of product teams, with a plethora of great devs and designers, and I’ve picked up a few tips and practices from being on teams that work well together. It’s no secret, there’s no magic; it boils down to sharing early, speaking a shared language, and being open to feedback! And you, dear designer, can build these into your design process—you can help your product team work better, faster, and smoother. Cue Daft Punk.

Let’s get into it!

Collaborate early and often

As a designer, the devs you work with are irreplaceable; they create what you envision and help you design good experiences in tricky situations! Your dev partners will help you design even better if you get them involved early in your design process; I often rely on devs’ perspective when technical constraints affect users; think shoddy network conditions, high volumes of results, or backend constraints that might trip people up. The earlier in your design process this collaboration happens, the better your product will be for it.

Don’t make devs guess

Developers may be straight-up magicians, but they’re not mind-readers: you have to document your design decisions somehow. Otherwise, the dev building your doohickey won’t know the context around why it works the way it does. Why does that matter, I hear you ask? Well, if you’re at all like me, there will be things you miss. Edge cases you didn’t know about, empty states or error states that you forgot. Your dev partners find those gaps as they’re working, and sometimes they’ll just use their best judgment to fix them.

Ask yourself, do you want your devs guessing at what you intended? Or would you prefer that they start a conversation with you, and together build something even better?

Speak the same language

One surefire way to speed up those iterations? Use a shared design system to help you call things by the same name.

Designer: “A ‘generate’ button that shows a spinner when you click it but the outline one, not blue…” Devleoper: “So, a loaderButton with appearence=’secondary’?”
Two speech bubbles show how a designer and developer using different language to talk about the same thing. Confusing, no?

If devs ever do need to guess at components, states, colors, etc., having a system to guide them can save the day. At Sprout we have a design system we call Seeds; the home for all of our patterns, components, and the guidance that ties everything together. Seeds is chock-full of time-saving gems, like empty/error/success states and big/small, wide/narrow variations of components!

This lightens the load on both designers and developers: there’s less documentation needed, less guesswork needed, and everyone can work faster without miscommunicating. All because we work from the same toolbox. In design systems (like Seeds), designers sweat the small stuff upfront like states, min-widths & max-widths, and a little writing around why the product takes the approach it does. Developers do likewise; documenting components’ states, optional properties, and when you should use one component over another.

Now that everyone’s speaking the same language, let’s look at how devs get to work.

Plan the handoff

Handoff gets a bad rap; people associate it with a sequential, “waterfall” development process, but whatever process your team uses, you still have to convey ideas so that devs can build them. Anything designers do that helps devs build the real thing is part of handoff, in my opinion. There’s no one way to do it; incorporate whatever works for you and your team! Here are some of the different ways I’ve seen designers hand off work to their dev partners:

  • Make a bespoke presentation that walks the team through the designs — including user personas and their real-world needs. It can be extra helpful to show other considered designs in a glossary at the end too!
  • Make redlines to answer sizing and spacing questions, then put them on a shared network drive that devs use already.
  • (In-person) Print out mockups and show them to the dev(s) who will be building it. Whatever questions they have, write or highlight notes right on top of the mockup!
  • (In-person) chat in the hall before a meeting! Sometimes all it takes is a quick conversation to get your point across.
  • (Remote) schedule a design QA together after devs have had time to start building your designs, they might have found gaps you can help with!

Remember, handoff is whatever’s helpful for you and your team. Add new steps! Toss out unhelpful ones! It’s all about what your team needs in order to do their best work. As you work with your team, you’ll learn both the tech’s constraints and the team’s preferences—both great things to inform future collaborations!

This sounds like a lot…

I hear ya! Try to start with smaller, easier tweaks to your process that still help your team. If it helps, pick one or two of these to try in your next project:

  • When you share your designs with your team, spend a little time upfront highlighting who is the person we’re creating this for? What’s their need? How do they meet that need today, if at all?
  • Give devs opportunities to ask questions: their dev brains will find details you might’ve missed! Plan for questions like: did you consider X solution instead? What happens in Y situation? What about Z person’s needs?
  • No ego please—during your QA pass of devs’ work, it may not look exactly like your perfect mockup darling. Does it still meet users’ needs, and your team’s quality bar? Then it’s probably ok!
  • Handoff can be anything that’s helpful for you and your team!

In summary

Remember, a solid design-dev working relationship boils down to: sharing early, speaking a shared language, and being open to feedback. You can do as much or as little as you want towards those, just keep at it!

This process is far from perfect, and I change it up all the time as I learn more. Even so, I hope you found something helpful in this, and definitely let me know if you try anything mentioned here or think up more!

#TeamSprout

--

--