コーダー・エンジニアも知っておきたい3つの「UXデザインの法則」

コーダー・エンジニアも知っておきたい3つの「UXデザインの法則」 Webデザイン
この記事は約6分で読めます。
スポンサーリンク

どうも上かるびです。

この間「UXデザインの法則」という本を読んだのですが、コーダー・エンジニアとしても学べること・知っておくべきことがいくつかありましたのでご紹介いたします。

UXデザインの法則
本書は、著者Jon YablonskiがUXデザインと交差する心理学の法則をまとめたウェブサイト「Laws of UX」を元に構成されています。「意思決定にかかる時間は選択肢の数と複雑さで決まる」、「タッチターゲットに至るまでの時間はターゲットの大きさと近さで決まる」などの10の法則を、各章において、ポイント、概要、起...
上かるび
上かるび

ちなみに東京都内のジュンク堂書店でオライリーの本を買うと、オライリーのグッズを1冊につき1つ貰えますよ!

コーダー・エンジニアも知っておきたい3つの「UXデザインの法則」

特に勉強になったものを3つピックアップしました。

その1:スマホでのタッチの正確性について

スマホなどのボタンについて、要素同士は〇〇dp空けないといけない云々、というお話は聞いたことがあるかと思います。

そのスマホでのタッチについて勉強になったのは、
人はスマホの中心部を見たり触ったりすることが多く、中心部がもっとも(タッチの)制度が高い領域になっているということです。

(本の図は引用できないため、本を参考にイラレで作った図です↓)

スマートフォンでのタッチの正確性(スティーブン・フーバーの研究に基づく)

ネコーダー
ネコーダー

確証はないけどハンバーガーメニューは右上でも右下でも大差ないってことなのかもね…

その2:404ページについて(ピークエンドの法則)

【ピークエンドの法則】
経験についての評価は、全体の総和や平均ではなく、ピーク時と終了時にどう感じたかで決まる。また人はポジティブな経験よりも、ネガティブな経験をより鮮明に思い出す。

アクセスしようとしたページが見つからない場合、ユーザーはイライラしてしまい結果的にサイトやプロダクト全体にネガティブな印象を持ってしまう可能性があるそうです。

Webサイトでのユーザージャーニーの観点では、対策として404ページが上げられます。

404ページにユーモアがあれば、逆に顧客との関係構築に利用できる可能性もあるとのこと。

以下、本書で挙げられていた404ページです。

Page Not Found | Mailchimp
Page Not Found
https://ueno.co/karubiii/
https://github.com/karubiii/
https://www.pixar.com/karubiii/

この他にもクロネコヤマトの404ページなども有名ですよね。

お探しのページは見つかりませんでした。 | ヤマト運輸
クロネコヤマトでおなじみ、ヤマト運輸のお探しのページは見つかりませんでした。本サイトでは荷物のお問い合わせ、集荷・再配達受付、個人のお客さま向けのサービスの他、事業概要や企業情報、CSR、採用情報について掲載しています。

GoogleやAmazonなどの大手企業もユーモアのある404ページを準備していることから、Webサイト構築の上で欠かせない要素になっているのかもしれません。

その3:応答を0.4秒以内にする(ドハティの閾値)

【ドハティの閾値】
1982年、IBM社員2人(片方がドハティさん)が応答時間が0.4秒未満になると「応答時間の減少により生産性が劇的に向上する」という論文を提出した。
ただサイトによっては0.4秒よりも処理時間が長くなり、簡単には短縮できないケースもあるかと思います。そこでユーザーの体感の待ち時間を短くするために本書で紹介されていた方法をご紹介します。

スケルトンスクリーン

Facebookのスケルトンスクリーン

コンテンツを読み込んでいる時に、スケルトンスクリーンにすることで、サイトの読み込みを速く見せることができるそうです。

またスケルトンスクリーンが各要素の表示領域を事前に確保することにより、読み込まれる際の画面のガタつき(レイアウトシフト)を防ぐこともできますね。

Zennで調べてみたら実装方法を投稿されている方がいらっしゃったので合わせてご紹介します。(Reactです)

スケルトンスクリーンを実装してみた

ブラーアップ

こちらは画像の読み込みに特化した対処法です。

最初に極小サイズの画像を読み込んでおき、大きな画像が読み込まれたらそれを置き換えていくという方法です。

解像度の低い画像を拡大する時にノイズが目立ってしまうので、ガウスぼかしを適用するのが一般的みたいです。

こちらもスケルトンスクリーン同様、画像の高さを担保することでレイアウトシフトも防げます。

アニメーションの活用

パーセンテージのインジケーター、プログレスバーなども待ち時間の体感速度を減らすことができるそうです。

進捗状況の正確さに関係なく、単純にプログレスバーを表示するだけでユーザーは辛抱強く待つようになるそうです。
“The Importance of Percent-Done Progress Indicator for Computer-Human Interfaces”

こちらで原文読めます。
Just a moment...
プログレスバーは以下の理由から効果的だそうです。
  • 処理が進んでいることが伝わると、人は安心感を覚える
  • 待たせている間も、興味を失わず見続けてもらえる
  • プログレスバーの動きを意識すると、待っているということを忘れ、体感の待ち時間が減る
上かるび
上かるび

上記を意識すればプログレスバーでなくてもいろんな手法で体感時間を減らせそうですね。

 

ユーザーの注意を目前のタスクに引きつけて置けるのは10秒が限界とされているそうです。
待ち時間が10秒を超える場合は、プログレスバーだけでなく、完了までの予想時間や進行中の表記も加えるのが良いそうです。
ネコーダー
ネコーダー

iPhoneのアップデートとかそういう仕様になってるよね。さすがや!

本書のこちらのセクションの「結論」に書かれていたことが最高だったので大文字で紹介して終わりたいと思います。

パフォーマンスは単にエンジニアが取り組むべき技術的な課題ではなく、デザインの本質的要素だ。プロダクトやサービスを利用している人が可能な限り速く、そして効率的にタスクを実行できるよう手助けすることはデザイナーの責任だ。
最近のWebサイトはアニメーションが凝ったものが多く、ファイルサイズも大きくなりがちです。
魅力的なアニメーションを実装するには良いですが、待ち時間が長すぎればそもそも見てもらえない可能性も出てくるので、実装者としてパフォーマンス面もしっかり勉強して最適化していかねばと思いました。

 

コメント

タイトルとURLをコピーしました