楽観的なユーザーインターフェイスの真の嘘

公開: 2022-03-10

クイックサマリー↬3つのユーザーインターフェイス（UI）がパブにアクセスします。最初のものは飲み物を注文し、次にさらにいくつか注文します。数時間後、請求書を要求し、パブを酔っぱらったままにします。 2番目のUIは、飲み物を注文し、前払いし、別の飲み物を注文し、支払いを行うなど、数時間でパブを酔っぱらったままにします。 3番目のUIは、入った直後にすでに酔っているパブを終了します—パブがどのように機能するかを知っており、時間を無駄にしないほど効率的です。この3つ目について聞いたことがありますか？これは「楽観的なUI」と呼ばれます。

3つのユーザーインターフェイス（UI）がパブに行きます。最初のものは飲み物を注文し、次にさらにいくつか注文します。数時間後、請求書を要求し、パブを酔っぱらったままにします。 2番目のUIは、飲み物を注文し、前払いし、別の飲み物を注文し、支払いを行うなど、数時間でパブを酔っぱらったままにします。 3番目のUIは、入った直後にすでに酔っているパブを終了します—パブがどのように機能するかを知っており、時間を無駄にしないほど効率的です。この3つ目について聞いたことがありますか？これは「楽観的なUI」と呼ばれます。

optimistic ui — 楽観的なUIデザインは、バラ色のメガネを通してWebを見ることではなく、少なくともそれだけではありません。（拡大版を表示）

最近、フロントエンド開発とUXの両方を専門とする多くの会議で心理的パフォーマンスの最適化について話し合ったのですが、コミュニティで楽観的なUIデザインのトピックがほとんど取り上げられていないことに驚きました。率直に言って、用語自体は明確に定義されていません。この記事では、それがどのような概念に基づいているかを調べ、いくつかの例を見て、その心理的背景を確認します。その後、このUX手法の制御を維持する方法に関する懸念事項と要点を確認します。

SmashingMagの詳細：

ユーザーは匿名のWebデザイナーです
カードベースのユーザーインターフェイスの設計
会話型インターフェース：私たちは今日どこにいますか？

ジャンプした後もっと！以下を読み続けてください↓

しかし、始める前に、真実は言われます。「楽観的なUI」と呼ぶことはできません。むしろ、それはインターフェースの実装の背後にあるメンタルモデルです。楽観的なUIデザインには、独自の歴史と理論的根拠があります。

昔々

ずっと前に—「ツイート」という言葉が主に鳥に適用されたとき、Appleは破産の危機に瀕しており、人々はまだ名刺にファックス番号を付けていました—Webインターフェースは非常に禁欲的でした。そして、彼らの大多数は楽観的な見方さえしていませんでした。たとえば、ボタンとの相互作用は、次のようなシナリオに従うことができます。

ユーザーがボタンをクリックします。
ボタンがトリガーされて無効状態になります。
呼び出しがサーバーに送信されます。
サーバーからの応答がページに返送されます。
応答のステータスを反映するためにページがリロードされます。

これは2016年にはかなり非効率に見えるかもしれません。ただし、驚くべきことに、同じシナリオが依然として多くのWebページやアプリケーションで使用されており、多くの製品の対話プロセスの一部となっています。その理由は、予測可能で、多かれ少なかれエラーがないためです。ユーザーは、アクションがサーバーから要求されたことを知っており（ボタンの無効状態がこれを示唆しています）、サーバーが応答すると、更新されたページに明確に示されます。このクライアント-サーバー-クライアントの相互作用の終わり。この種の相互作用の問題は非常に明白です。

ユーザーは待たなければなりません。今では、サーバーの応答時間の最短の遅延でさえ、この特定のページだけでなく、ブランド全体に対するユーザーの認識に悪影響を与えることがわかっています。
ユーザーがアクションへの応答を受け取るたびに、それは非常に破壊的な方法で表示され（既存のページが更新されるのではなく、新しいページが読み込まれます）、ユーザーのタスクのコンテキストが壊れ、思考の流れに影響を与える可能性があります。この場合、必ずしもマルチタスクについて話しているわけではありませんが、精神的な文脈の切り替えは不快です。したがって、アクションが本質的にコンテキストを切り替えることを意図していない場合（オンライン支払いは、切り替えが自然な場合の良い例です）、切り替えは、ユーザーとシステムの間に不親切な対話のトーンを設定します。

古き良き時代

