知覚としてのパフォーマンス：忍耐の管理

技術的な観点から最適化するものがもうないときに、フロントエンド最適化の機能を拡張するにはどうすればよいですか？ これを行うには、心理学とユーザーの知覚の管理に目を向ける必要があります。

待機は、アクティブフェーズとパッシブフェーズで構成できます。 ユーザーの知覚における期待が短くなるように、通常、アクティブフェーズを増やし、パッシブフェーズを減らします。 しかし、イベントにアクティブフェーズがまったく含まれておらず、完全に受動的な期待がある場合はどうすればよいでしょうか？

シリーズ「Performance as Perception」シリーズの目次：

• 知覚としての生産性：時間の知覚。
• 知覚としてのパフォーマンス：知覚管理。
• 知覚としてのパフォーマンス：忍耐の管理。 （この記事）

この記事の著者は、ノルウェーのフロントエンド開発者であるDenis Mishunovであり、スピーチを頻繁に行います（モスクワおよびサンクトペテルブルクで開催されたHolyJS会議を含む）。 デニスには工学と芸術の2つの学位があり、心理学、物理学、歴史、描画が好きです。 彼の日常業務では、すべてのフロントエンド開発者ツールのパフォーマンスの最適化に集中するために、常に物事とプロセスの底辺に到達しようとします。

そのため、現実の世界では、アクティブフェーズなしの待機が頻繁に発生します。チケットオフィスで並んで待機する、バスを待つ、遊園地で並んで待機するなどです。 科学者は証明しました：人が長く待たなければならないほど、彼はそれに反応します。 オンラインの世界で待つことに対するユーザーの反応は、オフラインと変わりません 。 1000件以上のケースに基づく研究により、インターネット上の14種類の待機状況が明らかになっています。 ユーザーの忠誠心に依存しているため、ユーザーが受動的に待機することを許可することはできません。

この記事のフレームワークでは 、 インターネット上での純粋な待機待機とは何か、どのように対処し、要求されたサービスを十分に迅速に受信できない場合でも、ユーザーの満足度を高く保つために何ができるかを検討します。 オンライン待機の心理をよりよく理解するために、待機キュー、顧客満足度、および現実世界での期待に関して行われた他の研究の心理に目を向けます。

待機キューの心理学および実世界に関連して実施される他の研究は、オンライン待機をよりよく理解するのに役立ちます。

心理的時間：トレランス管理

20世紀の前半に、ビルドマネージャーは、エレベーターを使用する際に時間がかかりすぎるという苦情を受けました。 単純な技術的解決策がなかったため、マネージャは何をすべきかを知りませんでした。 ユーザーの要求に答えるためには、高価で労働集約的な技術的ソリューションの問題を考慮する必要がありました。 そして、誰か （デザイナーはデザイナーだと言い、エンジニアはエンジニアだと言います）は、別の非技術的な観点から問題を解決する方法を見つけました。

見つかった解決策ははるかにシンプルで安価でした。エレベーターにミラーを、ロビーに床から天井までのミラーを設置しました。 ミラーをインストールした後、待機時間に変更を加えることなく、苦情の数はほぼゼロになりました。 なんで？

White Rabbit：遅れると彼女は激怒します！ 彼女はそこに来ます！」
ルイス・キャロル、不思議の国のアリスの冒険

ほとんどの人がこの質問に答えられると思います。 簡単に言えば、このソリューションは、閉じたエレベーターのドアの前で経験した純粋で受動的な期待を、人々が自分を見る機会を得たとき（そして静かに他の人を考慮する）アクティブに置き換えました。 この決定は、エレベータの前で彼らが小さくなったことを人々に納得させようとせず、客観的な待ち時間やイベントマーカーを変えませんでした。 代わりに、人々は最初からアクティブなフェーズに移行し、期待にはるかに耐えるようになりました。

エレベーターにミラーを設置するアイデアを思いついたのは誰ですか？

