👆

WebアプリケーションにおけるUIを構築するときに考える3つのこと - コンポーネント編

2022/04/14に公開

はじめに

わたしは普段フロントエンジニアとして働いており、WebアプリケーションのUIを設計・実装したりするような人間です。

UIを設計・実装していく時に、どういう考えをもとに取り組めばいいかというのをこの記事で整理してみたいと思います。

アプリケーション全体のUIを言語化すると壮大な話になり難しそうなので、今回はコンポーネントの設計・実装に絞って整理します。
コンポーネントとは、UIを構成する部品(ボタン、テキストフィールド、カードなど)のことを指しています。

さっそくですが、Webアプリケーションのコンポーネントを設計・実装していくにあたって重要なことは次の3点だと思っています。

  1. Web標準に沿って設計・実装する
  2. どういう状態を取りうるかを明確にし、その状態を適切に表現する
  3. UIの文脈に応じて、十分なバリエーションを揃える

以降でそれぞれ詳しく書き出してみたいと思います。

1. Web標準に沿って設計・実装する

初めに、思想的な話です。

ユーザはブラウザ上で様々なWebアプリケーションを利用しますが、それぞれのWebアプリケーションの基本的なUI(ボタンやフォーム、リンクなど)は操作性が一貫しています。

例えば、

  • ページ遷移が発生するようなリンクをCtrl + Clickすることで、新しいタブでリンクを開く
  • フォームに入力を行なった後にEnterキーを押下することで、submit処理を走らせる
  • ボタンにフォーカスがあったている状態でEnterキーまたはSpaceキーを押下することで、ボタンのclick処理を走らせる

こういった基本的なUIの操作性は、Web標準で決められているものです。

Web標準に従って設計・実装すれば、異なるアプリケーションであっても操作性を統一することができ、操作の習慣化に繋げていくことができます。

操作の習慣化というのは、使いやすいUIを構築していく上でとても重要になってくると思うので、この習慣化についてもう少し詳しく考えてみたいと思います。

操作の習慣化とはどういうことか

操作の習慣化とは、ユーザが特定の操作を無意識のうちに行えることだと解釈しています。

例えば、UI上のボタンを押下する際、マウスをクリックするという行為は無意識に行われているはずです。意識的に「マウスをクリックするぞ」と考えているわけではないと思います。(もちろんコンピュータを初めて触るような人は意識すると思いますが)

意識の所在

このマウスの例のクリックのように、基本的なUIの操作が習慣化されていることで、UIを操作するときのユーザの負荷を小さくすることができ、より行為の本質的な部分に集中することができるようになるはずです。

UIの基本操作を習慣化させるためには

じゃあ操作を習慣化させるにはどうすればいいかという話になってくるわけですが、それを達成する1要素として、プラットフォームのルールに従い、基本的なUI操作を統一させるというのがあります。

Appleのプラットフォームだと、Human Intareface Guideline、Androidだと、Material Designがプラットフォームのルールにあたるっものです。
Webの場合だと、Human Inteface GuidelineやMaterial Designのようにわかりやすいガイドラインはない気がしますが、Web標準と呼ばれるドキュメントがそれに相当すると思います。

Web標準に従い、基本的なUI操作が全てのアプリケーションで統一されていれば、どこにいても同じ操作が行えるため、ユーザの経験とともにその操作が習慣化されてきます。

もし基本的なUI操作にばらつきがあれば、いつまで経っても習慣化されず、毎回UIを適切に扱うことに意識が向いてしまいます。

私の場合、新しいタブでリンク先を開くときはCtrl+Clickが習慣化されているのですが、もしリンクをaタグで実装せずにCtrl+Clickが機能しない状態になっていると、別のやり方でリンクを新規タブで開く方法を模索する羽目になり、アプリケーションではなくUIに意識が向いてしまいます。

この習慣化についてまとめると以下のようなことです。

「プラットフォーム上のルールに従ってUIを構築する ⇨ ユーザの基本的なUI操作を習慣化させることにつながる」
※Webにおけるプラットフォーム上のルール: Web標準