その後、いわゆるWeb 2.0が登場し、Webページとの新しい対話モードが提供されました。これらの中核はXMLHttpRequestとAJAXでした。これらの新しい対話モードは、「スピナー」によって補完されました。最も単純な形式の進行状況インジケーターであり、その唯一の目的は、システムが何らかの操作の実行でビジーであることをユーザーに通知することでした。これで、サーバーから応答を受け取った後にページをリロードする必要はありませんでした。代わりに、すでにレンダリングされたページの一部を更新することもできます。これにより、Webがはるかに動的になり、ユーザーにとってよりスムーズで魅力的なエクスペリエンスが可能になりました。ボタンとの一般的な操作は次のようになります。

ユーザーがボタンをクリックします。
ボタンは無効状態でトリガーされ、システムが機能していることを示す何らかのスピナーがボタンに表示されます。
呼び出しがサーバーに送信されます。
サーバーからの応答がページに返送されます。
ボタンとページの表示状態は、応答状態に応じて更新されます。

この新しいインタラクションモデルは、古いインタラクション方法の前述の問題の1つに対処しました。ページの更新は破壊的なアクションなしで行われ、ユーザーのコンテキストを維持し、以前よりもはるかに優れたインタラクションに従事します。

XMLHttpRequestとスピナーは、古い対話方法の問題の1つである、サーバーの応答後のコンテキストの破壊的な切り替えを解決しました。（拡大版を表示）

この種のインタラクションパターンは、デジタルメディアのいたるところで広く使用されています。ただし、1つの問題が残っています。ユーザーは、サーバーからの応答を待つ必要があります。はい、サーバーの応答を高速化することはできますが、インフラストラクチャを高速化しようとしても、ユーザーは待機する必要があります。繰り返しになりますが、ユーザーはそれを穏やかに言うために待つのが好きではありません。たとえば、調査によると、消費者の78％は、ウェブサイトの速度が遅い、または信頼性が低いために否定的な感情を感じています。さらに、Harris Interactive for Tealeafが実施した調査によると、ユーザーの23％が自分の携帯電話でののしりを告白し、11％が悲鳴を上げ、4％全体がオンライントランザクションで問題が発生したときに実際に携帯電話を投げました。遅延はそれらの問題の1つです。

消費者の約78％は、ウェブサイトの速度が遅い、または信頼性が低いために、否定的な感情を感じています。（拡大版を表示）

ユーザーが待機している間に何らかの進行状況インジケーターを表示したとしても、そのインジケーターを非常にクリエイティブに使用していない限り、今日ではそれだけでは不十分です。ほとんどの場合、人々はシステムの速度が遅いことを示すスピナーに慣れています。ユーザーがサーバーの応答を待つか、タブまたはアプリケーションを完全に閉じる以外のオプションがない場合、スピナーは純粋にパッシブな待機に関連付けられるようになりました。それでは、この種の相互作用を改善するためのステップを考えてみましょう。楽観的なUIのこの概念を見てみましょう。

楽観的なUI

前述のように、楽観的なUIは、人間とコンピューターの相互作用を処理する方法にすぎません。その背後にある主なアイデアを理解するために、「ユーザーがボタンをクリックする」シナリオに固執します。しかし、原則は、楽観的にしたいと思うかもしれないほとんどすべての種類の相互作用について同じです。オックスフォード英語辞典によると：

op-ti-mis-tic 、 adj。 将来に希望と自信を持っています。

「未来に自信がある」の部分から始めましょう。

あなたはどう思いますか：あなたのサーバーはどのくらいの頻度でユーザーの行動でエラーを返しますか？たとえば、ユーザーがボタンをクリックするとAPIが失敗することがよくありますか？それとも、ユーザーがリンクをクリックすると失敗することが多いのでしょうか。率直に言って、私はそうは思いません。もちろん、これはAPI、サーバーの負荷、エラー処理のレベル、およびフロントエンド開発者またはUXスペシャリストとして関与したくないその他の要因によって異なる場合があります。ただし、APIがは安定していて予測可能であり、フロントエンドはUIで正当なアクションを適切に伝達するため、ユーザーが開始したアクションに応答するエラーの数は非常に少なくなります。私は、彼らが1から3％を超えてはならないことを述べるところまで行きます。これは、ユーザーがWebサイトのボタンをクリックした場合の97〜99％の場合、サーバーの応答はエラーなしで成功するはずであることを意味します。これは、より良い視点に置く価値があります。

