デザインからアプリ実装まで一貫したデザインシステムを構築するベストプラクティス

by Shuzo Takahashi

Slide 1

Slide 1 text

LINEヤフー Media Company, Yahoo! JAPAN Media Services Group しゅーぞー Shuzo Takahashi デザインからアプリ実装まで一貫したデザインシステムを構築するベストプラクティス

Slide 2

Slide 2 text

自己紹介高橋柊蔵（しゅーぞー） E LINEヤフー株式会社所k E 2020年新卒入 E Androidアプリエンジニア＆UIデザイナー学生時代にDroidKaigiにはじめて参加したとき、知らない人たちの飲み会にノリで参加したら、まさかのヤフー社員の集まりだった。そこからあれよあれよとしているウチに気づいたら入社してて今ココにいる。

Slide 3

Slide 3 text

やってること Yahoo! JAPANアプリを作っています検索やタイムライン、アシスト、フォロー...などアプリ全般の機能開発/デザイq 技術面ではアーキテクチャの刷新、KMPの導入、 SingleActivity化など

Slide 4

Slide 4 text

やってること Yahoo! JAPANアプリってなに？ニュース、検索、天気、雨雲レーダー…etcとヤフーサービスをオールインワンで提供するアプリ最近リニューアルを行い「トレンドタブ」「フォロータブ」「アシストタブ」を追加しました！

Slide 5

Slide 5 text

改めて、デザインシステムとは？ @LY Corporation 改めて、デザインシステムとは？ @LY Corporation

Slide 6

Slide 6 text

デザインシステムとはデザインシステムとは？サービスの目指すビジョンから「良いデザイン」を実現するためのデザインルールやデザイン原則を記載したドキュメント、それらを具体的な画面デザインや実装に落とし込むためのUIコンポーネントなど、デザインに関するあらゆる情報を体系化・構造化して提供する仕組みです。

Slide 7

Slide 7 text

デザインシステムとはデザインシステムを構成する要素（例）スタイルガイドデザインの基本的な考え方やルールに関して文書化したガイドライン。色の使い方、フォント、ロゴやアイコン、言葉遣いのルールなどが含まれる。コンポーネントライブラリリストやボタン、ナビゲーションなどの汎用的なUIパーツを提供するライブラリデザイントークン色、タイポグラフィ、余白、影など、サービス全体で一貫して使用するデザインを構成する最小要素の定義。

Slide 8

Slide 8 text

デザインシステムとは導入すると何がうれしい？一貫性の向上サービス全体で一貫性したUIを実現することで、ユーザーに直感的で理解しやすく、フラストレーション（悪い意味での驚き）の少ない体験を提供する。共通言語の確立デザインシステムは、デザイナー、エンジニア、企画、マーケなど、サービスに関わるあらゆる人々の共通の言語となることで認識をそろえてコミュニケーションコストを低減させる。

Slide 9

Slide 9 text

デザインシステムとは導入すると何がうれしい？デザインデータを信頼性の高いリファレンスとすることができ（SSOT）デザインデータを見たら実装が明瞭という状態にすることで、各アーキテクチャの仕様差を防ぐ。デザイン/実装のコストの低減（効率化）再利用可能なコンポーネントやデザインパターンの使用により、デザイナーとエンジニア両方での車輪の再開発防ぐ。

Slide 10

Slide 10 text

デザインシステムとは注意デザインシステムへの誤った理解デザインシステムは単なるリソースの集合ではない仕組みを作って機能する常態（=システム）となっていることが重要。デザインシステムは実装ライブラリや設計パターンではないたまに実装ライブラリを念頭に「デザインシステムを作る」という表現が見られますが、違和感があります。今からお話しますが、デザインシステムは特定ロールだけで作って機能するものではありません。

Slide 11

Slide 11 text

UI実装時の悩み @LY Corporation UI実装時の悩み @LY Corporation

Slide 12

Slide 12 text