Web標準に沿ったUIを構築するためにどうすればいいか

じゃあWeb標準に沿ってやっていこうといっても、結構ドキュメントのボリュームがあるので大変です。
そこで、どういうドキュメントを手がかりにしてやっていけばいいかというのを簡単にまとめたいと思います。

  • 適切なHTMLのタグを使用する
    • 適切なタグを使用することで、意味に沿った適切な挙動を表現できるはずです。
    • MDNのHTML要素リファレンスページで、分類ごとにどういう要素があるかがまとめられているので、ここで確認すると良さそうです。
  • 各HTML要素の仕様を把握する
    • 使う要素が把握できたらその要素についてのドキュメントを確認し、どういう属性がありどういうことが表現できるかを確認する。
    • また、HTMLのLiving Standardで該当要素に関する記述を読むと、より理解が深まるかもしれないし、深まらないかもしれない。ここはHTMLの仕様の一次情報になってくると思うので、読めるようになっておきたいので一応読んでる
  • アクセシビリティにおいて、各要素に求められることを把握する
    • WAI-ARIA Authoring Practicesを確認し、UI要素の役割ごとにどういう挙動が求められるかなどを確認する。
    • 何かしらの障害を持っていないような人もタブフォーカスやキーボード操作は多く使うと思うので、ここは気をつけておきたいところ。
    • Reactを利用して開発している場合は、React Ariaの該当要素のドキュメントを読むとわかりやすいかもしれない。また、アクセシビリティを考慮した実装をする際に重宝するはず。
  • UIライブラリのコンポーネントを観察する
    • Chakra UIなどの優秀なUIライブラリのコンポーネントを観察し、どういう挙動になっているかを観察してみるとイメージがつきやすいはず。

CSSの観点など他にもありそうな気がするが、今のところわたしが意識しているのはこんなところです。
もっとこういうの見るといいよとかあれば教えてください。

2. どういう状態を取りうるかを明確にし、その状態を適切に表現する

次に、コンポーネントの状態についてです。

良いUIの1つの条件として、インターフェースからアプリケーションがどういう状態になっているかを把握できることだと思います。

どういう状態かが適切に把握できるUIになっていれば、ユーザはアプリケーション内でどういうことが起きているのか、どういう操作が可能そうかが把握できるため、次に何をすればいいか、何が行えそうかが理解しやすくなります。

そこで、まずはどういう状態を取りうるかを洗い出していく必要があります。
ここの状態の洗い出し方法は、大きく2つあるかと思っています。

2-1. コンポーネント自体の状態を洗いだす
2-2. ユーザ操作とのインタラクションにおいて発生する状態を洗い出す

2-1. コンポーネント自体の状態を洗い出す

これはそのままですが、コンポーネント自体の状態を表すものです。
よく挙げられるので、次のようなものがあると思います。

  • 理想的な状態
  • ローディング状態
  • 空の状態
  • エラーが発生している状態

これらはどのコンポーネントに対しても当てはめて考えることができると思っているので、とりあえずこれらの状態が考慮できているかというのを一つの基準にしてもいいかもしれません。

もちろんものによっては上記が全て必要になることはないので、必要に応じて検討していけばいいと思います。

状態ごとのパスワード入力フォーム

2-2. ユーザとのインタラクションにおいて発生する状態を洗い出す

これはユーザ操作によって変化する状態のことを指しています。

例えば、ボタンであればカーソルをホバーするとホバー状態になったり、フォーカスを当てるとフォーカス状態になります。
実際ボタンホバー時には、カーソルの形が指差す手の形になり、クリックできることが推測できるようになります。
また、ボタンにはクリックした瞬間のアクティブ状態というのがあり、この状態をうまく表現することで、よりクリックした感覚をユーザに与えることができます。
※ボタンのホバー時にカーソルをpointerにするのは不適切そうなので、例の記載を修正。参考: Buttons shouldn't have a hand cursor

