デザインシステム はじめの一歩

Transcript

1. デザインシステム はじめの一歩 2023.11.18 Yuuri Isogai
2. 自己紹介 株式会社 Fusic デザイナー 礒谷 悠莉Yuuri Isogai 2021年1月にFusicの社内1人目デザイナーとして入社。 BtoB/BtoC問わず、WebシステムやモバイルアプリのUIデザインを 主に担当。お客さんと一緒にサービスフローの設計を行ったり、UX デザインの領域でも奮闘中。ReactやTypescriptで実装することも 好きで、Figmaで設計したコンポーネントをひたすらStorybookに 構築することが趣味。 1
3. 本題に入る前に 0 2
4. 3 デザインシステムに興味はあるものの どんなものかはピンと来ていない… 導入はしたいけれど 何から手を付けて良いか分からない
5. 4 デザインシステムに興味はあるものの どんなものかはピンと来ていない… 導入はしたいけれど 何から手を付けて良いか分からない なんとなく雰囲気が掴めた はじめの一歩を踏み出せそう！
6. アジェンダ 5 1 デザインシステムをなんとなく知る 2 一歩を踏み出すための流れ
7. デザインシステムをなんとなく知る 1 6
8. デザインシステムをなんとなく知る 7 Q1. そもそもデザインシステムとは何者なんだ…
9. デザインシステムをなんとなく知る 8 デジタル庁 デザインシステム https://www.figma.com/community/file/1255349027535859598/design-system-1-4-0
10. デザインシステムをなんとなく知る 9 デジタル庁 デザインシステム https://www.figma.com/community/file/1255349027535859598/design-system-1-4-0
11. デザインシステムをなんとなく知る 10 一貫したデザインや操作性で ウェブサイトやアプリを提供するための仕組み デジタル庁HP デザインシステム https://www.digital.go.jp/policies/servicedesign/designsystem
12. デザインシステムをなんとなく知る 11 Q2. デザインシステムを導入するメリットは？
13. デザインシステムをなんとなく知る 12 たとえばこんなメリットが挙げられます 一貫性の担保 再利用性の向上
14. デザインシステムをなんとなく知る 13 たとえばこんなメリットが挙げられます 一貫性の担保 再利用性の向上 ユーザーの学習コストを軽減することができ、 サービスをより使いやすいと感じてもらうことができる デザインや実装時の工数が減ることで、 より時間をかけたい工程に時間を割くことができる
15. デザインシステムをなんとなく知る 14 Q3. どんな内容で構成されているの？
16. デザインシステムをなんとなく知る 15 一般的には以下のようなもので構成されていることが多い スタイルガイド UIコンポーネント デザイン原則 ドキュメント
17. デザインシステムをなんとなく知る 16 デジタル庁 デザインシステム https://www.figma.com/community/file/1255349027535859598/design-system-1-4-0
18. デザインシステムをなんとなく知る 17 デジタル庁 デザインシステム https://www.figma.com/community/file/1255349027535859598/design-system-1-4-0
19. デザインシステムをなんとなく知る 18 Q4. こんなすごいデザインシステムを設計するのに何億年かかるの…
20. デザインシステムをなんとなく知る 19 何億年もかかるどころか、製品やサービスの成長などに伴って デザインシステムも変化し続けるのではないだろうか？
21. デザインシステムをなんとなく知る 20 というわけで 何億年もかかるどころか、製品やサービスの成長などに伴って デザインシステムも変化し続けるのではないだろうか？
22. デザインシステムをなんとなく知る 21 というわけで 何億年もかかるどころか、製品やサービスの成長などに伴って デザインシステムも変化し続けるのではないだろうか？ まずは身近で必要最低限なものから 少しずつ始めてみる
23. 一歩を踏み出すための流れ 2 22
24. 一歩を踏み出すための流れ 23 2 エンジニアとデザイナーでこまめに会話する 1 最優先の課題に対する最小の解決策を考える
25. 一歩を踏み出すための流れ 24 要件定義 仕様決定 開発開始前MTG デザイン レビュー 実装前MTG 実装
26. 一歩を踏み出すための流れ 25 実装前MTG 実装 要件定義 仕様決定 開発開始前MTG デザイン レビュー エンジニアと一緒に打ち合わせに参加 サービスやシステムで叶えたいことをヒアリング イメージを図説しながら仕様のすり合わせ・提案
27. 一歩を踏み出すための流れ 26 要件定義 仕様決定 開発開始前MTG デザイン レビュー 実装前MTG 実装 前提条件をエンジニアとデザイナーとですり合わせ
28. 一歩を踏み出すための流れ 27 要件定義 仕様決定 開発開始前MTG デザイン レビュー 実装前MTG 実装 前提条件をエンジニアとデザイナーとですり合わせ 使用するコンポーネントライブラリの有無、種類 → 「近しいけど流用はできない挙動が多かったので、結局ほぼフルスクラッチになってしまった…」を減らすことができる →　使用する場合は、デザインシステムを考える際にライブラリに合わせて最初から行うと実装と連携しやすくなる
29. 一歩を踏み出すための流れ 28 要件定義 仕様決定 開発開始前MTG デザイン レビュー 実装前MTG 実装 前提条件をエンジニアとデザイナーとですり合わせ 使用するコンポーネントライブラリの有無、種類 デザインが必要な範囲の確認 → 「近しいけど流用はできない挙動が多かったので、結局ほぼフルスクラッチになってしまった…」を減らすことができる →　使用する場合は、デザインシステムを考える際にライブラリに合わせて最初から行うと実装と連携しやすくなる → 「そういえばこの画面なかった…いろいろ破綻した…」を減らすことができる
30. 一歩を踏み出すための流れ 29 要件定義 仕様決定 開発開始前MTG デザイン レビュー 実装前MTG 実装 プロジェクトの状況や制約に応じて最優先の課題に対する最小の解決策を考える
31. 一歩を踏み出すための流れ 30 要件定義 仕様決定 開発開始前MTG デザイン レビュー 実装前MTG 実装 プロジェクトの状況や制約に応じて最優先の課題に対する最小の解決策を考える 最優先の課題に対する最小の解決策事例 モバイルアプリの画面が3つ必要。開発期間がとても短い。 PoC開発を通して価値検証を行い、プロジェクトが本格始動する場合は改めてブランディングやコンセプトについても検討する。 →　とにかく使いやすいUIで動くものを作るスピードが最優先 →　コンセプトの打ち出しは最低限に抑え、UIの分かりやすさに必要不可欠なスタイルだけ設計
32. 一歩を踏み出すための流れ 31 要件定義 仕様決定 開発開始前MTG デザイン レビュー 実装前MTG 実装 プロジェクトの状況や制約に応じて、最小最優先の課題と解決策を検討 最小最優先の体験談 モバイルアプリの画面が3つ必要。開発期間がとても短い。 価値検証の後に、プロジェクトが本格始動する場合は改めてブランディングやコンセプトについても検討する。 →　とにかく使いやすいUIで動くものを作るスピードが最優先 →　コンセプトの打ち出しは最低限に抑え、UIの分かりやすさに必要不可欠なスタイルだけ設計
33. 一歩を踏み出すための流れ 32 要件定義 仕様決定 開発開始前MTG デザイン レビュー 実装前MTG 実装 プロジェクトの状況や制約に応じて、最小最優先の課題と解決策を検討 最小最優先の体験談 モバイルアプリの画面が3つ必要。開発期間がとても短い。 価値検証の後に、プロジェクトが本格始動する場合は改めてブランディングやコンセプトについても検討する。 →　とにかく使いやすいUIで動くものを作るスピードが最優先 →　コンセプトの打ち出しは最低限に抑え、UIの分かりやすさに必要不可欠なスタイルだけ設計 エンジニアがインブラウザデザイン 再利用しそう 再利用しそう 再利用しそう 最低限お客さんのブランドイメージを訴求したい テキストのベースカラー 一番大切なアクション
34. 35 33 要件定義 仕様決定 開発開始前MTG デザイン レビュー 実装前MTG 実装 プロジェクトの状況や制約に応じて、最小最優先の課題と解決策を検討 最小最優先の体験談 モバイルアプリの画面が3つ必要。開発期間がとても短い。 価値検証の後に、プロジェクトが本格始動する場合は改めてブランディングやコンセプトについても検討する。 →　とにかく使いやすいUIで動くものを作るスピードが最優先 →　コンセプトの打ち出しは最低限に抑え、UIの分かりやすさに必要不可欠なスタイルだけ設計 補足テキスト 基本テキスト 項目タイトル 画面タイトル
35. 一歩を踏み出すための流れ 34 要件定義 仕様決定 開発開始前MTG デザイン レビュー 実装前MTG 実装 こまめにエンジニアにレビューしてもらう
36. 一歩を踏み出すための流れ 35 要件定義 仕様決定 開発開始前MTG デザイン レビュー 実装前MTG 実装 こまめにエンジニアにレビューしてもらう コンポーネントの切り分け方、画面遷移やインタラクションなど →　データの渡し方などからコンポーネントの切り分け方を調整してほしいなどの相談もこまめに発生する →　状態別で不足しているデザインをこまめに気付ける
37. 一歩を踏み出すための流れ 36 要件定義 仕様決定 開発開始前MTG デザイン レビュー 実装前MTG 実装 こまめにエンジニアにレビューしてもらう コンポーネントの切り分け方、画面遷移やインタラクションなど コンポーネント名やデザイントークンの命名など →　データの渡し方などからコンポーネントの切り分け方を調整してほしいなどの相談もこまめに発生する →　状態別で不足しているデザインをこまめに気付ける →　デザインデータのコンポーネント名＝実装に近付くほどStorybook等がなくても参照がしやすい
38. 一歩を踏み出すための流れ 37 要件定義 仕様決定 開発開始前MTG デザイン レビュー 実装前MTG 実装 こまめにエンジニアにレビューしてもらう コンポーネントの切り分け方、画面遷移やインタラクションなど コンポーネント名やデザイントークンの命名など →　データの渡し方などからコンポーネントの切り分け方を調整してほしいなどの相談もこまめに発生する →　状態別で不足しているデザインをこまめに気付ける →　デザインデータのコンポーネント名＝実装に近付くほどStorybook等がなくても参照がしやすい
39. 一歩を踏み出すための流れ 38 要件定義 仕様決定 開発開始前MTG デザイン レビュー 実装前MTG 実装 最新の認識をすり合わせたり、実装に関わる情報を共有する
40. 一歩を踏み出すための流れ 39 要件定義 仕様決定 開発開始前MTG デザイン レビュー 実装前MTG 実装 最新の認識をすり合わせたり、実装に関わる情報を共有する デザインファイル全体の配置や、システム化したもの・していないものの共有 →　デザイン作業の合間に配置を整理して場所が変わったりしがちなので、最終的にどこに何があるか説明する →　コンポーネントライブラリの使用が前提だった場合、何がライブラリに沿っていて、何がオリジナルなのか
41. 一歩を踏み出すための流れ 40 要件定義 仕様決定 開発開始前MTG デザイン レビュー 実装前MTG 実装 最新の認識をすり合わせたり、実装に関わる情報を共有する デザインファイル全体の配置や、システム化したもの・していないものの共有 FigmaであればDev ModeやProperty機能など、開発を効率化できる操作について共有 →　デザイン作業の合間に配置を整理して場所が変わったりしがちなので、最終的にどこに何があるか説明する →　コンポーネントライブラリの使用が前提だった場合、何がライブラリに沿っていて、何がオリジナルなのか
42. 一歩を踏み出すための流れ 41 要件定義 仕様決定 開発開始前MTG デザイン レビュー 実装前MTG 実装 エンジニア・デザイナーそれぞれがお互いのコードをレビュー デザインの反映に関わるPR コンポーネント構築に関わるPR
43. まとめ 3 42
44. まとめ 43 2 エンジニアとデザイナーでこまめに会話する 1 最小最優先の課題と解決策を言語化する
45. まとめ 44 エンジニアとデザイナーのよりよいコラボについてとても興味があります Figma → Storybook → Chromaticのフローについてとても興味があります デザインシステムに一緒に思いを馳せる仲間がほしいです
46. ご清聴いただきありがとうございました Thank you ;) We are Hiring ! https://recruit.fusic.co.jp/