よくある課題事例 UIの実装時に発生しがちな問題あるある a UIデザインと実装後でヴィジュアルや仕様が違v a 実装ができない、コストが大きくかかるデザインになってい a 画面によってUIコンポーネントの設計思想が大きく違っていて一貫性がなg a Composable関数が特定ユースケースしか考慮されておらず使い回せない

Slide 13

Slide 13 text

よくある課題事例 UIの実装時に発生しがちな問題なぜ発生するのか？ i デザイナーが画面構造や実装時の制約を考慮しきれていなQ i エンジニアが「よしなに」判断して実装を行ってしまE i ルールや一般的なプラクティスが定まっていない

Slide 14

Slide 14 text

UIデザインの責務デザインデータに求められることこんなときどうする...？ d 画面サイズが変わったときの挙動がわからなT d テキストが溢れたときが考慮されていなT d 端末の文字サイズ変更をしたときに盛大に崩れc d ダークテーマのときに考慮されていないデザインデータは画面構造や状態変化を考慮してある= になっているべき実装可能な作り

Slide 15

Slide 15 text

UIデザインの責務そもそものUIデザインの責務ペライチの画像を作るのがUIデザインではない UIのヴィジュアル（モック）は動的な状態変化の一部を「スナップショット」したもb 「UIデザイン」とは時間やユーザーアクションとともに変化する画面を設計することであり、モックのヴィジュアルを制作することではない画面構造や状態変化を考慮してUIを設計するのはデザイナーの責務（主に）エンジニアの判断で「よしなに」実装してしまうのはまずい

Slide 16

Slide 16 text

UIデザインの責務方針そもそものUIデザインの責務 h 「ペライチの画像（=ヴィジュアルのモック）」で状態変化や画面構造などを全て伝えることは出来なI h でも、仕様書に全てを文章で記述することも出来ないし、適切ではなI h 例えば「画面サイズが変化したときは左右マージンが8px→16pxにする」などを全て文書で羅列してあっても嬉しくない... 現代の複雑なアプリでは、「ペライチな画面をフォトショで制作」+「文章で補完」みたいな手法はムリがある

Slide 17

Slide 17 text

仕様書とデザインデータの役割方針仕様書とデザインデータの使い分けデザインデータ（Figma）の役割実現したときのヴィジュアルを示e UIの構造を表して、UIの実装（レイアウト）に必要な情報を示す仕様書の役割状態が変化する条件や入稿される文言のパターンなどを記述すo 主にビジネスロジックの実装に必要な情報を示す

Slide 18

Slide 18 text

FigmaとComposeの実装 @LY Corporation FigmaとComposeの実装 @LY Corporation

Slide 19

Slide 19 text

FigmaとComposeの実装 FigmaはUIを構造的に表現できる Figmaはペライチの画像を作るツールではなく、UIの構造が表現できる設計ツールI p 実装するときにUIの構造を考えるのでは無く、Figma の段階で作り込むI p AndroidとiOSのUIのズレも抑える事ができる。エンジニアはFigmaの構造に従って実装するデザインと実装を一致させる出典：https://www.figma.com/ja-jp/design/

Slide 20

Slide 20 text

FigmaとComposeの実装方針 Figma DevModeを使う実装に必要な情報が確認しやすい Composeで実装したときのコードも表示してくれる出典：https://www.figma.com/ja-jp/dev-mode/

Slide 21

Slide 21 text

FigmaとComposeの実装 Figma Componentsとは g 再利用するパーツは「Components」で作成す g 元のComponentsを変更すると、各instanceに反映され g 動的に変化する部分はプロパティにす g 例：タイトルや日付のテキスト、ラベルの可視性な 6 g 内包するパーツを置き換えることもできる（Instance Swap）

Slide 22

Slide 22 text

FigmaとComposeの実装方針 Componentsの実装方針 Componentsの単位でComposable関数を作s Figmaの命名と関数の命名を揃えr 再利用できるように特定ユースケースに依存しなR UiStateを引数で渡さない、中で参照しなR プロパティをComposable関数の引数にすr 基本的にはプリミティブな型になr Instance SwapはComposable関数オブジェクトを引数に取ることで表現する

