Want to receive post like these in your inbox? You can subscribe! It's free.
If you're a developer who work on the frontend and collaborate with a design team, or if you're a UI/UX designer who work on design projects and collaborate with developers, than you must be familier with the frustrations that comes along side the design handoffs.
Today I will mention these frustrations (starting with the most common ones) and share how you can avoid them as a designer or a developer.
It is important to note that it is not just the designers duty to make developers life easy and adapt to their preferences. Infact, majority of the time it is the developer who needs to learn the designers way of thinking. However, collaboration is the key to avoid any conflicts and determining what works for all.
If you haven't already, checkout my previous blog post on how I organize my projects in Figma which covers all the points mentioned under the avoidance sections below.
The unrealistic vision
The number one frustration any developer has faced in the past is being presented with design or interactions that are impossible to implement in the time and budget they have allocated.
You will often hear a developer saying "This is way too hard to implement. Would you please tune it down" and the design/animations never turn out to be as beautiful as it was originally envisioned.
To avoid this frustration
- Keep feasibility on top of mind
- Involve the developer from day one
- Have daily stand-ups, share the goals and process
- Be in the same room, sit together, colocation is important
- Document the animation spring details
- Decide the spacial model and think in layers
The unavailable assets
One of the greatest frustration of any developer working on implementing designs is the availability of the assets and/or their different format. For assets to scale properly a 2x and 3x version is required.
In teams where design and development are considered as two separate tasks and designers usually move on to other projects before their design is developed the availbility of assets can be a huge frustration of developers working on the implementations.
You will hear the developer say "Where are the 2x and 3x assets? The app won't be perfect without 2x or 3x assets".
This frustration can be easily avoided by simply
- Seprating all your assets in the design system
- Making sure the assets are available in different resolutions
- Create a platform-specific guidelines
- Ask the developer to learn and extract their own assets
The inconsistent formatting
Sometimes in small teams and often due to the lack of a design system framework, the designers often forget to decide the format of colors they use. Usually formatting is left for the design tool to take care of.
However, while coding a developer can be greatly frustrated when half of the colors are in HEX format and the other half are RGB.
Often what happens is the design tool spits out RGB for things like border and box-shadows and HEX for basic background.
This makes developers go "Why are all these formats different? Which one should I use again?"
Fixing this is straight forward
- Avoid relying on design tool to generate the color code
- Spend time on a design system and a color palette early on
- Stick to using the same color through out the design, and ofcourse
- Make sure you only use a single format for you colors, ask your developer which format do they prefer
The naming paradigm
Thinking about color formats, another frustration associated with colors is color names. Sometimes a design can have multiple shades of the same color used across the board.
As a developer thinking about color names, specially when they look the same, is the last thing you want to spend your time on. This is justified because as a developer there are other things to worry about, like consuming the server responses and working on the state reducer logic.
Same thing goes for assets and layers too. It is important as a designer to think and decide on the colors and asset names right when you create them.
A developer will say "I have other things to worry about. Why do I have to think of color names that all look the same?"
Hear them out and avoid this by
- Uniquely naming all the colors and it shades on the design system level
- Naming the assets and layers as you make them
- Deciding on and using the correct vocabulary that is useful on the both sides
The contradicting labels on mobile and desktop
As a designer you will be surprised to know the small details developers rely upon when implementing a design in code. For example, the labels and their positioning needs to be pixel perfect across screens and devices and it can cause frustration if they aren't.
Have you ever had a developer come up to you and say "Hey, can you confirm which label is proper one? It looks different on mobile vs the web."
To make sure the labels and alignments are consistent across platforms
- Reuse your components across platforms as much as possible
- Use autolayouts where ever necessary in your design system components
- Always use a grid system to snap elements in the right place
The missing edge cases and empty states
Now I know we all go through this and sometimes designing for the edge cases and empty states can be cumbersome and pushed at the very end. But, as a developer it can be extreamly frustrating to find out half way through that the error state or warning state design is not ready yet.
You will hear developers say "I will have to finish the edge cases when the designs are ready." and the edge cases are never ready until its too late.
This can be avoided by simply following a simple trick of
- Documenting the design as it happens
- Being organized from day one
- Creating a project encyclopedia
- Creating a design readiness checklist for marking what is done, and
- Remembering what is left to do
Takeaway
Both designers and developers work on the same team and share the same end goals and it is super vital to collaborate as often as possible from day one to avoid any bottlenecks and inconsistencies that may arise.
To think if designers learning development pitfalls is more important OR developers learning design vocabulary is more important beats the purpose as both developers and designers need to learn each other traits for better collaboration and a productive workspace.
What do you think about this list? Share it with your designer/developer friends.
TweetIf you're a UX designer this growing list of UX resources might come in handy