ユーザーは常にソフトウェアまたはハードウェアを正しく使用しており、それ以外の場合は失礼、侮辱的、哲学的に間違っていることを示唆していると私は考えています。たとえば、私と私が知っているすべての人は、USBドライブをコンピューターから引き出し、クリックイジェクトする必要はありません。 OS開発者は、これを確認し、これに対応するソフトウェアを構築して、「間違った」というメッセージでユーザーを煩わせる必要はありません。
これは、UXデザイナー/開発者の間で広く受け入れられている見解ですか?この哲学の公式用語はありますか?
編集:「ユーザーは何も間違って使用することはできません」という意味を明確にする必要があるようです。ユーザーが何かを間違って使用するのを防ぐべきだと言っているのではありませんが、何かを使用する「間違った」方法はありません。大多数のユーザーがマイクをハンマーとして使用する場合(Shure SM57のように)、設計者はこれを採用し、次のイテレーションでハンマー機能を改善する必要があります。
編集2:私のポイントを証明してくれてありがとう。ここに私が投稿したポイント(ユーザーは何も間違ったものを使用することはできません)を1つの方法で解釈し、あなたはすべて別の方法で解釈しました。私の意図は、取るべき間違った行動はないということでした、そしてあなたの全体的な解釈は、実際に間違った行動があるということでした。
みなさん正解です。投稿の設計者として、私はここで責任を負っていません。私はこの投稿の要旨をもっと明確にすべきでした。ユーザーの解釈のみが重要であるため、私の意図が何であるかについてあなたと議論する権利はありません。そんな爽快な議論をありがとうございました!
いいえ。これは、UXデザイナーの間で広く受け入れられている見解ではありません。残念ながら。
SOを使用しており、自分をUXデザイナーと見なしている人の間では、そうでもありません。
これは主に、UXデザインが厳密な分野ではなく、その支持者が潜在的なユーザーの忍耐と理解を実践していないためだと思います。おそらくさらに悪いことに、彼らは理想的なUXの「デザイン」が存在し、データから識別できると信じているようです。これは、分析の基準を設定する資格が最も低く、洞察と直感の両方が欠けているため、この複合物です。多くの場合、これらのことをまったく評価しません。
UXデザインは、プログラミングよりも自己選択バイアスに関連する問題が多い数少ない分野の1つです。かなりの成果です。
はい、これには用語があります(「ユーザーはanythingを実行できません」=)。
しかし、他の答えが指摘するように、完全に間違いのないものを作ることは現実的ではありません。ウィキペディアで、ダグラスアダムスの引用を見つけましたほとんど無害:
完全に間違いのないものを設計しようとするときに人々が犯す一般的な間違いは、完全なばかの独創性を過小評価することです
最小化の用語もあり、ユーザーが何を間違えることができるか:
ディフェンシブデザインでは、ユーザーが危害を最小限に抑えられるように設計する一方で、完全な間違いがないことを期待しません。いくつかのテクニックは次のとおりです。
everyの可能性があるユーザーとの対話のための調整は不可能です。
あなたの例を使ってみましょうが、USBをコンピュータ全体に切り替えます。ユーザーは電源コードを引き、ドライブに保存されているすべてのデータを魔法のようにコンピューターが安全にオフになることを期待できます。 USBのように。 UXデザイナーはこれにどのように備える必要がありますか?
上記のすべての解決策は、実行中のコンピュータのプラグを抜く危険についてユーザーに警告する単純な手動よりも悪いです。
電動のこぎりが指に触れると魔法のようにすぐに動作が停止することを期待していない場合は、コンピューターがすべての作業を実行することを期待しないでください。これが、デザイナーとプログラマーが頭字語 [〜#〜] rtfm [〜#〜] を持っている理由です。
あなたが説明しているのは ユーザー中心設計 の結果です(造語 Don Norman自身 )。 「ユーザーは常に正しい」と「それはユーザーの責任ではない」です。
指摘したように、この種の考え方は、UXの専門家の間でさえ一般的ではありません。問題は、ユーザーのメンタルモデルに合わせるのではなく、ユーザーの行動を「修正」しようとしていることです。
この例では、ユーザーのメンタルモデルは、フラッシュドライブの準備ができており、そこにファイルをコピーしたり、そこからファイルをコピーしたりしていない場合は、フラッシュドライブを削除できることです。したがって、ソフトウェアとハードウェアをこれに合わせて設計し、結果として発生する可能性のあるエラーを防止する必要があります。これを実現するためのいくつかの提案を次に示します。
あなたが探しているコンセプトはポカよけ( https://en.wikipedia.org/wiki/Poka-Yoke )なのでしょうか。これは多くの場合、機械的な設計(たとえば、同時に開くことができないZooケージの両開きドア)に関連していますが、UX設計で類推できます(たとえば、使用できるものが何もないときに削除ボタンを提供しないでください)削除)。
これは、一般的なUX設計原則です。最良のエラーメッセージは、そもそもエラーメッセージを回避することです。設計原則の例は多数ありますが、標準セットはありません。
Jacob Neilsonは、10のユーザビリティヒューリスティックスで「エラー防止」という用語を使用しました。 https://www.nngroup.com/articles/ten-usability-heuristics/
「適切なエラーメッセージよりも優れているのは、最初から問題が発生しないようにする注意深い設計です。エラーが発生しやすい状態を解消するか、エラーをチェックして、アクションを実行する前に確認オプションをユーザーに提示してください。」
アップルは、IOSガイドライン: https://developer.Apple.com/design/human-interface-guidelines/ios/overview/themesで「ユーザーコントロール」と呼んでいます。 /
「最高のアプリは、ユーザーを有効にすることと望ましくない結果を回避することの正しいバランスを見つけます。」
分析の観点からこの質問に近づくだけで、一部のUX環境ではこの考え方がわかり、他の環境ではわかりません。ユーザーが何ができるかについて非常に制限されている場合は、説明した原則に従うUXの方が優先されます。ユーザーが許可される自由が多ければ多いほど、これらの原則の人気は低くなります。
この効果の本当の名前は言いませんが、「大きな力には大きな責任が伴う」と言います。
これは、このスレッドで何度も表示されているUSBの例の問題です。ハードウェアを物理的に変更できるユーザーには、注目すべきの自由度があります。彼らはシステムに対して大きな力を持っているため、何が起こるかについてより多くの責任があります。確かに、ファイルのコピーが完了するまでロックをかけるUSBデバイスを作成できます。 USBデバイスの軸に沿ってハードウェア上の穏やかなタグに電力を制限する限り、それは機能します。 Sawzallを使用しているユーザーは、十分な責任がなく、接続中にUSBデバイスを半分に切断することで何ができるかを知らない場合、間違いなく私のUSBデバイスに何か問題を起こす可能性があります。
このSawzall要件を満たすためのPSUの実装についても話そうではありません...
コンパイラを備えたシステムはすべて、この現実に直面する必要があります。コンパイラーでwillを実行して問題を起こすことができます。私は何かを壊します。削除するはずのなかったファイルを削除できます。一体、私は持っているそのようなファイルを削除しました! Doomの輝かしいマルチスレッドの前兆と並行して、それらも削除しました!それは悪い知らせであり、間違いなく「私の間違い」でした。
これを、iPhoneアプリの設計と比較してください。 iOSは、ユーザーが実行できること、およびユーザーが設計によりアプリケーションと対話する方法を厳しく制限しています。それは、優れたモバイルOSの目的です。同様に、アプリ開発者が許可する操作はほとんどありません。これにより、UXがシンプルになります。このような状況では、ユーザーが実行できる狭い範囲の操作をキャプチャして、ユーザーが実際に何か間違ったことを実行できないことを証明するのは非常に簡単です。このような設定では、ユーザーエクスペリエンスの観点から、この考え方をサポートすることは非常に理にかなっています。
特に、ビジネスアプリはこれを念頭に置いて設計されています。あなた本当に低賃金の入門レベルの労働者にあなたのアプリで破滅的な間違いをさせたくありません。 POSデバイスは、外国の悪意のあるエージェントに誤ってクレジットカード番号をメールで送信しないように設計されています。あなたはそれを行うことはできません!
したがって、両極端を見ることができます。状況によっては、ユーザーが本当に何も問題を起こさないようにする必要があります。他の状況ではできません。メンタリティの間に境界線がないと言うのはかなり合理的だと思います。それは、「ユーザーが間違ってはいけない」から「ああ、神様、猿はナイフを持っている!」という滑らかなスペクトルです。
私たちは常にこれをユーザープルーフと呼んでおり、通常、ソフトウェア開発において最も時間がかかる側面です。ユーザーが何も悪いことをすることができないほど多くはありませんが、ユーザーが何をしても、ソフトウェアがクラッシュしたり壊れたりすることはありません。この用語は、少なくとも私が専門的に開発を始めた1997年にさかのぼります。
設計とエンジニアリングのすべてにコストがかかるという事実を誰も取り上げていないことに私はショックを受けました。より多くのユースケースをカバーし、ユーザーが望むより多くの機能を備えた、より優れたバージョンをいつでも設計できますが、そのたびに何かを犠牲にします。あなたが犠牲にするのは文字通りのコストであり、価格を上げたり利益を下げたりするかもしれません。
USBを抜かずに引き抜く例を使用するには、さまざまなアプローチに関連するコストがいくつかあります。
USBを適切な位置にロックすると、ドライブとポートの両方に製造コストと複雑さが加わり、ドライブの取り付けや取り外しが煩雑になるため、使いやすさが低下します。誰かがそのようなドライブを作ることができたとしても、私はそれを決して買わず、ロックのない通常のUSBを買い続けます。
その代わりに、USBが可能な限り排出可能な状態に保たれていることを確認すると、パフォーマンスが低下します(コンピューターが一定のクリーンアップを実行し、書き込み時間を短いバーストに制限する必要があるため)。フラッシュドライブの最大のセールスポイントの1つは読み取り/書き込み速度であるため、誰もそれを購入したくないでしょう。
いずれにせよ、このニッチなUX問題をカバーしようとすることで、多くの潜在的な顧客を失っています。
基本的に私が言っているのは、コスト/利益分析を行い、どの機能に価値があるか、そしてあなたが達成しようとしていることの範囲を超えている機能を決定しなければならないということです。はい、ユーザーを監視して耳を傾け、現実世界のシナリオでより役立つように製品を改良する方法を見つける必要がありますが、常に限界があります。
OS [およびすべてのソフトウェア]開発者は、これを確認し、これに対応するソフトウェアを構築して、ユーザーに「間違った」メッセージを表示する必要はありません。
はい、あなたは完全に、完全に、完全に正しいです。
あなたが言うことをするエンジニアと会社は莫大なお金を稼ぎます。
私たちの時代全体の最大の主要製品のいくつかは、完全にあなたの説明に基づいています。
これは、UXデザイナー/開発者の間で広く受け入れられている見解ですか?
はい、それは中心的なアイデアの1つです。
それは、UXの中心的な問題の1つとして、またはその中で、常に広く議論されています。
文字通り何百もの選択肢の中からあらゆる機能を探し求めなければならないので、BMW 7シリーズは悪夢でした。傑作のルノーエスパスコックピットは(下記参照)ユーザー主導であり、その縮図です。
この哲学の公式用語はありますか?
もちろんそうだ
10分前ではありません「ユーザー主導にする」と叫んだ人もいました。使用前にお客様が「設定しなければならない」スイッチなどがありましたが、これはばかげた考えです。代わりに、私はそれを「パスカルスタイル」にするために皆に叫びました。私は文字通り「これをユーザー主導にして、クソスイッチを取り除く」と言いました。
昨日私は文字通り仕事日全体を製品に関連する「パスカル問題」で処理し、他の問題はありませんでした。
2年前私は4か月かけて、独自の発明/エンジニアリング/珍しいグラフィカルインターフェイス用の新しい種類のアルゴリズムを使用して、最終結果全体が2つの悪い「アンチパスカルスタイル」アクションを排除していました。 (結果は数十億になった。)
ある程度、日常のフレーズは
基本的に、同様のアプローチになります。
注-「パスカル問題」は確かに非常に広まっているので、
たとえば、あなたが与えたリテラルの例では、それは
または
私たちが聞いたところによると、Appleはおそらく、あなたが生まれる前に、当時の競合他社よりも(「もっと」)プラグアンドプレイプリンターやその他の周辺機器が最初に市場に投入されてから約100億ドルを稼いだことになります。
したがって、「プラグアンドプレイ」または「ホットスワップ可能」は、ユーザー主導の設計全体の特定の特定のサブセット、KISS-UX、「Pascal-issue」です。
「ユーザーが間違ったものを使用できない」という意味を明確にする必要があります。ユーザーが何かを間違って使用するのを防ぐべきだと言っているのではありませんが、何かを使用する「間違った」方法はありません。大多数のユーザーがマイクをハンマーとして使用する場合(Shure SM57のように)、設計者はこれを採用し、次のイテレーションでハンマー機能を改善する必要があります。
これにより、タイトルの意味がほぼ完全に変わります。エラーを回避することから、「バグは機能である」までです。
私が考えることができる最も近いものはAgile/Lean UXです。ここに短いフィードバックループがあります。マイクやモバイルアプリなど、製品を構築してユーザーの手に渡ります。次に、それらの使用方法に応じて、これらの機能を拡張します。
また、元々の目的で使用されていないものに関しても、流行語 "pivot"が入ってくると思います。これは、マイクの人々が気づくところです彼らは偶然により良いハンマーを作り、あなたが歌うハンマーの販売を始めました。
非常に有用であることが判明した間違いがある、同様の関連領域が他にもあります-偶然の事故はここで関連する用語のようです。これらの中で最も有名なものは ペニシリン であると思いますが、英国では ブルータック の発見もあります。
フレミングは、彼のペニシリンの発見の日付が1928年9月28日金曜日の朝であったと語りました。この物語の伝統的なバージョンは、発見を偶然の事故:ロンドンのセントメアリー病院(現在はインペリアルカレッジの一部)の地下にある彼の研究室で、フレミングは、誤って開いたままにされていたブドウ球菌を含むペトリ皿が開いた窓から青緑色のカビに汚染されていることに気づきました。目に見える成長。型の周りに抑制された細菌の成長のハローがありました。フレミングは、カビが増殖を抑制し、細菌の溶解を引き起こした物質を放出したと結論付けました。
頭に浮かぶフレーズは
「お客様は常に正しいです。」
ユーザーは開発者としての顧客です。
それを過ぎて...防弾。
ユーザー中心主義は広範な原則であり、IME、それは、現代のソフトウェア製品チームと多くのハードウェア製品チームの間で広く受け入れられています。
UCDは、可能な限り最も現実的な状況でユーザーを観察することによって推進されます。デザイナーは、製品環境とプロトタイプに対する反応と相互作用を研究し、日常の環境にいるガイドなしのユーザーが、製品チームが提供するツールをどのように利用するかを学びます。
UCDの問題は、対象範囲が狭いユーザーの観察に追いつきすぎる傾向があり、全体像や技術の可能性を失ってしまうことです。
Activity Centered Designがこの問題を直接扱っていると思います。 ACDは、ユーザーのワークフロー全体と達成する必要のあるジョブに対応します。
ACDは視点を変える
「ユーザーはこのことで機能をどのように実行したいですか」
「ユーザーをこの仕事で根本的に成功させるにはどうすればよいか」。
ユーザーがあなたの製品を見て、それを意図しない目的または意図しない方法で使用することを決定した場合、UXDはビジネスに質問を強いられます。
元の問題の解決に全力で取り組んでいるのか、それともこの予期せぬ機会に対処するためにピボットしたいのか?
一般的には、元の問題に集中したままにします(テストでそれが関連性があることを示していると仮定します)。ユーザーのアクティビティの観察に基づいて、UXDは次のプロトタイプに組み込む証拠を持っています。
これは、迅速なプロトタイピングとユーザーテストが維持される場所です。正しい方法で正しい問題を解決したかどうかを確認する、より効果的で効率的な方法はありません。そのモデルの詳細については、 本「Sprints」 を確認してください。
UXDがユーザーの「エラー」を組み込まずに製品を設計している場合、彼らはそれを間違っています。チームを学校に送るか、新しいチームを見つける時が来ました。
成功への落とし穴 は、開発コミュニティで使用される用語です。言語またはライブラリの設計に重点を置いていますが、フロントエンドの対話にも適用できます。 UXを他の開発者と話し合って同じページにたどり着くために使用する語彙です。
「ユーザーは何も間違ったものを使用することはできません」というデザインは存在すべきではないので存在しません。これは「防止」設計であり、意識的なミスやユーザーエラーを回避しますが、「ユーザーは何も間違ったものを使用できない」と想定すると、悪影響が生じる可能性があります。
ユーザーエラーの防止:無意識のスリップの回避 のNielsen Norman Groupは次のように説明しています。
ユーザーがエラーをコミットするのが非常に簡単になるのは設計者の責任です。したがって、ユーザーエラーの解決策は、ユーザーを叱る、一生懸命試すように依頼する、またはより広範囲なトレーニングを与えることではありません。答えは、エラーが発生しにくいようにシステムを再設計することです。
スリップ防止のための一般的なガイドライン:
- 役立つ制約を含める
- 提案を提案する
- 適切なデフォルトを選択
- 寛容なフォーマットを使用する
一方、ユーザーアドレスを収集するときに寛容すぎる場合は、それを使用して製品を配信する方法を教えてください。あなたが正しい住所を提供するように彼にストレスを与えたくないので、彼をストーカーすることは解決策ではありません。
別の例としては、ユーザーに自分のアカウントを削除すると、これが使用できなくなることをユーザーに通知する場合があります。ユーザーが気が変わったときに30日間の間隔を空けてもかまいませんが、ユーザーが誤ってアカウントを削除してしまう可能性があるため、この後、データを保存することはできません。
コミュニティとしてのUXには「ユーザーは何も悪いことはできない」という言葉はないと思います。それ自体。しかし、「フールプルーフ」、「フェールオープン」、「チャイルドプルーフ」など、他の分野のさまざまな設計哲学が適用される場合があります。
たとえば、5歳と6歳の娘は1年以上YouTube Kidsアプリを使用していて、その間ずっと技術的な問題が1つしかありませんでした私は彼らに下にスワイプする方法を彼らに示した、そして彼らは去った。しかし、あなたが少し待つと、彼らは自然に消えていく。それは驚くべき成果です。
このテーマに関する1つの優れたリソースは、Steven KrugによるDo n't Make Me Thinkです。
Macの世界から来て、個人的には、アプリケーションのドキュメントをデスクトップからタスクバーのアプリケーションのアイコンにドラッグするだけの簡単な方法ではドキュメントが開かないことに驚かされました。私たちはWindowsバージョン10を使用していますが、これはまだ機能しません。 Windows 7までは、エラーが発生していました。
あなたの哲学はすべてに当てはまるわけではないかもしれません-いくつかのプロセスは常に学習曲線を必要とします-しかし、あなたは何かに任されています。
オンラインバンキングのウェブサイトで迷ったら、サポート担当者に次のことを伝えます。
[〜#〜] i [〜#〜]がそれを見つけることができない場合(熟練したコンピューターの専門家として)、あなたはそれを間違っています。
すべての経験が必ずしも楽しいまたは簡単である必要はありません。認知の容易さは、人々がより楽しく、創造的に感じるのに役立ちますが、逆に直観的な判断の誤りを起こしやすくします。
逆に、 認知的緊張は、直感的なエラーを修正できるより注意深く意図的な思考モードを動員するという証拠があります。
これは、重要な仕事や学校、助成金、政府の許可申請の完了などの比較的多くの問題が発生している状況や、医療や製薬のコンテキスト、あるいは非常に高価なオンライン購入を検討している場合に特に関係があるようです。
よく繰り返される「 Do n’t Make Me Think 」は、必ずしも間違ったアドバイスではないかもしれません。私自身のライフサイエンスユーザー向けの設計経験では、ターゲットとしてappropriateに簡単ではなく、より傾倒しています。