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

DroidKaigi 2024 での発表資料

Transcript

1. LINEヤフー Media Company, Yahoo! JAPAN Media Services Group しゅーぞー Shuzo Takahashi デザインからアプリ実装まで 一貫したデザインシステムを 構築するベストプラクティス
2. 自己紹介 高橋 柊蔵（しゅーぞー） E LINEヤフー株式会社所k E 2020年新卒入‘ E Androidアプリエンジニア＆UIデザイナー 学生時代にDroidKaigiにはじめて参加したとき、知らない人たちの飲み会にノリで参加したら、まさかのヤ フー社員の集まりだった。 そこからあれよあれよとしているウチに気づいたら入社してて今ココにいる。
3. やってること Yahoo! JAPANアプリを作っています ‰ 検索やタイムライン、アシスト、フォロー...などアプリ 全般の機能開発/デザイq ‰ 技術面ではアーキテクチャの刷新、KMPの導入、 SingleActivity化など
4. やってること Yahoo! JAPANアプリってなに？ ニュース、検索、天気、雨雲レーダー…etcとヤフーサービスをオールインワンで提供するアプリ 最近リニューアルを行い「トレンドタブ」「フォロータブ」「アシストタブ」を追加しました！
5. 改めて、 デザインシステムとは？ @LY Corporation 改めて、 デザインシステムとは？ @LY Corporation
6. デザインシステムとは デザインシステムとは？ サービスの目指すビジョンから「良いデザイン」を実現するための デザインルールやデザイン原則を記載したドキュメント、それらを具体的な画面デザインや 実装に落とし込むためのUIコンポーネントなど、 デザインに関するあらゆる情報を体系化・構造化して提供する仕組みです。
7. デザインシステムとは デザインシステムを構成する要素（例） スタイルガイド デザインの基本的な考え方やルールに関して文書化したガイドライン。 色の使い方、フォント、ロゴやアイコン、言葉遣いのルールなどが含まれる。 コンポーネントライブラリ リストやボタン、ナビゲーションなどの汎用的なUIパーツを提供するライブラリ デザイントークン 色、タイポグラフィ、余白、影など、サービス全体で一貫して使用するデザインを構成する最小要素の定義。
8. デザインシステムとは 導入すると何がうれしい？ 一貫性の向上 サービス全体で一貫性したUIを実現することで、ユーザーに直感的で理解しやすく、 フラストレーション（悪い意味での驚き）の少ない体験を提供する。 共通言語の確立 デザインシステムは、デザイナー、エンジニア、企画、マーケなど、サービスに関わるあらゆる人々の共通の 言語となることで認識をそろえてコミュニケーションコストを低減させる。
9. デザインシステムとは 導入すると何がうれしい？ デザインデータを信頼性の高いリファレンスとすることができ（SSOT） デザインデータを見たら実装が明瞭という状態にすることで、各アーキテクチャの仕様差を防ぐ。 デザイン/実装のコストの低減（効率化） 再利用可能なコンポーネントやデザインパターンの使用により、デザイナーとエンジニア両方での車輪の再 開発防ぐ。
10. デザインシステムとは 注意 デザインシステムへの誤った理解 デザインシステムは単なるリソースの集合ではない 仕組みを作って機能する常態（=システム）となっていることが重要。 デザインシステムは実装ライブラリや設計パターンではない たまに実装ライブラリを念頭に「デザインシステムを作る」という表現が見られますが、違和感があります。 今からお話しますが、デザインシステムは特定ロールだけで作って機能するものではありません。
11. UI実装時の悩み @LY Corporation UI実装時の悩み @LY Corporation
12. よくある課題 事例 UIの実装時に発生しがちな問題 あるある a UIデザインと実装後でヴィジュアルや仕様が違v a 実装ができない、コストが大きくかかるデザインになってい“ a 画面によってUIコンポーネントの設計思想が大きく違っていて一貫性がなg a Composable関数が特定ユースケースしか考慮されておらず使い回せない
13. よくある課題 事例 UIの実装時に発生しがちな問題 なぜ発生するのか？ i デザイナーが画面構造や実装時の制約を考慮しきれていなQ i エンジニアが「よしなに」判断して実装を行ってしまE i ルールや一般的なプラクティスが定まっていない
14. UIデザインの責務 デザインデータに求められること こんなときどうする...？ d 画面サイズが変わったときの挙動がわからなT d テキストが溢れたときが考慮されていなT d 端末の文字サイズ変更をしたときに盛大に崩れc d ダークテーマのときに考慮されていない デザインデータは画面構造や状態変化を考慮してある= になっているべき 実装可能な作り
15. UIデザインの責務 そもそものUIデザインの責務 ペライチの画像を作るのがUIデザインではない ˜ UIのヴィジュアル（モック）は動的な状態変化の一部を「スナップショット」したもb ˜ 「UIデザイン」とは時間やユーザーアクションとともに変化する画面を設計することであり、モックの ヴィジュアルを制作することではない 画面構造や状態変化を考慮してUIを設計するのはデザイナーの責務（主に） エンジニアの判断で「よしなに」実装してしまうのはまずい
16. UIデザインの責務 方針 そもそものUIデザインの責務 h 「ペライチの画像（=ヴィジュアルのモック）」で状態変化や画面構造などを全て伝えることは出来なI h でも、仕様書に全てを文章で記述することも出来ないし、適切ではなI h 例えば 「画面サイズが変化したときは左右マージンが8px→16pxにする」などを全て文書で羅列して あっても嬉しくない... 現代の複雑なアプリでは、 「ペライチな画面をフォトショで制作」+「文章で補完」みたいな手法はムリがある
17. 仕様書とデザインデータの役割 方針 仕様書とデザインデータの使い分け デザインデータ（Figma）の役割 ƒ 実現したときのヴィジュアルを示e ƒ UIの構造を表して、UIの実装（レイアウト）に必要な情報を示す 仕様書の役割 ƒ 状態が変化する条件や入稿される文言のパターンなどを記述すo ƒ 主にビジネスロジックの実装に必要な情報を示す
18. FigmaとComposeの実装 @LY Corporation FigmaとComposeの実装 @LY Corporation
19. FigmaとComposeの実装 FigmaはUIを構造的に表現できる Figmaはペライチの画像を作るツールではなく、UIの構造 が表現できる設計ツールI p 実装するときにUIの構造を考えるのでは無く、Figma の段階で作り込むI p AndroidとiOSのUIのズレも抑える事ができる。 エンジニアはFigmaの構造に従って実装する デザインと実装を一致させる 出典：https://www.figma.com/ja-jp/design/
20. FigmaとComposeの実装 方針 Figma DevModeを使う 実装に必要な情報が確認しやすい Composeで実装したときのコードも表示してくれる 出典：https://www.figma.com/ja-jp/dev-mode/
21. FigmaとComposeの実装 Figma Componentsとは g 再利用するパーツは「Components」で作成す“ g 元のComponentsを変更すると、各instanceに反映 され“ g 動的に変化する部分はプロパティにす“ g 例：タイトルや日付のテキスト、ラベルの可視性な 6 g 内包するパーツを置き換えることもできる （Instance Swap）
22. FigmaとComposeの実装 方針 Componentsの実装方針 ‚ Componentsの単位でComposable関数を作s ‚ Figmaの命名と関数の命名を揃えr ‚ 再利用できるように特定ユースケースに依存しなR ‚ UiStateを引数で渡さない、中で参照しなR ‚ プロパティをComposable関数の引数にすr ‚ 基本的にはプリミティブな型になr ‚ Instance SwapはComposable関数オブジェクトを 引数に取ることで表現する
23. FigmaとComposeの実装 Figma Variants ’ 一つのComponentsでUIのパターンを表現できn ’ 同じ役割のUIコンポーネントだが、ヴィジュアルその ものが大きく変わる場合（=同一のUIの構造ではない） に使‚ ’ 次のケースではVariantsではなB ’ 画面サイズによるレスポンシブな変化はレイアウト の構造で表現すn ’ 構造が変わらない動的な変化はPropertyで表現する
24. FigmaとComposeの実装 方針 Variantsの実装方針 W 同一のUI構造ではないため、それぞれでComposable関数を作成す“ W 一つのコンポーネントを動的に変化させるように実装するとカオスにな“ W Figmaの構造が別D W 命名はComponents名+Variantsのパターン名にする
25. FigmaとComposeの実装 方針 Figma TextStyleと実装方針 タイポグラフィ f 汎用利用できるようにトークンとして定義す‡ f LineHeightの指€ f Figmaでは固定値もしくは比率で指定でき‡ f 比率120%は実装では 1.2.em
26. FigmaとComposeの実装 方針 LineHeightには注意 „ Androidには上下に余分な余白が付いてくるので、無効 にすs „ platformStyle = PlatformTextStyle(includeFontPadding = falseu „ 今後このプロパティは無くなs „ Androidでは見切れるサイズを設定出来なW „ 0.9.em などを指定しても反映されなW „ 文字サイズギリギリや見切れを前提とする LineHeightの指定はデザインデータで行わないルー ルにする必要がある
27. FigmaとComposeの実装 UI実装の自動生成について h FigmaのDevModeではComposeでの実装が確認でき  h 以前はLineHeightやVariableが正しく表示出来ない などの課題があったが改善されてきてい h サイズが固定値で表示されてしまうので注意が必要 h Googleの提供する「Relay」につい¹ h FigmaとAndroid Studioのプラグインを導入するこ とで、Composeのコードを自動生成でき h DevModeに比べると比較的正確に生成されるが、 既存のデザインシステム設計の差異などを考慮が必 要で一定の運用コストがある
28. デザイントークンの 適切な管理と運用 @LY Corporation デザイントークンの 適切な管理と運用 @LY Corporation
29. デザイントークンの運用 改めてデザイントークンとは デザイントークンはデザインを構成する最小要素 f 色、タイポグラフィ、余白、影なP f サービス全体で一貫して使用する メリット f それぞれの要素の用途が明確にな˜ f 同様の役割が重複しないようにして一貫性をもたせ˜ f 参照を集約して、管理コストを下げる＆変更を行いやすくする
30. デザイントークンの運用 事例 課題があった以前の運用 以前の運用 デザイナー 色を定義 Color Style デザイナー 色や命名を転記 ドキュメント （手動で書く） エンジニア ドキュメントを見て実装 color.xml カオス極まれな状態 ‍ 実装とデザインデータとドキュメントで定義値がズレて何が正しいのかわからない ルールの認知が不十分でエンジニアがテキトーに命名しちゃう デザインのファイルごとに独自の色が定義されまくってて、同じようなのが重複しまくり ダークテーマ対応時にツラミが爆発...
31. デザイントークンの運用 方針 デザイントークン運用の改善方針 どうあるべきか？ ” トークンを一括管理できるツールを導入して、SSOTとすg ” 色定義の実装は手動で行わず、自動でコードに反映すg ” 適切な状態を維持するために全体管理する役割を定めて、レビューを行う
32. デザイントークンの運用 方針 Figma Variableを導入 VariableはFigmaでデザイントークンをいい感じに管理で きる機能f r Figmaで操作できて、他のツールとの行き来も不要f r 一覧で見ることができるため、構造や実際の色合いな どが確認しやすいf r ダーク/ライトテーマなどを表現できるf r APIが用意されていて、コードベースで定義を取得でき る。
33. デザイントークンの運用 方針 定義→実装に反映を自動化 デザイナーが色を定義 (VDライブラリを更新) Variables (共通ライブラリ) Jsonで取得 REST API それぞれの形式に変換 Style Dictionary 実装で使うライブラリが更新 SDK android iOS iOS React ÄÀ FigmaでVariableにトークンを追加/変更す¤ ŸÀ VariableからJSONを取得して、StyleDictionaryのフォーマットに成形するˆ ™À StyleDictionaryでKotlinコードを生成したら、デザイントークンSDKのRepositoryにcommitするˆ §À SDKが更新されるので、アプリ側で取り込む。
34. デザイントークンの運用 その他Variableの活用色々 Y 端末サイズ（横幅など）を定義して、FigmaとComposeのプレビューで同じサイズで表示確認出来るよう にす˜ Y モードを活用してOS固有のコンポーネントやOSバージョンによるFigma上での表示出し分% Y Figma上での多言語対応による出し分け
35. Material Designの扱い @LY Corporation Material Designの扱い @LY Corporation
36. M3について Material3の採用について Googleが提供するデザインシステム「Material3」の採用 している、もしくは検討している方も多いと思います。 出典：https://m3.material.io/
37. M3について 注意 Material3を採用する場合の注意点 採用する場合はデザイナーやビジネスサイドと認識を揃える g Mateiral3は「デザインシステム」であり、既にデザインシステムを構築している場合は競合が発生するの で注ƒ g ヴィジュアルや表現の幅に大きく影響するため、ブランディングの面でも考慮が必€ g また、iOSなどの他のプラットフォームとの一貫性の面でも考慮が必要なため、デザイナーが主体となって 検討したほうがトラブルが少ない 完全に依存関係を断ち切るのは難しい g プラットフォームの標準となっているため、依存関係を完全に断ち切るのは難しâ g UIコンポーネントだけを限定的に使用する場合、モジュール内で隠蔽したり、M3のトークンの参照をしな いなどルールの周知が必要
38. エンジニアとデザイナーの連携 @LY Corporation エンジニアとデザイナーの連携 @LY Corporation
39. Figmaについて 方針 FigmaはUIを構造的に表現できる Figmaはペライチの画像を作るツールではなく、UIの構造 が表現できる設計ツール。 画面構造や状態変化を考慮して作る事ができる。 エンジニアはFigmaの構造に従って実装を行 う。デザインと実装を一致させる。 出典：https://www.figma.com/ja-jp/design/ 「実装できるようにFigmaをちゃんと作る」 は理想だけど、デザイナーだけでは難しい
40. エンジニアとデザイナーの連携 事例 実装で表現しきれない 実装し始めたところで↓が判明しi v OSの提供する標準コンポーネントのカスタマイズでは対応が難し‡ v 既存の画面実装はXMLとComposeがミックスしており、連動には考慮が必要 その結果..U v デザイナーに実装が難しい旨を伝えて、Figmaの大幅な修正（手戻り）が発生しi v エンジニアが頑張って対応したところ、複雑な実装になって負債化 アプリの品質を損ねてしまったり、リードタイムが伸びる要因
41. エンジニアとデザイナーの連携 方針 デザインデータを正しく修正する q FigmaでのUIの構造はデザイナーが意図を持って作成しているため、実装は一致する必要があるH q 実装時に課題が判明したときは、先にFigmaのUI構造を修正するH q デザイナーだけにコストを寄せず、エンジニアも一体になってデザインデータを作り上げる。 Figmaを中間の言語として、お互いにやや越境する。 UIデザインにエンジニアも参加する。
42. エンジニアとデザイナーの連携 方針 UIの設計とUIの実装は一つのプロセスとして考える デザイン制作はイテレーティブなもの 実装の都合や仕様の変更は常に発生し、デザインは変動する。 UIデザインとUI実装は切り離されたプロセスではなく、一体として考える。
43. エンジニアとデザイナーの連携 方針 UIの設計とUIの実装は一つのプロセスとして考える ヤフーアプリで行っている取り組み j FigmaでのUI設計を行う段階からエンジニアも参加してモブデザインを行m j 実装時に少しでも悩ましい場面が出たらデザイナーにも参加してもらって、モブプログラミングを行m j デザインから開発を横断的に品質チェックする役割を定めて、デザインデータやPRのレビューを行う
44. 組織で取り組むデザインシステム @LY Corporation 組織で取り組むデザインシステム @LY Corporation
45. デザインシステム組織 デザインシステムをどう導入していくか？ ここまでの内容は「エンジニアだけ」「デザイナーだけ」で行うことは出来ません。 ロールを横断して、同じ目線でデザインシステムの構築やUI設計/実装の品質向上に取り組む必要があります。 導入に失敗する原因 デザインシステム構築失敗談でよくあるのが、一方のロールだけで作り上げようとしてしまう事です。 デザインシステムを構築しても、それが使われないと意味がありません。 「使われる」というのは「利用者がメリットを感じられる状態」です。 まずは、お互いに解像度を高めて、課題を認識することが最初のステップです。
46. デザインシステム組織 方針 デザインシステム組織のススメ 継続的に取り組む体制（チーム）が必要 デザインシステムには完成はない。適切に維持し続けるためにも継続的な体制が必要。 チームにはロールを横断して様々な人が参加する デザインシステムは特定のロールだけで構築できるものではない。 文化を醸成して根付かせる デザインシステムへの価値理解、継続的な改善を行う意識、デザインと実装の一致、SSOTの担保など
47. デザインシステム組織 事例 課題があった以前の体制 デザイナーとエンジニアのロールが明確に分かれており、規模の大きな組織のためお互いの関わりが疎でし たE @ お互いがどのような課題を抱えているのか把握出来ていなP @ どのような状態が望ましいのかがわからなP @ そもそも課題だと認識出来ていない この状態は「良いデザイン」を「効率的により早く」「品質をより高く」 ユーザーに届ける事ができなくなってしまう要因
48. デザインシステム組織 方針 感じている課題を共有するのが一歩 いきなりデザインから開発まで全体を見通して課題を洗い出そうとするのは難しいです。 まずは抱えている課題をお互いに共有して、理想の状態を一緒になって考えましょう。 その課題がエンジニアに限ったものなのか、それとも根本を同じとする課題をデザイナーも抱えているのかが 見えてきます。（逆もしかり） 課題が提示されたとき、影響を自分たちが直接受けていないとしても、解決にコミットメントすることは重要 です。 影響を受けていないとしても、発生要因になっているかもしれません。 それは一方にコストが偏っている状態なので、解決が必要です。
49. デザインシステム組織 方針 横断チームを作る 「課題を共有して一緒に解決する」事を行うとデザインシステムに取り組む体制が必要なことに気づきます。 課題解決はもちろんですが、そもそもの課題を発生させない仕組みを構築/維持することが重要です。 デザインシステムには完成はなく、継続的な取り組みが必要です。 チームには、できるだけ様々なロールから横断的に参加してもらえると良いです。 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
50. デザインシステム組織 方針 文化を醸成する 体制の構築と文化の醸成はセットで必要 デザインシステムの重要性を認識して、コミットメントする意識があったとしても体制が無ければ安定的に取 り組むことが出来ません。 また、逆に体制だけを用意しても目的意識を共有できて無いとドライブしません。 様々なバックグラウンドのメンバーが参加すると、デザインシステムへの理解度や将来的イメージにバラツキ が生じることもあります。 有効な取り組„ m お互いの業務に参加して解像度を高め„ m 輪読会などでのインプッj m ステークホルダーからの期待値や自分たちのバリューについてディスカッションする（MVVを定める）
51. ご清聴ありがとうございました！