August 18, 2023

Design ❤️ Dev

I started my career in design and quickly learned that handing off beautiful screenshots to an engineering team is a risky business. There’s an awful lot that can get lost in translation: animation, interaction, responsive behavior, edge cases introduced by new content.

That’s why prototyping functionality was built into design tools — the more you can show functionality and document expected behavior, the more likely you are to have an end product that works as expected.

But even with the most capable tools, there will be times when you haven’t had time to flesh those expectations out completely, or the engineering team misunderstands. How do you provide feedback to devs once a component has been built?

A couple of practical tips:

• Offer them a compliment sandwich. Start by complimenting their work and praising what’s been done correctly. This sets a positive tone and lets them know that you’re on the same team. Then provide the critique. Follow up by reaffirming the shared goal of meeting the user’s needs.
• Practice the Socratic method. That word “critique” in the previous point may be a bit too harsh. When talking with teams from other disciplines, ask a lot of questions. Your goal is to draw out underlying ideas and presuppositions — theirs and yours. “I noticed when you clicked the button, the transition is a fade instead of a slide. What led to the choice of a fade? Are their technical constraints that made the slide transition tricky? I chose a slide transition because of X reason. Is there a compromise we could explore, given the technical constraints?”
• Make your feedback specific and focused. “That header looks off” doesn’t cut it. Is it the spacing? The color? The animation? Be specific about the problems. Bonus points for framing the feedback in terms of the user experience.
• Give feedback where they live. If the engineering team tracks issues with GitHub, document your feedback there. If they use Jira, create stories and tasks there. It’s a small gesture, but shows that you’re a good faith partner in getting things done.
• Pay attention to recurring problems. If you find that certain aspects of the design keep getting lost in the translation, write it down. This collection of common gotchas can become a sanity check for future builds.
• Listen up! Feedback isn't a one-way street. Developers often bring important insight based on things like performance, device standards, or technical constraints. Be open to their input.

One other thing that goes without saying: work as closely with the engineering team as you are able. Frequent, brief check-ins (sync or async) let you review progress, answer questions, and bridge the communication gap in general. When it comes to digital product design, communication really is half the battle.

—
Cheers,

Up Next: Starting small, a lesson from the shore

← Full Archives