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.3k
デザインとエンジニアリングをつなぐコンポーネントの運用設計
# 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
28
110k
デザイナーとエンジニアの垣根を取り払う"デザインエンジニア"という考え方
masakiohsumi
7
4.4k
Other Decks in Design
See All in Design
ZKK_001.pdf
nicholaspegu
0
710
Commune_Brand_Guideline_JA
commune
1
150
Bridging the Design Gap: How Collaborative Modelling removes blockers to flow between stakeholders and teams @FastFlow conf
baasie
0
150
FANCL×CA流アプリリニューアルPJ 成功の秘訣とそのプロセス / dx-fancl-renewal
cyberagentdevelopers
PRO
2
240
美しいUIを作るために デザイナーが意識している ちょっとした考え方
yuichi_hara7
50
32k
portfolio
amitnk
1
120
地図・デザイン・可視化 −情報をわかりやすく伝えるために−
hjmkth
1
460
デザインからアプリ実装まで一貫したデザインシステムを構築するベストプラクティス
shuzo
13
5.8k
PMとデザイナーはニコイチ! メリットと具体的なアクション10選
mosmos_noki
1
1.1k
【Designship 2024|10.13】デザイン組織を進化させるための仕組み化の要諦
payatsusan213
1
490
シームレスな連携を実現するデザイントークンの設計と構築
amishiratori
0
310
Kim Possible - Crush
olgastoryboard
0
130
Featured
See All Featured
Optimising Largest Contentful Paint
csswizardry
33
2.9k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
355
29k
Side Projects
sachag
452
42k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
664
120k
Measuring & Analyzing Core Web Vitals
bluesmoon
1
38
The Language of Interfaces
destraynor
154
24k
Raft: Consensus for Rubyists
vanstee
136
6.6k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
328
21k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
37
1.8k
How To Stay Up To Date on Web Technology
chriscoyier
788
250k
Designing for Performance
lara
604
68k
VelocityConf: Rendering Performance Case Studies
addyosmani
325
24k
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の⼀貫性と開発効率を重視して運⽤フローを設計 運⽤設計はみんなが関わることなので、まずはチームで対話してみるのがオススメ プロダクトや組織に合ったコンポーネントの運⽤⽅法を考えよう
ご静聴ありがとうございました。