Slide 1

Slide 1 text

「REALITY」を支えるデザインシステム : 2年間にわたる挑戦の舞台裏 REALITY株式会社 飯尾 直樹 宮川 春菜

Slide 2

Slide 2 text

矢﨑 雄人 / Yazaki Yuto ● 2017年グリー株式会社新卒入社 ● 2022年4月からREALITY株式会社に転属 ○ iOSエンジニア兼ストリームアラインドチームEM ○ デザインシステム REALITY株式会社 エンジニアマネージャー 2

Slide 3

Slide 3 text

飯尾 直樹/ Iio Naoki ● 2020年株式会社リブセンス新卒入社 ○ サーバーエンジニア ● 2022年3月からREALITY株式会社入社 ○ Androidエンジニア ○ デザインシステム REALITY株式会社 Androidエンジニア 3

Slide 4

Slide 4 text

宮川 春菜 / Miyakawa Haruna ● 2023年グリー株式会社新卒入社 ○ REALITY株式会社配属 ■ iOSエンジニア ■ デザインシステム REALITY株式会社 iOSエンジニア 4

Slide 5

Slide 5 text

● REALITYの紹介 ● デザインシステムの始動 ● デザインシステム導入のステップ ● デザインシステムの構築 ● 導入による効果 ● 継続する ● まとめ 目次 5

Slide 6

Slide 6 text

REALITYの紹介 6

Slide 7

Slide 7 text

7

Slide 8

Slide 8 text

8

Slide 9

Slide 9 text

REALITYアプリのUI描画 9

Slide 10

Slide 10 text

ネイティブUIの実装箇所 ● アバター以外の画面はほぼ全てネイティブUI ○ iOS: SwiftUI, UIKit ○ Android: Jetpack Compose, XML 10 トップ ダークモード対応 プロフィール チャット Unity

Slide 11

Slide 11 text

デザインシステムの始動 11

Slide 12

Slide 12 text

サービス拡大によるデザイン上の課題 ● サービス開始から7年目を迎えるREALITY ○ チームメンバーの増加、アプリ機能の増加 ● デザインの一貫性の担保・生産性の向上が課題に ○ デザインデータと実装の乖離 ○ 画面毎の実装のバラツキ 12 似たデザインだけど共通化されていない...

Slide 13

Slide 13 text

デザインシステム導入プロジェクトが始動 (2022年中頃~) 13 GREE Tech Conference 2022 約2年を経て... REALITYのデザインシステムがどのようになったのかを話します。

Slide 14

Slide 14 text

デザインシステムとは デザインルールやUIコンポーネントを体系的に提供し、 プロダクト開発における一貫性と効率性を向上させる枠組。 14 【スタイルガイド】 デザインの基本的なルール。 Color, Typographyなどの定義をデザイントークンと呼ぶ。 【コンポーネントライブラリ】 再利用可能で汎用的なUIパーツとその集合体。 より上位概念としてのデザイン原則、 ブランドアイデンティティなど。 引用: https://www.hi-interactive.com/blog/design-systems-from-a-ux-perspective

Slide 15

Slide 15 text

デザインシステムの導入戦略 ● 限られたリソース ○ デザイナー2名、エンジニア(iOS, Android)各1名 全員兼務 ○ その他の機能開発と並行して実施 ● 網羅的なデザインシステムを一挙には作れない ○ 完璧は目指さず、小さくインクリメンタルに進める ● 課題感が高く、効果が高そうなところから ○ デザインシステムを作ることを目的にせず、あくまでも課題ベースで ○ まずはデザイントークンとコンポーネントを構築していく 15

Slide 16

Slide 16 text

デザインシステム導入のステップ 16

Slide 17

Slide 17 text

定義→実装→反映のサイクル 17 定義: Figmaで定義する。 パターンの列挙、命名、ガイドラインの明記など 実装: iOS・Androidのコードに落とし込む。 インタフェースの設計、デザインの実装 反映: プロダクトのFigmaデータ・コード実装の置き換え。 全てを置き換え or 新たに手をつける所から適用

Slide 18

Slide 18 text

定義→実装→反映サイクルの繰り返し 18 コンポーネント デザイントークン 定義 実装 反映 Color 定義 実装 反映 Typography 定義 実装 反映 Icon 定義 実装 反映 Button 定義 実装 反映 Checkbox 定義 実装 反映 Tabs 定義 実装 反映 List Item

Slide 19

Slide 19 text

デザインシステムの構築 19

Slide 20

Slide 20 text

