Figma102_デザインからアプリ実装まで一貫したデザインシステムを構築するベストプラクティス

スケーラブルなデザインシステム構築の実践

Transcript

1. LINEヤフー Media Company, Yahoo! JAPAN Media Services Group しゅーぞー Shuzo Takahashi LINEヤフー Media Company, Yahoo! JAPAN Media Services Group もゆ　Moyuri Iseki デザインから開発まで 一貫したデザインシステムを 構築するベストプラクティス
2. 自己紹介 高橋 柊蔵（しゅーぞー） U LINEヤフー株式会社所W U 2020年新卒入@ U Androidアプリエンジニア＆UI/UXデザイナR U X: shuzo_create 井石 萌佑理（もゆ） n LINEヤフー株式会社所“ n 2023年新卒入” n UI/UXデザイナー
3. やってること Yahoo! JAPANアプリを作っています c 検索やタイムライン、アシスト、フォロー、きせかえ... などアプリ全般の機能開発やデザイン
4. やってること Yahoo! JAPANアプリってなに？ ニュース、検索、天気、雨雲レーダー…etcとヤフーサービスをオールインワンで提供するアプリ 去年リニューアルを行い「トレンドタブ」「フォロータブ」「アシストタブ」を追加しました！
5. UIデザインとUI実装で発生する課題 @LY Corporation UIデザインとUI実装で発生する課題 @LY Corporation
6. よくある課題 事例 UIデザイン→実装で発生しがちな問題 あるある „ UIデザインと実装後でヴィジュアルや仕様が違‘ „ 普通に実装できるつもりでデザインしたが、実装コストが大きい/実装不可なものになってい” „ 表示状態を網羅的に担保できておらず、特定のケースで破綻す „ 些細なヴィジュアルの変更だが、実際のUI構造では表現が困z „ 画面によってUIコンポーネントの設計思想が異なっていて粒度や一貫性がなく、オーダーメイドのパーツが 増える
7. よくある課題 事例 UIデザイン→実装で発生しがちな問題 なぜ発生するのか？ € デザイナーが画面構造や実装時の制約を考慮しきれていなa € エンジニアが「よしなに」判断して実装を行ってしまP € ルールや一般的なプラクティスが定まっていない
8. UIデザインの責務 デザインデータに求められること 実装者の視点で困ること u 画面サイズが変わったときの挙動がわからなp u テキストが溢れたときが考慮されていなp u 端末の文字サイズ変更をしたときに盛大に崩れ8 u ダークテーマのときに考慮されていない デザインデータは画面構造や状態変化を考慮してある= になっているべき 実装可能な作り
9. UIデザインの責務 そもそものUIデザインの責務 ペライチの画像を作るのがUIデザインではない ™ UIのヴィジュアル（モック）は動的な状態変化の一部を「スナップショット」したも† ™ 「UIデザイン」とは時間やユーザーアクションとともに変化する画面を設計することであり、モックの ヴィジュアルを制作することではない 画面構造や状態変化を考慮してUIを設計するのはデザイナーの責務（主に） エンジニアの判断で「よしなに」実装してしまうのはまずい
10. UIデザインの責務 方針 そもそものUIデザインの責務 k 「ペライチの画像（=ヴィジュアルのモック）」で状態変化や画面構造などを全て伝えることは出来なC k でも、仕様書に全てを文章で記述することも出来ないし、適切ではなC k 例えば 「画面サイズが変化したときは左右マージンが8px→16pxにする」などを全て文書で羅列するの は誰も幸せにならない... 現代の複雑なアプリでは、 「ペライチな画面をフォトショで制作」+「文章で補完」みたいな手法はムリがある
11. 仕様書とデザインデータの役割 方針 仕様書とデザインデータの使い分け デザインデータ（Figma）の役割 ƒ 実現したときのヴィジュアルを示t ƒ UIの構造を表して、UIの実装（レイアウト）に必要な情報を示す 仕様書の役割 ƒ 状態が変化する条件や入稿される文言のパターンなどを記述すg ƒ 開発観点では主にドメイン/ビジネスロジックの実装に必要な情報を示す
12. Figmaで構造的に表現するUIデザイン @LY Corporation Figmaで構造的に表現するUIデザイン @LY Corporation
13. FigmaでUI構造を表す FigmaはUIを構造的に表現できる Figmaはペライチの画像を作るツールではなく、UIの構造 が表現できる設計ツールX V 構造的にUIを設計できるため、早期の段階で実現可能 なデザインに落とし込む事ができv V Figmaを共通仕様とすることで、プラットフォーム間で の仕様差異を抑制できる Figmaでデザインの品質を担保して、 それに従って実装する デザインと実装を一致させる 出典：https://www.figma.com/ja-jp/design/
14. FigmaでUI構造を表す 方針 Componentsの基本的方針 q 再利用するパーツは「Components」で作成す‰ q 動的に変化する部分はプロパティにす‰ q 例：タイトルや日付のテキスト、ラベルの可視性な h q 内包するパーツが変わるときは、Instance Swapで 表現す‰ q 各Instanceはプロパティに設定されている項目以外 を独自に変化させてはならない
15. FigmaでUI構造を表す 方針 Componentsの実装 t Componentsの単位でUIコンポーネント関数を実g t Figmaの命名と関数の命名を揃えT t 再利用できるように特定ユースケースに依存しなq t ドメインオブジェクトやUI状態モデルを引数で渡さ ない、中で参照しなq t プロパティを関数の引数にそのまま実装すT t 基本的にはプリミティブな型になT t Instance SwapはUIコンポーネントを関数オブジェ クトとして引数に取ることで表現する
16. FigmaでUI構造を表す 方針 Variantsの基本的方針 € 同じ役割のUIコンポーネントだが、ヴィジュアルその ものが大きく変わる場合（=同一のUIの構造ではない） に使h € 次のケースではVariantsで表さなg € レスポンシブな変化はレイアウトの構造で表現すy € 同一の構造で表せる動的な変化はPropertyで表現す y € ローカルな状態変化はVariantsとPropertyで表現し、 グローバルな状態変化はVariableなどで設定すy € 例えば、ダークテーマや画面サイズなどはVariable で変化させる
17. FigmaでUI構造を表す 方針 Variantsの実装 v 同一のUI構造ではないため、それぞれでUIコンポーネント関数を作成すU v 一つのコンポーネントを動的に変化させるように実装するとカオスになU v 命名はComponents名+Variantsのパターン名にする
18. FigmaでUI構造を表す 方針 TextStyleの基本的方針と実装 タイポグラフィ ‡ 汎用利用できるようにトークンとして定義すD ‡ LineHeightの指x ‡ Figmaでは固定値もしくは比率で指定できD ‡ 比率120%は実装では 1.2em
19. デザイントークンの 適切な管理と運用 @LY Corporation デザイントークンの 適切な管理と運用 @LY Corporation
20. デザイントークンの運用 改めてデザイントークンとは デザイントークンはデザインを構成する最小要素 h 色、タイポグラフィ、余白、影なQ h サービス全体で一貫して使用する メリット h それぞれの要素の用途が明確になi h 同様の役割が重複しないようにして一貫性をもたせi h 参照を集約して、管理コストを下げる＆変更を行いやすくする
21. デザイントークンの運用 課題 トークンが利用されていない運用における課題 トークン未利用 時の運用 デザイナー 色を定義 Color Style デザイナー 色や命名を転記 ドキュメント （手動で書く） エンジニア ドキュメントを見て実装 css, xmlなど カオス極まれな状態 ‍ 実装とデザインデータとドキュメントで定義値がズレて何が正しいのかわからない ルールの認知が不十分でエンジニアがテキトーに命名しちゃう デザインのファイルごとに独自の色が定義されまくってて、同じようなのが重複しまくり ダークテーマ対応時にツラミが爆発...
22. デザイントークンの運用 方針 デザイントークン運用の改善方針 どうあるべきか？ ‰ トークンを一括管理できるツールを導入して、SSOTとす„ ‰ 色定義の実装は手動で行わず、自動でコードに反映す„ ‰ 適切な状態を維持するために、全体管理をする役割を定めて、レビューを行う
23. デザイントークンの運用 方針 Figma Variableを導入 VariableはFigmaでデザイントークンをいい感じ管理でき る機能h j Figmaで操作できて、他のツールとの行き来も不要h j 一覧で見ることができるため、構造や実際の色合いな どが確認しやすいh j ダーク/ライトテーマなどを表現できるh j APIが用意されていて、コードベースで定義を取得でき る。
24. デザイントークンの運用 方針 定義→実装に反映を自動化 デザイナーが色を定義 (VDライブラリを更新) Variables (共通ライブラリ) Jsonで取得 REST API それぞれの形式に変換 Style Dictionary 実装で使うライブラリが更新 SDK android iOS iOS React ě FigmaでVariableにトークンを追加/変更す© «› VariableからJSONを取得して、StyleDictionaryのフォーマットに成形する › StyleDictionaryで各プラットフォームのコードを生成して、デザイントークンSDKのRepositoryに commitする ț SDKが更新されるので、アプリ側で取り込む。
25. カラートークンの整理 @LY Corporation カラートークンの整理 @LY Corporation
26. デザイントークンの整理 事例 トークン整理の背景・経緯 【前提】ヤフーアプリのデザインシステムの構造 Yahoo! JAPAN 横断の
 デザインシステム RIFFでは
 カバーしきれないものを
 独自で定義 ヤフーアプリの
 ⁨⁩のデザインシステム § Yahoo! JAPAN 横断⁨⁩のデザインシステム「Riff」以外で必要になったUIコンポーネントやカラーパレットを ヤフーアプリのデザインシステムとしてまとめている
