Recap: Schema by Figma Tokyo 2022

Young
BedroomConf Korea
Published in
6 min readDec 25, 2022
The conference venue was decorated with dreamy lighting

Recently, I had a chance to attend the Schema by Figma Tokyo 2022 in Shinagawa. Attendees were selected among those who applied for the entrance pass before the event. (And it was free! 🤑)

Most of the attendees were Japanese (of course), but some foreign attendees, too, including the Figma US office people who came to Tokyo for a business trip for this event. The staff distributed the name tag and swags, which were cute badges and a big wide violet canvas bag that you could put anything inside. Quite practical.

All the sessions were engaging. I want to summarize some of the talks in this article to fulfill my knowledge desire, which is quite a selfish reason. Please understand it 🙏😛

The Keynote by Sho Kuwamoto

https://youtu.be/EKIj_-QkbZQ

One of the Figma people at the event was Mr. Sho Kuwamoto, VP of Product at Figma, who moved to the US from Japan when he was 5. He did the keynote by briefly explaining the short history of the Figma Japan office, introducing himself, and his career journey. Before Figma, he worked for various web-based companies, including Adobe for Dreamweaver. He said,

I eventually joined Figma 7 years ago, and the ideas I learned back in Macromedia and Adobe informed some of our thinking at Figma.

This reminds me of the recent Figma acquisition by Adobe.

Early in the design, two types existed. For freeform design, people don’t know what to make and just freely think about what they want to make. After the design is refined, they think about the implementation, and it’s called ‘structured design.’ Freeform design and structured design going back and forth. It’s not a linear process. Both of them are equally important for designers. Today, those ideas are still relevant, but things are more complicated. So the design systems today are very advanced. It’s hard to manage.

There’re three complex things that we need to maintain in the design system.

  1. Layout complexity: If it’s two layouts, it’s not that difficult, but sometimes you have lots of layouts, and it’s hard to maintain in the design system.
  2. Theming complexity: Many design systems only have one or two themes(light mode and dark mode), which is simple. However, some DS have more themes. For example, the main for the company and each theme for each product. You could also have a mobile theme.
  3. Process complexity: Design systems are not just about components or tokens. It’s also about documentation about the usage. It can be anything that makes your team work more efficiently. When the team is small, the process might not be necessary. But if teams get bigger, it becomes essential.

So, what are the ideas to manage those complexities? Here’re two.

  1. Testing for Design (In short, visual regression testing.)
  2. Branching and Merging

Those ideas come from the code; he said it’s not coincidental. The world of design is moving toward the world of collaboration. The early purpose of the design system was to reduce the chance of making mistakes. (i.e., reducing the number of font weights or color codes) But he didn’t like the framing because it sounded like restricting people. So the new purpose of DS, he suggests, is ‘reducing the friction to increase creativity.’

Openness and the use of Figma in solving social issues with Nana Yokota & Noriyasu Vontin

https://youtu.be/yj6T-fO49yo

“Design system is not only for designers.”

Nana is a design advocate from Fujitsu and a former UI designer. She and Noriyasu, a design manager at Fujitsu, explained how Fujitsu is doing the social service design and how the design system contributes to this process. Below is their design approach:

💡 Social issues → Design → Engineering → Service

The Fujitsu Data Design Committee selects the social issue to solve. The committee consists of in-house designers of 23 domestic companies.

The ‘Design → Engineering’ step in the design approach can be rephrased as ‘UI/UX Design → Development.’ And design system comes into this phase, and the main stakeholders are designers and developers.

The number of developers is significantly higher than the number of designers, so that designers can join every project. That’s why the design system exists; to help developers make the product with a consistent UI/UX without deep design knowledge.

But how can we judge if that design is good or bad? For this, they are making the v4. Fujitsu design system is now v4 since the first version was released in 2014. They enhanced the a11y and consistency in 2015 and applied the light/dark theme in 2018 for v3. For v4, they’re using design tokens and developing interactive components.

And to make the developers feel more engaged in the design system, they created a mechanism that consists of two parts. One is ‘outgoing development(発信形),’ and the other is ‘participatory involvement(参加形).’ The outgoing one is the one-direction announcement from the design system team, such as the specification announcement.

The participatory one is for making the intake process more accessible, for example, through feature requests. Making precedents(事例) for permeating the design system is essential. After making the precedent, they made it as an article and shared it with the company.

The design system needs to be opened for everyone. And this openness is also required to solve social problems. Because to implement the social issue solution, companies, governments, and citizens need to work together.

Workflows for Building Design System in Figma at Yahoo Japan with Takanori Hirohashi

https://youtu.be/lNHax1LT0Ns

Takanori-san did a presentation about the operation of Yahoo Japan’s company-wide design system called ‘RIFF’. RIFF has two objectives. One is to improve the UI design quality, and the other is to improve the efficiency of design work so that, eventually, everyone can make the Yahoo Japan-ish UI easily.

Yahoo Japan has nearly 50 products and about 400 designers in the company. 13 designers out of 7,500 people are working on the company design system. There’re sub-teams for three products: styleguide/design kit/dev kit.

There were two problems in the design system operation. The first was the company-wide design system’s low adoption rating, and the second was the operation cost limit.

So the team solved those problems with three approaches. First, they started small by cooperating with only a few services, aiming to resolve the service’s problems. Second, they built close communications through weekly representative meetings and the public channel. The last is pair design for improving an individual’s skills and work effectively.

There’re still many services that are not in the scope of the design system, such as apps for mobile platforms. The design system team will try to introduce it to those services.

Design System and Systemization of Thinking by Sukeharu Ito

https://youtu.be/KYMpp9LL6W4

The designer from teamLab did an impressive presentation. They started as a design solution company even though they’re now famous for the art exhibition. 700 out of 900 people in teamLab worked on the solution part and did more than 100 projects. Designers in the solution part work closely with engineers who are 70% to 80% of the part. Only 20 out of 700 are designers.

For the efficiency of the design work, the importance of design systematization is increasing among the team. So the teamLab people thought about creating the design kit/guideline/component or something like DS for similar projects. Still, it wasn’t easy to make because each project has a different direction. For example, only the level 1 atom parts can be generalized if we consider the atomic design.

Even though they don’t have a design system, they want to systematize the thinking process. It’s rather about a mindset or culture. It’s about ‘principle(原則) → patterns(パターン) → design(設計) → make it as a knowledge(ナレッジ化).’

They keep running this process until they reach the essential(本質) solution. Then, they realized that sometimes the result of this process is similar in totally different projects. Finally, they make these findings into knowledge and keep accumulating them, aiming to systemize those. This could also be the ‘design’ system if thinking itself is the essence of design. How? By communication. Even though the essential solution is universal, teamLab will create various wheels optimized for each project for users.

Before Finish

These days, I’m more interested in the talks, which can help me shape my mindset, not only explaining the specific way of doing something. All the methods are just tools to achieve the intention or the essence, which are the things that matter the most in the end.

It was a great chance to learn how designers approach their work since I was an alien from the engineering world 👾. But I think in the future, we will borrow more concepts from each other’s world and become more deeply intertwined and collaborate and communicate heavily, so I think it’s worth spending some time to study about their language.

--

--