フリマアプリ：デザインシステムのリニューアル
Client
Mercari, Inc.
Team
PM
EM
Director
Designer x3 (me)
Engineer x7
Platform
Web
iOS
Android
Tool
Figma
Adobe CC
Jira
Confluence
Slack
Timeline
2024.3-2024.12
Overview
日本最大のフリマサービス「メルカリ」におけるDesign System 4.0の構築案件です。既存のDesign Systemをベースに、iOS・Android・Webの3プラットフォームを横断し、今後の国際展開や多様な利用環境にも対応できる設計基盤として再構築されました。
私はパートナーデザイナーとして、Design Token の再構築やコンポーネントの整理・再定義、デザインドキュメントの整備などを担当しました。
Background
クライアントはサービスの国際展開を控えており、既存のDesign System（DS 3.0）ではそれに対応しきれない状況に直面していました。 このプロジェクトでは、より柔軟で拡張性の高いDesign Systemの再構築が求められていました。
課題
類似パターンが乱立し、Component構造の整合性がない
拡張性のない設計とCustom Componentの氾濫
すべてのデザインデータが1つのFigmaファイルに集約されており、Figmaファイルの構造が非効率
全てのcomponent master dataとドキュメントは1ページに存在
Goals
現状の課題を踏まえ、Design System 4.0では以下のような目標を設定しました。 最大の目的は、将来の機能拡張や複数プロダクトへの展開を見据えた、柔軟で拡張性の高いDesign Systemの再構築ことでした。
ビジュアルスタイルの一貫性を維持しつつ、構造を再設計
UX改善や新機能追加に対応できる柔軟な設計
マルチプロダクト対応を前提とした拡張性の確保
WCAG AAを目標にアクセシビリティの向上
Design Systemのユーザビリティ向上
Challenge
Design System 4.0の構築は、単なるデザインの刷新ではなく、設計思想の再定義と運用体制の整備を伴う複雑なプロジェクトでした。
限られたスケジュールの中で、システム全体の設計と構築を同時に進行する必要があった。
開発チームの共通言語は英語で、非英語話者が多いデザインチームとの連携に工夫が求められた。
DS 3.0のドキュメントが不十分で、再設計にあたってはすべての既存・Custom Componentの仕様確認が必要だった。
運用体制が未整備な状態で、機能開発と並行して設計・問い合わせ対応・ルール整備を行わなければならなかった。
My role
Design Tokenの設計・命名
既存およびCustom Componentのリサーチと構造設計
Component SpecやDesign Guidelineなどのドキュメント作成
アクセシビリティ対応に向けたリサーチと設計反映
Approach
複数の課題に対応しながら、拡張性・運用性・整合性を重視したシステム再構築が進められました。
Design System Strategy
今回の設計指針として、Atomic Designのフレームワークを採用しました。しかし、なにがComponentであるべきか、どんなComponentがDesign Systemとして管理されるべきかその境界を示してはいません。
なので、Design SystemのComponentに該当しないレイヤーを独自に設計しました。具体的には、Blueprint と Custom Component という2つの枠を定義しました。
Blueprint
構造上はComponentとして管理しないものの、デザインパターンとして汎用されるUIを指します。Figmaのデザインデータから、iOS・Android・Webのソースコードまでを包括的にカバーする「設計図」として提供されます。
Custom Component
Custom Component は、シンボルをディタッチしたり、Figma上で制約をかけきれないプロパティ（strokeなど）を含む、仕様外のカスタム要素を指しています。
一時的に作られたComponentとしてよくあるため、将来的にそのスペックがDesign Systemでサポートされるか、或いはUIの仕様を調整することで薄くなっていきます。
こうした構造により、Design Systemとしての一貫性を担保しながら、必要に応じてシステム外の柔軟な対応も可能にしています。
Design Token
まず、最初に着手したのはDesign Tokenの再整理でした。
旧バージョンにもTokenは存在していましたが、アクセシビリティへの配慮不足やTypographyの用途の曖昧さ、一部Tokenの形骸化など、いくつかの課題が見られました。 これらを踏まえ、既存設計を見直しながら再設計を行いました。
特にTypographyに関しては、Typography は文字サイズの基準のみが定義されており、どの文脈でどのサイズを使うべきかが不明確でした。そのため、特にComponent内では、同じ役割のテキストでもサイズがバラバラに使われるケースが多く、デザイナー間で混乱が生じていました。
4.0 では、この問題を解決するために、従来のサイズ基準の定義をGlobal Tokenとして踏襲しつつ、用途に応じたSemanticレイヤーを新たに定義しました。
なお、全体的に開発との整合性を保つため、Tokenの命名ルールはエンジニアチームと事前に認識をすり合わせまして、下記のルールを定めました。
platform - category - concept - variant - state
たとえば、上記の図で登場したButtonのラベルのTypographyは、WebでのToken名は「web-typography-button-large-bold」となります。
このルールにより、役割や用途が一目で分かるだけでなく、デザインと実装の対応関係も明確になり、コミュニケーションや運用コストを大幅に削減できるようになりました。
Component
旧バージョンは、数が多くのComponentが、用途ベースで同一レベルにグルーピングされていました。そのため構造的な関係性が見えづらく、全体像を把握するのが困難な状態でした。
そこで今回の再設計では、Atomic Designのフレームワークを採用し、Design System ComponentをAtom / Molecule / Organismの3階層に分類しました。
Atom Component
最小単位のコンポーネント要素、再利用性が高く、他の階層のベースとなる。
Molecule Component
複数のAtomを組み合わせて、単一の機能や役割を持つ小さなUIブロック。ある程度の意味や機能を持つが、まだシンプル。
Organism Component
複数のMoleculeやAtomを組み合わせて、明確な役割を持つ独立したUIセクションを構成する。画面単位の再利用が可能。
こうして階層ごとに分類することで、Componentの構造が明確になり、誰にとっても理解しやすい体系となりました。
再利用性や拡張性も高まり、他国展開や新サービスへのスムーズな転用が可能になります。
Component Design
具体的にどうやって既存・Custom Componentを抽出し、新たの拡張性があるComponentに設計しているのか？私が担当した「Row」と呼ぶ一連のComponentを一例として説明します。
現状リサーチ
複数のページで頻繁に使われている「Item Object」と呼ばれるComponentは、新機能の開発が進むにつれて、3.0で定義された仕様だけでは対応しきれなくなっていました。その結果、仕様外のCustom Componentが多数発生している状況です。
さらに、「OOXX Row」と呼ばれる、ビジュアルは似ているものの挙動が異なるComponentも多数存在しており、「Item Object」とレイアウトや挙動が重複するようなケースも見られました。
そこで、これらを含めて要素を抽象化し、レイアウト軸と挙動軸で整理して現状を洗い出しました。
レイアウト軸軸と挙動軸で現状洗い出し
議論の繰り返しで結果を導く
結論を簡単に決めたわけではありません。この一連のComponentは構造が複雑で、膨大なページに使用されています。さらに、3つのプラットフォームに対応する必要があり、技術的にも構造の統一は容易ではありませんでした。デザインを提案し、開発と議論を重ね、試作を繰り返す。このプロセスを何度も繰り返すことで、最適な構造に辿り着きました。
結果として、一番基盤となるのはレイアウトを制御するComponentです。このComponent自体には具体的なパーツは含まれず、レイアウトだけを目的としています。
レイアウトを制御するComponent
その上で、Row全体のデザインを制御する、挙動のないMolecule Component「Base Row」を定義しました。その上に、具体的な挙動を加え、それぞれの役割に応じたOrganism Componentを構築しています。
こうした構造により、Componentの妥当性を担保しつつ、全体のデザインの一貫性も維持できます。さらに、さまざまなユースケースに対応できる拡張性の高いComponent構造としています。
3.0に存在していた「Item Object」は、4.0 ではこのような構造に再設計されました。
こうして既存のComponentや各種Custom Componentを吸収しながら、iOS・Android・Web の 3プラットフォーム間で一貫性を持たせ、将来のサービス拡張にも柔軟に対応できる設計としています。
Document
拡張性を重視したComponent設計を行ったことで、各コンポーネントの用途や使い方を正確に伝えるドキュメントの整備が不可欠となりました。
旧バージョンでは、Masterデータとドキュメントが同一のFigmaファイルに混在しており、情報探索のしづらさが課題となっていました。そこで今回の再構築では、Masterデータとドキュメントを分離し、情報の安全性と参照性を向上させました。
また、ドキュメントには開発と整合性の取れたDesign Specに加え、Componentの利用意図や注意点をまとめたデザインガイドラインも併記することで、チーム全体が共通理解を持てるよう配慮しています。
Design Specの一例（クライアント公開資料より）
Design System運用体制
従来、Design Systemを専任で担当するチームは存在しておらず、旧バージョンはドキュメントだけに頼った運用が続けられていました。
そのため、コンポーネントの設計ルールや使用可否の判断が属人的になりやすく、整合性の維持が困難な状況でした。
この課題に対応するため、今回のプロジェクトではDesign Systemチームによるレビューのルートを提案し、デザインチーム内に運用体制の土台を構築しました。
Achivement
本プロジェクトでは、Design Systemの構造、設計思想、運用体制を見直すことで、海外展開や将来的な拡張にも対応可能な、持続性と整合性を兼ね備えたDesign System 4.0を構築しました。
Atomic DesignをベースとしたComponent構造の再定義により、再利用性を高める設計と拡張性を実現
設計と実装の整合を担保するDesign Token体系の再構築により、iOS・Android・Webの3プラットフォームで一貫した実装が可能に
ドキュメントとMasterファイルを分離した運用構成により、開発・非デザイナーを含めたチーム全体でのスムーズな参照と理解を実現
レビュー体制と運用ルールの導入により、属人性を排除し、今後のサービス拡張やグローバル対応を見据えた持続可能な体制を土台作り
これにより、Design System 4.0は、変化の大きい市場や複数言語・文化への対応を前提とした、柔軟かつ強固な設計基盤として機能し始めています。
