How to create Figma design loved by developers
I recently gave a presentation at Figma Config 2022 titled “How to Create Figma Design Loved by Developers”.
Since the presentation was done in Japanese and I wanted to share the content to more people, I decided to transcribe the presentation in English. Hope you would like it!
What is “Design loved by Developers”
I believe there are two big criteria, and they are
- Easy to grasp the intent of design
- Easy to update implementation when the design changes
I believe that the former can be achieved by Structured Design, and the latter by Design System.
Structured Design is a concept that was introduced in the keynote of Figma’s design system conference called Schema in 2021. There are two forms of design: Freeform and Structured.
Since there is no strict definition of the term, I will speak from my understanding that Freeform refers to an unstructured design that satisfies only the appearance, while Structured design defines behaviors other than appearance and organize design data. (I will discuss about “What exactly is structured?” in the section “Tell the intent of Design” in more detail)
Why do we need different forms of design?
So why do we need two different forms of design, Freeform and Structured?
I believe it is because two purposes are required for the artifact called “design”.
One is to verify the hypothesis of UI.
At this stage, the goal is to create various UI plans and make a decision to “Let’s go with this UI!”. Since the form of the UI has not yet been determined, and since it will be scrapped and built repeatedly, making design structured may be useless or even a hindrance.
The other purpose is to communicate the design intent to the developer.
The final goal of design is to be implemented into a working product. In order to achieve this smoothly, the design should be structured so that it is easy to obtain the necessary values when implementing the design, and it is desirable to make it difficult to create misunderstanding.
In addition to this, Structured Design also contributes to the maintainability and quality of the design itself over the long term.
I believe that the ability to seamlessly realize these two forms of design is one of the reasons why Figma is loved.
In this article, I would like to talk about tips for “tell intent of design” which I mentioned at the beginning of this article, i.e., what you should do to make your design Structured from Freeform, and tips for “make Design
easy to update” i.e., how to systematize your design.
Tell the intent of Design
In order for a developer to turn the design into an actual working screen, various values must be reflected in the code. It is important to be able to communicate “intent of design” speedily without discrepancies.
What is the “intent” of design?
I am sure there are many other details, but I think there are four major categories which are:
- Visual properties — colors, typography, etc.
- Layout
- Responsive
- State
1. Visual Properties
There’s no much thing to worry about visual properties since they can basically be read from Figma’s design pane as long as you do nothing strange.
However, if the line-height is not set properly, there may be a discrepancy between the apparent margins and the margins that can be read from canvas, so be careful about this.
It is more important for engineers to be able to use Figma, so please refer to the article I wrote on this subject.
2. Layout
In terms of layout, I believe it is important to “build layers like code” while making appropriate use of functions such as Auto Layout.
This is because it is possible to avoid anti-patterns that make it difficult to read the intent of design, and to prevent designs that are difficult to implement.
For example, I have encountered the following anti-patterns, where multiple lines of text are represented by line breaks and could not read a value of margin.
Below paddings are not set, leaving room for interpretation by the developer (i.e., the actual implementation may not be what the designer intended), which may lead to lower maintainability in the future.
Then what should we do in order to be able to build layers like code?
(by the way by using term “code”, I only mean the visual part which is HTML and CSS for Web, not including JS.)
A lot of things resemble between Figma and code, for example, Auto Layout is almost the same as Flexbox in CSS.
Constraints also work to specify relative width/height and work like position:absolute.
Through learning code, I think it will lead to better design whose layers are more closely structured to how the HTML tags are structured.
Another important way to get feedback is to try to implement your own design.
However, since you designed yourself and know the details of intent of design, it is better to get feedback from other developers, and think about whether there are any rooms for improvements to the design where there are differences from the finished product.
3. Reponsive
When you hear the word “responsive,” you probably think of having designs for different breakpoints, such as Desktop, Tablet, Mobile, and so on.
However, in addition to this, the code also needs to define the behavior when the screen size changes even within the same device type.
This can be defined using Constraints, which define how the layers will (or will not) change when the parent frame changes size.
Also the property Resize in Auto Layout allows you to specify whether the width and height should change according to the height of the child or have fixed values.
4. State
UI is dynamic and has many different state.
The UI Stack is a well-known diagram, and states such as Blank (Empty), Loading, and Error are often missing and are not discovered until the engineer implements the UI.
In addition to this, it is also useful to create prototypes to make user transitions easier to see. Prototypes are basically used for testing UI, but from an engineer’s point of view, it is also helpful to see transitions by interactions.
Also you may like to use plugin called ProToFlow, which can display arrows as prototyped in the design pane so developers do not have to switch to prototype pane to see transitions.
Variants and Interactive Components are also important.
Variants can represent multiple states of a component, and Interactive Components can show transitions among those states.
Continuously Refactor Design
I have talked about various things, but some of you may be wondering, “Do I have to do all of these things at once?”
my answer is “No, you may do it progressively.”
I would like to explain that it is not necessary to do everything from the beginning, and that doing so will lead to the maintainability of the design itself.
The first thing you should be aware of is to separate the Design phase from the Handoff phase.
The goal of the Design Phase is to make a decision to “Let’s go with this UI” for the purpose of testing UI hypothesis, as explained at the beginning of this article.
In this phase, we create lo-fi and hi-fi prototypes, and do not put too much effort into detailed appearance or making design structured.
After that, we move to the Handoff Phase, where we make design structured and put some memos so that developers can easily understand design.
I call this kind of activity to make the design itself more maintainable “Refactoring” of design.
Also, in the engineering culture, there is a practice of having a “debt day,”(I apologize if it only exists in Japanese engineering culture) a day when we work only on eliminating debt.
I think doing the same thing to design would be effective to making the design more maintainable.
It is difficult to maintain an optimal design at all times, and I think it is an everyday occurrence that it becomes less optimal due to new requirements. Therefore, I think it would be good if we can create a mechanism for improving design based on the premise that “debt always pile up”.
Make Design easy to update
Now, let’s talk about the next major topic, “Make Design easy to update”. From the developer point of view, “design that is easy to update” means “it is easy to make changes to code when design is newly created or updated”
To achieve this, it is important to systemize the design, in other words build design system.
Why is making design system beneficial to developer as well?
Because when design is systematized, a consistent UI is created using already defined design tokens and components, which makes coding simple and fast because the code can also reuse resources already defined.
Therefore, we will discuss the following two points that can be done when systematizing this design in Figma.
- Design Tokens
- Components/Variants
Design Token
First of all, “what is a design token?” The definition is as follows.
Design tokens are indivisible pieces of a design system such as colors, spacing, typography scale.
Design Tokens W3C Community Group
https://github.com/design-tokens/community-group#design-tokens
For more details about design token itself, please read great articles as below.
One way to achieve this in Figma is to use the standard feature called Style.
It is important to make use of this, but it does not have a functionality to export/import this settings so that they can be used in code.
So I highly recommend using plugin called Figma Tokens.
It allows you to define various values that you cannot define as style in Figma such as spacing, border-radius, etc., and also allows you to output as JSON, sync with GitHub, etc. It is fully equipped with features for utilizing design tokens, so please try it out.
Components/Variants
Figma allows you to define components and multiple states of those components as Variants.
And in defining this component, it is important to align the granularity, name, and properties between design and code. This is partly because these are meant to be the common language of design, and partly because if they are out of alignment, the complexity for updating code may increase when the design is updated.
The tips for designing components include “think about the state that defines the change of the component” and “make it a single responsibility,” and I think it is very effective to design this together with the developers.
The above component design tips are exactly what developers think about in their daily work, so I think that involving them will lead to a better component design. Also, it is a good way to reduce rework by making sure that the designers are aware of each other’s work at the design stage.
Communication
So, having talked about various technical stuffs, I would like to conclude by discussing communication.
The reason for mentioning about communication is to convey the following points.
- The best form of design differs from organization to organization.
- Don’t overdo it with design, but be flexible in areas that can be done by communication.
First of all, every organization has its own unique characteristics, some developers are familiar with design and Figma, some are not, some have a small number of developers, and some have huge number of developers and teams.
Therefore, the extent to which the design is made varies from organization to organization.
I think it would be good to communicate and explore the best form of design for each organization.
For example, if something is difficult to be expressed in Figma, it can be done by simply pasting a memo on it.
It is also useful to hold a handoff meeting, which is a synchronized meeting when the design is handed off to the developer.
Also, as with the component design mentioned earlier, having the design reviewed early in the design phase from the perspective of implementability can prevent backtracking and speed up the total delivery process.
Structuring the design is a very important activity, but I think it would be good if we could make it flexible without being too rigorous.
Conclusion
The way a design is created can affect the overall speed and quality of product development in both positive and negative directions.
Structuring the design and making it maintainable makes it easier for developers to understand the intent of design and leads to faster and higher quality implementation.
Also, how far the design should be structured depends on the organization, so let’s communicate with each other to find the best form of design!