Slide 23

Slide 23 text

FigmaとComposeの実装 Figma Variants 一つのComponentsでUIのパターンを表現できn 同じ役割のUIコンポーネントだが、ヴィジュアルそのものが大きく変わる場合（=同一のUIの構造ではない）に使次のケースではVariantsではなB 画面サイズによるレスポンシブな変化はレイアウトの構造で表現すn 構造が変わらない動的な変化はPropertyで表現する

Slide 24

Slide 24 text

FigmaとComposeの実装方針 Variantsの実装方針 W 同一のUI構造ではないため、それぞれでComposable関数を作成す W 一つのコンポーネントを動的に変化させるように実装するとカオスにな W Figmaの構造が別D W 命名はComponents名+Variantsのパターン名にする

Slide 25

Slide 25 text

FigmaとComposeの実装方針 Figma TextStyleと実装方針タイポグラフィ f 汎用利用できるようにトークンとして定義す f LineHeightの指 f Figmaでは固定値もしくは比率で指定でき f 比率120%は実装では 1.2.em

Slide 26

Slide 26 text

FigmaとComposeの実装方針 LineHeightには注意 Androidには上下に余分な余白が付いてくるので、無効にすs platformStyle = PlatformTextStyle(includeFontPadding = falseu 今後このプロパティは無くなs Androidでは見切れるサイズを設定出来なW 0.9.em などを指定しても反映されなW 文字サイズギリギリや見切れを前提とする LineHeightの指定はデザインデータで行わないルールにする必要がある

Slide 27

Slide 27 text

FigmaとComposeの実装 UI実装の自動生成について h FigmaのDevModeではComposeでの実装が確認でき h 以前はLineHeightやVariableが正しく表示出来ないなどの課題があったが改善されてきてい h サイズが固定値で表示されてしまうので注意が必要 h Googleの提供する「Relay」につい¹ h FigmaとAndroid Studioのプラグインを導入することで、Composeのコードを自動生成でき h DevModeに比べると比較的正確に生成されるが、既存のデザインシステム設計の差異などを考慮が必要で一定の運用コストがある

Slide 28

Slide 28 text

デザイントークンの適切な管理と運用 @LY Corporation デザイントークンの適切な管理と運用 @LY Corporation

Slide 29

Slide 29 text

デザイントークンの運用改めてデザイントークンとはデザイントークンはデザインを構成する最小要素 f 色、タイポグラフィ、余白、影なP f サービス全体で一貫して使用するメリット f それぞれの要素の用途が明確にな f 同様の役割が重複しないようにして一貫性をもたせ f 参照を集約して、管理コストを下げる＆変更を行いやすくする

Slide 30

Slide 30 text

デザイントークンの運用事例課題があった以前の運用以前の運用デザイナー色を定義 Color Style デザイナー色や命名を転記ドキュメント（手動で書く）エンジニアドキュメントを見て実装 color.xml カオス極まれな状態 ‍ 実装とデザインデータとドキュメントで定義値がズレて何が正しいのかわからないルールの認知が不十分でエンジニアがテキトーに命名しちゃうデザインのファイルごとに独自の色が定義されまくってて、同じようなのが重複しまくりダークテーマ対応時にツラミが爆発...

Slide 31

Slide 31 text

デザイントークンの運用方針デザイントークン運用の改善方針どうあるべきか？トークンを一括管理できるツールを導入して、SSOTとすg 色定義の実装は手動で行わず、自動でコードに反映すg 適切な状態を維持するために全体管理する役割を定めて、レビューを行う

Slide 32

Slide 32 text

デザイントークンの運用方針 Figma Variableを導入 VariableはFigmaでデザイントークンをいい感じに管理できる機能f r Figmaで操作できて、他のツールとの行き来も不要f r 一覧で見ることができるため、構造や実際の色合いなどが確認しやすいf r ダーク/ライトテーマなどを表現できるf r APIが用意されていて、コードベースで定義を取得できる。

Slide 33

Slide 33 text

デザイントークンの運用方針定義→実装に反映を自動化デザイナーが色を定義 (VDライブラリを更新) Variables (共通ライブラリ) Jsonで取得 REST API それぞれの形式に変換 Style Dictionary 実装で使うライブラリが更新 SDK android iOS iOS React ÄÀ FigmaでVariableにトークンを追加/変更す¤ À VariableからJSONを取得して、StyleDictionaryのフォーマットに成形する À StyleDictionaryでKotlinコードを生成したら、デザイントークンSDKのRepositoryにcommitする §À SDKが更新されるので、アプリ側で取り込む。

Slide 34

Slide 34 text

デザイントークンの運用その他Variableの活用色々 Y 端末サイズ（横幅など）を定義して、FigmaとComposeのプレビューで同じサイズで表示確認出来るようにす Y モードを活用してOS固有のコンポーネントやOSバージョンによるFigma上での表示出し分% Y Figma上での多言語対応による出し分け

Slide 35

Slide 35 text

Material Designの扱い @LY Corporation Material Designの扱い @LY Corporation

Slide 36

Slide 36 text

M3について Material3の採用について Googleが提供するデザインシステム「Material3」の採用している、もしくは検討している方も多いと思います。出典：https://m3.material.io/

Slide 37

Slide 37 text

M3について注意 Material3を採用する場合の注意点採用する場合はデザイナーやビジネスサイドと認識を揃える g Mateiral3は「デザインシステム」であり、既にデザインシステムを構築している場合は競合が発生するので注 g ヴィジュアルや表現の幅に大きく影響するため、ブランディングの面でも考慮が必 g また、iOSなどの他のプラットフォームとの一貫性の面でも考慮が必要なため、デザイナーが主体となって検討したほうがトラブルが少ない完全に依存関係を断ち切るのは難しい g プラットフォームの標準となっているため、依存関係を完全に断ち切るのは難しâ g UIコンポーネントだけを限定的に使用する場合、モジュール内で隠蔽したり、M3のトークンの参照をしないなどルールの周知が必要

Slide 38

Slide 38 text

エンジニアとデザイナーの連携 @LY Corporation エンジニアとデザイナーの連携 @LY Corporation

Slide 39

Slide 39 text

Figmaについて方針 FigmaはUIを構造的に表現できる Figmaはペライチの画像を作るツールではなく、UIの構造が表現できる設計ツール。画面構造や状態変化を考慮して作る事ができる。エンジニアはFigmaの構造に従って実装を行う。デザインと実装を一致させる。出典：https://www.figma.com/ja-jp/design/ 「実装できるようにFigmaをちゃんと作る」は理想だけど、デザイナーだけでは難しい

Slide 40

Slide 40 text

エンジニアとデザイナーの連携事例実装で表現しきれない実装し始めたところで↓が判明しi v OSの提供する標準コンポーネントのカスタマイズでは対応が難し v 既存の画面実装はXMLとComposeがミックスしており、連動には考慮が必要その結果..U v デザイナーに実装が難しい旨を伝えて、Figmaの大幅な修正（手戻り）が発生しi v エンジニアが頑張って対応したところ、複雑な実装になって負債化アプリの品質を損ねてしまったり、リードタイムが伸びる要因

Slide 41

Slide 41 text

エンジニアとデザイナーの連携方針デザインデータを正しく修正する q FigmaでのUIの構造はデザイナーが意図を持って作成しているため、実装は一致する必要があるH q 実装時に課題が判明したときは、先にFigmaのUI構造を修正するH q デザイナーだけにコストを寄せず、エンジニアも一体になってデザインデータを作り上げる。 Figmaを中間の言語として、お互いにやや越境する。 UIデザインにエンジニアも参加する。

Slide 42

Slide 42 text

エンジニアとデザイナーの連携方針 UIの設計とUIの実装は一つのプロセスとして考えるデザイン制作はイテレーティブなもの実装の都合や仕様の変更は常に発生し、デザインは変動する。 UIデザインとUI実装は切り離されたプロセスではなく、一体として考える。

Slide 43

Slide 43 text

エンジニアとデザイナーの連携方針 UIの設計とUIの実装は一つのプロセスとして考えるヤフーアプリで行っている取り組み j FigmaでのUI設計を行う段階からエンジニアも参加してモブデザインを行m j 実装時に少しでも悩ましい場面が出たらデザイナーにも参加してもらって、モブプログラミングを行m j デザインから開発を横断的に品質チェックする役割を定めて、デザインデータやPRのレビューを行う

Slide 44

Slide 44 text

組織で取り組むデザインシステム @LY Corporation 組織で取り組むデザインシステム @LY Corporation

Slide 45

Slide 45 text

デザインシステム組織デザインシステムをどう導入していくか？ここまでの内容は「エンジニアだけ」「デザイナーだけ」で行うことは出来ません。ロールを横断して、同じ目線でデザインシステムの構築やUI設計/実装の品質向上に取り組む必要があります。導入に失敗する原因デザインシステム構築失敗談でよくあるのが、一方のロールだけで作り上げようとしてしまう事です。デザインシステムを構築しても、それが使われないと意味がありません。「使われる」というのは「利用者がメリットを感じられる状態」です。まずは、お互いに解像度を高めて、課題を認識することが最初のステップです。

Slide 46

Slide 46 text

デザインシステム組織方針デザインシステム組織のススメ継続的に取り組む体制（チーム）が必要デザインシステムには完成はない。適切に維持し続けるためにも継続的な体制が必要。チームにはロールを横断して様々な人が参加するデザインシステムは特定のロールだけで構築できるものではない。文化を醸成して根付かせるデザインシステムへの価値理解、継続的な改善を行う意識、デザインと実装の一致、SSOTの担保など

Slide 47

Slide 47 text

デザインシステム組織事例課題があった以前の体制デザイナーとエンジニアのロールが明確に分かれており、規模の大きな組織のためお互いの関わりが疎でしたE @ お互いがどのような課題を抱えているのか把握出来ていなP @ どのような状態が望ましいのかがわからなP @ そもそも課題だと認識出来ていないこの状態は「良いデザイン」を「効率的により早く」「品質をより高く」ユーザーに届ける事ができなくなってしまう要因

Slide 48

Slide 48 text

デザインシステム組織方針感じている課題を共有するのが一歩いきなりデザインから開発まで全体を見通して課題を洗い出そうとするのは難しいです。まずは抱えている課題をお互いに共有して、理想の状態を一緒になって考えましょう。その課題がエンジニアに限ったものなのか、それとも根本を同じとする課題をデザイナーも抱えているのかが見えてきます。（逆もしかり）課題が提示されたとき、影響を自分たちが直接受けていないとしても、解決にコミットメントすることは重要です。影響を受けていないとしても、発生要因になっているかもしれません。それは一方にコストが偏っている状態なので、解決が必要です。

Slide 49

Slide 49 text

デザインシステム組織方針横断チームを作る「課題を共有して一緒に解決する」事を行うとデザインシステムに取り組む体制が必要なことに気づきます。課題解決はもちろんですが、そもそもの課題を発生させない仕組みを構築/維持することが重要です。デザインシステムには完成はなく、継続的な取り組みが必要です。チームには、できるだけ様々なロールから横断的に参加してもらえると良いです。 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

Slide 50

Slide 50 text

デザインシステム組織方針文化を醸成する体制の構築と文化の醸成はセットで必要デザインシステムの重要性を認識して、コミットメントする意識があったとしても体制が無ければ安定的に取り組むことが出来ません。また、逆に体制だけを用意しても目的意識を共有できて無いとドライブしません。様々なバックグラウンドのメンバーが参加すると、デザインシステムへの理解度や将来的イメージにバラツキが生じることもあります。有効な取り組 m お互いの業務に参加して解像度を高め m 輪読会などでのインプッj m ステークホルダーからの期待値や自分たちのバリューについてディスカッションする（MVVを定める）

Slide 51

Slide 51 text

ご清聴ありがとうございました！