ReactやAngular/Angular2の台頭によって、WebクライアントサイドはビューをUIコンポーネントの粒度で開発して、最終的に画面を構成する、という形式が一般的になってきたように思います。
今ではこれはWebクライアントサイドに限った話ではなくて、React Nativeをはじめ、Flutterなど、iOSやAndroidのアプリケーションを作るためのこれらのフレームワークでも同じことが言えます。
この開発スタイルをたびたび「UIコンポーネント指向」と呼んだりします。これは画面ごとの開発における、開発面にとどまらない様々な問題が顕在化してきた結果、自然な流れとして行き着いた先という風に僕には見えます。
(この話のデザイナー視点での説明を@tyshgcさんがこちらにまとめていらっしゃいます。)
エンジニアとデザイナーは考え方が違う
UIコンポーネント指向な開発と対比になるのは、画面ごとの開発だと思います。jQueryが盛んに用いられていた頃のWeb開発はこの形でした。しかしながらこれは古い新しいの問題ではないと思います。
デザイナーはどちらかと言うと全体から考える傾向にあります。大まかな構成、つまりレイアウトを考えてから少しずつ中にあるパーツを作り込んでいきます。
「部品を作りましょう」と指示しても手を動かせないデザイナーがいたとしても、それは才能がないからではなく、逆立ちして作れと言われているように聞こえるからだと思います。
via. 協働のためのデザイン思考の再構築
エンジニアリングの観点からは、細分化されたモノを組み合わせて構成していくのは当たり前の考え方ですが、デザイナーにとってはそうではないようです。
とはいえ、これはコミュニケーション上の問題を引き起こす原因になりかねないように思います。ですので、ここでは少しでもエンジニアリングの気持ちがわかるように、エンジニアリングからみたUIコンポーネント指向について伝えられればと思います。
UIコンポーネントとは何を指すのか
まずは、「UIコンポーネント」という言葉について少しだけはっきりさせます。UIコンポーネントとは、ボタンやフォーム、ナビゲーションなどの「画面を構成するUIの部品」を指します。UIコンポーネントの中には別のUIコンポーネントが入っていることもあります。
アプリケーションやWebサイトの画面を構成する要素を分解していくと、複数のUIの部品で画面が構成されていると考えることができるようになります。これがUIコンポーネント指向で、視点の方向を細部から全体にして、パーツから全体を組み立てる考え方です。
スタイルはUIコンポーネントが持つ
画面の中のUIは、現実世界のモノを例える形でデザインされていることが多いです(ここではスキュアモーフィズムやフラットデザインなどの流行の変遷については便宜上無視します)。
当然ながら、「ボタン」というUIコンポーネントがあるなら、それは現実世界のボタンスイッチと同じような役割を果たす見た目をしています。たとえば、下記のようなスタイルを持っているでしょう。
- 背景色がついている(透明かもしれない)
- アイコンまたはテキストを内包している
- 中に余白がある
- 影や立体感がある、など
ユーザー入力があることを知っている
UIコンポーネントの中には、クリック/タップ、マウスホバー、スワイプ、キーボード入力などの操作を受け付けるものもあります。これらをユーザー入力やイベントと呼んだりします。
UIコンポーネントは、これらのユーザー入力があることと、その種類を知っています。先ほどの「ボタン」は、まさにクリックやタップ、マウスホバーを受け付けるUIコンポーネントです。
しかしながら、再利用性の観点から、「クリックされた時に何をするか」には関心しません。役割や操作ごとに機能の異なる同じようなボタンを作るよりも、あるボタンを色々な役割や操作に適用させ再利用する方が効率的です。
様々な使われ方に対応する
同じ「ボタン」というUIコンポーネントは、一般的なアプリケーションやWebサイトではいろんな場面で何度も出てくるでしょう。機能や文脈に合わせて何種類もの同じようなUIコンポーネントを作るよりも、1種類のUIコンポーネントがいろんな場面で使いまわせるようになっていた方がいいでしょう。
そのため、UIコンポーネントは細かい調整ができるようになっているべきです。たとえばボタンのUIコンポーネントを「色=赤」として用いれば、それは「赤いボタン」になります。テキストやアイコンなども可変であるべきです。
他にも、ポップアップダイアログを「閉じられる=YES」として用いれば、「右上に×ボタンのついたポップアップダイアログ」などというバリエーションもあるでしょう。
このような再利用性は、ボタンに限りません。どんなUIコンポーネントも応用が効くようになっていれば、プロダクトの改善スピードが上がります。
プロダクトの中に存在する「モノ」
また、アプリケーションやWebサイト中には、紐解いていくと色んな「モノ」が存在します。TwitterのツイートというUIコンポーネントでは、「ユーザー」と「ツイート」という少なくとも2つのモノを用いて表現することがわかります。
この概念的な「モノ」をデザイナーとエンジニアで紐解いていくのも、これからは大切だと思います。ユーザーが操作できるUIの多くは、本質的には「『何』を『どう』するのか」という操作の視覚的な表現だとも考えられます。
コミュニケーションコストの省力化
エンジニアリングとデザインの協業においては、UIコンポーネント指向な設計の方がコミュニケーションコストが下がるかもしれません。
たとえば、画面ごとのデザインガイドラインは必要なくなります。より簡易的な、「どこにどのUIコンポーネントを設置するか」という情報だけで済むからです。
そもそも今となっては、単位としての「画面」とは実に曖昧に思えます。モーダレスなポップアップダイアログと、レイヤーのように上に被さるUIのような2つの概念に対して、感覚的な差別化しかできないからです。
代わりに、UIコンポーネントごとのデザインガイドラインを作ればいいのです。これは、コミュニケーションの粒度が細かくなっていると考えることもできます。
複雑性を細分化する
コミュニケーションの粒度が細かくなると、発生する問題も細かくなります。1つ1つの解決が早くなり、総量の認識が容易で、分担もしやすくなります。問題になる前に気付きやすくもなります。
僕らが作るプロダクトは年々複雑さを増しています。そんな中で、開発工程すら複雑なままものづくりを続けていたら、どんどん問題が出てくるでしょう。考慮漏れ、伝達網羅性の担保、そこからくる認識のズレ、設計上の矛盾など、挙げるとキリがありません。
どんな開発手法でも、同じように問題は起きます。UIコンポーネント指向も万能ではありません。しかし、問題は解決しなければなりません。解決のためのアプローチとして、複雑性を細分化することで問題を少なく、そして解決を早くできるのはUIコンポーネント指向のメリットと言えるかもしれません。
お互いのことを知ろう
デザイナーにとって、エンジニアと協働しやすくするために、エンジニアリングからみたUIコンポーネント指向について説明しました。同様に、エンジニアもデザイナーの考え方ややり方を理解していくべきだと思います。
ひとまずは、この記事を読んだ方々にとって、UIコンポーネント指向な設計についての理解の助けになれば幸いです。Design For User #2 — コンポーネント指向から考えるUIと設計でこのテーマについて喋りました。内容は同じですが、共有などに活用していただければ嬉しいです。
この記事について何か意見があれば、コメント欄などで是非教えてください。よろしくお願いします。
