デザインシステムでデザインが“ととのい“はじめた

2024-12-22Advent Calendar 2024, デザイン, デザインシステム, デザイントークン

この記事はレコチョク Advent Calendar 2024 の22日目の記事となります。 

こんにちは。レコチョクの河野です。
日頃、プロダクトデザイナーとして戦略の階層から表層のUIデザインやデザインシステム構築まで幅広く担当しています。また、レコチョクのグループ会社である株式会社エッグスに出向し、事業部のメンバーとしてサービス企画に0→1のフェーズから関わっています。

2024年の個人的ベスト音楽エピソードは「勤続5年で取得できるリフレッシュ休暇で4泊5日の沖縄旅行に行き、Nintendo Musicで配信されている『あつまれどうぶつの森』のBGMを現地で聴き続け、心身ともに島人になりきる術を体得した」でした。ちなみに、一番好きなトラックは「午前5時（晴）」です。よろしくお願いします。

さて、今回は、前年度のアドベントカレンダーの投稿記事「【デザイン】新規サービス開発でデザイントークンを導入してみました！」から引き続き、デザイントークンでデザインやアプリ開発が改善された事例を紹介しようと思います。前回は新規サービスであるP!TNEのアプリでのデザイントークン構築を題材に取り上げました。今回は既存サービスであるEggsのデザインリニューアルとデザイントークン構築の過程について紹介できればと思います。

なお、こちらの内容は先日、株式会社パイオニア様と合同で開催した「レコチョク×パイオニア合同勉強会 #3」で登壇した際の内容となります。勉強会の様子は別記事「パイオニアさんと第3回合同勉強会を実施しました！(2024年 12月)」でレポートしているので、こちらもご覧ください。

Eggsについて

Eggsとは「多様な音楽があふれる未来をつくる。」をミッションに掲げ、レコチョクのグループ会社、株式会社エッグスが運営しているインディーズアーティストとリスナーを繋ぐプラットフォームです。

Eggsのサービス開始は2015年です。サービス開始から約9年の月日が流れ、システム的に技術的負債が蓄積しているような状態でした。そんな技術負債を解消するために約1年ほど前に技術負債プロジェクトをキックオフさせ、プロダクトをグロースさせていくため基盤を固めるための取り組みが実施されることになりました。

負債解消プロジェクトの開始前にビジネス・エンジニア・デザイナーが集まって、それぞれの立場から課題を洗い出し、認識合わせをする時間を設けました。その中でアプリのUIにおける統一性の担保やエンジニアとデザイナーとの連携について課題感を感じているという声がありました。そこで、技術負債解消の期間においてデザイナーとしても、何か改善につながる取り組みができないかというところから模索したのがデザインシステム・デザイントークンの構築でした。

Saunaについて

前述の経緯を経て、生まれたのが社内でSaunaと呼んでいるデザインシステムです。

Saunaではミッションとして「あらゆる階層のデザインが”ととのう”ための仕組みをそろえる」を掲げています。

デザインシステムの構成要素は会社や目的によって多種多様です。Saunaの構築開始時点ですでに他社では量・質ともに完成度の高いデザインシステムが多数公開されていました。しかし、無闇やたらに先行事例をトレースしてしまうと、合目的性が見えないルールや規則が乱立し、デザインが”ととのう”状態から逸脱する可能性がありました。

そこで、Saunaではデザインが”ととのう”という状態を1段階ブレイクダウンし「どういう状態になっていればデザインが”ととのう”ための仕組みを揃えたと言えるのか」を定義することにしました。その結果「関わる人のあらゆる迷いを減らす」をミッション(目的)に対するビジョン(目標)として掲げることにしました。

ビジョンを明確にしたことで、導入の検討が進んでいたデザイントークンについても「エンジニアやデザイナーの迷いを減らす手段」として位置付けを明確にして実際の構築に取りかかることができました。

デザイントークンとは

デザイントークンとはデザイン要素にトークン(呼び名)を付与して管理する手法です。一般的には、

色の16進数の値や、フォントサイズの数値などのデザイン要素の値に付与するトークン (グローバルトークン)
UI上の分類された文脈に対してトークン (セマンティックトークン)

と2階層に分けて構成する手法が知られています。

詳しい解説は去年のアドベントカレンダーの記事にありますので、ぜひご覧ください。

デザイントークンの構築について

Saunaでのデザイントークン構築当時、社内では新規サービスの立ち上げフェーズにおいての構築の実績はありました。しかし、すでにリリースされているUIに対してデザイントークンを定義するプロセスは初めてでした。P!TNEのように新規サービス(＝新規画面)とは異なり、世に出て実際のユーザーが使っているUIを対象とするため、現状と乖離があるデザイントークンを構築すると、作り手のみならず、使い手であるユーザーにも混乱を招くということが予想されました。

そこで、P!TNEの時も参考にした、putchom氏の「デザイントークンのつくりかた」の書籍にある通り、現状のUIをくまなく観察し、把握するところから始めました。

写真のように観察会として時間を取り、当時の画面の構成で約60画面あるものを1つずつ観察していきました。観察会の中でアプリ全体を見渡しながら、UI上の文脈を整理したり、デザイン上の揺らぎを抽出するという作業を行いました。その結果、現状のトンマナを踏襲しながら統一感を担保できるようなセマンティックトークンを設計することができました。

開発との連携で意識したこと

当初の目標でもある「デザイナーとエンジニアの迷いを減らす」を達成するために、デザイントークンの構築以外にも取り組んだことがいくつかあります。

一般にデザイントークンの真価はデザイン要素に関わる情報のSingle Source Of Truth (SSOT)を実現できることだと言われています。今回構築したデザイントークンにおいても、その価値が発揮できるよう、これまでアプリエンジニアが自前で定義した定数ファイルに定数を手打ちで追加したり修正したりするといった作業を自動化しました。

具体的にはFigmaのVariablesから半自動でSwiftのenumとKotlinのobjectで定数定義を生成できるスクリプトを作成しました。Figma上でのデザイントークンの定義をそのままコード上で参照できるようにデザイナー側で定数ファイルを生成し、Pull Requestを出すような運用でデザイン改修を進めることができました。

あわせて、FigmaのDevMode (開発者モード)を活用し、デザインデータを参照するときに指定されているトークン(セマンティックトークン)がそのまま参照できるようにデザインデータの作り方も工夫しました。

この2つによって、エンジニアが実装する際はデザイン指定の生の値を気にしなくても、Figmaでトークンを確認し、そのトークンをIDE上に入力すれば、デザイナーが指定した値を狙った通りの箇所に適用できる状態を実現することができました。

実際に見られた効果

ここからは当初の目標であった”迷い”は減ったのか？というところを検証していきます。

チームの様子を観察すると、Slack上でのやり取りに変化が見られました。従来であれば、「XX部分のフォントサイズ・太さを教えていただきたいです」「14px Regularです」のようなやり取りがエンジニアとデザイナーの間で度々起こっていましたが、このようなやり取りは目に見えて減りました。また、Figma上のデザインデータと実際にデプロイされたアプリのUIを比較しても、デザイン再現度が向上したように思います。