おいちゃんと呼ばれています

ウェブ技術や日々考えたことなどを綴っていきます

良い UI をつくる

UI デザイン JavaScript CSS

師走に入った。来年良いスタートを切るために一年を振り返るには良い時期だ。

さて、2015年の後半くらいから、フロントエンド・エンジニアとして「良い UI をつくる」ことに自分のリソースを集中させてきた。UI はここではウェブアプリケーションの UI を指す。

一年半をそれに費やしてきて、このあたりで、自分が考える、良い UI（ユーザーインターフェイス）とは何か、どうすればそれを実現できるのかを整理しておくのも悪くないなと思ったので書き留めておく。

良い UI をつくるには

良い UI をつくるには次の 2つが必要だと考える。

  • 1 良い UI を定義できること
  • 2 上記 1 を実装（実現）できること

そう、いまから何をしようとしているのかというと、良い UI をつくるために必要な要素をツリー構造で整理しようとしているのだ。

ただし、以下に良い UI をつくるために必要な要素を分類しようと試みているが、主な目的としては、分類・整理することで自分のスキルセットをより深く理解するところにあるため、分類に学術的な裏付けがあるわけではないことをあらかじめご勘弁いただきたい。

良い UI とは何か

良い UI とは何か。それは良い UX（ユーザー体験）をもたらすことに寄与するインターフェイスのことだと考える。

ここで寄与するという書き方をしたのは、良い UX は、プロダクトが良い UI を備えていたからといって、必ずしも良い UX がもたらされるわけではなく、他の様々な要素が関係してくるためである。そもそもプロダクトが解決しようとしている問題が妥当で、それを解決するためにプロダクトが正しく定義されている必要があるし、ブランディングやカスタマーサポートも関係してくる。しかしそれらについては今回触れない。

話を戻して、良い UX をもたらすことに寄与する、ということをもう少し細かく見ていくと、私たちがウェブアプリケーションに触れているとき、たくさんの刺激を受け取って、それによって気持ちが左右されている。刺激を 2つに大別してみる。

  • (1) 負の情動を喚起する刺激
  • (2) 正の情動を喚起する刺激

(1) は「なんだこれ、分かりにくいなー」とか「くっそ重いなー」とかいわゆるストレスを感じさせるもので、(2) のほうは逆に心地良く感じさせるものである。

良い UX に寄与するためにはできる限り (1) をなくしたほうが良いし、(2) があるほうが良い。もちろん単純な数だけの問題ではないが。

負の情動を喚起する刺激

さて、ここまでで、良い UI をつくるために必要な要素は、

  • 1 良い UI を定義できること
    • (1) 負の情動を喚起する刺激を減らすこと
    • (2) 正の情動を喚起する刺激を増やすこと
  • 2 上記 1 を実装できること

というところまで埋まった。

「負の...」を、「正の...」よりも前に持ってきたのには理由がある。

ユーザーは普通、何かやりたいこと（目的）があって、そのウェブアプリケーションに訪れている。そして、UI を手段としてその目的を達成する。つまり、ユーザーの関心は手段である UI よりも目的のほうにあって、UI は何よりも「邪魔しないこと」が重要なのである。

