Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥
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
プロダクトデザイナーに学ぶ、『見る気が起きる』ダッシュボードの作り方 / Creating Engaging Dashboards: Lessons from Product Designers
yamamotoyuta
1
290
ユーザー体験は細部に宿る -ウィジェットQAの挑戦と気づき- / UX is in the details: Challenges and Learnings from Widget QA
bitkey
PRO
0
120
TWCP#21 UXデザインと哲学のはなし
shinn
0
150
Treasure_Hunting
solmetts
0
120
「自分の仕事はどこまで?」と問い続けたら。デザイナーの「視座」を考える
mukai_takeru
0
260
第4回関東Kaggler会LT HCD-Net人間中心設計スペシャリストが語るNotebookメダルの取り方
utm529f
0
1.7k
DESIGNEAST 2025 A-3
_kotobuki_
0
120
decksh object reference
ajstarks
2
1.5k
プロダクトリニューアルと同時に進める初めてのデザインシステム
techtekt
PRO
0
320
Figmaレクチャー会Part1 基本のき編@千株式会社 社内勉強会
designer_no_pon
0
170
これからの「Webデザイン」の話をしよう~デザイナーの私が考えるブロックテーマへの対応で変わりゆくデザインの価値~
ds35mm
0
440
ドルちゃん
design_dolphins
0
510
Featured
See All Featured
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
508
140k
Automating Front-end Workflow
addyosmani
1371
200k
Embracing the Ebb and Flow
colly
88
4.9k
Build your cross-platform service in a week with App Engine
jlugia
234
18k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
196
70k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
141
34k
How To Stay Up To Date on Web Technology
chriscoyier
791
250k
A Tale of Four Properties
chriscoyier
162
23k
Optimising Largest Contentful Paint
csswizardry
37
3.5k
Git: the NoSQL Database
bkeepers
PRO
432
66k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
231
22k
How GitHub (no longer) Works
holman
316
140k
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の⼀貫性と開発効率を重視して運⽤フローを設計 運⽤設計はみんなが関わることなので、まずはチームで対話してみるのがオススメ プロダクトや組織に合ったコンポーネントの運⽤⽅法を考えよう
ご静聴ありがとうございました。