Open17
デザインシステムを作っていく時に考えたこと
読みたい
"デザイン"ためじゃないデザインシステムとは?
デザインシステムはデザインとエンジニアリングが不可分であるプロダクト開発において生産性を向上するための手段
デザインシステムは「開発者」に何をもたらすのか?
妥当な意思決定を早めるための補助線であって、法律ではない。意思決定は現場での判断に委ねられる。
この規模のデザインシステムをスケールし続けられる秘訣は何か?
特定の誰かがオーナーシップを握っているわけではなく、プロダクト開発の各担当者が課題ベースで検討・議論を主導し反映する。
そもそもデザインシステムに必要な考え方とはなんだろう
確認する
MD3の要素を確認して、デザインシステムについて深堀りしたい
- シードカラー
- 100,200,,,
他に公開されているデザインシステム
参考にできれば。
MD3を確認するときに並行して読みたい記事
Interaction States
網羅性
デザインシステムを実現する取り組み
プロダクトデザインの考え方も絡めると戦略的
Q
カラースタイルが指定されているオブジェクトのカラーコードを確認するには?
A
右のサイドバーのInspectに切り替えてオブジェクトを選択する
デザインシステムのロードマップ
- Figmaのコメント機能の使い方
- issueみたいに課題管理したい
- コメントのしやすさ。返事のしやすさ。ディスカッションのしやすさ。
- まずは、Figmaコメント→Slackの通知orチャンネル連携にしたい。
- 参考) https://wentz-design.com/post/figma-how-to-use-comment/
- 開発しやすくするためにFigmaサイドに必要な状態
- 構築で必要なプロパティのスマートな参照方法
- スタイルの活用
- プロジェクト内の定数にしておく
- コンポーネントの活用
- プログラミングコードの再利用性をあげる
- 不要なプロパティを削減していくとか?
- 要素の両サイドに同じマージン置くならCenterでよいなど?:face_with_monocle:
- 将来的に発展させていくには、ロードマップ参考になるかも
デザインデータ作成時のレイヤー構造
ContentLayer:テキストなどのコンテンツを配置するレイヤー
StateLayer:状態によってスタイルを変えるレイヤー
BaseLayer:UIコンポーネント固有のスタイルを持つレイヤー
UI Stack という言葉らしい
元ネタ
こんな感じ?
switch (state) {
case UiStack.blank:
case UiStack.loading:
return CircularProgressIndicator();
case UiStack.showData:
return DataList();
case UiStack.partial:
return OnbordingContents();
case UiStack.emptyData:
case UiStack.error:
return Text(
state.message,
);
}
トークン管理に便利なプラグイン
Github連携する