さて、待っている問題のウサギの穴を下ってみましょう。 それに直面しましょう：実際よりも待つ時間が少ないことをユーザーに納得させるのは必ずしも簡単ではありません。 ただし、待機時間が適切に規制されている場合、待機の必要性は顧客のWebサイトの評価に悪影響を及ぼしません 。 では、なぜ人々は待つのが嫌いなのでしょうか？

1985年に、デイビッドマイスターは8つの「原則」を策定しました（P.ジョーンズおよびE.ペッピアットらの実験で確認されました）期待の心理に関して。 Davis、Heinecke、およびPeppiattが後でリストにさらに2つの原則を追加したという事実にもかかわらず、簡単にするために、すべての原則をMeisterのリストと呼びます。 以下に、このリストと、各原則に対処する方法について考えられる推奨事項を示します。

	原理	推奨/コメント
P1	人々が何かで忙しくなければ、時間が忙しいときよりも時間が長くなります。	アクティブフェーズとパッシブフェーズのバランス。 これにより、エレベーターの問題が解決されました。
P2	人々は開始したい（プロセスが始まるまで待つのは、プロセスの途中で待つよりも長い）。	早期終了（開始時の短いパッシブフェーズと長いアクティブへの切り替え）およびプリエンプティブな開始（開始時の長いアクティブフェーズと終了時の短いパッシブフェーズ）の技術の適用
P3	アラームにより、待機時間が長くなります。	ユーザーとの実際の連絡がない場合、非常に主観的でオンラインでの管理が困難です。
P4	不確実な期待は、終わりが見える期待よりも長くなります。
P5	説明されていない期待は、説明された予想よりも長くなります。
P6	不当な期待は、公正な期待よりも長くなります。	ユーザーの期待に応える：待ち時間を競合他社のパフォーマンスと比較するか、他の方法がない場合は、さまざまな要因（信頼性、利便性）により、少なくともサービスの待ち時間を無効にします。
P7	サービスの価値が高いほど、顧客の待ち時間は長くなります。	サービスの価値を高めることは、この記事の範囲を超えています。
P8	単独で待つことは、グループで待つよりも長いようです。	ほとんどのユーザーは、コンピューターの前に一人で「並んでいる」と想定できるため、この原則を制御することはできません。
P9	待機中にクライアントが不快な場合、時間がクライアントにとって都合がよい場合よりも時間が長くなります。	「便利」という言葉は広い意味を持ち、非常に主観的です。
P10	新規ユーザー、および頻繁にアクセスしないユーザーにとって、彼らは常に来ているユーザーよりも待っているようです。	ここでは、ユーザーの期待に応える必要があり（P6を参照）、サイトに初めてアクセスした仮想ユーザーについて考えます。

アイテムP3、P8、P9、およびP10は、フロントエンド開発の観点またはWebサイト管理の観点のいずれからも影響を受けることはありません。 アイテムP4およびP5には、管理ツールはまったくありません。 これらの2つの原則は、人々が待機中に不幸になる主な理由の1つは、異なる性質の不確実性であるということです：待機するのにどれくらい時間がかかりますか？ 今何が起こっていますか？ 結果はありますか？ これらの質問に答えるために、 忍耐を管理することにしましょう。

プロセスを見せて

「どれだけ飛んだのかしら？ アリスは大声で言った。 「私はすでに地球の中心近くにいると思います！」
ルイス・キャロル、不思議の国のアリスの冒険

不確実性を部分的に排除し、待機時間とプロセスの現在の状態に関する情報を提供するために、優れたパフォーマンスインジケーターがあります。 ユーザー行動研究者のStephen S. Sev は、プログレスバーを2つの主なグループに分割することを提案しています。 動的 （時間とともに情報を更新する）と静的 （時間とともに変化しない）です。 それぞれを2つのサブグループに分けることができます： 決定論的 （時間、作業単位、またはその他の方法でプロジェクトの完了を反映）および不定 （プロジェクトの完了を反映しない）。

さまざまな種類の進捗インジケータ。 クラスに注意してください。

