$30 off During Our Annual Pro Sale. View Details »
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
デザインとエンジニアリングをつなぐコンポーネントの運用設計
Search
cawpea
February 08, 2019
Design
6
9.6k
デザインとエンジニアリングをつなぐコンポーネントの運用設計
# ThinkAtomicDesign でお話した資料です。
https://thinkatomicdesign.connpass.com/event/115574/
cawpea
February 08, 2019
Tweet
Share
More Decks by cawpea
See All by cawpea
組織で取り組むアクセシビリティのはじめ方
masakiohsumi
0
200
不確実なソフトウェア開発におけるUXエンジニアの意義と役割
masakiohsumi
9
14k
複雑なアプリケーションにオブジェクト指向UIで立ち向かう
masakiohsumi
28
120k
デザイナーとエンジニアの垣根を取り払う"デザインエンジニア"という考え方
masakiohsumi
7
4.5k
Other Decks in Design
See All in Design
そのUIコンポーネント、これから先も使えますか?―Headless UI,Open UI,グローバルデザインシステム
sakito
2
2.3k
見過ごさない誠実さ_アクティブバイスタンダーとIntegrityが支えるアジャイル文化 / integrity-and-active-bystander
spring_aki
1
220
プロダクトデザイナーに学ぶ、『見る気が起きる』ダッシュボードの作り方 / Creating Engaging Dashboards: Lessons from Product Designers
yamamotoyuta
0
210
Goodpatch Tour💙 / We are hiring!
goodpatch
31
920k
【MIXI MEETUP!ー TECH & DESIGN DAYー】新たなSNS「mixi2」の “0→1”開発の舞台裏:デザイナーが語るプロダクト誕生秘話
mixi_design
PRO
0
170
1年目デザイナーが実践する、チーム貢献のための2つのアプローチ
kinomidesign
0
130
見栄えと使いやすさの先にある 特別感 をデザインする / Designing a Sense of Specialness Beyond Aesthetics and Usability
bitkey
PRO
0
200
mount_company_profile
mount_inc
0
3.6k
企業にデザインが融けたとき、デザイナーにできること。事業会社12年間の探究と葛藤 / Designship2025
visional_engineering_and_design
0
1.1k
root COMPANY DECK / We are hiring!
root_recruit
1
25k
What makes a great Director?
_limex_
0
350
BXデザイン組織が挑んだスクラム 〜ブランドを育み、デザイナーを解放する変革の物語〜(Scrum Fest Mikawa 2025)
tadashiinoue
0
880
Featured
See All Featured
Designing Experiences People Love
moore
142
24k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
659
61k
GitHub's CSS Performance
jonrohan
1032
470k
GraphQLとの向き合い方2022年版
quramy
49
14k
We Have a Design System, Now What?
morganepeng
54
7.9k
Java REST API Framework Comparison - PWX 2021
mraible
34
9k
The Power of CSS Pseudo Elements
geoffreycrofte
80
6.1k
How To Stay Up To Date on Web Technology
chriscoyier
791
250k
Bash Introduction
62gerente
615
210k
Why You Should Never Use an ORM
jnunemaker
PRO
60
9.6k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
140
34k
Transcript
デザインとエンジニアリングをつなぐ コンポーネントの運⽤設計 2019/02/08 Masaki Osumi #ThinkAtomicDesign
cawpea Frontend Developer ⼤⾓ 将輝 - Masaki Osumi
None
免責事項 “Think Atomic Design”ですが、Atomic Designの話はしません。
• チーム開発におけるコンポーネントの運⽤課題 • コンポーネントの運⽤を改善するために⾏ったこと • コンポーネントを運⽤するときに考慮すること 今⽇お話しすること
チーム開発におけるコンポーネントの運⽤課題
開発の歴史 2017/9 ver2をリリース 2019/1現在 16ヶ⽉間 エンジニア(FE) UIデザイナー PO エンジニア(FE) UIデザイナー
PO
• デザイナー同⼠でコンポーネントのパターンやトンマナが微妙に異なる • エンジニア同⼠でコンポーネントを重複実装したり、分割の仕⽅が異なる 開発メンバーが増えたことで発⽣した問題 コンポーネントが増えすぎる UIの⼀貫性も失われる デザインと実装に 余計に時間がかかる
これ、そんなに時間かかりますか? 新しいコンポーネントが必要なので、 結構時間かかりそうです ここなんですけど、既存のコンポー ネントと違う理由なんですか? ここは◦◦の理由でこのデザインに しています。 既存コンポーネントがあるの知りま せんでした…。使い回しでOKです。 or
開発でしばしば⾒られる光景 PO エンジニア(FE) エンジニア(FE) UIデザイナー
PO エンジニア(FE) UIデザイナー 早く価値提供したい ユーザー体験よくしたい 開発効率よくしたい コンポーネントをめぐる争い
コンポーネントの運⽤を改善するために⾏ったこと
None
デザイナーはどのようにコンポーネントをデザインしているのか? エンジニアはどのようにコンポーネントを実装しているのか? お互いの考え⽅を共有し合い、それぞれの観点を踏まえて、 今後のコンポーネントの運⽤⽅法を設計
⼀貫性のあるUIを効率的に提供する •デザイナーが増えたり、⼊れ替わったりしても⼀貫性のあるUIを提供できること •都度実装するのではなく、再利⽤性を⾼めてスピーディーに機能が開発できること コンポーネントを運⽤する⽬的を定める
デザインガイドラインの策定 1. Design Principle プロダクトのデザインを考える上で基本となる思想について 2. Structure 情報のモデリング、ナビゲーション、モードの扱いについて 3. Skelton
画⾯内におけるペイン構成と各ペインの役割等について 4. Visual Design ⾊やアイコン、タイポグラフィ、ラベリング等について 5. UI Components プロダクトで扱うUI Componentについて デザイン思想の⾔語化
▼ 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
デザイン思想の⾔語化 ▼ Buttons ・使⽤⽅法 ・スタイルのパターンと意味 ・禁⽌事項
コンポーネントカタログ(Storybook)の整備 ▼ Controls ・Buttons ・Tabs ・Dropdown Menu ・Searchable Select Menu
・Text Field ・Check Box ・Radio Button ・Date Time Picker
共通の⽬的があることでコミュニケーションが円滑になる PO UIデザイナー エンジニア(FE) デザイン ガイドライン コンポーネント カタログ
コンポーネントを運⽤するときに考慮すること
ソフトウェアコンポーネント(Software Componentry)は、 ソフトウェアシステムの様々な機能を関⼼の分離によって分割したものである そもそもコンポーネントって何? ソフトウェアコンポーネント - Wikipediaより引⽤ https://ja.wikipedia.org/wiki/ソフトウェアコンポーネント ”
コンポーネント指向とは、ソフトウエアを機能ごとに部品(ソフトウエアコンポー ネント)として分割し、必要に応じて組み合わせて使うという考え⽅である そもそもコンポーネント指向って何? 組み込みでも始まったコンポーネント指向開発 | ⽇経 xTECH(クロステック)より引⽤ https://tech.nikkeibp.co.jp/it/article/COLUMN/20100528/348618/ ”
None
UIコンポーネントの構成要素
特異度を⾒極めるのは、モジュールデザインで最も難しいことのひとつです。 限定的にするほど再利⽤しにくくなります。逆に⾔えば、再利⽤されやすくするには、より汎⽤的にする必要があります。 限定的な部分が多いほどシステムの保守や⼀貫性の維持が難しくなりますが、 汎⽤的なモジュールが多すぎても平凡なデザインになります。パターンを定義するのに正しい⽅法はありません。 すべては何を達成したいか次第です。 限定的 汎⽤的 書籍[Design Systems デジタルプロダクトのためのデザインシステム実践ガイド]より引⽤
” UIコンポーネントの特異度
コンポーネントの運⽤について 調べてみよう もっと情報が⾒たいな… 操作 操作 UIコンポーネントはユーザーの関⼼事に基づく
• カプセル化 • ローカルスコープの獲得 • 交換可能性、再利⽤性の向上など • UIのパターン化 • ユーザーの認知、学習の効率化など
Webにおいてコンポーネント化するメリット デザイン観点のメリット 実装観点のメリット 構造 装飾 振る舞い
特定の⽬的に最適化させて独⾃性を⾼めたい 例:イベントサイト 独⾃性よりもUIの⼀貫性を重視したい 例:コンテンツ管理サイト プロダクトの性質として、デザイン観点のメリットがあるか考える 部分最適なデザイン = UIをパターン化しにくい 全体最適なデザイン =
UIをパターン化しやすい
ページ別にコンポーネントを分けて、 コンポーネントを交換しやすくする ページ全体でコンポーネントを統⼀して、 コンポーネントの⼀貫性・再利⽤性を⾼める デザインの⽅向性に合わせて、コードの設計を考える 特定の⽬的に最適化させて独⾃性を⾼めたい 例:イベントサイト 独⾃性よりもUIの⼀貫性を重視したい 例:コンテンツ管理サイト
組織の状態によっても適した運⽤⽅法は変わる デザイナーがコードを書ける、 エンジニアがデザインできる場合 デザイナーとエンジニアの距離がある 1⼈でコンポーネントのデザイン、実装が⾏える ただし、スピード感に限界がある デザイナーとエンジニアが それぞれ独⽴して動けるような運⽤の⽅が お互いラクな時もある
まとめ
・コンポーネントの現実的な運⽤⽅法はプロダクトや組織の状況によって変わる ・プロダクトの性質や⽬的からデザインの⽅向性、コードの設計を考えることができる ・私たちのチームではUIの⼀貫性と開発効率を重視して運⽤フローを設計 運⽤設計はみんなが関わることなので、まずはチームで対話してみるのがオススメ プロダクトや組織に合ったコンポーネントの運⽤⽅法を考えよう
ご静聴ありがとうございました。