楽観的なUIは、ユーザーがボタンをクリックすると、サーバーが97〜99％のケースで成功応答を返す必要があるという前提に基づいています。（拡大版を表示）

少し考えてみてください。成功の反応について97〜99％確信していれば、それらの反応の将来について自信を持つことができます。少なくとも、シュレディンガーの猫よりもはるかに将来について自信があります。ボタンの相互作用についてまったく新しいストーリーを書くことができます。

ユーザーがボタンをクリックします。
ボタンの視覚的状態は、即座に成功モードにトリガーされます。

それでおしまい！少なくともユーザーの観点からは、それ以上のことは何もありません。待つことも、無効になっているボタンを見つめることも、さらに別の迷惑なスピナーもありません。相互作用はシームレスであり、システムがユーザーに自分自身について大雑把に思い出させることはありません。

楽観的なUIインタラクションには、無効にされたボタンやスピナーの場所がありません。（拡大版を表示）

開発者の観点からは、完全なサイクルは次のようになります。

ユーザーがボタンをクリックします。
ボタンの視覚的状態は、即座に成功モードにトリガーされます。
呼び出しはサーバーに送信されます。
サーバーからの応答がページに返送されます。
97〜99％のケースで、応答が成功することがわかっているため、ユーザーに迷惑をかける必要はありません。
リクエストが失敗した場合にのみ、システムが起動します。今のところこれについて心配する必要はありません。この点については、この記事の後半で説明します。

楽観的な相互作用のいくつかの例を見てみましょう。 FacebookやTwitterにあるように、あなたはおそらく「いいね」ボタンに精通しているでしょう。後者を見てみましょう。

それは、明らかに、ボタンをクリックするだけで始まります。ただし、ユーザーがボタンを押したりホバーしたりしなくなったときのボタンの視覚的な状態に注意してください。瞬時に成功状態に切り替わります！

いいねボタンがクリックされると、Twitterは即座にそれを視覚的に成功状態に更新します。

この瞬間に、ブラウザの開発者ツールの[ネットワーク]タブで何が起こっているかを見てみましょう。

ボタンの視覚的な状態は、まだ進行中のサーバー要求とは関係なく更新されます。（拡大版を表示）

「ネットワーク」タブは、サーバーリクエストが送信されたが、まだ進行中であることを示しています。「いいね」のカウンター番号はまだ増えていませんが、色が変わると、サーバーから応答を受け取る前であっても、インターフェイスはユーザーに成功を明確に伝えています。

サーバーから正常な応答を受信すると、カウンターが更新されますが、遷移は瞬間的な色の変化よりもはるかに微妙です。これにより、ユーザーは、待機することなく、スムーズで中断のないエクスペリエンスを得ることができます。

「いいね」ボタンは視覚的に成功モードですが、サーバーの応答で成功が確認された後にのみ、カウンターが更新されます。（拡大版を表示）

楽観的な相互作用の別の例は、独自の「いいね」ボタンを備えたFacebookで見られます。シナリオは非常に似ていますが、Facebookがサーバーの応答を待たずに、ボタンの成功色とともにカウンターを即座に更新する点が異なります。

Facebookは、ボタンの視覚的な状態とともにカウンターを即座に更新することを除いて、Twitterと同じ楽観的な相互作用を採用しています。

ただし、ここで注意すべきことが1つあります。サーバーの応答時間を見ると、 1秒強であることがわかります。 RAILモデルが単純な対話の最適な応答時間として100ミリ秒を推奨していることを考えると、これは通常、長すぎます。ただし、この場合、この対話は楽観的であるため、ユーザーは待機時間を認識しません。良い！これは、心理的パフォーマンスの最適化のもう1つの例です。

しかし、それに直面しましょう。サーバーがエラーを返す可能性は1〜3％です。または、ユーザーが単にオフラインになっている可能性があります。または、おそらくサーバーは技術的には成功応答を返しますが、応答にはクライアントがさらに処理する必要のある情報が含まれています。その結果、ユーザーには失敗インジケーターは表示されませんが、応答が成功したとは見なされません。このようなケースに対処する方法を理解するには、そもそも楽観的なUIが心理的に機能する理由と方法を理解する必要があります。

楽観的なUIの背後にある心理学

これまでのところ、主要なソーシャルネットワークでの前述の楽観的な相互作用について不満を言う人は誰もいません。したがって、これらの例によって、楽観的なUIが機能することがわかったとしましょう。しかし、なぜ彼らはユーザーのために働くのですか？人々が待つことを嫌うという理由だけで彼らは働きます。それだけです、皆さん！記事の次の部分にスキップできます。