デザイントークン 20 デザインシステムの構築 Color Margin Typography Size Space Icon Padding Shadow

Slide 21

Slide 21 text

Typographyの定義 ● テキストのウェイト、サイズ、行間、文字間隔などを定義 ● ガイドラインを作成 ○ どんな場面でどのTypographyを使うのか?を明文化 21

Slide 22

Slide 22 text

Typographyの実装 ● 定義と実装が一致するようなインタフェース ○ SwiftUIのView Modifierを用意 ● Figmaからの自動書き出しはしなかった ○ 頻繁に更新されるものではないため(更新があれば都度手動適用) ○ → 自動化することに手間をかけすぎない 22 Text("REALITY Design System") .typography(.h1) Text("REALITY Design System") .typography(.body)

Slide 23

Slide 23 text

Typographyの反映 ● Figmaのデザインデータは全てに適用 ● コード実装は一括置換が難しく、全てを置き換えるのは大変 ○ 新規実装のみデザインシステムを適用する運用に 23

Slide 24

Slide 24 text

Colorの定義 ● 既存のカラーパレットを元に命名ルールを整備 ○ コントラスト比が低いなど改善の余地はあったが... ○ 既存カラーパレットのまま、風呂敷を広げすぎない 24

Slide 25

Slide 25 text

● Figmaからの自動書き出しはしなかった ○ (Typographyと同様の理由で)更新頻度が低いため、自動化は後回し ● 反映 ○ カラー名の変更や調整がメインだったので、一括で全て置換 ○ 後に、コントラスト比などを調整した新定義に変えてさらに一括置換 Colorの実装 25 VStack { Text("REALITY Design System") .typography(.h1) Text("REALITY Design System") .typography(.body) } .foregroundStyle(Color(.themeWhite)) .background(Color(.themePrimary))

Slide 26

Slide 26 text

Iconの定義 26 ● 命名ルールを整備してガイドラインを作成 サイズのパターンを定義

Slide 27

Slide 27 text

Iconの自動書き出し 27 https://speakerdeck.com/yutoyazaki/automate-image-export-from-figma-to-ios-and-android-using-figma-export Xcode Figma GitHub Actions などのCI Android Studio 各リポジトリへPRを作成 新しいIconを追加

Slide 28

Slide 28 text

Iconの実装 28 Icon(.giftBox, .size24) Icon(.giftBox, .size48) .foregroundStyle(Color(.themeOrange))

Slide 29

Slide 29 text

その他のデザイントークンは...? ● margin, size ○ Figma側でガイドラインを作成したが、コード側での恩恵が少ないため実装は後回しに ● shadow ○ 使用箇所が少なかったので一旦後回しに → とにかく課題ベースで、効果の大きい所を優先する 29

Slide 30

Slide 30 text

30 そろそろこういうボタンが作れる? Icon Color Typography

Slide 31

Slide 31 text

「定義→実装→反映」サイクルの繰り返し 31 コンポーネント デザイントークン 定義 実装 反映 Color 定義 実装 反映 Typography 定義 実装 反映 Icon 定義 実装 反映 Button 定義 実装 反映 Checkbox 定義 実装 反映 List Item 定義 実装 反映 List Item

Slide 32

Slide 32 text

コンポーネントライブラリ 32 デザインシステムの構築 Checkbox Toggle Dialog List Button Form TextField

Slide 33

Slide 33 text

Buttonの定義 ● 2パターン ○ Text Button = テキスト and/or アイコン ○ Icon Button = アイコン only ● サイズとタイプを定義 ○ ガイドラインを明文化 33

Slide 34

Slide 34 text

