The Design-Developer Relationship: More Than Just the Handoff
Why focusing on this often-overlooked aspect of the product design role can mean a big pay-off for you in the long run.
As someone who is involved in mentoring junior members of my team, I often get asked for my advice for people starting their careers in product design. I don’t usually answer what I think they expect to hear. My number one piece of advice is:
Spend more time with your developers.
Why? Because you don’t execute your work, they do.
A lot of designers overlook this aspect of their job because it’s an intangible, workplace-dynamic sort of thing. Getting along with people is generally good advice, but in the workplace it can mean the difference between a successful and an unsuccessful career. In product design, the stakes are even higher because someone else is actually building what you design.
As a designer, the harsh truth is that ultimately the success of your work depends on someone else executing your vision.
Designers and developers work differently, see problems differently, have different educational backgrounds, and are motivated differently. This causes friction as it can feel like two opposing forces, rather than seeing the reality that both are actually working towards the same goal but just speaking two different languages.
The good news is that spending more time talking to, supporting, learning from, and working with developers is a habit that you can adopt and practice, and will help you in your design career.
How We Got Here
Design as Craft
Many designers see design as a craft.
And there’s nothing wrong with that, unless you are accidentally in an echo chamber.
It’s not deliberate. Most designers I know, including myself, enjoy the process of taking requirements from their product manager, going off and tinkering away at the problem until they reemerge with a good solution. It’s this creative process that got us into the field in the first place, and it’s this creative problem-solving that makes design valuable.
Many designers go through the process of ideation with their product managers, input from end users, feedback from internal stakeholders, and even sign off from the rest of the design team. Reading articles on NNg, taking web courses and browsing through Behance are also extremely valuable because you need to refine your design eye and to be aware of industry standards. All of this results in a well-thought out robust solution.
You are doing design well.
So why are so many designers shocked when they present their work to the engineering team and get a lot of pushback?
Developers Just Don’t Understand Design, Right?
Put yourself in your developer colleague’s shoes. You are presented a lofty plan for the work you will be spending the next six months on. By the time a prototype is presented to you, it often feels like it’s too late for you to give your input. The plan has been set.
Without having a sense of solid reasoning to back up what you are being asked to work on, it can be frustrating to spend time on something you don’t see the value in. Nobody needs someone dictating their work to them without feedback.
You can see how this friction builds up.
Worse; this dynamic can sour someone’s perception of working with other designers in the future, too.
Opposition vs Collaboration
I see a lot of people going into the designer-developer relationship with an oppositional mindset after a few of these crushing encounters. You have spend your blood, sweat and tears researching, ideating and aligning on a solution. So if someone says “no”, you might have to completely pivot and restart the ideation process.
That’s why it’s so important to begin collaborating with developers early.
Rarely does someone say “no” without a good reason; understanding why will help you next time.
What To Do About It
Receiving Feedback
Giving feedback is a skill, but so is receiving feedback. This is something I personally struggled with when I was starting out in my career. You really do fall in love with your designs. Being able to take your own ego out of the equation goes a long way in being able to really understand the reasons why something is being challenged, and ultimately to move towards more feasible solutions next time. It’s a tough learning curve, but in practicing receiving tough feedback and working with it, you will be a more effective designer in the long run.
Switch to Being an Active Stakeholder
I believe another aspect of tricky dynamic is misunderstanding the role of design in the whole development cycle. Many designers see themselves as consultants who provide design material for product managers who are in charge of executing their project with their own team. Some design team structures implicitly support this dynamic. I would encourage reframing your mindset about your role as a designer, no matter where you find yourself.
Switch your mindset away from only being responsible for ideation and handoff. You are now a proactive team-member with developer colleagues, and you now have regular touchpoints with developers during the entire product development cycle.
A Practical Guide For Product Development
Here, I outline guidelines for how to improve this relationship from ideation to launch. Your mileage may vary, depending on team composition and culture, project timeframes and a number of other crunchy things.
The main thing to keep in mind during every phase is that you are responsible for initiating and maintaining a positive rapport with your developers. Do it early, and do it consistently.
Many designers see hand-off as the most important interaction they have with developers. However, without developer collaboration earlier in the process before handoff, designers have a reality check that their work is impossible to execute, or will have to be seriously modified. This can be avoided with some small adjustments.
1. Ideation: Do Your Design Due Diligence
You should be able to back up every single design decision you make. Your mockup is a hypothesis that needs to be proven and reinforced. Your reasoning should ideally be one of the following, in order of importance:
- It was validated in user research,
- It’s consistent with our design system patterns and components,
- It’s industry best practice.
You should actually involve your developers as early as this without disrupting them. Invite them to research sessions or share research findings. Ask for their opinion on your work in progress. Send them some screenshots for their input. They might tell you something you didn’t think of, or provide really valuable suggestions. In my experience, most front-end developers I work with care a lot about their users and have a lot of great ideas.
Not only that but as a designer, you work primarily in the front-end. If you don’t have experience with code, having an understanding of how this technology works will means knowing the constraints you are dealing with, saving you from expensive rabbit holes down the road. You can learn a lot from your developer colleagues here. See this relationship as an opportunity to educate yourself (for free!) and account for technical constraints before handoff, saving you and your team time and heartache.
2. Handoff: Have Two Plans
Once you have a working final prototype, you should now create two mental plans for presenting your work to the development team:
- Best Case Plan: This is the Realistic Blue Sky plan. All the best possible choices are included here: product requirements are fulfilled, users are delighted, patterns are consistent, copy is flawless. This is your must-haves, should-haves, and could-haves. It is aspirational, but it should always be realistic.
- Bare Minimum Plan: You should have a mental list of all the must-haves from your Best Case Plan, and know when you can cut or change anything else. Your must-haves absolutely need to be things you can back up; they should either be meeting hard requirements or at minimum are necessary to pass accessibility criteria.
The goal here is to get as close as possible to your Best Case Plan while considering technical feasibility and project constraints like timeframes and deadlines.
The skill that you need to develop at this point is working with developers on achieving the Best Case Plan, including showing flexibility to compromise on cutting or modifying the non-essential stuff, and explaning your rationale for the hard requirements. The goal here should be not in persuading to have it your way, but to work with your developers on a viable solution. Showing adaptability also indicates that you are not going to be difficult to work with later, because you are able to change based on their input.
3. Development: Support Role
Once you have established a plan, made changes to your prototype, and updated final requirements, it’s now time to drastically shift your focus. As your developers are coding, you will be in a support role.
At this stage your focus should be simple: make their lives easier. This is strategic: you will need to draw on goodwill in the Design QA stage later (more on that below), and gives you active visibility on how the project is progressing.
Here, support proactively:
- Reach out over Teams or Slack to ask how you can help them,
- Answer their comments on your design files quickly and follow-up to make sure they have what they need,
- Offer to book a quick meeting to unblock them as soon as they need help,
- Provide positive constructive feedback on demos.
4. Design QA: Handle With Care
Design QA is an extremely underrated aspect of your job as a designer, and I could write a whole article on this alone. This phase is critical because design is essentially planning, and the best laid plans often fall short. Make sure this phase has been included in the roadmap and be systemic about feedback you provide.
Once your developer is ready to demo their work, you will give them feedback on how to refine and what to change before shipping. A lot of things that are very obvious to you might not be to someone else, no matter how clean and clear your handoff files are or how well you presented your work during a pre-grooming session.
Now, it’s about handling your own requests to them with skill and sensitivity. The key here is to realize that you will be asking someone to modify their hard work, and you will need to approach this with tact.
Conclusion
Designers and developers share the goal of creating quality experiences for users, they just often approach the problem differently.
The success of your own work as a designer relies on a collaborative partnership between you and your developers. Spending time establishing a positive professional rapport with your colleagues will be foundation of goodwill you can draw upon when you will ask them to do work in the future, as well as helping you learn and grow in your own career.
The more time you spend learning from coworkers outside your field, the more well-rounded you will become as a designer, and the more efficient you will be at designing.