しかし、あなたがまだ読んでいるなら、あなたはおそらくそれがなぜそうなのかを知ることに興味があるでしょう。それでは、このアプローチの心理的根拠をもう少し深く掘り下げてみましょう。

脳の研究は、楽観的なUIが機能する理由の背後にある心理学を理解するのに役立ちます。（拡大版を表示）

楽観的なUIには、心理学的分析に値する2つの基本的な要素があります。

ユーザーのアクションへの高速応答。
サーバー、ネットワーク、その他の場所で発生する可能性のある障害の処理。

ユーザーアクションへの迅速な対応

楽観的なUIデザインについて話すときは、人間とコンピューターの相互作用における最適な応答時間について話します。そして、このタイプのコミュニケーションに関する推奨事項は、1968年から存在しています。当時、Robert B. Millerは、彼の独創的な作品「人間とコンピューターの会話トランザクションにおける応答時間」（PDF）を公開しました。ユーザーがコンピューターから取得できるさまざまなタイプの応答。これらのタイプの1つであるミラーは、「アクティブ化を制御するための応答」と呼んでいます。これは、キーを押してから視覚的なフィードバックまでの遅延です。 1968年にさかのぼっても、0.1〜0.2秒を超えてはなりませんでした。はい、これを推奨するのはRAILモデルが最初ではありません。アドバイスは約50年前からあります。ただし、ミラーは、フィードバックのこの短い遅延でさえ、熟練したユーザーには遅すぎる可能性があると述べています。これは、理想的には、ユーザーは100ミリ秒以内にアクションの確認を取得する必要があることを意味します。これは、人体が実行できる最も速い無意識の行動の1つであるまばたきの範囲に入りつつあります。このため、通常、100ミリ秒の間隔は瞬時に認識されます。「ほとんどの人は1分間に約15回まばたきをし、まばたきは平均100〜150ミリ秒続きます」とUniversity CollegeLondonの神経学研究所のDavinaBristowは言い、これは「全体として、年間少なくとも9日間まばたきをすることを意味します。」

（実際のリクエストが終了する前であっても）その即時の視覚的応答のため、楽観的なUIは、心理的パフォーマンスの最適化で使用される早期完了手法の例の1つです。しかし、瞬く間に応答するインターフェースが好きな人がいるという事実は、私たちのほとんどにとって驚くべきことではありません。そして、それを達成することも難しくありません。昔もボタンをクリックするとすぐに無効になり、通常はユーザーの入力を確認するのに十分でした。ただし、インターフェイス要素の無効状態はパッシブ待機を意味します。ユーザーはそれについて何もできず、プロセスを制御できません。そして、これはユーザーにとって非常に苛立たしいことです。そのため、楽観的なUIで無効状態を完全にスキップします。ユーザーを待たせるのではなく、肯定的な結果を伝えます。

潜在的な障害の処理

楽観的なUIデザインの2番目の興味深い心理的側面である潜在的な障害の処理に取り掛かりましょう。一般に、UIエラーを可能な限り最善の方法で処理する方法については、多くの情報と記事が用意されています。ただし、この記事の後半で障害の処理方法を説明しますが、楽観的なUIで最も重要なのは、エラーの処理方法ではなく、いつ処理するかです。

人間は自然に活動を塊に編成し、主観的に定義された目的またはサブ目的の完了によって終了します。これらの塊を「思考の列」、「思考の流れ」（PDF）、または単に「流れ」と呼ぶことがあります。流れの状態は、最高の楽しみ、エネルギッシュな集中力、創造的な集中力によって特徴付けられます。フロー中、ユーザーはアクティビティに完全に夢中になります。タミー・エヴァーツによるツイートはこれをうまく示しています：

ウェブ上では、そのような活動の塊の持続時間ははるかに短いです。ロバート・B・ミラーの作品を少し振り返ってみましょう。彼が引用する応答タイプは次のとおりです。

リストされた情報の簡単な問い合わせへの応答。
グラフィック形式の複雑な問い合わせへの回答。
「システム、あなたは私を理解していますか？」への応答