ここで疑問が生じます： どのような場合にそれらを使用する必要がありますか？ 明らかに、ユーザーが実行するアクションごとにクラスAインジケーターを表示すると、すぐにユーザーを困らせます。 そのため、いくつかのガイドラインが必要です。 対応するインジケータと比較できる特定の静的な時間間隔があります。

• 即座に（0.1-0.2秒）

これは、単純な刺激物に対する普通の人の反応時間です。たとえば、落下するペンをつかんだり、熱いカップから手を離したりします。
瞬時に知覚されるものについては、インジケータを表示する必要はなく、これは明らかです。

• すぐに（0.5-1秒）
  

G. A. Millerが発見したように、ほとんどの成人は短期記憶に5〜9個の単純な要素を保存できます。 多数の実験、特にマサチューセッツ工科大学のM.グリーンとA.オリバの実験で確認された研究は、「複雑な自然画像の処理と物体の視覚認識」に10分の1秒しかかからないことを示しています。 これは、短期記憶で5〜9個の要素を処理するには0.5〜0.9秒かかることを意味します。 したがって、1秒は、ユーザーの思考の流れが中断されない最大時間と見なされます。

この間隔で複雑なインジケータを表示すると、思考の流れが中断されます。 ただし、通常、テキスト情報なしで単純なインジケータを表示しても問題はありません。 スピナーや操作の進行状況の非常に原始的なインジケーター（簡略化されたクラスA）などのクラスDインジケーターは、ユーザーの思考の流れを中断することなく自然に見え、同時にシステムがアクティブであることをスムーズに示唆します。

• 最適時間（2〜5秒）
  

最適な読み込み時間は異なる場合があり、主観的なパラメーターによって異なりますが、ほとんどのタスクの実行時間が2〜5秒の間隔を超えると、ユーザーの集中力は低下します。 そのため、2秒が最適なページ読み込み時間であると考えています。

この間隔では、リクエストが処理され、システムが応答していることをユーザーに明確にする必要があります。 繰り返しますが、クラスDインジケーターまたは単純化されたクラスAインジケーターを使用するのが最適です-追加情報にユーザーの注意を払う必要はありません。

GitHub（左）やFlickrなどの一部のサイトでは、スピナーやダウンローダーにロゴが含まれており、「最適な間隔」またはより短い時間でユーザーに表示されます。

• 注意の間隔（5〜10秒）

これは、ユーザーの忍耐のしきい値の制限であるため、より完全なソリューションが必要です。 この間隔以上で発生するイベントの場合、「作業中」という一般的なインジケータよりも多くの情報を表示する必要があります。ユーザーは、待機する必要がある時間を知る必要があります。 したがって、クラスAまたはクラスBの動的インジケータを表示する必要があります。ここで、プロセスの進行状況が表示されます。

5秒を超えるプロセスの場合、パーセンテージを示す、または操作の現在のステータスに関するより詳細な情報を含む単純な進行状況インジケータが適しています。

要約すると、次のようにガイドラインを策定できます。

Webで進行状況インジケーターを使用するための基礎

• 期間が0.5〜1秒のイベントでは、クラスDインジケーター（スピナー）または簡易クラスAインジケーター（進行インジケーター）を表示することをお勧めします。 選択は各ケースに依存します。
• 1〜5秒続くイベントの場合、クラスDインジケーター（スピナー）または簡易クラスAインジケーター（進行インジケーター）が必要です。
• 5秒より長いイベントの場合 、クラスAまたはBの動的インジケーターを使用することをお勧めします。

多くの場合、操作の進行状況のインジケータは複雑な場合があり、さまざまなクラスとその組み合わせのインジケータが含まれます。 これにより、マイスターのリストとは異なる原則を考慮することが可能になります。

momondo.comは、クラスDインジケーター（スピナー）とクラスBインジケーター（操作の完了を通知せずに現在のステータスを表示）を組み合わせます。


Slackアプリには、タスクの2つのレベルの進行状況インジケーターが含まれています。 2つ目は、感情的な要素がプロセスに追加され、ユーザーが肯定的なメッセージを受け取るようにします 。