27. デザイントークンの整理 事例 トークン整理前の状態 ヤフーアプリの独自定義が約240色も存在することが判明 f Riffでカバーしきれない部分をヤフーアプリで独自定義し続けた結果、似たようなカラーや未使用のカラー が多く存在してい‰ f 命名ルールや階層構造が定まっていなかった（＋α きせかえの考慮されていない構造となっていた） その結果・・・ ± デザインの一貫性を欠く要因となり、メンテナンス性が低下¹ ± 似たような色やスタイルを何度も再定義することになり、効率の悪いプロセス’ ± 新しいコンポーネントの追加や修正も複雑化
28. デザイントークンの運用 事例 デザイントークン整理のプロセス トークン整理のプロセス C トークン構造の整… C きせかえを考慮した構造に変y C 命名ルールと階層構造の策a C 一貫性を保つため、階層構造・命名規則を明文R C Figmaのvariableの活v C Figma variableでトークン整理を実施
29. デザイントークンの整理 方針 トークン構造の整理 （変更前）セマンティックが意味を果たしておらず、膨大なコンポーネントトークンの数
 　　　　　＋きせかえが考慮できていない構造 （変更後）色数を削減できる構造＋きせかえの拡張性を考慮した構造に改善 ヤフーアプリ
 きせかえ Components token ヤフーアプリ 
 Components token きせかえ 
 Components token きせかえ
 各テーマの ColorPalette ヤフーアプリ
 Semantic token Riff 
 Semantic token Riff 
 Global token ヤフーアプリ
 Global token 点線で囲ったもの：
 デザインデータや実装時に参照可能なトークン
