デザインとエンジニアリングをつなぐコンポーネントの運用設計

Transcript

1. デザインとエンジニアリングをつなぐ コンポーネントの運⽤設計 2019/02/08 Masaki Osumi #ThinkAtomicDesign

2. cawpea Frontend Developer ⼤⾓ 将輝 - Masaki Osumi

3. None

4. 免責事項 “Think Atomic Design”ですが、Atomic Designの話はしません。

5. • チーム開発におけるコンポーネントの運⽤課題 • コンポーネントの運⽤を改善するために⾏ったこと • コンポーネントを運⽤するときに考慮すること 今⽇お話しすること

6. チーム開発におけるコンポーネントの運⽤課題

7. 開発の歴史 2017/9 ver2をリリース 2019/1現在 16ヶ⽉間 エンジニア(FE) UIデザイナー PO エンジニア(FE) UIデザイナー

   PO

8. • デザイナー同⼠でコンポーネントのパターンやトンマナが微妙に異なる • エンジニア同⼠でコンポーネントを重複実装したり、分割の仕⽅が異なる 開発メンバーが増えたことで発⽣した問題 コンポーネントが増えすぎる UIの⼀貫性も失われる デザインと実装に 余計に時間がかかる

9. これ、そんなに時間かかりますか？ 新しいコンポーネントが必要なので、 結構時間かかりそうです ここなんですけど、既存のコンポー ネントと違う理由なんですか？ ここは◦◦の理由でこのデザインに しています。 既存コンポーネントがあるの知りま せんでした…。使い回しでOKです。 or

   開発でしばしば⾒られる光景 PO エンジニア(FE) エンジニア(FE) UIデザイナー

10. PO エンジニア(FE) UIデザイナー 早く価値提供したい ユーザー体験よくしたい 開発効率よくしたい コンポーネントをめぐる争い

11. コンポーネントの運⽤を改善するために⾏ったこと

12. None

13. デザイナーはどのようにコンポーネントをデザインしているのか？ エンジニアはどのようにコンポーネントを実装しているのか？ お互いの考え⽅を共有し合い、それぞれの観点を踏まえて、 今後のコンポーネントの運⽤⽅法を設計

14. ⼀貫性のあるUIを効率的に提供する •デザイナーが増えたり、⼊れ替わったりしても⼀貫性のあるUIを提供できること •都度実装するのではなく、再利⽤性を⾼めてスピーディーに機能が開発できること コンポーネントを運⽤する⽬的を定める

15. デザインガイドラインの策定 1. Design Principle  プロダクトのデザインを考える上で基本となる思想について 2. Structure  情報のモデリング、ナビゲーション、モードの扱いについて 3. Skelton

     画⾯内におけるペイン構成と各ペインの役割等について 4. Visual Design  ⾊やアイコン、タイポグラフィ、ラベリング等について 5. UI Components  プロダクトで扱うUI Componentについて デザイン思想の⾔語化

16. ▼ Controls ・Buttons ・Tabs ・Dropdown Menu ・Searchable Select Menu ・Text

    Field ・Check Box ・Radio Button ・Date Time Picker ▼ Buttons ・使⽤⽅法 ・スタイルのパターンと意味 ・禁⽌事項 デザイン思想の⾔語化 1. Design Principle 2. Structure 3. Skelton 4. Visual Design 5. UI Components

17. デザイン思想の⾔語化 ▼ Buttons ・使⽤⽅法 ・スタイルのパターンと意味 ・禁⽌事項

18. コンポーネントカタログ(Storybook)の整備 ▼ Controls ・Buttons ・Tabs ・Dropdown Menu ・Searchable Select Menu

    ・Text Field ・Check Box ・Radio Button ・Date Time Picker

19. 共通の⽬的があることでコミュニケーションが円滑になる PO UIデザイナー エンジニア(FE) デザイン ガイドライン コンポーネント カタログ

20. コンポーネントを運⽤するときに考慮すること

21. ソフトウェアコンポーネント（Software Componentry）は、 ソフトウェアシステムの様々な機能を関⼼の分離によって分割したものである そもそもコンポーネントって何？ ソフトウェアコンポーネント - Wikipediaより引⽤ https://ja.wikipedia.org/wiki/ソフトウェアコンポーネント ”

22. コンポーネント指向とは、ソフトウエアを機能ごとに部品（ソフトウエアコンポー ネント）として分割し、必要に応じて組み合わせて使うという考え⽅である そもそもコンポーネント指向って何？ 組み込みでも始まったコンポーネント指向開発 | ⽇経 xTECH（クロステック）より引⽤ https://tech.nikkeibp.co.jp/it/article/COLUMN/20100528/348618/ ”

23. None

24. UIコンポーネントの構成要素

25. 特異度を⾒極めるのは、モジュールデザインで最も難しいことのひとつです。 限定的にするほど再利⽤しにくくなります。逆に⾔えば、再利⽤されやすくするには、より汎⽤的にする必要があります。 限定的な部分が多いほどシステムの保守や⼀貫性の維持が難しくなりますが、 汎⽤的なモジュールが多すぎても平凡なデザインになります。パターンを定義するのに正しい⽅法はありません。 すべては何を達成したいか次第です。 限定的 汎⽤的 書籍[Design Systems デジタルプロダクトのためのデザインシステム実践ガイド]より引⽤

    ” UIコンポーネントの特異度

26. コンポーネントの運⽤について 調べてみよう もっと情報が⾒たいな… 操作 操作 UIコンポーネントはユーザーの関⼼事に基づく

27. • カプセル化 • ローカルスコープの獲得 • 交換可能性、再利⽤性の向上など • UIのパターン化 • ユーザーの認知、学習の効率化など

    Webにおいてコンポーネント化するメリット デザイン観点のメリット 実装観点のメリット 構造 装飾 振る舞い

28. 特定の⽬的に最適化させて独⾃性を⾼めたい 例：イベントサイト 独⾃性よりもUIの⼀貫性を重視したい 例：コンテンツ管理サイト プロダクトの性質として、デザイン観点のメリットがあるか考える 部分最適なデザイン = UIをパターン化しにくい 全体最適なデザイン =

    UIをパターン化しやすい

29. ページ別にコンポーネントを分けて、 コンポーネントを交換しやすくする ページ全体でコンポーネントを統⼀して、 コンポーネントの⼀貫性・再利⽤性を⾼める デザインの⽅向性に合わせて、コードの設計を考える 特定の⽬的に最適化させて独⾃性を⾼めたい 例：イベントサイト 独⾃性よりもUIの⼀貫性を重視したい 例：コンテンツ管理サイト

30. 組織の状態によっても適した運⽤⽅法は変わる デザイナーがコードを書ける、 エンジニアがデザインできる場合 デザイナーとエンジニアの距離がある 1⼈でコンポーネントのデザイン、実装が⾏える ただし、スピード感に限界がある デザイナーとエンジニアが それぞれ独⽴して動けるような運⽤の⽅が お互いラクな時もある

31. まとめ

32. ・コンポーネントの現実的な運⽤⽅法はプロダクトや組織の状況によって変わる ・プロダクトの性質や⽬的からデザインの⽅向性、コードの設計を考えることができる ・私たちのチームではUIの⼀貫性と開発効率を重視して運⽤フローを設計 運⽤設計はみんなが関わることなので、まずはチームで対話してみるのがオススメ プロダクトや組織に合ったコンポーネントの運⽤⽅法を考えよう

33. ご静聴ありがとうございました。