オスロ大学のウェブメールなどの一部では、スピナーと現在の状況に関する情報を組み合わせています。 ほとんどの場合、この情報は正しくなく、実際のアクションを反映していないという事実にもかかわらず（テキストはユーザーが待機している時間に応じてのみ更新されます）、待機プロセスでユーザーを支援する場合、これは優れたソリューションです。



Little Big Roomは、ムードを改善し、不安を軽減するページローディングインジケータ（マイスターリストのP3）と、サイトをさらに待つための快適な感覚（P9）を作成する素晴らしいサイトです。

待機中に他の気を散らすツール（アニメーションなど）を使用する場合、タスクの進行状況を示す追加のインジケーターは必要ない場合があることに注意してください：ユーザーは既にアニメーションの処理で忙しいため、デフォルトで待機を容易にします。

進捗インジケータは、P4およびP5に従って不確実性を中和するのに十分な情報を提供できます。 しかし、ダウンロードの進行状況を表示するだけではありませんか？ いくつかの原則に対処できますか？ もちろんできます。

進捗インジケータを超えた許容範囲

アリスは黙っていました。彼女の人生でこれほど議論されたことは一度もなく、彼女は忍耐を失っていると感じました。
ルイス・キャロル、不思議の国のアリスの冒険

かなり興味深いサービス、 tripmydream.comを見てみましょう。 ユーザーは、事前定義された予算に基づいて、世界中の航空券とホテルの情報を検索できます。 旅行のトピックや希望する日付の選択などの基本的な操作を実行した後、ユーザーは旅行の予算を設定し、検索ページに移動します。


tripmydream.comの検索ページでは、忍耐を管理するためのいくつかの手法が一度に実装されています。

生産性の観点から、世界中のフライトとホテルの組み合わせを見つけることは、事前に定義された予算に従ってさえも、簡単な作業ではありません。 開発者のツールによると、私たちが行ったリクエストの結果は2分間届き続けました。 この場合、トレランスを管理するために何が行われているかを検討してください。

まず、早期終了の方法が適用されます。検索条件に一致する最初の結果が見つかるとすぐに情報が表示されます。 しかし、早期完了だけでは十分ではありません。最初の関連する結果は、ほぼ10秒待ってから表示されました。


早期終了方法だけでは、tripmydream.comは保存されませんでした。最初の検索結果は10秒後に表示されました。

以前、このような長いプロセスでは、進行状況の動的な指標を表示する必要があるという結論に達しました。 tripmydream.comの場合、これは包括的なクラスBインジケーターで、オレンジ色の進行状況バーとその直下の分析ブロックで構成されます。


包括的なクラスBインジケータは、進行インジケータと処理された方向を報告するユニットで構成されます。

最後に、以下の漫画のキャラクターを検討してください。 キャラクターはP9（不快な待ち時間は快適な時間より長く続く）に対処するように設計されています：原則として、笑顔の漫画キャラクターは屈託のない子供時代の記憶に関連する感情を呼び起こし、したがって、待機中により快適な感情を生じさせます。 キャラクターは、実際の人よりもコンピューターの前で仮想の友人と過ごす時間が長い私たちにとって、P8を部分的に解決することさえできます（期待だけで会社よりも長いようです）。 ただし、漫画のキャラクターを使用することは、サービスのユーザーの期待に反するものではないことに注意してください。たとえば、銀行のウェブサイト上のそのようなキャラクターは不適切です。


漫画のキャラクターは、待つことをより耐えやすくするのに役立ちます。

一般に、早期終了は、P1およびP2に従ってユーザーがタイムアウトを受け入れるのを制御するのに役立ちます。 包括的な進捗インジケータはP4およびP5を扱います。 下の漫画のキャラクターはP9とP8を処理しようとしています。 期待の多くの破壊的な原則がここで制御されています！