彼は、これらすべてを、ユーザーが関連するタイプの応答を取得する必要がある同じ2秒の間隔に結び付けます。深く掘り下げることなく、この間隔は人の作業記憶にも依存することに注意する必要があります（人が頭の中に一定量の情報を保持でき、さらに重要なことに、それを操作できる時間の長さを指します）。開発者およびUXスペシャリストとしての私たちにとって、これは、要素を操作してから2秒以内に、ユーザーがフローに参加し、期待する応答に集中できることを意味します。この間隔の間にサーバーがエラーを返した場合でも、ユーザーはいわばインターフェースとの「対話」状態にあります。それは、あなたが何かを言い、他の人があなたに少し反対する、2人の間の対話に似ています。他の人が同意してうなずくのに長い時間を費やしたが（UIでの成功状態の表示に相当）、最終的にあなたに「いいえ」と言った場合を想像してみてください。ぎこちないですね。したがって、楽観的なUIは、フローから2秒以内にユーザーに障害を通知する必要があります。

楽観的なUIは、ユーザーに失敗を明確かつ注意深く伝える必要があります。最も重要なことは、ユーザーのフローから2秒以内に発生する必要があることです。（拡大版を表示）

楽観的なUIで失敗を処理する方法の心理学を武器に、最後に失敗したリクエストの1〜3％に到達しましょう。

楽観的なUIデザインの悲観的な側面

私が耳にする最も一般的な意見は、楽観的なUIデザインは一種の黒いパターンであるということです。つまり、それを採用することによって、私たちはユーザーの相互作用の結果についてユーザーに嘘をついています。法的に、どの裁判所もおそらくこの点を支持するでしょう。それでも、私はこのテクニックを予測または希望と考えています。（「楽観的」の定義を覚えていますか？ここで、「希望に満ちた」部分の余地を残します。）「嘘をつく」と「予測する」の違いは、失敗したリクエストの1〜3％をどのように扱うかです。 Twitterの楽観的な「いいね」ボタンがオフラインでどのように動作するかを見てみましょう。

まず、楽観的なUIパターンに沿って、ボタンはクリックされた直後に成功状態に切り替わります。これも、ユーザーがオンラインのときのボタンの動作とまったく同じように、ユーザーがボタンを押したりホバーしたりすることはありません。

オフラインの場合でも、Twitterの「いいね」ボタンはクリックされた後も視覚的に更新されます。（拡大版を表示）

ただし、ユーザーがオフラインであるため、リクエストは失敗します。

したがって、ユーザーのフロー内でできるだけ早く、障害を通知する必要があります。繰り返しますが、通常2秒はそのようなフローの持続時間です。 Twitterは、ボタンの状態を元に戻すだけで、これを可能な限り微妙な方法で伝達します。

リクエストが失敗した後、Twitterは、視覚的な煩わしさなしに、「いいね」ボタンの視覚的な状態を微妙に戻します。（拡大版を表示）

ここでの良心的な読者は、リクエストを送信できなかったことやエラーが発生したことを実際にユーザーに通知することで、この障害処理をさらに一歩進めることができると言うかもしれません。これにより、システムが可能な限り透過的になります。しかし、落とし穴があります。つまり、一連の問題があります。

画面に突然表示されるあらゆる種類の通知は、ユーザーのコンテキストを切り替え、失敗の背後にある理由を分析するように促します。この理由は、おそらくエラーメッセージに表示されます。
他のエラーメッセージや通知と同様に、これは実用的な情報を提供することにより、この新しいコンテキストでユーザーをガイドする必要があります。
その実用的な情報は、さらに別のコンテキストを設定します。

さて、これまでに、これが少し複雑になっていることに同意することができます。このエラー処理は、たとえばWebサイトの大きなフォームでは、「いいね」ボタンをクリックするだけの簡単なアクションでは合理的ですが、必要な技術開発とユーザーの作業メモリーの両方の点でやり過ぎです。

ですから、そうです、私たちは楽観的なUIの失敗についてオープンにすべきであり、私たちの楽観主義が嘘にならないように、できるだけ早くそれを伝える必要があります。しかし、それは文脈に比例するはずです。失敗したような場合は、ボタンを微妙に元の状態に戻すだけで十分です。つまり、ユーザーが重要な相手のステータスを気に入っている場合を除きます。この場合、常にうまく機能します。

極端な悲観主義

もう1つの質問が発生する可能性があります。ユーザーが成功インジケーターを取得した直後で、サーバーから応答が返される前にブラウザータブを閉じるとどうなりますか？最も不快なケースは、リクエストがサーバーに送信される前にユーザーがタブを閉じた場合です。しかし、ユーザーが非常に機敏であるか、時間を遅くする能力を持っていない限り、これはほとんど不可能です。