例えば、リンクであればカーソルをホバーするとホバー状態になったり、フォーカスを当てるとフォーカス状態になります。
実際リンクにホバーした時に、カーソルの形がpointerになり、クリックできることを推測できるようになります。

リンクのhover

このような、ユーザとのインタラクションにおいて発生する状態をあらかじめ把握し、適切に設計しておくことで、よりユーザの操作をサポートできるはずです。

2-1は、ユーザに対して静的に操作に関する情報を提供しますが、2-2では動的に情報を提供するようなイメージです。そうすることで、情報を必要最小限に留めながら、より多くの情報をユーザに提供することができるのではないかと思います。

このインタラクションにおいて発生する状態の洗い出し方法は、CSSの擬似クラスを元にリストアップするやり方がいいかなと思っています。

この擬似クラスの一部が、ユーザとのインタラクションにおいて発生する状態をそのまま表現しています。ただ、ものによっては2-1として解釈されるものがあるので、そこに関しては、2-1の作業を補填すると考えて進めればいいかなと思います。

https://developer.mozilla.org/ja/docs/Web/CSS/Pseudo-classes

buttan要素を例に挙げると、:hover, :active, :disabled, :focusなどがあげられるでしょう。


2-1と2-2で、どういう状態を取り得るかを明確にできたら、それぞれの状態の見た目を設計していくわけですが、この時に、適切に状態を表した見た目になっているかを意識する必要があります。

もし誤った状態に推測されたり、どういう状態かが把握できなければ、本来の目的のユーザの操作を手助けすることができず、むしろ妨害してしまいます。

エラー状態のわかりやすさ

なので、ここは慎重に設計をする必要がありそうです。必要に応じて、第三者に「この部品ってどういう状態だと思うか」というのを聞いてみたりして、常に客観的に見れるようにしておくといいと思います。
また、相対的に見ないと分かりづらいかどうかというのも考えながら設計しておくとより良いかもしれないです。

ここで、状態を適切に表現した設計ができれば、アプリケーションがどういう状態であるか、どういう操作が今行えるかというのを容易に把握することができ、次の操作の手助けになるはずです。

3. UIの文脈に応じて、十分なバリエーションを揃える

最後に、コンポーネントのバリエーションについてです。

同じコンポーネントでも、UI上の文脈に応じて、多少表現方法が変わってくるはずです。
事前にどういう文脈があるかを把握しておけば、そのバリエーションを洗い出すことが可能になると思います。

UI設計を進めていく際には、まずワイヤーフレームや手書きのスケッチなどでどういう画面があって、その画面にはどういう部品を配置してどういうことを達成するかというのを事前に考えると思います。
そこで出てきた情報をもとに、バリエーションを洗い出せればい良いはずです。

もし最初に洗い出せなくても、後から適宜追加すれば済む話だと思うので、必要に応じて取り組むのがいいと思っています。

とりあえずまず考えるバリエーションとしては、下記のようなものがあるかなと思います。

  • サイズ
    • スペースの問題上サイズが変わってくることがある。スペースがあまり取れなさそうな領域かどうかを考えながら洗い出すと、どういうサイズ感が必要かがわかるかもしれない
  • 役割
    • ボタンとかだと、ユーザにとって重要なアクションとそうでないアクションを分けたり、破壊的なアクションとそうでないアクションを分別したりするために、役割をいくつか設けることが多いはず

さいごに

  • Web上のUI操作を習慣化させるために、Web標準に沿ってコンポーネントを構築する
  • ユーザの操作を惑わせないようにするために、どういう状態があるかを明確にし、その状態を適切に表現する
  • 適切なコンポーネント配置ができるように、UIの文脈に応じて十分なバリエーションを揃えておく

ちゃんとここで書いたようなことを実践しながら、より良いUIを作っていけるように頑張っていきたいと思いました。

参考

変更履歴

  • 2022/04/24
    • 2-1 空の状態のイラストを修正
    • 2-2 ボタンを使った例をリンクを使った例に変更

Discussion