しかし、このページの漫画のキャラクターではすべてがそれほどスムーズではありません。彼は落ち着くだけでなく、コミュニケーションも行い、ユーザーに追加のテキスト情報を提供します。 ここに問題があります。 この要素の文字と対応するテキストは6秒ごとに新しいものに変更されるため、ほとんどの場合、ユーザーは全文を読む時間がありません。


画像の横にテキストを配置するときは、ユーザーに十分な時間を与えて読んでください。 読み取り中にテキストが削除されると、我慢はできなくなりますが、がっかりします。

インターネットには、寛容管理の良い例と悪い例がたくさんあります。 しかし、異なるアプローチを使用して同じ結果を達成しようとしている2人に注目します。

SlideShareとSpeaker Deckは、おそらくプレゼンテーションスライドをダウンロードするための2つの最も人気のあるサービスです。 このようなサービスは、イベント後にスライドをより多くの視聴者と共有できるため、プレゼンテーションを行う人にとって非常に便利です。 どちらのサービスにも、美的または歴史的な理由でどちらか一方を好むファンがいますが、ユーザーの観点からは、サービスの機能は非常に似ています。 特に、プレゼンテーションファイルをこれらのサービスにアップロードするプロセスに関心があります。

技術的な観点から見ると、プロセスはどちらの場合も同じです。ユーザーはファイルを選択してアップロードし、タイトルやその他のメタ情報を示し、ボタンをクリックしてプレゼンテーションを公開します。 心理的な観点から見ると、プロセスは同じです。ファイルのダウンロードは、ユーザーがダウンロードプロセスを制御しないため、純粋に受動的な期待です。 彼はダウンロードをキャンセルする以外何もできません。 ただし、 このプロセスのインターフェイスは SlideShareとSpeaker Deckで異なります。

SlideShare（上）とSpeaker Deckには、同じスライドの読み込み操作に対してまったく異なるインターフェイスがあります。

まず良いことについて。 これらのスクリーンショットを見ると、ファイルアップロードプロセスでサービスが忍耐管理をどのように使用しているかがわかります：メタ情報をファイルアップロード後ではなく、入力中に入力することが提案されているため、P1の原則に沿って作業します忙しい）とマイスターのリストからP2（開始したい）です。 ユーザーを受動的な待機状態にするのではなく、脳の活動段階を開始し、このフォームに記入することを提案します。

しかし、2つの指標の違いはわかりますか？ スピーカーデッキに2つの異なる進行状況インジケーターが表示されます。 そして、ここで状況は制御不能になります。 2番目のプログレスバーは、インターフェイスに混乱をもたらすだけでなく、ユーザーの認識プロセスを大幅に遅くします。 SlideShareの場合、フォームへの入力が完了した時点でプレゼンテーションファイルがアップロードされたため、遅延や受動的な待機に気付きませんでした。 しかし、Speaker Deckを使用すると、ファイルが比較的速くダウンロードされたとしても（最初のダウンロードインジケーター）、スライドが表示されるまで2番目のプロセスが完了するのを待つ必要がありました。 そして、[詳細の保存]ボタンをクリックしても、まさにそれが行われます。プレゼンテーションの処理中にのみ詳細が保存されます。 インターフェースの何も「処理」の完了後にユーザーに何を期待するかを伝えないため、状況は悪化しています。ユーザーは、待つ価値のある利点を得ることができますか？

スピーカーデッキは、ユーザーがフォームに記入するよりもはるかに多くの時間をスライドの処理に費やすため、忍耐を管理することのすべてのプラスの効果が平準化されます。

この比較では、SlideShare は忍耐管理方法の印象的な使用法を示しています。ユーザーは、ファイルをサービスにアップロードするときに受動的な待機にほとんど気付きません。 一方、最初の段階のスピーカーデッキは同じ方法を使用しますが、プロセスの継続が失敗したため、成功は平準化されます。

したがって、忍耐力管理を使用して、パフォーマンス最適化戦略を拡張し、プロジェクトの客観的な時間、知覚、および許容範囲を管理するための基本的な方法の全体像を把握できます。