「邪魔」には大きく 2つあると考えている。

  • (ア）目的の達成までの道筋が「分かりにくい」こと
  • (イ）操作中の不快感（を与えるもの）

このうち (ア）のほうは端的に「分かりにくさ」であり、ナビゲーションが分かりにくいだったり、レイアウトの分かりにくさだったり、初期のフラットデザインにあったような「どこを押せばよいか分からない」問題だったり、いま自分がどういう状態なのか分からない、操作の結果が不明確、ということである。

他方 (イ）について、操作中に不快感を与えるものの代表は「遅さ」である。この「遅さ」をさらに 2つに分類してみる。

例えば次の画面に遷移する操作を行って、その画面が表示されるまでに時間がかかると「待たさせる」ことになる。これは操作が完了するまでの遅さである。

もうひとつは操作に対する（初期）応答の遅さであり、私たちがよく「もっさり」とか「ひっかかる」と表現するものである。

ここで少し立ち止まって、応答がどのくらい遅いと不快に感じるのか、あるいはどうして不快に感じるのか、もう少し踏み込んで整理したい。そのために「自己帰属感」という概念をヒントになると思われるので取り上げる。

自己帰属感

まず自己帰属感とはどういうものか。

自己帰属感とは自己感の一種で、「いま目の前で動いている手は、自分の手である」「今見えている風景は、自分が見ている風景である」という、風景や手、あるいは道具に対して現れる、「自分が」という部分の理由となる感覚のひとつである。

（『UI GRAPHICS』の「インターフェイスと身体（文・渡邊恵太）」より抜粋）

UI GRAPHICS ?世界の成功事例から学ぶ、スマホ以降のインターフェイスデザイン

UI GRAPHICS ?世界の成功事例から学ぶ、スマホ以降のインターフェイスデザイン

  • 作者: 水野勝仁,深津貴之,渡邊恵太,菅俊一,緒方壽人,iA,鹿野護,森田孝陽
  • 出版社/メーカー: ビー・エヌ・エヌ新社
  • 発売日: 2015/12/17
  • メディア: Kindle版
  • この商品を含むブログを見る

これを検証するための「マルチダミーカーソルの実験」という興味深い実験がある。実験内容と結果をざっくり抜き出すと、

f:id:inouetakuya:20161206033338j:plain

  • 被験者は上の画像のようにダミーのカーソルが複数あっても、動きの連動という情報のみで（早い人で平均1〜2秒程度で）自分のカーソルを見つけ出すことができる
  • カーソルの動きに遅延を入れると、それが 500 ミリ秒ほどであっても、自分のカーソルの発見が急激に難しくなる
  • さらに遅延を入れていくと、もはや発見は無理に等しいほど難しくなる

というものである。少し説明を端折ることになってしまうが、応答速度に遅延があると、操作対象に対して身体の延長感、一体感（= 自己帰属感）が得られず、操作者は接することに対して不快感を覚える。

（実験についての詳しい内容と説明は上にあるリンク先の PDF をみてほしい。『融けるデザイン』も詳しい）

融けるデザイン ―ハード×ソフト×ネット時代の新たな設計論

融けるデザイン ―ハード×ソフト×ネット時代の新たな設計論

正の情動を喚起する刺激

ユーザーに正の情動を喚起する刺激は何か。ユーザーはやりたいこと（目的）があって、ウェブアプリケーションに訪れているとするならば、前述の「負の情動を喚起する刺激」の裏返し、つまり「邪魔」が入らずに目的を達成できること自体が正の情動を喚起する刺激となると考える。

また目的の達成が UI によって強調されると、喚起される正の情動が大きくなることもある（ということをユーザビリティテストの被験者のリアクションから感じたことが数回ある）

あるいは「邪魔しない」レベルがユーザーの期待を上回るものであれば、目的の達成とは独立して、UI そのものが正の情動を引き起こす可能性もある（ということを見聞き＆自ら経験したことが数回ある。例えば私たちが「さくさく動く」と表現する場面）

さらには目的の達成に直接的には寄与しなくとも、プロダクトの世界観を高度に表現するインターフェイスはユーザーに正の情動をもたらしうる（例えば「洗練された」プロダクトにおける「洗練さ」を表現するグラフィックデザインなど）

プロダクトの UI が持つ刺激を可視化する

さて UI が情動に対して与える刺激について述べてきたが、その刺激は必ずしも目に見えているわけではない。どこに「分かりにくさ」や「遅さ」が潜んでいるのか、あるいは作り手が意図したとおりにユーザーに正の情動が与えられるのか。これらを可視化して、必要に応じて改善することも良い UI をつくるために必須であると考える。

良い UI の定義まとめ

よーし、ようやく折り返し地点まで到達した。ここまでをまとめると以下のとおり。

  • 1 良い UI を定義できること
    • (1) 負の情動を喚起する刺激を減らすこと
      • (ア）目的の達成までの道筋が「分かりにくい」こと
      • (イ）操作中の不快感（を与えるもの）
        • 操作が完了するまでの遅さ
        • 操作に対する（初期）応答の遅さ
    • (2) 正の情動を喚起する刺激を増やすこと
      • 目的の達成の強調
      • ユーザーの期待を上回る操作感
    • (3) プロダクトの UI が持つ刺激を可視化すること
  • 2 上記 1 を実装（実現）できること

良い UI を実装（実現）する

良い UI をどうすればウェブアプリケーションで実装（実現）できるか。これに対する答えは個々のプロダクトによって異なるし、ひとつのプロダクトでもそれを実装するときによって扱う技術は異なる、という前提をふまえたうえで、2016年現在、自分の目からどう見えているのかを書く。

ときおり読み返して、いま自分が何ができていて、今後何を学ぶ必要があるかを確認するチェックリストとして使おうと思う。その際に必要に応じて加筆・修正することもお許しいただきたい。

「分かりにくさ」の解決

1-(1)-(ア) 目的の達成までの道筋が「分かりにくい」こと の解決については、静的な表現として「情報設計、ナビゲーション、レイアウト」が有効である。これらは多くの場合 HTML + CSS の基本的な機能で実現できる。

また動的な表現であるモーションも、ユーザーの注意を引いたり、反応を返したり、理解を促す、という役割を果たし、分かりにくさの解決に貢献できる（詳しくは『UI GRAPHICS』の「UI とモーションの関係性」参照）。モーションを実装するためには CSS3 のトランジション及びアニメーションを使うか JavaScript を使う。

ブラウザによっては CSS3 のトランジション及びアニメーションが対応していないし、JavaScript を使う場合にも、使っている JS フレームワークのため、モーションを jQuery なしで実装する必要も出てくる。

そして、いまこれを書きながら、頭の中でモーションを実装していて、CSS の記法が分かっていても適切なパラメータを設定できないと実装できないなということに気付いた。

その意味ではマテリアルデザイン はデザインのコンセプトとロジックにとどまらず、どう実装するか数値パラメータレベルまで言及しているので（マテリアルデザインをそのまま採用するか否かを問わず）非常に参考になるし、Material Design Lite のソースを読めば、さらに詳細な数値パラメータを把握できる。

また私は CSS で簡単なモーションを実装したいときは Animate.css のソースを読んだりしている。JavaScript でモーションを実装となると、いまだと Velocity.js をおさえておけば良いと思う。

「操作が完了するまでの遅さ」の解決

1-(1)-(イ)-操作が完了するまでの遅さ の解決について、一例として、

例えば次の画面に遷移する操作を行って、その画面が表示されるまでに時間がかかると「待たさせる」ことになる。

というケースを考えてみたとき、まず何はともあれ「どこに時間がかかっているか」を把握するところからはじまる。サーバーサイドの処理に時間がかかっているのか、フロントエンドの処理に時間がかかっているのか。私は Chrome のデベロッパーツールを使っているが、SpeedCurve というリッチなサービスもある。

今回フロントエンドの話を中心に据えたいが、仮にサーバーサイドの処理に時間がかかっていたならば、

  • 処理ロジックの改善（例: DB 操作時に適切にインデックスを使ったり、N + 1 問題をなくしたり）
  • キャッシュして良い処理はキャッシュする
  • 非同期でよい処理は非同期にまわす

などの対策が考えられる（このあたりはサーバーサイドに限ったことではなく、フロントエンドにも共通することが多くある）

フロントエンドに話を戻して、リソース（JavaScript, CSS, 画像等）の読み込み本数が多い、サイズが大きいという問題があれば、HTTP/2 で効率良く読み込むようにしたい。

また Webpack を使って、リソースを適切に統合または分割して、必要なリソースを必要なタイミングで読み込むように最適化する。

そして SPA（シングルページアプリケーション）にして、画面遷移時に画面全体をレンダリングし直さずに、必要な範囲のみをレンダリングすることも検討したい。

ここに取り上げた技術の良い活用事例があるのでリンクを貼っておく。

「操作に対する（初期）応答の遅さ」の解決

1-(1)-(イ)-操作に対する（初期）応答の遅さ の解決についても、まずは応答の遅さを引き起こしている原因を特定するところからはじまる。Chrome のデベロッパーツールなどで、ブラウザのメインスレッドに負荷をかけている処理を探し出す、そして改善する、ということになる。

WEB+DB PRESS Vol.89

WEB+DB PRESS Vol.89

例えばイベントが多発していたら lodash の throttle, debounce などを使って間引きする（処理回数を減らす）。キャッシュして良い処理はキャッシュする。キャッシュについていうと、先日 Vue.js のある機能のキャッシュとその破棄の仕組みを解説した記事が興味深かった。

あとは例えばアニメーションを CPU ではなく GPU で行うようにすること（ハードウェア・アクセラレーション）や、ブラウザのメインスレッドとは別にバックグラウンドで処理をすること（Web Workders）などを検討する。

プロダクトの UI が持つ刺激を可視化する

プロダクトの UI が持つ刺激を可視化する方法は、大きく 2つに分けることができると考える。つまり、

  • (1) 生身の人間からフィードバックを受けることで可視化する方法
  • (2) データつまりユーザー行動ログを解析して可視化する方法

このうち (1) については Prott や Adobe XD などでプロトタイプをつくり、ユーザビリティテストを行うことが挙げられる。

(2) については Google アナリティクスなどの各種解析ツールを用いて解析することが挙げられる。

まとめ

以上、自分が何をやりたくて（= 良い UI をつくりたい）、そのために何が必要だと考えているのかまとめてみた。

そして、書き出していく過程のなかでずっと「自分の強みは何なのか」を考えていた。

いくつかの項目について、この項目は自信があるな、というものを確認できた。

また、いくつかの項目について、この項目はあのデザイナーが得意だなとか、この項目はあの人という具合に、自分よりも良い仕事をする同僚の顔も浮かんできたが、いざとなれば全部自分でやれるなということ、そして、自分はそれらの技術や人を統合して良い UI をつくっていく、という点に強みを持っているのだなということを確認できた。

ただ、自信がある項目についても、技術を統合して良い UI をつくっていくということについても、社内はともかく、業界全体に目を向けた場合にはまだまだ全然だろうなという漠然とした不安がある。

漠然としたままではどうにもできないので、

  • (1) まず自分のロールモデルとなる人を見つける
  • (2) その人と自分との間にどういう差分があるのかを知る

というところを次のステップにしたい。2017年もやっていくぞ。

www.adventar.org