見出し画像

UI設計の解像度を少し高める【コンポーネント編】

くれほ

サービスを作る際に必ず行っていくUIの設計。考慮していくポイントはフェーズによって様々ですが、プロセスの目的を理解し、必要に応じてそれらの取捨選択を行えるようになれば、プロダクトの着実なレベルアップに繋がってくるのではないかと考えております。

今回は、コンポーネント周りで自分自身が考えている事をつらつらと書いていこうかと思います。

----------------

今回話す「コンポーネント」とは

簡単に言うと「UIの部品」のことです。
サイトを分解してみると、ヘッダーやフッダーなどの大きめの部品から、ボタンやテキストエリアなどの小さい部品まで、様々な部品がそれぞれ繋がって１つのサービスになっている事がわかるかと思います。
そういった様々な部品のことを今回はコンポーネントとよんでいきます。

----------------

代表的なコンポーネントの利用目的を把握する

まずは、代表的なコンポーネントの大まかな利用目的について把握していきましょう。これらを把握した上で適切な選択ができるようになれば、目的に沿ったUIの設計や、サービスを作る際に考える戦略を画面にまで落とし込むことの実現に一歩近づくのではないかと考えております。
逆にコンポーネントの目的を把握せずに制作を実施してしまうと、複雑な操作や一貫性のない体験を作り出し、ミスリードやサービス離脱の原因を生み出すことに繋がってしまいます。
利用目的を把握し、それらを適切に利用する事が世の中に浸透していくサービスを創り出す第一歩になるのではないかと思っています。

ヘッダー

ヘッダーはすべてのページの上部に共通して表示されるコンポーネントです。共通して上部に配置されるため、アクセスしやすく、誰もが目にする重要な領域です。繰り返し見られることでメリットのあるものや、サイトとしてプライオリティの高いページへのアクセス経路として活用されます。
サービスのロゴやメインコンテンツへ遷移するリンクなどが配置されることが多いです。

フッター

フッターはすべてのページの下部に共通して表示されるコンポーネントです。ページの最下部の要素となるため、コンテンツの優先順位は低くなってしまいますが、利用者がページ内で行う主要な体験を行った後に閲覧される事が多い領域であるため、ある程度の情報を組み込んでも全体の体験を阻害しにくいといった特徴があります。そのためサービス全体を把握するためのコンテンツ、導線の配置や各ページに共通して配置したい情報を載せておく領域としてよく活用されています。

【 活用例 】
・ページ情報や著作権などの表示
・サイトマップを配置しサイトの全体像を表示
・コンタクト情報を表示　など

ナビゲーション

異なる階層の画面に移動したり、階層は同じものの、違ったコンテキストとなる画面に移動するために利用するコンポーネントです。
このナビゲーションが上手に設計されていると利用者はサービスの概要が容易に把握できたり、スムーズな回遊を行えるようになります。
（ナビゲーションの種類によって、サービスの概要の把握を促進するものとスムーズな回遊を実現するものが異なってきます。利用者にどの状況でどの情報を与えていく必要があるのかをユースケースなどを元に検討しながら配置していく事でより快適な体験の実現ができるものと考えています。）

ボタン

ボタンはアクションを起こす場面や、入力を完了させる場面など、ユーザーとシステムを繋ぐシーンでは必ず用いられる重要なコンポーネントです。大きく2種類に分けて活用していきます。

【 プライマリボタン 】
画面において、もっとも重要なアクションをするためのボタンです。1画面に対して1つというのが基本的な考え方です。
【 セカンダリボタン 】
同一画面内で、2番目以降に重要なアクションをするためのボタンです。取り消しやキャンセルといった、ユーザーがアクションを進めるうえで必要ではありながら、重要性はプライマリボタンほど高くない場合に用います。

また、機能が内包されていて、利用用途がある程度定まっているボタンが4種類存在します。それぞれ利用方法によって使い分けていきましょう。

【 チェックボックス 】
複数の候補から任意の数を選ぶ場合に利用する。
【 ラジオボタン 】
複数の候補（選択肢が少ない場合）からどれか1 つを選ぶ場合に利用する。
【 セレクトボタン 】
複数の候補（選択肢が多い場合）からどれか1 つを選ぶ場合に利用する。
【 スイッチボタン 】
1 つの項目に対してオン、オフをする場合に利用する。

テキストフィールド

テキストフィールドはユーザーが文字情報を入力するためのコンポーネントです。サーチバーなどで使われている1 行のパターンと、記事や文章を書く時に利用される複数行のパターンが存在します。

