Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
「REALITY」を支えるデザインシステム: 2年間にわたる挑戦の舞台裏
Search
gree_tech
PRO
October 25, 2024
Video
Technology
2
560
「REALITY」を支えるデザインシステム: 2年間にわたる挑戦の舞台裏
GREE Tech Conference 2024で発表された資料です。
https://techcon.gree.jp/2024/session/TrackC-6
gree_tech
PRO
October 25, 2024
Tweet
Share
Video
More Decks by gree_tech
See All by gree_tech
コミュニケーションに鍵を見いだす、エンジニア1年目の経験談
gree_tech
PRO
0
110
REALITY株式会社における開発生産性向上の取り組み: 失敗と成功から学んだこと
gree_tech
PRO
2
1.7k
『ヘブンバーンズレッド』におけるフィールドギミックの裏側
gree_tech
PRO
2
550
セキュリティインシデント対応の体制・運用の試行錯誤 / greetechcon2024-session-a1
gree_tech
PRO
1
550
『アナザーエデン 時空を超える猫』国内海外同時運営実現への道のり ~別々で開発されたアプリを安定して同時リリースするまでの取り組み~
gree_tech
PRO
1
520
『アサルトリリィ Last Bullet』におけるクラウドストリーミング技術を用いたブラウザゲーム化の紹介
gree_tech
PRO
1
600
UnityによるPCアプリの新しい選択肢。「PC版 Google Play Games」への対応について
gree_tech
PRO
1
960
実機ビルドのエラーによる検証ブロッカーを0に!『ヘブンバーンズレッド』のスモークテスト自動化の取り組み
gree_tech
PRO
1
620
"ゲームQA業界の技術向上を目指す! 会社を超えた研究会の取り組み"
gree_tech
PRO
1
740
Other Decks in Technology
See All in Technology
AWS CDK 実践的アプローチ N選 / aws-cdk-practical-approaches
gotok365
6
700
Agentic Workflowという選択肢を考える
tkikuchi1002
1
480
Azure AI Foundryでマルチエージェントワークフロー
seosoft
0
180
PHPでWebブラウザのレンダリングエンジンを実装する
dip_tech
PRO
0
200
【TiDB GAME DAY 2025】Shadowverse: Worlds Beyond にみる TiDB 活用術
cygames
0
1k
製造業からパッケージ製品まで、あらゆる領域をカバー!生成AIを利用したテストシナリオ生成 / 20250627 Suguru Ishii
shift_evolve
PRO
1
130
LinkX_GitHubを基点にした_AI時代のプロジェクトマネジメント.pdf
iotcomjpadmin
0
170
ひとり情シスなCTOがLLMと始めるオペレーション最適化 / CTO's LLM-Powered Ops
yamitzky
0
420
Amazon ECS & AWS Fargate 運用アーキテクチャ2025 / Amazon ECS and AWS Fargate Ops Architecture 2025
iselegant
16
5.3k
PHP開発者のためのSOLID原則再入門 #phpcon / PHP Conference Japan 2025
shogogg
4
680
急成長を支える基盤作り〜地道な改善からコツコツと〜 #cre_meetup
stefafafan
0
120
Windows 11 で AWS Documentation MCP Server 接続実践/practical-aws-documentation-mcp-server-connection-on-windows-11
emiki
0
930
Featured
See All Featured
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
29
9.5k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
45
7.4k
Gamification - CAS2011
davidbonilla
81
5.3k
Navigating Team Friction
lara
187
15k
RailsConf 2023
tenderlove
30
1.1k
How to Think Like a Performance Engineer
csswizardry
24
1.7k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
26k
The Language of Interfaces
destraynor
158
25k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
8
670
Documentation Writing (for coders)
carmenintech
71
4.9k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.9k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
790
Transcript
「REALITY」を支えるデザインシステム : 2年間にわたる挑戦の舞台裏 REALITY株式会社 飯尾 直樹 宮川 春菜
矢﨑 雄人 / Yazaki Yuto • 2017年グリー株式会社新卒入社 • 2022年4月からREALITY株式会社に転属 ◦
iOSエンジニア兼ストリームアラインドチームEM ◦ デザインシステム REALITY株式会社 エンジニアマネージャー 2
飯尾 直樹/ Iio Naoki • 2020年株式会社リブセンス新卒入社 ◦ サーバーエンジニア • 2022年3月からREALITY株式会社入社
◦ Androidエンジニア ◦ デザインシステム REALITY株式会社 Androidエンジニア 3
宮川 春菜 / Miyakawa Haruna • 2023年グリー株式会社新卒入社 ◦ REALITY株式会社配属 ▪
iOSエンジニア ▪ デザインシステム REALITY株式会社 iOSエンジニア 4
• REALITYの紹介 • デザインシステムの始動 • デザインシステム導入のステップ • デザインシステムの構築 • 導入による効果
• 継続する • まとめ 目次 5
REALITYの紹介 6
7
8
REALITYアプリのUI描画 9
ネイティブUIの実装箇所 • アバター以外の画面はほぼ全てネイティブUI ◦ iOS: SwiftUI, UIKit ◦ Android: Jetpack
Compose, XML 10 トップ ダークモード対応 プロフィール チャット Unity
デザインシステムの始動 11
サービス拡大によるデザイン上の課題 • サービス開始から7年目を迎えるREALITY ◦ チームメンバーの増加、アプリ機能の増加 • デザインの一貫性の担保・生産性の向上が課題に ◦ デザインデータと実装の乖離 ◦
画面毎の実装のバラツキ 12 似たデザインだけど共通化されていない...
デザインシステム導入プロジェクトが始動 (2022年中頃~) 13 GREE Tech Conference 2022 約2年を経て... REALITYのデザインシステムがどのようになったのかを話します。
デザインシステムとは デザインルールやUIコンポーネントを体系的に提供し、 プロダクト開発における一貫性と効率性を向上させる枠組。 14 【スタイルガイド】 デザインの基本的なルール。 Color, Typographyなどの定義をデザイントークンと呼ぶ。 【コンポーネントライブラリ】 再利用可能で汎用的なUIパーツとその集合体。
より上位概念としてのデザイン原則、 ブランドアイデンティティなど。 引用: https://www.hi-interactive.com/blog/design-systems-from-a-ux-perspective
デザインシステムの導入戦略 • 限られたリソース ◦ デザイナー2名、エンジニア(iOS, Android)各1名 全員兼務 ◦ その他の機能開発と並行して実施 •
網羅的なデザインシステムを一挙には作れない ◦ 完璧は目指さず、小さくインクリメンタルに進める • 課題感が高く、効果が高そうなところから ◦ デザインシステムを作ることを目的にせず、あくまでも課題ベースで ◦ まずはデザイントークンとコンポーネントを構築していく 15
デザインシステム導入のステップ 16
定義→実装→反映のサイクル 17 定義: Figmaで定義する。 パターンの列挙、命名、ガイドラインの明記など 実装: iOS・Androidのコードに落とし込む。 インタフェースの設計、デザインの実装 反映: プロダクトのFigmaデータ・コード実装の置き換え。
全てを置き換え or 新たに手をつける所から適用
定義→実装→反映サイクルの繰り返し 18 コンポーネント デザイントークン 定義 実装 反映 Color 定義 実装
反映 Typography 定義 実装 反映 Icon 定義 実装 反映 Button 定義 実装 反映 Checkbox 定義 実装 反映 Tabs 定義 実装 反映 List Item
デザインシステムの構築 19
デザイントークン 20 デザインシステムの構築 Color Margin Typography Size Space Icon Padding
Shadow
Typographyの定義 • テキストのウェイト、サイズ、行間、文字間隔などを定義 • ガイドラインを作成 ◦ どんな場面でどのTypographyを使うのか?を明文化 21
Typographyの実装 • 定義と実装が一致するようなインタフェース ◦ SwiftUIのView Modifierを用意 • Figmaからの自動書き出しはしなかった ◦ 頻繁に更新されるものではないため(更新があれば都度手動適用)
◦ → 自動化することに手間をかけすぎない 22 Text("REALITY Design System") .typography(.h1) Text("REALITY Design System") .typography(.body)
Typographyの反映 • Figmaのデザインデータは全てに適用 • コード実装は一括置換が難しく、全てを置き換えるのは大変 ◦ 新規実装のみデザインシステムを適用する運用に 23
Colorの定義 • 既存のカラーパレットを元に命名ルールを整備 ◦ コントラスト比が低いなど改善の余地はあったが... ◦ 既存カラーパレットのまま、風呂敷を広げすぎない 24
• Figmaからの自動書き出しはしなかった ◦ (Typographyと同様の理由で)更新頻度が低いため、自動化は後回し • 反映 ◦ カラー名の変更や調整がメインだったので、一括で全て置換 ◦ 後に、コントラスト比などを調整した新定義に変えてさらに一括置換
Colorの実装 25 VStack { Text("REALITY Design System") .typography(.h1) Text("REALITY Design System") .typography(.body) } .foregroundStyle(Color(.themeWhite)) .background(Color(.themePrimary))
Iconの定義 26 • 命名ルールを整備してガイドラインを作成 サイズのパターンを定義
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を追加
Iconの実装 28 Icon(.giftBox, .size24) Icon(.giftBox, .size48) .foregroundStyle(Color(.themeOrange))
その他のデザイントークンは...? • margin, size ◦ Figma側でガイドラインを作成したが、コード側での恩恵が少ないため実装は後回しに • shadow ◦ 使用箇所が少なかったので一旦後回しに
→ とにかく課題ベースで、効果の大きい所を優先する 29
30 そろそろこういうボタンが作れる? Icon Color Typography
「定義→実装→反映」サイクルの繰り返し 31 コンポーネント デザイントークン 定義 実装 反映 Color 定義 実装
反映 Typography 定義 実装 反映 Icon 定義 実装 反映 Button 定義 実装 反映 Checkbox 定義 実装 反映 List Item 定義 実装 反映 List Item
コンポーネントライブラリ 32 デザインシステムの構築 Checkbox Toggle Dialog List Button Form TextField
Buttonの定義 • 2パターン ◦ Text Button = テキスト and/or アイコン
◦ Icon Button = アイコン only • サイズとタイプを定義 ◦ ガイドラインを明文化 33
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)
こういうコンポーネントを作りたい... 35 不足しているコンポーネントを拡充する アプリのあらゆる画面で多用されているリストUI
User StatusとUser Iconを定義・実装 • ユーザーの状態に応じて変化する ◦ ライブ配信中、視聴中、オンライン、オフライン 36 User Status
User Icon
Badge, Checkbox, Toggleを定義・実装 37 Badge Checkbox Toggle
List Itemを定義 • 4パターンを用意 ◦ User / Icon / Image
/ Text List Item • 領域毎にコンポーネントをカスタマイズできる 38
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)
「定義→実装→反映」サイクルの繰り返し 40 コンポーネント デザイントークン 定義 実装 反映 Color 定義 実装
反映 Typography 定義 実装 反映 Icon 定義 実装 反映 Button 定義 実装 反映 Checkbox 定義 実装 反映 Tabs 定義 実装 反映 List Item
コンポーネントが充実してきた 41
様々な画面がコンポーネントの組み合わせで作れるようになった 42
デザインシステム導入による効果 43
開発者へのアンケート 44 デザインシステム導入による効果 対象: iOS, Androidアプリエンジニア 回答者数: 10名
デザインシステムのコンポーネントを使って UIを実装したことはありますか? 45
デザインシステムのコンポーネントを使用することで、 コードの品質や一貫性にどのような影響がありましたか? 46
デザインシステムのコンポーネントを使用することで、 実装スピードにどのような影響がありましたか? 47
ポジティブな回答が多数! 48
その他のご意見 (自由回答) 49 古い実装をもっと置き換 えていきたい とても助かってます :bow: xxの画面もコンポーネ ントで作り直したい paddingの定義も欲しい
ooのコンポーネントに 機能を追加して欲しい
参照箇所、コード削減の概算 50 デザインシステム導入による効果
参照箇所、コード削減の概算 • 本当にデザインの一貫性、生産性が上がったのか? ◦ 2年間続けてきて、改めて定量的に測ってみた 51 iOS Android 正確な数値ではなくても良いので、概算することで実感地が分かった
デザインシステムを継続する 52
• 直近の四半期でやりたいことをリスト化 ◦ 例: 今Qはxxコンポーネントの定義と実装をする。(反映をするのは来Qで) ◦ 定義→実装→反映のサイクルによってやる事が具体化しやすくなった • 課題や優先度をアップデートし続ける ◦
「取り掛かってみたら、想定より効果が見込めなさそうだったため他の事項を優先する」 などの軌道修正を細かくする 四半期毎に目標を立てる 53
小さいイテレーションを繰り返す • 大きい事を一気にやろうとしない ◦ プロジェクトメンバーは全員兼務 ▪ 手の空いた時に少しでも進められるように ◦ (物によっては、まとまった時間を確保する事もある) •
改善タスクとして他メンバーにも手伝ってもらう ◦ 「反映」の作業はコンテキストを知らなくても依頼しやすい ◦ オンボーディングのタスクとしても最適 54 定義 実装 反映 Component
まとめ 55
まとめ • 導入のステップ ◦ デザイントークン、コンポーネント毎に「定義→実装→反映」のサイクルを回す • 実装 ◦ コンポーネントの種類が増えていくことで、 様々な画面がコンポーネントの組み合わせで実装できるようになった
• デザインシステムの効果 ◦ 定性評価: デザインシステムが浸透していて、開発効率や品質が上がっている ◦ 定量評価: 多くの箇所で参照されており、コードの削減に役立っている • 目標を立てて継続する ◦ 小さいイテレーションを繰り返して積み重ねていく 56
None