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
デザインとエンジニアリングをつなぐコンポーネントの運用設計
Search
cawpea
February 08, 2019
Design
6
9.1k
デザインとエンジニアリングをつなぐコンポーネントの運用設計
# ThinkAtomicDesign でお話した資料です。
https://thinkatomicdesign.connpass.com/event/115574/
cawpea
February 08, 2019
Tweet
Share
More Decks by cawpea
See All by cawpea
不確実なソフトウェア開発におけるUXエンジニアの意義と役割
masakiohsumi
9
13k
複雑なアプリケーションにオブジェクト指向UIで立ち向かう
masakiohsumi
27
110k
デザイナーとエンジニアの垣根を取り払う"デザインエンジニア"という考え方
masakiohsumi
7
4.3k
Other Decks in Design
See All in Design
Climb Visual Development
rkendrick25
0
100
間違った「問い」を乗り越え ノベルティをプチバズりさせた話
takaikanako
0
1.1k
コラボレーションを小さくはじめ、大きく広める - 相互理解のためのデザイン&開発交流会, Friends of Figma Tokyo
yasuhiroyokota
2
1k
Apple提供アプリのナビゲーションバーアイテムクイズ / 20231110-hig
uhooi
1
160
#コムデナ vol.2 「初めてのデザインカンファレンス協賛!共有したい3つのやらかし」
kiyoshifuwa
1
280
root Design Partnership Policy
root_recruit
0
3.4k
Backlogのイロハ・ やさしい使い方(基本編)
wattlaa
0
280
Métricas de UX - Reflexões sobre o uso de dados numéricos no contexto de UX
videlvequio
0
120
デザインに関わる全ての人たちでエベレスト登頂を目指すために取り組んでいること
amishiratori
0
520
社内のコミュニケーション課題に対して個人的に行っているデザイン以外の草の根活動
sugiyama_sukedachi
0
120
意志と、デザインと、ときどきお金
transit_kix
2
1.9k
2024デザすぷVol.4 新年会/ Design Sprout Bar vol-4
root_recruit
1
260
Featured
See All Featured
Building Better People: How to give real-time feedback that sticks.
wjessup
350
18k
The Mythical Team-Month
searls
214
42k
Side Projects
sachag
451
41k
Into the Great Unknown - MozCon
thekraken
10
830
The Brand Is Dead. Long Live the Brand.
mthomps
48
22k
Reflections from 52 weeks, 52 projects
jeffersonlam
343
19k
Become a Pro
speakerdeck
PRO
8
4.4k
A better future with KSS
kneath
230
16k
A Philosophy of Restraint
colly
195
15k
Documentation Writing (for coders)
carmenintech
59
3.8k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
12
1.4k
Why You Should Never Use an ORM
jnunemaker
PRO
50
8.6k
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の⼀貫性と開発効率を重視して運⽤フローを設計 運⽤設計はみんなが関わることなので、まずはチームで対話してみるのがオススメ プロダクトや組織に合ったコンポーネントの運⽤⽅法を考えよう
ご静聴ありがとうございました。