Overview
日本最大級のフリマサービス「メルカリ」のDesign System 4.0構築に、パートナーデザイナーとして参加しました。
Design Tokenの再設計、Componentの構造の再定義、アクセシビリティ対応の調査と反映、Design Spec・Guidelineの作成を担当しました。
Challenge
国際展開を控え、Design System 3.0では変化に対応できなくなっていました。
- 類似パターンとCustom Componentが乱立し、Component構造に一貫性がない
- すべてのMasterデータとドキュメントが1つのFigmaファイル・1ページに集約され、管理も参照も難しい
- ドキュメントが不十分で、既存Componentの仕様そのものが把握しきれない
ビジュアルの一貫性は保ったまま、構造・設計思想・運用体制を同時に再設計し、WCAG AA水準のアクセシビリティを実現することが求められました。
Approach
Design System Strategy
Atomic Designを設計指針とし、用途ベースで同列に並んでいたComponentをAtom / Molecule / Organismの3階層に再編しました。ただしAtomic Designは、何をDesign System Componentとして管理すべきかの境界までは示しません。そこで、その外側にBlueprintとCustom Componentという2つのレイヤーをチームで定義しました。
Blueprint
Componentとしては管理しないが、汎用されるUIパターン。FigmaからiOS・Android・Webのコードまでを包括する「設計図」として提供します。
Custom Component
Componentの仕様では対応できず、機能ごとに個別に作られたUI要素。将来的にDesign Systemへ取り込むか、UI仕様の調整によって段階的に減らしていきます。
Design Token
旧Tokenには、アクセシビリティ配慮の不足、一部Tokenの形骸化、Typographyの用途の曖昧さといった課題がありました。アクセシビリティについては、カラーをWCAG AAのコントラスト比を基準に再調整し、文字の最小サイズも定義しました。
Typographyは、サイズ基準のみが定義されていたため、同じ役割のテキストでもComponentごとにサイズがバラバラでした。4.0ではサイズ基準をGlobal Tokenとして残し、用途を示すSemanticレイヤーを追加しました。
命名ルールはエンジニアチームと事前にすり合わせ、以下に統一しました。
platform - category - concept - variant - state
たとえば、WebのButtonラベルのToken名はweb-typography-button-large-boldとなります。
Token名だけで用途と実装先が分かるため、デザインと開発の確認コストを削減しました。
Component Design
私が担当した「Row」系Componentを例に、既存・Custom Componentをどう整理し、拡張可能な構造へ再設計したかを紹介します。
現状リサーチ
頻繁に使われる「Item Object」は、新機能の追加に3.0の仕様が追いつかず、Custom Componentが多数発生していました。
さらに、見た目は似ていても挙動が異なる「OOXX Row」も多数存在し、Item Objectとレイアウトや挙動が重複していました。
これらを抽象化し、レイアウト軸と挙動軸で整理しました。
レイアウト軸と挙動軸で現状を整理
何度も覆った構造
構造は何度も作り直しました。実装途中で技術的に実現できないと分かりデザインを変えたこともあれば、新たなパターンが見つかり、統合し直したこともあります。
こうした変更を繰り返す中で、レイアウト・デザイン・挙動・用途を層として分離し、1つの変更が他の層に波及しない構造に辿り着きました。
一番基盤となるのは、具体的なパーツを持たずレイアウトだけを制御するComponentです。
その上に、挙動を持たずRow全体のデザインを制御するMolecule「Base Row」を置き、挙動ごとのOrganism（Layer 3）、用途ごとのOrganism（Layer 4）を積み上げました。
3.0のItem Objectは、4.0では以下の構造に再設計されました。
これにより、既存・Custom Componentを吸収しながら、3プラットフォームで一貫した構造を実現しました。
Document
拡張性を重視した構造だからこそ、使い方を正確に伝えるドキュメントが欠かせませんでした。
Masterデータとドキュメントを分離し、Masterの誤編集を防ぎつつ、必要な情報を探しやすくしました。開発と整合したDesign Specに加え、利用意図や注意点をまとめたDesign Guidelineを併記しました。
Operations
これまでDesign Systemの専任体制がなく、設計ルールや使用可否の判断が属人化していました。今回のプロジェクトを機に、Design Systemチームのレビューを経るルートをチームとして提案し、運用体制の土台を作りました。
Outcome & Reflection
構造・Token・ドキュメント・運用体制を見直し、iOS・Android・Webで一貫したDesign System 4.0を構築しました。
私自身は、Rowの構造を何度も作り直す中で、開発の視点から自分のデザインを問い直すことを学びました。どう実装されるのか、3つのプラットフォームで成立するのか、拡張しても破綻しないのか。設計を決める前に、こうした問いを自分に向けるようになりました。
Design System チームの engineering manager をしている vwxyutarooo です。私達はメルカリのアプリ・ウェブ開発に利用している Design System をフルリニューアルしました。
mercari.com