楽観的なUIが適切に実装され、サーバーの応答を2秒以上待たない要素にのみインタラクションが適用される場合、ユーザーはその2秒のウィンドウ内でブラウザータブを閉じる必要があります。これは、キーストロークでは特に難しくありません。ただし、これまで見てきたように、97〜99％のケースでは、タブがアクティブであるかどうかに関係なく、リクエストは成功します（応答がクライアントに返されないだけです）。

したがって、この問題は、サーバーエラーが発生した1〜3％の場合にのみ発生する可能性があります。それでは、2秒以内にタブを閉じるために急いでいる人はどれくらいいますか？彼らがタブを閉じるスピード競争に参加していない限り、その数は重要ではないと思います。ただし、これが特定のプロジェクトに関連していて、悪影響を与える可能性があると思われる場合は、いくつかのツールを使用してユーザーの行動を分析してください。そのようなシナリオの確率が十分に高い場合は、楽観的な相互作用を重要でない要素に制限します。

リクエストが人為的に遅れる場合については、意図的に言及していません。これらは通常、楽観的なUIデザインの傘下にはありません。さらに、私たちは物事の悲観的な側面に十分な時間を費やしてきたので、良い楽観的なUIを実装するためのいくつかの主要なポイントを要約しましょう。

経験則

この記事が、楽観的なUIデザインの背後にある主要な概念のいくつかを理解するのに役立つことを心から願っています。おそらく、次のプロジェクトでこのアプローチを試すことに興味があるでしょう。もしそうなら、始める前に覚えておくべきことがいくつかあります：

これまでに説明したすべての前提条件：依存しているAPIが安定していて、予測可能な結果を返すことを確認してください。十分に言った。
インターフェイスは、リクエストがサーバーに送信される前に、潜在的なエラーや問題をキャッチする必要があります。さらに良いことに、APIからエラーが発生する可能性のあるものを完全に排除します。 UI要素が単純であるほど、楽観的にすることが簡単になります。
成功または失敗の応答しか期待されない単純なバイナリのような要素に楽観的なパターンを適用します。たとえば、ボタンのクリックで「はい」、「いいえ」、「たぶん」などのサーバー応答が想定される場合（これらはすべて、さまざまな程度で成功を表す可能性があります）、楽観的なパターンがなければ、このようなボタンの方が適しています。
APIの応答時間を把握します。これは非常に重要です。特定のリクエストの応答時間が2秒を下回らないことがわかっている場合は、最初にAPIに楽観的な見方をするのがおそらく最善です。前述のように、楽観的なUIは、サーバーの応答時間が2秒未満の場合に最適に機能します。それを超えると、予期しない結果が発生し、多くのユーザーが不満を感じる可能性があります。警告されていると考えてください。
楽観的なUIは、ボタンのクリックだけではありません。このアプローチは、ページの読み込みなど、ページのライフサイクル中のさまざまなインタラクションやイベントに適用できます。たとえば、スケルトン画面は同じ考え方に従います。プレースホルダーに入力してユーザーにできるだけ早く表示するために、サーバーが正常に応答すると予測します。

楽観的なUIデザインは、実際にはWebで目新しいものではなく、これまで見てきたように、特に高度な手法でもありません。これは、製品の知覚パフォーマンスを管理するのに役立つ、単なる別のアプローチ、別のメンタルモデルです。人間とコンピューターの相互作用の心理的側面に基づいているため、楽観的なUIデザインをインテリジェントに使用すると、実装にほとんど必要とせずに、Web上でより優れたシームレスなエクスペリエンスを構築できます。しかし、パターンを真に効果的にし、製品がユーザーに嘘をつかないようにするためには、楽観的なUIデザインの仕組みを理解する必要があります。

資力

「人間とコンピュータの会話型トランザクションにおける応答時間」（PDF）、Robert B. Miller、秋の合同コンピュータ会議、1968年
「RAILの紹介：パフォーマンスのためのユーザー中心のモデル」、Paul Irish、Paul Lewis、Smashing Magazine、2015年
「モバイルWebストレス：感情的なエンゲージメントとブランド認知に対するネットワーク速度の影響」、Tammy Everts、ラドウェアブログ、2013年
人間の発達と教育における流れの応用、ミハイ・チクセントミハイ、2014年
「モバイルデザインの詳細：スピナーを避ける」、Luke Wroblewski、2013年
「パフォーマンスが重要な理由、パート2：知覚管理」、Denys Mishunov、Smashing Magazine、2015年