シリーズ「知覚としての生産性」の最初の部分である「時間の知覚」と「 知覚の管理 」の他の方法について読んでください。

しかし、客観的側面または心理的側面のどちらに導かれているかに関係なく、できるだけ早くすべてを行う必要がありますか？ ご想像のとおり、これで終わりではありません。

簡単、タイガー！

「数秒を意図的に追加することでエクスペリエンスが向上する場合がありますか？」Stephen P. Andersonの記事「Wait for It ...」で尋ねます。 それを理解しましょう。

少し前のことですが、 南アフリカの最初の国立銀行のウェブサイトで架空のローディングインジケーターについて議論が始まりました。その間、一部の尊敬される人々 は 、これがなんらかのナンセンスだと主張しました。 しかし、結論に急がないでください。

最初の国立銀行のサイトにある架空のダウンロードインジケータは、多くの論争を引き起こしました。

まず第一に、William McEwanが書いているように、「より速くなることができますが、それはクライアントが望んでいる速度とまったく同じ場合だけです。 すべての顧客が会社とのすべてのコンタクトを超高速で完了することを望んでいるわけではありません。」 銀行のサイトが急いでくるのが好きですか？ Webサイトは、ユーザーの実際の生活に関連するオフラインインタラクション用のオンラインインターフェイスです。 ユーザーはこれらの操作に期待しており、原則として、銀行とのそのような相互作用は光の速度では発生しません。

すべてが可能な限り高速である必要はありません。

第二に、このダウンロードインジケータを追加することにより、銀行は特別な感情的なデザイン品質を開発しようとしています 。それは、多くの利点を備えた統合製品のアイデアです。 「本当に価値のあるものの多くは時間がかかります」と、テキサス大学の心理学の助教授であるダレルワーフィーは言います。 これは、マイスターのP7リストと一致しています。サービスの価値が高いほど、顧客は長く待機します。 銀行はファーストフードを販売していません-彼らはそれから即納を期待していません。 平均的なユーザーへの応答を単に遅らせることにより、銀行は、サービスの知覚価値を構築することにより、ユーザーの期待を管理しようとします。 ちなみに、前述のリトルビッグルームのウェブサイト上のローディングインジケーターは、ファーストナショナルバンクのローディングインジケーターのように、実際のプロセスとは関係がありません：オペレーションの進行状況を示すだけでなく、期待を制御します。

これにより、次のことがわかります。相互作用や作業のまったく新しい方法を導入していない場合、ユーザーはそれについて既に一定の期待を抱いています。 プロセスを加速すると、これらの期待が制限され、ユーザーが無効になり、サービスの価値が大幅に低下する場合があります。 長い目で見れば、これはより遅いプロセスよりも損害を与える可能性があります。


場合によっては、プロセスを高速化すると、サービスの知覚価値が大幅に低下します 。

「すべてに道徳があります。それを見つけることができるのはあなただけです！」 と不思議の国のアリスの冒険で公爵夫人は言いました。 そして、この記事はその教訓を控えめに伝えようとしています。 私たちのプロジェクトの生産性と速度は確かに非常に重要です。 しかし、スピードへの渇望を解消する前に、ユーザーの期待とニーズを満たす必要があります。 優れた開発者は、Webサイトを高速化する方法を知っています。 優秀な開発者は、いつそれを行うのかを知っています。 新しいツールを習得し、ユーザーを調査して、最高のツールを提供します。

すべてに終わりがあります。 そして、これはこの記事を完了するためのマーカーです。

---

フロントエンドのパフォーマンスの最適化に興味がありますか？ HolyJS 2018 Piterカンファレンスへようこそ！ JavaScriptコミュニティの現在と未来を世界の専門家と議論するために、500人以上のJS開発者が集まります：ダグラスクロックフォード、リーベロウ、アザットマーダン、ジェラルドサンズ、ミンコゲチェフ、ヴィタリーフリドマン-フロントエンドに関するレポートだけでなく、 。 バックエンドとデスクトップの両方に触れます。 すべての詳細は会議ウェブサイトにあります。