デザインシステム導入時のフロントエンドの役割

最近はデザインシステムについて情報を集めている。

デザインシステムを導入するとなると、きっと前提条件が大きく異なる気がする。

クロスプラットフォーム環境下のサービス展開や、同一ブランドの複数サービスなど、共通のデザインルールを複数のサービスで活用することが考えられる環境でデザインシステムの導入が検討される。

デザインシステムを導入する場合、フロントエンドとしてのUIコンポーネント設計の重要性は上がる。

どのような手段が存在するのかキャッチアップを進めているが、同様の悩みを抱えている方々の記事が多くヒットした。

なんとか理想の環境が構築できそう。（どこかでまとめて気になったものは改めて紹介しようかな。）

デザインシステムのアーキテクチャ理想像

デザインシステムをデザインツールで運用するケースは少ないのではないだろうか。（ちゃんと運用されているケースは少ないだろう。） デザインツールでは、エンジニアとデザイナーの共通言語として利用することが難しいからだと思っている。

一例として、Storybookを導入するという手段がある。Storybookでデザインシステムを作成すると、コードやコンポーネントのAPI、コンポーネントのホバーやクリック時の挙動など動的なコンポーネントの状態をチェックすることができるので、エンジニア、デザイナーの共通言語として最適である。

導入に際して、作成したUIコンポーネントは共通パーツとして、複数のリポジトリで利用することができるアーキテクチャ構築が望ましい。

現在考えているのが、サービスのリポジトリとは別にStorybookなどを導入したUIコンポーネント用のリポジトリを用意して、サービスリポジトリはそれぞれ共通のUIコンポーネントリポジトリを参照することで、共通のコードを利用することができる。というものだ。

npm packageも考えたが、クローズドで利用することが想定されるので、まずはprivate GitHubリポジトリが作成できれば運用できそうなのでこちらの方が手軽な気がしている。

共通利用を想定したUIコンポーネント、デザインシステムは汎用性と、運用性が重要となる。 サービス別に使われ方の異なる利用方法を想定する必要があったり、特定のサービスでしか利用されないニッチな用途にも対応させる必要があり、これが難しい...。

Material-UIなどUIコンポーネントサービスを参考に勉強しているが、改めてこれらの偉大さに気がつく。。

デザインシステムは誰が管理するのか、UIコンポーネントのアップデート時の運用フローはどうするのかなど、やらないといけないことは山積みだ。 ただ、肝心のデザインシステムを作るデザイナーがどのようにこれを作っていくかというのは少し気掛かりなところでもある。

運用性を考えてきたエンジニアとしての役割

きっと、デザイナーはコンポーネント作成後、画面にした場合のマッチ度によっては微調整を加えるということも大いにあるだろう。 そのようなケースで生まれるイレギュラーなデザインがデザインシステムには脅威となる。

極論を言えば、デザインシステムとワイヤーフレームがあれば、デザイナーの想像通りの画面が出来上がる状態が理想と言える。

これまで行ってきた、デザインとデザインシステムのデザインの考え方は異なると思っている。 どちらかというとエンジニアの思考に近いのではないだろうか。

もちろんビジュアルの部分は変わらないと思うが、デザインシステムとする時に必要な事が、エンジニア側の思考が必要になる気がしている。

日々、運用を目的としたコンポーネント抽象化を行ってきたエンジニアがやるべきポイントが多くあるのではないだろうか。 エンジニアとして密にデザイナーにコミュニケーションを取りに行ったほうがいいし、なんなら、デザイン着手前からコミュニケーションはよく取るべきだろう。

最低でも、マークアップタグで表現されるUIパーツは作成しておくべきだろうし、想定されるデザインパターンもある程度洗い出しておく必要があるはずだ。

うまく言語化するのは難しいが、どこかでうまく記事にできればその時にしっかりまとめよう。

何にハードルを感じるのかなどデザイナー側の意見も気になるところだ。