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.4k
デザインとエンジニアリングをつなぐコンポーネントの運用設計
# ThinkAtomicDesign でお話した資料です。
https://thinkatomicdesign.connpass.com/event/115574/
cawpea
February 08, 2019
Tweet
Share
More Decks by cawpea
See All by cawpea
不確実なソフトウェア開発におけるUXエンジニアの意義と役割
masakiohsumi
9
14k
複雑なアプリケーションにオブジェクト指向UIで立ち向かう
masakiohsumi
28
120k
デザイナーとエンジニアの垣根を取り払う"デザインエンジニア"という考え方
masakiohsumi
7
4.4k
Other Decks in Design
See All in Design
一人ひとりのポテンシャルを活かしたナレッジマネジメントとは?
atsushihomma
0
370
ito aya Portfolio
itoaya116
0
120
#yumemi_grow 読書シェア会 vol.1 - スコット・バークン著『デザインはどのように世界をつくるのか』
kaitou
1
120
Rayout Pattern 01
one0
0
1.6k
LayerX DesignersDeck
layerx
PRO
0
3.5k
Managing Design Systems (Antwerp 2024)
nathanacurtis
1
400
The Very Small Creatures - dressing up warm sequence
lizziestoryboards
0
240
今更聞けないデザイン思考 - 高専キャリア2024冬 / imasara-design-thinking
chige
5
940
pixel-art-skill-and-knowhow/ドット絵の経歴と知見
aokashi
0
230
Generating Momentum | Yasuhiro Yokota
yasuhiroyokota
1
280
実践ゼロから作らないデザインシステム SaaS × デザインシステム × プロダクトデザイン / Efficient Design System for SaaS—no need to start from scratch.
kaminashi
2
970
誰もがAIエージェントを"操作"したがる〜AIエージェントに求められるUX〜
ikeyatsu
2
1.2k
Featured
See All Featured
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
GraphQLの誤解/rethinking-graphql
sonatard
69
10k
A Tale of Four Properties
chriscoyier
158
23k
BBQ
matthewcrist
87
9.5k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
160
15k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
47
5.3k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
176
52k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
8
680
Fantastic passwords and where to find them - at NoRuKo
philnash
51
3.1k
Art, The Web, and Tiny UX
lynnandtonic
298
20k
Measuring & Analyzing Core Web Vitals
bluesmoon
6
280
For a Future-Friendly Web
brad_frost
176
9.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の⼀貫性と開発効率を重視して運⽤フローを設計 運⽤設計はみんなが関わることなので、まずはチームで対話してみるのがオススメ プロダクトや組織に合ったコンポーネントの運⽤⽅法を考えよう
ご静聴ありがとうございました。