デザインシステムってめっちゃ難しいよね
ポエムです。何も解決しません。このサイトはpvとかメッセージとかないのでTwitterでください。
メンションとかつけてくれたら飛んできます。
今だったらもうちょいできるかもとか思いますが、未だによくわからん。
それでは本題。
（ポエムなので刺さないでね）
デザインシステムの導入理由
デザインシステム最近流行ってますよね。
実際弊社でもデザインシステムを作り始めています。
自分は特に関われていないので、単に自身の経験談になります。
この前のイベントの後の懇親会で話したりして整理できてきたのでまとめます。
デザインシステムの導入理由はいくつかあると思います。
大体ある程度複数だったり複雑な画面になってくると、社内や個人開発でもプロダクト間のデザインを統一したい欲が出てきます。
理由はいくつかあると思いますが主に以下の3点かなと思います。
- プロダクト間の統一感をつくりたい
- 適当に作ると、サービスごとに毛色が違いすぎるものができてしまう問題がある
- コンポーネントの再生産がだるい
- 色々なプロダクトで似たようなコンポーネントがある
- MUIとかじゃ満足できない
- 細かいところに手が届かず、細かいところの調整は複雑になる
よくあるやつだと思いますし、ある程度規模が大きくなってると問題になってきます。
一見するとデザインシステムはこれらの問題に対応できる銀の弾丸に見えます。
でもそううまく行かないことが多いです。
それぞれ自分の個人開発の中で破綻した流れを上げようと思います。
※ 何回かチャレンジしてるので、何回も失敗してるんですよねえ()
1. 神Atomicコンポーネント爆誕！！！
アトミックデザインでやりますってやったわけです。
アトミックデザインについては適当に調べてもらえるといいんですが、Atomicとは簡単にいうと超シンプルなボタンとかのイメージです。
原子なので当然ですね。
でも神コンポーネント化したんです。
なんでなのか？
最小単位のボタンをいろんな場所で呼ぼうとしたんです。
最小単位ですからね。
いろんなところから呼びますね。
あれ？
ここでは無効化が必要だぞ？
あれ？
ここだと、アイコンが欲しいぞ？？
あれ？
色は？サイズは？etc...
これもあるあるですね。はい。
ロジックは持つなとかラッパー作れとか色々思うところはありますが、その時の自分はこう思ったわけです。
プロダクト間で統一するならしゃあないよね？？
ボタンの単一機能の責任自体は逸脱してないし、、、
コード量多いけどview以外の責任持ってないしなあ
ラッパーは？？
ラッパー作りまくったら結局各プロダクト間で差が出るし統一感出なくね？？？って
はい。適当にやると大体複雑性に負けます。
特にプロダクトが多くて、やりたいことが違う場合その傾向が強い気がします。
例えばエンジニア向けのツールと一般ユーザー向けも違いますし、責任者とそれ以外など画面を意図的に変えたい場合があったりします。
統一すべき部分とあえてずらしたい部分。それを明確に分けて考えるべきです。
2. 多重ラッパー地獄
1の神コンポーネントを対策するために、機能を分割すれば良いと考えます。
例えばアイコンのあるボタンですね。
ボタンをラッパーするイメージで作ると簡単に破綻します。
なぜでしょうか？
元のコンポーネントを弄らないという絶対の意思を持たないといけないからです。
※これが意外とできないんですよね...
引数を弄らなければ比較的問題は小さいですが、どうしてもここをいじったらすぐ終わるのに！！！みたいなもどかしい状況は発生します。
オブジェクト指向で継承は使うな！みたいな言説が流行るように適当にラッパーを作り、複雑な木構造のような形になるともう終わりが近いです。
結局これは何をするものなの？となるわけです。
とはいえそこまで行くことはあまりないと思います。その一歩前で基本的に気がつくわけです。この先は地獄だぞと...
3. 結局再生産してる問題
これも機能を分割していけばいいじゃんというアプローチからことは始まります。
アイコンボタン、デリートボタン、サブミットボタン etc...
単一の目的に沿っていて良さそうです。
実際に使う時のユースケースを考えてみましょう。
イメージしてください。膨大な画面のボタンがずらっと並ぶボタンディレクトリを...
ここまで極端な例はないと思いますが、これによって困ることがあります。
何があるかわからない。どのタイミングで新しいコンポーネントが必要なのか？
また重複して作ってしまったりと結構面倒くさいです。
こんなにコンポーネント作ったのに各プロジェクトごとに欲しいものが違うと、あまり意味がありません。
また、デザインシステムのメンテ問題であったり、既存に組み込む場合のCSS衝突、各プロジェクトの中に気が付いたら重複するコンポーネントがいる etc...
と色々問題はあります。
自分の考え
自分としてはshadcn/uiあたりをデザインシステムの基準に則って設定を変えてやるぐらいで、あとはfixしてしまうのが良いのではと思っています。
MUIやBootstrapのようなフレームワークに従って作るのも良いかもしれません。
しかしTimePickerの値を5分以上で入力可能にするかゆい部分の修正が複雑になりがちであったりなど、色々と問題があります。
これらの問題を解決するために独自のフレームワークとしてデザインシステムを導入しようとしているのに、ガチガチに厳格に固めた結果うまくいかなくなるっていうのはもったいないです。
MUIだったりBootstrapを使うレベルで作る場合は、CSSなどで独自の色を出す程度にするのが良いとは思います。
個人的にMUIなどのガチガチのUIフレームワークはあんまり好きではないです。
流行るだけの理由があると思うので多分MUIを使いこなせていないだけだとは思うんですが、きっと何かしらのアプローチ方法は用意されていると思っています。
shadcn/uiはあくまでも例で、別に何でもいいと思うんです。
個人的にはカスタマイズが直感的にできるのが好きだといった感じです。
MUIでも独自のものでもBootstrapでも何でもいいはずです。
元も子もない話ですが、慣れているライブラリのデフォルトCSSを上書きするのが良いと考えています。
会社でデザインシステムを導入する場合は、どこまで厳格にコンポーネントを定義していくか、どこまでカスタマイズ性を求めるか。
そこに終始すると思うのでグラデーションですね。
MUIからshadcn/uiまでのそのグラデーションの中で、どこを落としどころとするかというのを事前に決めてから進めていくのがいいと思います。
自分は今後のカスタマイズ性だったりメンテナンス性だったり、そういったものを重視したいです。
なので比較的薄いラッパーで、ほとんど元々のフレームワークを変更せずに、ライブラリを変更せずに、CSSのデフォルトの部分を上書きしてやる程度に抑えるのが理想かなと考えています。
ある程度共通化しながらも独自色を出す、プロダクトごとに色を出すって言うことも重要になってくると思います。
なので、最低限だけ決めていくっていうのがいいのかなと考えています。
実際ここで取り上げた例って、あくまで例なので、そんなことならないよってものもあったりあると思うんですが。
UIのあらゆる要望に網羅的に対応することはできないし、あらゆる要望ってものも今後出てくると考えています。
求めるデザインというのはデザイナー次第であったり、自分の今の考え方によって全然変わってきてしまうものです。
それに対応できる柔軟性というものは今後も残したいっていうその意思に関しては変わらない気がします。
多分デザイントークンとか、API設計をちゃんとすればいけるとか色々あると思うんですが、そこまで仕事中に時間を割けなかったり、個人開発でモチベーションが上がらないことが多い気がしています。
デザインシステムは作った後に使う人がいて、メンテナンスが継続されて初めて有効になります。
ライブラリの破壊的なアップデートなどの脅威はあるものの、現状の個人的な解としては薄いラッパーが良いかなと考えています。
自分的にはshadcn/uiを導入しつつ、各プロダクトで色を出したい部分に関してはプロダクト内でさらにshadcn/uiをラッパーして、さらに細かく調整していくようなものを作っていくのがいいのかなと考えています。
まとめ
個人的に思うところとしては、ここら辺のデザインって言うところはほんとに難しいなぁというのがあるので、なるべく考えないようにしたいなぁっていうのは思ってますね。
なるべく逃げていいように作りたいっていうのがあります。
めっちゃでも難しいなぁっていうのも思うので、うまく動けている会社はすごい！と思う今日この頃です。
最近また個人開発熱があるので、またやってもいいかもしれないとか思ったりw