30. デザイントークンの運用 方針 命名ルールを策定 セマンティックトークンの命名ルール E トークンの用途と状態を組み込D E トークンが使用される場所や目的を明確にする semantic color surface surface container header button primary disabled highlight secondary category layer visual appearance item（optional）
31. デザイントークンの運用 方針 命名ルールを策定 コンポーネントトークンの命名ルール P コンポーネント特有のカラーとなるため、コンポーネント名を冒頭に持ってくU P 具体的な状態や適用箇所を示€ P 類似のスタイルはグループ化して名前をつけることで、再利用性と管理の効率を高める component
 color navbar searchbox inputField default contents text default surface category component state layer item （optional） sub component （optional）
32. デザイントークンの運用 方針 Variableを活用し、
 デザイントークン整理を実施 d Variableではコレクション（変数の関連セット）を分けられる
 →これによって構造整理を実現できb d トークンが一覧で表になっている
 →トークン整理・管理が簡単にできb d グループ化ができる
 →トークン整理や確認が楽になる
33. デザイントークンの運用 その他Variableの活用色々 ˜ 端末サイズ（横幅など）を定義して、FigmaとUI実装のプレビューで同じサイズで表示確認出来るように す† ˜ モードを活用してOS固有のコンポーネントやOSバージョンによるFigma上での表示出し分' ˜ Figma上での多言語対応による出し分け
34. エンジニアとデザイナーの連携 @LY Corporation エンジニアとデザイナーの連携 @LY Corporation
35. Figmaについて 方針 FigmaはUIを構造的に表現できる Figmaはペライチの画像を作るツールではなく、UIの構造 が表現できる設計ツール。 画面構造や状態変化を考慮して作る事ができる。 エンジニアはFigmaの構造に従って実装を行 う。デザインと実装を一致させる。 出典：https://www.figma.com/ja-jp/design/ 「実装できるようにFigmaをちゃんと作る」 は理想だけど、デザイナーだけでは難しい
36. エンジニアとデザイナーの連携 事例 デザインを実装に落とし込めない 例：Figma上で考慮しきれない実装上の課– Š OSの提供する標準コンポーネントのカスタマイズでは対応が難しn Š 既存の画面実装は宣言的UIと古い仕組みが混ざっていて、設計に工夫が必要 その結果..E Š 実装が難しいことが判明して、Figmaの大幅な修正（手戻り）が発生しA Š エンジニアが頑張って対応したところ、複雑なコードになって実装が負債化 アプリの品質を損ねてしまったり、リードタイムが伸びる要因
37. エンジニアとデザイナーの連携 方針 デザインデータを正しく修正する T FigmaでのUIの構造はデザイナーが意図を持って正確に作成するf T 実装時に課題が判明したときは、先にFigmaのUI構造を修正してから、実装に反映する。 Figmaを中間の言語として、お互いにやや越境する。 デザインデータを共に作り上げる。
38. エンジニアとデザイナーの連携 方針 UIの設計とUIの実装は一つのプロセスとして考える デザイン制作はイテレーティブなもの 実装の都合や仕様の変更は常に発生し、デザインは変動する。 UIデザインとUI実装は切り離されたプロセスではなく、一体として考える。 ヤフーアプリで行っている取り組み ¶ FigmaでのUI設計を行う段階からエンジニアも参加してモブデザインを行± ¶ 実装時に少しでも悩ましい場面が出たらデザイナーにも参加してもらって、モブプログラミングを行± ¶ デザインから開発を横断的に品質チェックする役割を定めて、デザインデータやPullRequestのレビュー を行う
39. ボトムアップで立ち上げる デザインシステム組織 @LY Corporation ボトムアップで立ち上げる デザインシステム組織 @LY Corporation
40. デザインシステム組織 デザインシステムをどう導入していくか？ ここまでの内容は「エンジニアだけ」「デザイナーだけ」で行うことは出来ません。 ロールを横断して、同じ目線でデザインシステムの構築やUI設計/実装の品質向上に取り組む必要があります。 導入に失敗する原因 デザインシステム構築失敗談でよくあるのが、一方のロールだけで作り上げようとしてしまう事です。 デザインシステムを構築しても、それが使われないと意味がありません。 「使われる」というのは「利用者がメリットを感じられる状態」です。 まずは、お互いに解像度を高めて、課題を認識することが最初のステップです。
41. デザインシステム組織 方針 デザインシステム組織のススメ 継続的に取り組む体制（チーム）が必要 デザインシステムには完成はない。適切に維持し続けるためにも継続的な体制が必要。 チームにはロールを横断して様々な人が参加する デザインシステムは特定のロールだけで構築できるものではない。 文化を醸成して根付かせる デザインシステムへの価値理解、継続的な改善を行う意識、デザインと実装の一致、SSOTの担保など
42. デザインシステム組織 事例 課題があった以前の体制 規模の大きい組織の中で、デザイナーとエンジニアのロールが明確に分かれいて、関わりが疎でしたV A お互いがどのような課題を抱えているのか把握出来ていな€ A どのような状態が望ましいのかがわからな€ A そもそも課題だと認識出来ていない この状態は「良いデザイン」を「効率的により早く」「品質をより高く」 ユーザーに届ける事ができなくなってしまう要因
43. デザインシステム組織 方針 感じている課題を共有するのが一歩 いきなりデザインから開発に至る全過程を一度に把握し、課題を洗い出すのは困難です。 まずは、お互いの課題を共有し、理想の状態を共に考えましょう。 根本を同じとする課題を両方が抱えていて、共感が生まれるかもしれません。 もし、判明した課題が片方の作業フローでのみ感じるものだとしても、解決にコミットする姿勢が重要です。 問題の原因を生み出してしまっている可能性があります。
44. デザインシステム組織 方針 横断チームを作る 共に課題解決を行うと、そもそもの課題を発生させない仕組みを構築/維持することが重要なことに気づきま す。 我々は、プロダクト開発のアジリティを保ちつつ、現状に即した対応をするため、様々なロールから成る横断 チームを組んでいます。 Yahoo! JAPAN アプリでの体制 DesignSystem WG ” デザイナŽ ” Android開… ” iOS開… ” WebFE開発 Android App Dev Android App Dev/ Designer Web FE Dev/ Designer Designer Designer Designer Designer Designer Designer iOS App Dev iOS App Dev Android App Dev Web FE Dev Web FE Dev
45. デザインシステム組織 方針 体制の構築と文化の醸成はセットで必要 デザインシステムに取り組む意識があっても、体制が無ければ安定的に取り組むことが出来ません。 また、逆に体制だけを用意しても目的意識が無いとドライブしません。 様々なバックグラウンドのメンバーが参加することで、理想像やアプローチにバラツキが生じることもありま す。 ヤフーアプリで行っている取り組み ¾ 越境して、解像度を高めるために業務をスイッチする ¾ 輪読会やカンファレンスに参加してナレッジを持ち帰り、ディスカッションす¡ ¾ ステークホルダーからの期待値や自分たちのバリューについて分析して、MVVを定める
46. ご清聴ありがとうございました！