Practical ways to become your dev team's favorite designer
Engineers frequently tell me that my designs are challenging to develop or that certain features will cause the system to slow down. What strategies can I employ to create more developer-friendly interfaces and UX solutions?

Earlier this year, we discussed the importance of communication between design and PM. We already know miscommunications and misalignment can lead to cost and production problems.
But lack of collaboration between designers and developers can also result in decreased efficiency and increased project turnaround time.
Designers and developers need to work closely together when building a product, but there are many obstacles between them.
Engineers frequently tell me that my designs are challenging to develop or that certain features will cause the system to slow down. What strategies can I employ to create more developer-friendly interfaces and UX solutions?
If you've ever found yourself wondering what you can do to be a designer that developers love to work with, this post is for you.
Involve developers as early as possible
To strengthen the design-dev connection, you can start optimizing your processes together immediately.
This way, the debates about what can be developed will no longer begin once designs are "finished." Instead, your engineering partners will be able to identify trade-offs early and often, which you will then be able to incorporate into your design.
I'd recommend involving the development team as early as conceptualizing user flows or information architecture. All because the flow of information can have a potential back-end complexity (such as underlying data structure changes), which will almost certainly lengthen the development time.
Develop a common language
I would recommend creating a common language to facilitate collaboration (e.g., shared names for design primitives and components).
Developers will avoid manually translating a designer's intentions into the equivalent code if the terms, properties, styles, and components used in the design are reusable and consistent.
This is a powerful argument favoring design systems that clearly compile a collection of reusable components. Design and development teams can use the system to collaborate more quickly and easily by acting as a single source of truth.
Share often and get feedback
This is one of the scariest things for designers but also super important. Over the years, the most practical tactic I've learned is overusing the phrase "something like this."
Sharing designs with developers and getting feedback often will help you as a designer to make better decisions, both in the short and long term.
A good developer's input will assist the designer in creating an outstanding product. It will run smoothly with the right team. It will be easier to communicate with each other if the designers understand each other's roles and expectations.
Smaller yet important tips
Think in variables
A developer will not type "64px." Instead, they'll try to use the corresponding variable, such as "2xl." Determine these key variables (or "tokens") and then employ them. This is what allows you to develop a consistent, collaborative language.
Embrace the box model
All frontends are built with boxes (or "divs"). Our designs become much easier to implement when we use the same mental models.
That is to say, Frames > Groups.
I strongly advise you to rely heavily on auto-layout. Soon you'll start seeing CSS in your Figmas.
Create consistent canvas layouts
There are numerous approaches to this. What matters most is consistency.
Here's what I'm thinking:
Organized primarily according to horizontal flows
Vertically stack variations of a specific screen
Move vertically across breakpoints
Clearly communicate status
This becomes especially important when updates are being made. I use Annotations to show if something is a WIP idea vs. ready to build.
Loom videos are your friend
Making a 1-2 minute Loom is one of the simplest ways to explain your designs. I would constantly attach these to flows. Ensure that everything is still written down. The video should be optional and not required for comprehension.
Communicate max-widths + max-heights
Developers are always going to be wondering:
Does this layout expand forever? Or am I looking at the max-width?
I always try to put this in writing and/or create a stretched canvas to show when UI elements stop growing.
Design around worst-case scenarios
What are the possible errors?
What are all the potential empty states?
What does this look like at the most awkward device size?
What happens if this content doesn't load?
What happens if this text is really long?
Conclusion
It is critical to have clear communication. It should be done in such a way that both parties benefit.
To meet and communicate effectively, both sides should have clear goals. The designer should be aware of the project's specifications. This will give the developer a better understanding of the client's desires.
It is a good sign if both sides are happy with the project. They can communicate more effectively by using the same tools.