Things developers wish design system designers remembered
Jules Mahe
One of the key benefits of design systems is helping designers and developers work together better, more efficiently and with better communication. But that’s only theory; in real life, it’s not always that simple to build bridges between those professions. This difference is mainly because of their different tools, ways of working, mindsets, etc.
But don’t worry, we got you covered and asked developers what they wish designers would remember when working on a design system. We gathered their answers into a list to ease collaboration and make your daily design system a better place. We also have another design system checklist article if that’s something you’re interested in.
So, feel free to send this article to your favorite designers next time you need to work together 😉
Designers and developers: one team
If you worked in the design system field for a while, you know that communication is both essential and difficult to get. Early involvement of developers in the design phase, regular discussions, and consideration of their ideas during brainstorming and prototyping are key. In terms of implementation, designers should consider developers as their users, the ones who use the designer’s handoff to implement the product. As such, designers should have some empathy and understand the developer’s needs and working style. In return, developers should also offer feedback, as they have the knowledge of what can and cannot be implemented. Both designers and developers need each other to ship a successful system; that’s why a “one team” mindset works wonders!
Involve developers from conception
Although it is the designer’s responsibility for the conception part of a project, having developers in this early phase may be more beneficial than designers think. Consider this proactive approach as an investment in the future, as the developers will receive a comprehensive handoff with context. Involving developers in the solution-building process will help them understand the design more clearly. The user experience in its front-end form can be overshadowed by designers’ focus on the user interface. By utilizing developers’ insights into how a design should function, designers are able to create mockups that are more functional and higher quality. It is helpful for designers to better understand the behavior of various features to create a more effective end product.
A developer can significantly contribute to it and think about all the edge cases of a component: how does this component behave with another one; what if they need to add an icon, responsive, empty state, etc., thus avoiding too much back and forth. Moreover, developers’ knowledge can be used to estimate the build time for components, pages and user journeys.
Ultimately, by actively participating in this early phase, developers can effectively steer designers and address technical hurdles early on. For example, the developer’s point of view may help save time by asking the right technical questions at the beginning of the project instead of finding out the technical issue before launching.
…to delivery
Every time something critical needs to be delivered, bring both designers and developers together instead of letting them do their own thing. Setting up a dedicated channel between all relevant parties allows communication issues to be easily avoided. It’s also an excellent way to share ideas and resources, improving your design system’s efficiency and collaboration.
Having regular feedback during the build and delivery process helps ensure things are shaping up as planned. Developers can warn about technical limitations that will arise and may require rethinking an approach before it’s too late.
The delivery phase also allows designers to explain their work to developers by doing some handover and show to developers how to use a component, how it behaves, their options, etc. Designers should consider this phase as onboarding, which prevents the developer from wasting time making incorrect assumptions and poor judgement calls.
Documentation
Because documentation is the heart of a design system, it must be fueled with the right information to be efficient. However, having the right documentation that serves everyone’s interests isn’t always something easy to achieve. So what should designers consider documenting for developers to be comprehensive and effective?
States
Designers may tend only to design the different states of a component they need for their projects, forgetting to design all the different states necessary. Usually, they’re going to do a default, a hover and perhaps a disabled state if you’re lucky enough. But what about the focus, pressed, selected, activated, read-only, etc.? We wrote an article about naming conventions to help you get started if you want to have something to share with designers about the different states they should consider when designing.
See this as a way of working for your design system; designers should always consider this wide range of states for each component they deliver and detail their behaviors and specificities in the documentation.
Variations
Regarding states, there’s another thing designers tend to forget when designing components: variations. Whether it’s about responsiveness, different devices or technologies, corner cases like empty states, no internet, error page, etc., it must be clearly documented and communicated. Developers can help designers think about these variations needed if they’re involved at the beginning of the project (see above) by requesting these variations during the conception and thus before they deliver. The developer’s experience is valuable for designers as they are coding, they have to think about all these different scenarios and outcomes (when they write if/then statements, etc.) to make sure they have coded everything. It’s easy for designers to focus on the happy path only and forget about things like disabled states, empty cases, etc.
Optimizing styles
Colors, fonts, spacing, etc., are the foundations of every project. Having clear guidelines explaining how these styles should be applied and implemented is essential. Once again, communication is key and it’s important to make sure everyone understands how these styles work and to discuss best practices with their design and developer teammates.
For instance, developers can help designers understand how browsers render elements and why style elements like line-height may be affected.
On the other hand, designers should be aware of providing only a few elements. A typical example is with the greyscale, having too many (50?) shades of grey while it could often be reduced to 8-10 greys tops. Having a limited color palette helps developers to be better at consistency by remembering what each style is made for. Less is more.
Dos and Don’ts
What can seem evident for designers isn’t the case for everyone. That’s why dos and don’ts are always appreciated, even if they seem to remind us of obvious facts. Making sure people know how to use or not use a particular component or pattern is a good way to avoid mistakes. Plus, it’s an opportunity to use visuals and examples to illustrate what you should and should not do, making your documentation easy to read and understand.
Handoff files
The handoff phase is the cornerstone of an excellent designer-developer relationship. That’s why it is essential that designers take time to teach developers how to access the handoff delivery tools in Figma, InVision, Zeplin, Sketch, etc. By the way, did you know that zeroheight also has an inspect mode when you upload design files?
Ensure they understand the tool well, including finding information on color codes, font type/size/weight, element spacing and sizes, etc. If necessary, schedule a demo session and record it for later viewing by all team members.
Naming convention
When it comes to naming files, investing time in it for files and artboards can ensure future clarity and understanding. Having proper naming of files and artboards with clear, simple, and semantic labels can assist the development team in understanding the purpose of each frame or flow. Some basic rules, such as using lowercase, hyphens instead of spaces, latin characters only and having short and efficient names not exceeding three words, are general rules to apply for naming conventions. You can find more helpful rules in our naming convention article.
Also, it will be easier for developers to understand the file structure if designers use semantic names that specify the function. For example, it’s always easier and more understandable to have a “Homepage” screen than a “Userflow-01” screen. The same goes for the way naming frames, styles, components, etc.
Ultimately, developers can set up their components using the same naming convention to make things consistent and easier to use for everyone.
Share clear and comprehensive files
This housekeeping rigor is also necessary for the way designers’ files are organized. They should only deliver what is necessary and remove unused variations and outdated screens. If old screens need to be stored, they can be stored in another file. However, designers should provide the final versions when delivering the products to the development team. This way, you can minimize misunderstandings and maintain the file’s relevance by sharing only the key frames and artboards. This is all part of considering the developer’s user experience in the end. By using the designer’s file, developers should have a good experience with little friction and confusion.
Another way is to identify which files are ready for development from what is still in progress by using visuals such as icons or emojis to show the state of work: in progress, to review, done, etc. As the handoff is done incrementally, it will help developers identify what is ready for consumption. Using this approach, the team will save time and effort on screens that are still under design and still need to be ready for development.
How IDAGIO organized their Figma files
Annotate and explain
Providing multiple designs and digital assets to the developer may be overwhelming for them, especially if you’re working with new teams or async. To mitigate this, designers should annotate their designs and leave comments explaining each decision. There are many ways to operate this: sticky notes, comments features, or using documentation platforms tools like zeroheight ;). It is worth asking them for feedback directly to ensure that the annotations are helpful and relevant to developers.
As a result of these annotations, everyone can gain insight into the intended functionality and behavior of the product by defining how the system behaves, how it responds to user actions, how it communicates results or how it helps fulfil the user’s intentions.
Provide all the assets
Creating all the relevant assets from components and pages (fonts, icons, images, etc.) with different sizes (1x, 2x, 3x, etc.) and formats (SVG, PNG, PDF, etc.) is precious time saved for developers. It’s time they won’t spend asking about these elements to designers. Export options in design tools like Figma or Sketch are helpful for setting up these exports quickly and efficiently. Moreover, with zeroheight, you can find and export all these assets easily in your design uploads and the inspect mode. So there are no excuses not to provide these for developers!
A long-term relationship
It is imperative that designers are involved in the quality assurance process even after the product has been delivered. In addition to improving both parties’ knowledge of one another’s work processes and the product itself, this can provide them with valuable insights into each other’s processes. That’s why it is essential to find time for discussion.
Holding retrospectives and creating lists of what worked, what posed challenges, and what could be done differently is an essential step for designers and developers. The best way to ensure actionable feedback is to use descriptive scenarios and link comments to code repositories, design system libraries, documentation pages, and other relevant materials. Consider including links to specific components within the component library when providing feedback and clearly describing the issues and opportunities for improvement.
Documenting design decisions and their reasoning ensures a consistent understanding of the designer’s work by developers and other stakeholders. That’s why documentation is essential when building a design system, and we are here to help you with this part.
In the end, design systems are not so much about tools and processes as they are about humans. Thus, investing effort and time into this designer-developer relationship sets a high standard for your development and design teams, but most importantly, it will improve the quality of the end product.