モーダル

元の画面の上に被せて一時的に確認や操作をさせるためのコンポーネントです。モーダルは、表示されたタスクが完了するまでユーザーは他の作業を行えないような性質があるため、現在のプロセスを続けるのに不可欠な情報がある場合に利用します。

ページネーション

ページネーションは繰り返す要素が１画面に収まりきれない場合に続きを表示するためのコンポーネントです。PC画面では表示領域がある程度担保されているのでナンバリングされたクリッカブル要素多数のページネーションが多く見られます。一方SP画面は表示領域もある程度限られてくるため、前のページへ戻るための要素と次のページへ進む要素の２要素で構成されているコンポーネントを多く見かけます。

--------------

コンポーネントの構築方法を知る

代表的なコンポーネントの利用目的を大まかに把握したら、次は構築方法について知っていきましょう。今回はコンポーネントの構築でデファクトスタンダードとなりつつある、Atomic Designという方法論に則って構築方法を説明していきます。

Atom(原子)

Atomは配色やフォントの定義をはじめ、ボタンやフォームのパーツ単位など UIの最小要素が該当する要素となります。
Atom単体だと抽象的でどういう意味を持つかは分かりません。

Molecule（分子）

MoleculesはAtomを組み合わせて作る要素です。
Moleculesになることで、Atomであった要素が結合されて意味を持つ単一コンポーネントとなります。

Organism（有機体）

Organismは複数のAtom、Molecule、Organismを組み合わせて形成されます。実際のものでいえば、ヘッダー、フッターなどの粒度のコンポーネントがこちらに該当します。

Template（テンプレート）

ここから少し、概念が変わります。
今までは要素を指すものでしたが、ここからはページ構造を表すものとなります。複数の要素を組み合わせてワイヤーフレームのようなものを作成したものがTemplateとなります。

Page（ページ）

PageはTemplateがブラッシュアップされ内容が入ったものとなります。
高粒度のカンプデータのようなイメージです。

構築する上で注意しているポイント

Atomic Designを構築する上で、個人的に注意しているポイントを書いておきます。

【 AtomとMoleculeのコンポーネントは単一の機能や役割にする 】
AtomとMoleculeのコンポーネントでは「機能としての役割」を定義しているので、１つのコンポーネントで複数の機能を持たないように意識しています。Organism以上の単位のコンポーネントになるとそもそもコンポーネントとしての役割が変わり、「レイアウトとしての役割」を担うようになるため機能は複数あっても問題はないといった認識で進めています。

【 定義したコンポーネントよりも外側の領域のスタイルを記述しない 】
例えば、ボタンのAtomコンポーネント作成時にそれを利用する場所でmatgin-topのようなスタイルを反映したいとなった時、このレイアウトはボタンのコンポーネントの外側に位置するレイアウトなのでコンポーネント内で記述はしない。ということです。
理由は繰り返し利用する際の再利用性が下がってしまうためです。

【 可変するスタイルは親のコンポーネントに操作させる 】
Atomコンポーネントのボタンの幅などを別の種類のMoleculeやOrganismなどによって変更させたい場合は、Atomで幅の定義をせずMoleculeやOrganismで幅の調整を行う。というものです。同じスタイルのボタンを幅の違いだけで複数作るのは効率が悪いので、このような形を取ることを意識しています。

【 一度しか使わないコンポーネントはなるべく生成しない 】
これは人によるかと思います。個人的にはコンポーネントとして切り出す目的は再利用性の向上によって効率を高めることと、サイトの一貫性を保つことにあると考えております。なので、一度しか使わない要素に関しては色や大きさなどの共通ルールの定義はするものの、コンポーネントとして切り出さない方針のほうがコンポーネントも無駄に増えることが無いので良いのかなと考えております。

--------------

まとめ

今回はコンポーネントについて2019年10月現在で自分が考えている事を書いていきました。
サービスを作る時、始めは何も決まりがなくてもなんとなく統一感や一貫性を保てるものですが、複数の手や作業によって繰り返し繰り返し改善や施策が入ると徐々にその一貫性に亀裂が入ってきます。
大きく後戻りや再設計を行うフェーズを設けなくて済むように、始めからある程度の制約をもった上で制作していく事で適度なバランスを保ちながらサービスを拡大していくことができるのではないかと思っております。

最後まで見ていただきありがとうございました。

この記事が気に入ったらサポートをしてみませんか？