As Pelin Kenez, Co-Founder & CEO at Zeplin, puts it:
It’s where the “infinite possibilities” of Design Creation met the “bounded realities” of bringing the design to life.
This development cycle presents challenges in all its steps. In this article, I’ll talk about how the design delivery step, specifically in an area of what I call Component Spec, bundles up all the necessary information to craft a cohesive and comprehensive component set to be used as part of a product’s design system.
Often, beginner designers who are not yet familiar with the “laws of physics” in web and native app development tend to create product designs that showcase a flow. Their deliverables typically consist of a series of screens, ideally connected by a flow from start to finish.
Most of these designers don’t consider how their designs will be implemented, which is crucial. In my view, this awareness distinguishes junior UX/UI designers from mid-level ones. Eventually, not all of the designer’s wants and dreams can be realized in development — not just because they may be impractical with existing tools, but also because they often overlook edge cases and responsiveness. This can lead to reliability issues and unexpected behavior when the developed pages or components face real-life scenarios, interact with other elements, or encounter more content than they were designed to handle.
Creating designs that make sense inside the structure and limitations of web and native app development differentiates a junior UX/UI designer from a mid-level designer.
Have you ever come across a website, SaaS platform, or product with obvious visual bugs? I certainly have, often remarking, “What poor development!” However, the issue usually isn’t with the developers’ decisions; instead, I believe it stems from a lack of clear design and product definition.
Such issues should not exist; they create roadblocks in the user experience, hindering the product’s ability to deliver value and increasing costs in terms of man-hours for the development team. Developers must identify the problem, correct the relevant code, test it, and then merge it into production. A significant amount of time is wasted on fixing these issues, particularly when they occur in reusable components. Proper design definition could have prevented this. When implemented at scale within a design system, these problems can be minimized, helping to avoid poor experiences and unexpected behavior across the product.
In a typical design system, you’d find instructions for designers on when and how to use the available components in their designs, often providing edge cases, different variants, and copy guidelines. Designers, as consumers of the design system that need to use it, will face a set of rules and limitations that will help them while building designs, but that is just on the surface level. What about developers? They are also a type of design system consumer. They will take the design instructions and build the pages and screens with those components. Can the design document provide sufficient documentation when creating a new component?
Consider one of the most basic, if not the first, components any designer will create in their design system journey — The Button.
We must decide on a few characteristics of that button before using it as a shared component within our design system. Name a few: size, color, icon, radius, typography, padding, gap. That is even before we discussed different size variants or the actual button usage!
In the past, designers usually provided a static image that reflected the layout and size of the component. You can usually still find this kind of detailed image on beginner designer groups on social networks. Back then, that may have been fine, but today, it is far from a complete list of instructions for the development of a UI component.
The example above contains the bare minimum needed. When a developer approaches the development, in this case, a button, they must define many other parameters. If the designer hasn’t defined them, where should the developer get them from? I’m writing this article in the year 2024, and fortunately for our developer, Figma’s dev mode can come to our help!
Like the confused IKEA man who can call the IKEA store for help, the developer can consult the dev mode properties panel to get (most of) the necessary instruction he so desperately needs.
Can’t Dev mode suffice?
While Figma’s Dev mode provides much information about a component’s layout, position, style, and typography, it will do its best to show relevant information for a developer to follow. By that, I mean that Dev mode doesn’t have all the tools, measurements, and capabilities to display code effectively. Seasoned developers will use the properties as a guideline but will prefer to write the code differently.
Undefined outcomes
Designers might want (or even need) a canvas when they are messing around, trying things out, brainstorming, discussing, showing variations to stakeholders etc.
Erez Reznikov, Evolving beyond a canvas tool, Substack
As Erez Reznikov points out, designers thrive with the freedom of working on a “canvas” rather than being bound by the “gravity” of the DOM (Document Object Model) while exploring creative ideas.
Moreover, most UI design tools, by their nature, allow designers to create screens in a way that may lead them to overlook the need for their designs to function within the ‘laws of physics’ that govern web and native platforms. That is just how these tools work.
Designers may sometimes overlook the fact that their designs need to function within the ‘laws of physics’ that govern web and native platforms.
This fact may lead to poorly defined components, ending up in unpredictable edge-case behavior. For example, a typical button might look great in one state but lack the necessary adaptability when dynamic content is introduced. For instance, what happens when the parent container narrows, and the button no longer has enough space on the sides? Should it:
- Line break but keep the previous height?
- Adjust the height for more lines?
- Extended the text outside the borders?
To resolve this unexpected behavior, I recommend implementing a rule that truncates the button’s text with an ellipsis and prompts a tooltip with the complete text on hover.
However, these definitions are not shown in Figma unless specifically defined by the designer and written explicitly. These definitions might be overlooked because the component was built on a canvas, where the constrains of layout may not be enforced.
When inspecting the button, Figma will provide information about its layout. Considering the padding and height properties, Figma tells us that the padding is padding: 0px 24px which means that it has 0px on top of a button and 24px to the left and right. The more robust way for this component to be written is with the padding-inline property since that component’s height and the inner elements’ position is already defined.
padding-inlineis a CSS logical shorthand property that combines thepadding-inline-startandpadding-inline-endproperties into a single declaration, creating space around an element’s content in the inline (left and right) direction.
— Joel Olawanle on css-tricks.com
In addition to the above, designers may not utilize the full range of properties and parameters that real development offers. For example, Figma utilizes Auto-layout as a Flexbox Layout, allowing child elements to be fixed with px or set to fill or hug. Countering that, designers are not usually exposed to actual development, which limits their knowledge about other options; the CSS Grid Layout allows users to input px, percentages, or fr units, allowing for more control over the outcome of dynamic content.
