How to make programmers happy and design-to-developer handoff less painful
I am a Product designer with more than 8 years of experience. I specialize in building Design systems, conducting user research, improving design processes, enhancing users’ experience across interfaces and beyond, and so on. I have worked with various clients across Fintech, Education, and Entertainment.
My passion is making people’s lives better, efficient, and helping them solve goals through interfaces and working environment is not an exception.
During my personal experience and experience as a mentor, the most common pain point in the team’s process is the design-to-developer handoff.
Handing off mockups to developers can be hard for several reasons:
- Lack of technical knowledge
Designers may not have the technical knowledge needed to create mockups that can be easily interpreted, recognized, understood, and, as result, implemented by developers. It could lead to misunderstandings or errors during the development process. - Lack or exces of detail
Some designers may create mockups that are not detailed enough for developers. This can make it difficult for developers to know exactly what is required and could cause revisions and rework. - Incompatibility
Mockups may be created using design tools that are not compatible with the development tools used by developers. This can make it difficult for developers to import or work with the mockups, which can slow down the development process. - Lack of consistency
Without proper documentation or clear instructions, designers may create mockups that are not consistent with the overall design style or branding guidelines. - Different workflows
Developers and designers may have different workflows and processes that they are used to, which can make it complex to handoff mockups in a way that is easy for developers to work with. - Lack of documentation and annotations
Without due documentation and annotations, developers may find it hard to understand the design intent behind certain elements of the mockups and may not be able to replicate the design exactly as intended.
Need to remember that all teammates could be focused on different aspects of a digital product and user experience, so it’s quite common to have a disconnect between the developers and the designers. In turn, this can lead to a vague handoff process.
Mostly every designers and developers know that mockups provide a visual representation of the end product and can also help identify any potential issues before the actual development process begins.
Here are some of the pieces of the process that could help make the process of handoff from designer to developer smooth.
User Flow
The most useful for developers is to see how all mockups are connected with each other. It is like start solve a puzzle from 20 to 1000 pieces without understanding what exactly you need to solve. In this case, building user flow with all interactions and connections between screens could save a lot of time in the development process and developers could spend hours by making the product more stable and seamless than solving that crazy puzzle. Also, this approach gives them some useful information that they can’t find in static mockups.
Showing a user flow can help:
- Solving the gap between design and development;
- Improving collaboration and communication;
- Visualizing the user experience, making it easier for developers to understand the context and goals of each page and feature;
- Planning and implementing developer’s work more effectively;
- Ensuring that design and development efforts are consistent and aligned.
More over, building User flow is also valueble for designers, stakeholdeps and altogether team because this approach help referencing for future work, as they provide a visual history of the design and development decisions that have been made.
Aspects of the displayed content
Showing aspects of the displayed content is crucial for developers to fully understand the intended behavior and design of a web application. Aspects refer to situations that are outside the normal user behavior or conditions that occur within the boundaries of the system’s functionality. For example, what happens when a user inputs invalid data in a form field or tries to interact with a disabled button?
By presenting aspects, developers can anticipate and address potential issues before they arise, improving the overall user experience and stability of the application.
Here are some examples of aspects of the displayed content in interfaces:
- What happens when a user inputs incorrect data, such as an invalid email address or phone number?
- How does the interface handle unexpected errors, such as a lost internet connection or a server error?
- How does the interface handle unexpected user behavior, such as rapidly clicking buttons or scrolling too fast?
- How does the interface handle users with disabilities, such as users with screen readers or keyboard-only navigation?
- How does the interface handle different screen sizes, resolutions, and aspect ratios on different devices?
- How does the interface handle high traffic or slow loading times, and how does it maintain a responsive and smooth user experience?
- What happens when a user reaches the limits of input, such as the maximum number of characters in a text field?
I believe that showing edge cases is essential in the handoff process to create a robust and user-friendly website or mobile application. By looking through edge cases designers could help developers build and maintain a high-quality product that meets the needs of users and meets design and functional requirements.
Different screen sizes and devices
Showing mockups of an interface in different resolutions is essential for web and mobile application development as it helps developers understand the design and behavior of the application on different devices. There are a lot of devices that come in a wide range of screen sizes and resolutions, and it is important to consider how the interface will look and function on each one.
Additionally, mockups in different resolutions also help ensure that the interface meets accessibility guidelines, such as making sure text is legible and buttons are large enough to be easily tapped.
Here are more arguments to create mockups for different sizes of screens:
- Different resolutions can affect the way an interface is displayed, which can impact the user experience;
- By seeing how an interface looks on different resolutions, developers can make necessary adjustments to ensure a consistent experience for users;
- Showing an interface on different screen resolutions can help to identify and fix any issues related to responsive design, such as layout or font size problems;
- Supporting development effort: Providing an interface on different screen resolutions supports the development effort by allowing developers to test and implement designs in a more efficient and effective way;
- Showing an interface on different screen resolutions can improve collaboration and communication between design and development teams, as they are working from a shared understanding of how the interface will look on different devices.
In conclusion, showing mockups of the interface in different resolutions is necessary for both web and mobile application development as it helps ensure a consistent, seamless, and accessible user experience on all devices.
State of elements
The most crucial part of handing off mockups and even in design overall is designing all possible states of each element.
Providing states of elements can help developers understand the different states a UI element can have in a design. It could be presented as a page with all UI elements gathering in the UI-kit or as a bunch of elements placed near the mockup where these elements show for the first time. In a perfect case, it is helpful to add annotations or descriptions to explain the intended behavior of each state.
Another option is to use the prototype feature in Figma or the other prototyping tool to demonstrate the interactivity between different elements and their states but, anyway, it is important to keep the different states organized and easy to access, so developers can quickly reference them.
States of elements of a web interface or mobile app refer to the various visual and functional representations of UI elements such as buttons, form fields, and text, in response to user interactions.
Here are some examples of basic elements with different states:
- Buttons: Normal, Hover, Active, and Disabled;
- Form Fields: Normal, Focus, Error, and Success;
- Text: Normal, Hover, Active, and Disabled;
- Images: Normal, Hover, and Active;
- Modals: Open and Close;
- Tabs: Normal, Hover, and Active;
- Dropdown Menus: Normal, Open, and Closed;
- Loaders: Loading and Loaded;
- Sliders: Normal, Drag, and Drop.
Regarding the type of states, it is possible that the same elements could have some differences in naming or state depending on the device or goal for various products. In this case, it is necessary to communicate with a developer to define what the exact state could be for each UI element. These states help create a dynamic and interactive user experience.
The best part is that a lot of companies share their Design Systems and UI-kits that could help in understanding what type and name could have each element of the screen.
By providing the different states of elements, designers can help developers understand how UI elements should behave in response to user interactions for each type of device.
Spacing, inset, offset
It is still hard to read each other’s minds so this is one more problem that usually faces designers and developers. While designing mockups designer could imagen another behavior for some elements on various screen sizes than the developer. The reasons of that are different backgrounds, drastically dissimilar tasks that both of them try to solve, experience, and so on.
Developers should be aware of spacing, insets, and offsets in mockups because they play an important role in determining the visual hierarchy, balance, and overall design of a user interface. By understanding these concepts, developers can ensure that their implementations match the intended design and maintain consistency across different devices and screen sizes. Additionally, a deep understanding of these elements allows developers to make informed decisions when making changes to improve the user experience.
Designers should provide the following information about spacing, insets, and offsets to developers:
- Unit of measurement used for spacing, insets, and offsets, such as pixels, dp, or rem;
- Size values for each element, including the size of margins, padding, and other white space;
- Relationships between different elements, such as which elements should be aligned and how far apart they should be;
- Reasoning behind the use of specific spacings, insets, and offsets and how they contribute to the overall design;
- Context on how the elements should look and behave in different screen sizes and orientations, such as on desktop or mobile devices.
By providing this information, designers can ensure that developers have a clear understanding of the design intent and can accurately implement it in the final product.
Icons
Parts with the handoff of the icons is also the most common pain point due to several approaches but all this pain could be solved by starting communication between the designer and the developer. Handing off icons to developers properly ensures consistency and accuracy in the design of websites or mobile applications. Incorrect icon files or missing specifications can result in inconsistent or incorrect representation. Proper handoff of icons helps achieve a cohesive and visually appealing design.
Here are a bunch of tips for designers that could make the process of handing off icons easier:
- Export icons in a preferred format (e.g. SVG, PDF, PNG, or font-based icon systems);
- Provide a clear grid and size specifications for consistency;
- Supply the icons in a standard color and provide specifications for any variations;
- Organize icons into a logical set or system, with a clear naming convention;
- Provide guidelines for accessibility, such as adding alternate text for screen readers;
- Provide CSS code snippets or use tools such as Symbol sets in Sketch or Icon libraries in Figma;
- Minimize the number of points and paths in SVG icons to reduce file size;
- Optimize PNG and JPG icons with tools like TinyPNG or Kraken.io;
- Consider using an SVG icon system, such as Iconify or Font Awesome;
- Combine separate paths into a single path where possible.
Understandable, that not all of these tips could be used for some situations but usually developers could help designers to clarify what would work best for a specific situation.
Final thoughts
Sometimes, I feel that designer sees developers as an enemy or as a naughty team member without any reason.
I believe, that developers are the end-users of designers’ mockups so I tried doing my best to help them get everything that they need from my mockups.
So, to make a perfect handoff process just ask developers if anything is unclear for them and if they need any additional information.
For tips and a few approaches to making Figma’s workspace convenient for developers read my previous article: “Approaches to organizing Figma files at SpatialChat”.