Buttonの実装 ● SwiftUI標準のButtonにView Modifierを用意 ○ 定義外のボタンが作れないようなインタフェース 34 Button("Button") { // do something... } .textButton(type: .primary, size: .h24) Button("Button") { // do something... } .textButton(icon: .heart, type: .secondary, size: .h32) Button("") { // do something... } .iconButton(icon: .heart, type: .negative, size: .h48)

Slide 35

Slide 35 text

こういうコンポーネントを作りたい... 35 不足しているコンポーネントを拡充する アプリのあらゆる画面で多用されているリストUI

Slide 36

Slide 36 text

User StatusとUser Iconを定義・実装 ● ユーザーの状態に応じて変化する ○ ライブ配信中、視聴中、オンライン、オフライン 36 User Status User Icon

Slide 37

Slide 37 text

Badge, Checkbox, Toggleを定義・実装 37 Badge Checkbox Toggle

Slide 38

Slide 38 text

List Itemを定義 ● 4パターンを用意 ○ User / Icon / Image / Text List Item ● 領域毎にコンポーネントをカスタマイズできる 38

Slide 39

Slide 39 text

List Itemを実装に落とし込む 39 UserListItem(imageUrls: [url], userStatus: .live, username: ...) .followButton(isFollowing: $isFollowing) .icon(.cross, onTap: {}) UserListItem(imageUrls: [url], userStatus: .viewing, username: ...) .noticeBadge(.number(200)) UserListItem(imageUrls: [url], userStatus: .online, username: ...) .iconButton(.comment, onTap: {}) .iconButton(.hand, onTap: {}) IconListItem(.bell, text: "プッシュ通知") .rightText("オン") .icon(.rightArrow2) TextListItem(text: "通知を受け取る") .toggle(isOn: $isOn)

Slide 40

Slide 40 text

「定義→実装→反映」サイクルの繰り返し 40 コンポーネント デザイントークン 定義 実装 反映 Color 定義 実装 反映 Typography 定義 実装 反映 Icon 定義 実装 反映 Button 定義 実装 反映 Checkbox 定義 実装 反映 Tabs 定義 実装 反映 List Item

Slide 41

Slide 41 text

コンポーネントが充実してきた 41

Slide 42

Slide 42 text

様々な画面がコンポーネントの組み合わせで作れるようになった 42

Slide 43

Slide 43 text

デザインシステム導入による効果 43

Slide 44

Slide 44 text

開発者へのアンケート 44 デザインシステム導入による効果   対象: iOS, Androidアプリエンジニア 回答者数: 10名

Slide 45

Slide 45 text

デザインシステムのコンポーネントを使って UIを実装したことはありますか? 45

Slide 46

Slide 46 text

デザインシステムのコンポーネントを使用することで、 コードの品質や一貫性にどのような影響がありましたか? 46

Slide 47

Slide 47 text

デザインシステムのコンポーネントを使用することで、 実装スピードにどのような影響がありましたか? 47

Slide 48

Slide 48 text

ポジティブな回答が多数! 48

Slide 49

Slide 49 text

その他のご意見 (自由回答) 49 古い実装をもっと置き換 えていきたい とても助かってます :bow: xxの画面もコンポーネ ントで作り直したい paddingの定義も欲しい ooのコンポーネントに 機能を追加して欲しい

Slide 50

Slide 50 text

参照箇所、コード削減の概算 50 デザインシステム導入による効果

Slide 51

Slide 51 text

参照箇所、コード削減の概算 ● 本当にデザインの一貫性、生産性が上がったのか? ○ 2年間続けてきて、改めて定量的に測ってみた 51 iOS Android 正確な数値ではなくても良いので、概算することで実感地が分かった

Slide 52

Slide 52 text

デザインシステムを継続する 52

Slide 53

Slide 53 text

● 直近の四半期でやりたいことをリスト化 ○ 例: 今Qはxxコンポーネントの定義と実装をする。(反映をするのは来Qで) ○ 定義→実装→反映のサイクルによってやる事が具体化しやすくなった ● 課題や優先度をアップデートし続ける ○ 「取り掛かってみたら、想定より効果が見込めなさそうだったため他の事項を優先する」 などの軌道修正を細かくする 四半期毎に目標を立てる 53

Slide 54

Slide 54 text

小さいイテレーションを繰り返す ● 大きい事を一気にやろうとしない ○ プロジェクトメンバーは全員兼務 ■ 手の空いた時に少しでも進められるように ○ (物によっては、まとまった時間を確保する事もある) ● 改善タスクとして他メンバーにも手伝ってもらう ○ 「反映」の作業はコンテキストを知らなくても依頼しやすい ○ オンボーディングのタスクとしても最適 54 定義 実装 反映 Component

Slide 55

Slide 55 text

まとめ 55

Slide 56

Slide 56 text

まとめ ● 導入のステップ ○ デザイントークン、コンポーネント毎に「定義→実装→反映」のサイクルを回す ● 実装 ○ コンポーネントの種類が増えていくことで、 様々な画面がコンポーネントの組み合わせで実装できるようになった ● デザインシステムの効果 ○ 定性評価: デザインシステムが浸透していて、開発効率や品質が上がっている ○ 定量評価: 多くの箇所で参照されており、コードの削減に役立っている ● 目標を立てて継続する ○ 小さいイテレーションを繰り返して積み重ねていく 56

Slide 57

Slide 57 text

No content