デザインシステムとコンポーネントライブラリを作っていた経験を振り返って

普遍的なものを作るって難しいよね。という話

先日のInside Frontendでデザインシステムの話をみて、「そういや似たようなことをやってたな」とふと思い出しました。

walk-diagonally.hatenablog.com

せっかくなので前職でデザインシステムや社内向けコンポーネントライブラリを作っていた内容をちょっとまとめて振り返ってみます。
正直具体的な解決策はあまりない気がします。
なんせ難しいもの・・・

＊まとめて書こうかと思いましたが一旦難しかったところだけ書きます。時間ができたらupdate
＊デザインシステムやコンポーネントライブラリ作成の作業をいいかんじに抽象化して記載ができなかったので、これも時間ができたらupdate

デザインシステム

難しかったこと

イレギュラーケースが出てくる

当たり前以外の何者でもなく恐縮ですが・・・
一回ある程度決まりごとを作っても、サービスで新機能追加や改善をしていくと当初作ったルールと整合性が整わなくなってくる。

対処法

• 頑張って先を見据えて用意しておく
  なんだか脳筋みたいな書き方ですがこんなかんじかなと・・・
  「Statusカラー」みたいな定義をしたとします。
  初期で想定できるところとして Primary Warning Danger が必要だとなったときに、直近は必要ないとしても Default みたいなものも用意しておく、とかができたらいいのかなと思います。

• ルール化するところを極力イレギュラーケースが出ないレベル感で設定する
  上のStatusカラーみたいな例でいうと、そもそもStatusカラーなんて定義をもたいないで、「実装で作っていい色一覧」みたいなかんじで使っていいカラーを列挙しておくといったところにとどめておくとイレギュラーケースとかの対応はないのかなと思いました(ex: Default でもないまた別のStatus定義が必要になった、といったときもそのカラー一覧から選んで使うだけで済むといったかんじ)
  ＊もちろんStatusみたいなところはちゃんと定義はされておくべきだと思います。ドメイン毎でPrimaryの色が違いすぎると迷うと思うので。

いざ実装してみたら実態とあわない

デザインとして完成したものをいざ実装してみたらうまくいかないことって多いですよね

対処法

• 単なる平面のデザインではなく、モック/プロトタイピングで作る
  理想ですよね。
  正直自分はデザイナーではないので、昨今のツールたちでどこまで簡単にできるのかとかはわかってませんが、ちょっとしたアニメーションとか動きとかつけれるならそっちのほうがいいかなと思います。
• フロントエンド側もデザインを見たタイミングで動きをイメージする いわゆる歩み寄って気になった点を実装する前になくせるといいですね、というところで。

コンポーネントライブラリ

難しかったこと

良かれと思って修正したら誤爆する

今でこそtypescriptがメジャーな手段になってきたところですが、その前のお話だったので、普通のjsでした。
また、いろいろなサービスで使われてしまっていて、なおかつそのサービス内で魔改造されていたりもしたので、余計な誤爆があったりしました。

対処法

• typescriptを使う
  言わずもがなです。React使うならpropTypesもちゃんと定義して、固めるところはしっかり固めたほうがいいです。
• testを書く
  値のやりとりに関してはinputとoutputの担保を一旦しておけば、クリティカルなデグレを引き起こすことはなくなると思います。
  ただし、このあたりはtypescriptで保証されるかもしれないところなので、書き方によってはやらなくてもいいかもしれません。
  でも書いといて損はないと思います。
  見た目に関してもデモサイトを作ってE2Eテストするのいいのかなと思います
• サポートポリシー的なものを明確化してもよかったかなと
  結局jsなのでなんぼでも魔改造できてしまいます。そこで、こーゆーことするなよ、そんなことをして今後ライブラリをupdateした際に「デグレだ」と言われても対処しません、というような内容を明文化してもいいのかなと思いました。
  ただし、お客様に関係します とか言われたらもうどうしようもないので、やはりこの手の口約束のようなものは難しいです。

汎用性をどこまで / どこに持たせるか

汎用性を高めすぎると上にあるように修正したら誤爆、みたいなことを引き起こす可能性があるかと思います。

対処法

• できれば汎用性は持たせないようにする
  デザイン側で必要な要素を列挙、ライブラリがそれらを実現できるように充足するようにして実装者がいじれる余地を極力減らしたほうがいいかと思います。

ライブラリする化範囲

Atomic Designでいう Atoms なのか Molecules までやるのか、みたいなところの悩みが多かったです。
あとは良かれと思って「コンポーネントの引数にURL渡して、サーバーサイドをこんなかんじで実装したらいいかんじに実装できるよ！」みたいなコンポーネントもあったのですが、いろいろな社内政治に巻き込まれたりでメンテンナンスがめちゃくちゃ大変になったりしました。

対処法

• あくまで画面描画のところのみライブラリとしてサポートする
  普通の人からしたら「当たり前では？」みたいなことだと思いますが、その当たり前を普通にやったほうがいいかなと思いました。
  実装する人たちは結局みんなサーバーサイドの連携まで使うし、同様の仕組みで使うからそれならセットで提供したほうがいいとは思いますが、ホントにイレギュラーが少なかったり、そのコンポーネントのアップデートが少ないなら一式で提供してもいいのかなと思います。
  個人的には長期的に考えるとどこかで綻びが出てきてサポートが大変になるように思います
  ＊現に大変でした。実装側の実装が悪かっただけにも関わらず「コンポーネントの不具合な気がする」みたいなかんじで問い合わせがきたりもしてお互いが不幸だったように思います

• 組み合わせのコンポーネントに関しても極力一式では提供しない
  上に書いてある内容と似たようなかんじになるのですが、提供するものが増えると結局後々大変になってくる気がするので、組み合わせのコンポーネントは あえて用意しない ようにしてもいいのかなと思います。
  ユースケースとしてどう実装したらいいか、みたいなサンプルコードを用意するのはいいかもしれません。

共通

難しかったこと

実際に使う開発者が知らない

せっかく作っても認知されていない

対処法

永遠の課題の一つではないかなと思ってます。
以下がいいところなんじゃないかなと。
- 定期的にMTGなり共有会なりして知らしめる
- コードに埋め込めるものは埋め込んで、各開発者があまり意識する必要がない状態にする

ドキュメント化 / ドキュメント更新のコストをどう下げるか

タイトルの通り。

対処法

極力コード(jsDocとか)から生成できるように寄せる
まあいまならstorybookとかあるんで幾分かマシにはなったと思います

また思い出したタイミングで追記します(多分)