カテゴリ: 原則
種類: ユーザーインターフェース・ソフトウェア設計の原則
起源: 1980年代、IBMおよびAppleインターフェースガイドライン
別名: POLA、最小驚異の原則、Principle of Least Surprise
種類: ユーザーインターフェース・ソフトウェア設計の原則
起源: 1980年代、IBMおよびAppleインターフェースガイドライン
別名: POLA、最小驚異の原則、Principle of Least Surprise
クイックアンサー —
最小驚きの原則（POLA）は、システムの振る舞いがユーザーの期待に一致し、驚かせるべきではないと述べる設計ガイドラインです。1980年代のユーザーインターフェースガイドラインから生まれ、POLAはUXデザイン、API設計、ソフトウェアアーキテクチャにおける基本的な原則となり、予測可能性と一貫性を強調しています。
最小驚きの原則とは
最小驚きの原則は、ユーザーインターフェース、API、コードのいずれであれ、システムはユーザーを驚かせたり混乱させたりしない振る舞いをすべきであると述べています。ユーザーが予期しない振る舞いに遭遇したとき、彼らは「驚き」を経験し、それが信頼を蝕み、認知負荷を増大させます。「ユーザーインターフェースは、ユーザーがその振る舞いに決して驚かないように設計されるべきである。」— Apple Human Interface Guidelinesこの原則は、1980年代にIBMとAppleのインターフェースガイドラインから生まれました。そのアイデアは単純ながら革命的でした。ユーザーは経験によって形成されたメンタルモデルを持ってシステムにやって来ます。システムの振る舞いがこれらの期待と一致するとき、ユーザーは有能で自信を感じます。期待に違反するとき、たとえ小さな方法であっても、摩擦が増大します。 ソフトウェア開発では、POLAはユーザーインターフェースを超えて適用されます。API設計をガイドします。「delete」という名前のメソッドは、アーカイブではなく削除を行うべきです。コード構成をガイドします。「calculateTotal」という名前の関数は、データベースを変更するのではなく合計を計算すべきです。エラーハンドリングをガイドします。予期しないエラーはグレースフルに処理されるべきであり、アプリケーションをクラッシュさせるべきではありません。
最小驚きの原則を3つの深さで理解する
- ビギナー: ユーザーFacingの要素を設計する際、自問してください。「新しいユーザーはこの振る舞いを期待するでしょうか？」答えがノーの場合、振る舞いを変更するか、例外を明確に伝えてください。
- プラクティショナー: コードとAPIにPOLAを適用してください。ものを説明的に命名し、関数がその名前が示すことを行うことを確認してください。予期しない方法で動作する「賢い」ソリューションを避けてください。
- アドバンスド: ユーザージャーニー全体を考慮してください。各インタラクションは以前のものを基盤とし、一貫したメンタルモデルを構築すべきです。驚き、たとえ嬉しいものであっても、ユーザーのコントロール感を壊す可能性があります。
起源
最小驚きの原則は、1980年代のヒューマンコンピュータインタラクションの分野から生まれました。IBMの「Common User Access」標準とAppleのHuman Interface Guidelinesの両方が、インターフェースはユーザーの期待と一致する方法で振る舞うべきであると強調しました。 この原則は、予期しない振る舞いがユーザーのフラストレーションの主要な原因であることを観察したデザイナーと開発者の仕事を通じて、より広く認識されるようになりました。ユーザーが最終的に驚きを回避する方法を学んだとしても、認知コストは高かったのです。各驚きは、処理して記憶するために余分な精神的努力を必要としました。 ソフトウェアエンジニアリングでは、この原則はUI設計を超えて採用されました。API設計の指針となりました。「驚くべき」振る舞いは、個々のユーザーだけでなく、依存するソフトウェアのエコシステム全体を壊す可能性があるからです。今日、POLAは一貫性、予測可能性、単純さといった概念と並んで、基本的な設計原則の一つと考えられています。要点
応用場面
ユーザーインターフェースデザイン
ボタンはボタンのように見え、ボタンのように振る舞うべきです。「送信」フォームをクリックすると、ドラフトを保存するのではなく送信されるべきです。
API設計
メソッド名は、その行うことを明確に示すべきです。「updateUser」メソッドは、メールを送信したり通知をトリガーしたりするのではなく、ユーザーデータを更新すべきです。
コード構成
ファイルとフォルダは、開発者の期待に一致する方法で整理されるべきです。設定ファイルはビジネスロジックと混在させるのではなく、configディレクトリに属します。
エラーハンドリング
エラーメッセージは、何が悪かったのか、そしてそれをどのように修正するかを明確に説明すべきです。汎用的な「エラーが発生しました」というメッセージはユーザーを驚かせ、前進の道を提供しません。
事例
2012年、人気のある写真共有プラットフォームがPOLAに違反する変更を行いました。「削除」ボタンの振る舞いを変更し、写真を即座に完全に削除するのではなく、30日後に自動削除される「ゴミ箱」フォルダに移動するようにしたのです。 ユーザーは驚愕しました。多くの人々はストレージスペースを解放するために「削除」を使用しており、写真が消えることを期待していました。彼らはゴミ箱フォルダを確認せず、写真が再表示されたりストレージが減らなかったりして混乱しました。反発は大きく、ユーザーはシステムが信頼を裏切ったと感じました。 会社は最終的にプレミアムユーザーに対して振る舞いを元に戻しましたが、無料アカウントではそのままにしました（ストレージコストを節約するため）。しかし、ユーザー信頼への損害は持続しました。この事例は、善意の変更でさえ、確立されたユーザーの期待と衝突するときPOLAに違反しうることを示しています。 教訓。振る舞いを変更する前に、ユーザーが何を期待するかを考慮してください。変更が必要な場合は、それを明確に伝え、オプトアウトのメカニズムを提供してください。驚きは、技術的に正当化されていても、摩擦を生み出します。境界と失敗モード
POLAは文字通り取りすぎると、イノベーションの障害になる可能性があります。時々「正しい」ソリューションは直感に反します。例えば、テキストエディタの「元に戻す」機能は初期のユーザーを驚かせましたが、今では期待されています。 鍵は、貧弱な設計による驚きと、イノベーションによる驚きを区別することです。イノベーションには、ユーザーに新しいパターンを教えることが必要です。解決策はイノベーションを避けることではなく、明確なコミュニケーションとともに徐々に導入することです。 もう一つの失敗モードは、一貫性を犠牲にして既存のパターンに過度に適合することです。ある文脈で機能するインターフェースをコピーしても、特定のユースケースに合わない場合、ユーザーは局所的には驚かないが、全体的には混乱する可能性があります。 境界条件。POLAは設計をガイドすべきですが、麻痺させるべきではありません。イノベーションが驚くべき振る舞いを必要とするとき、教育に投資し、明確なフィードバックを提供してください。よくある誤解
誤解: POLAはイノベーションを意味しない
誤解: POLAはイノベーションを意味しない
POLAは新しいアイデアを禁止していません。新しい振る舞いが思慮深く導入されることを求めているのです。ユーザーは、明確に伝えられれば新しいパターンを学べます。
誤解: POLAはUIにのみ適用される
誤解: POLAはUIにのみ適用される
この原則は、ユーザーを持つあらゆるシステムに適用されます。APIを使用する開発者、システムを管理する管理者、コードの読者さえも含まれます。
誤解: ユーザーは常に自分が欲しいものを知っている
誤解: ユーザーは常に自分が欲しいものを知っている
ユーザーは一つのことが欲しいと言うことがありますが、それを得たときに驚くことがあります。POLAは、機能リクエストを収集するだけでなく、メンタルモデルを理解することです。
関連コンセプト
最小驚きの原則は、他の重要な設計および開発原則とつながっています。KISSの原則
単純に保て。単純で予測可能なシステムは理解しやすく、ユーザーを驚かせる可能性が低いです。
一貫性
一貫したインターフェースは確立されたパターンに従います。POLAは本質的にユーザーの期待との一貫性についてです。
メンタルモデル
ユーザーはシステムがどのように動作するかについてのメンタルモデルを持っています。POLAは、それらのモデルと戦うのではなく、一致するように設計することです。