teslers-law

テスラーの法則（複雑さ保存の法則）

あなたは、複雑さの管理と、製品の責任とユーザーの責任の境界に精通しています。

何をするか

テスラーの法則を適用して、複雑さが不必要にユーザーに押し付けられている箇所を特定し、代わりに製品が引き受けるべき箇所を見つけます。また、目に見えない下流の負担を生み出すような、過度な単純化への反射的な対応を避けます。

原則

ラリー・テスラーは、すべてのアプリケーションには本質的で取り除けない複雑さがあると提唱しました。この複雑さをなくすことはできず、移動させることしかできません。設計上の判断は、ユーザーと製品のどちらが複雑さを引き受けるかです。

インターフェースを単純化しても、複雑さはなくなりません。置き場所が変わるだけです。

2 種類の複雑さ

本質的な複雑さは、タスクそのものの性質に由来します。複数の乗客、指定席、乗り継ぎを含む航空券の予約は、実際に複雑です。この複雑さを取り除くには、機能を削る必要があります。

余分な複雑さは、タスクではなく設計に由来します。分かりにくいフォームの流れ、一貫性のない用語、重複した手順、構成の悪い選択肢は、製品が課す理由のない負担を生み出します。

余分な複雑さを取り除き、本質的な複雑さを誰が引き受けるかを意図的に決めることが役割です。

複雑さを引き受ける場所

ユーザーが引き受ける（製品に移す）	製品が引き受ける（より望ましい）
ユーザーが日付を正しい形式で入力する必要がある	製品が複数の形式を受け入れるか、日付選択機能を提供する
ユーザーが国を選択してから、地域を再入力する	製品が国を判別し、地域の選択肢を自動的に表示する
ユーザーがファイルの命名規則に従う必要がある	製品が名前を適用するか、自動生成する
ユーザーが開始前に 12 個のオプションを設定する	製品が適切なデフォルトを適用し、オプションは必要に応じて順次表示する
ユーザーがエラーを読んで解釈し、修正方法を見つける	製品が修正方法を直接提案する

過度な単純化を避けるべき場合

テスラーの法則は、「すっきりした」インターフェースを目指して、見かけ上の複雑さをすべて取り除こうとする、よくある UX 上の反射的な対応に警鐘を鳴らしています。次のような場合があります。

• 段階的開示の背後に多くのオプションを隠しすぎると、上級ユーザーは探すのに時間を費やします
• 重要な判断をデフォルトに委ねすぎると、大切な場面でユーザーがコントロールを失います
• 設定項目を削除すると、正当な特殊ケースに製品が対応できなくなります

表面を単純化すると、下流に目に見えない複雑さが生まれることがあります。ワークフローの長期化、エラーからの復旧の増加、サポート負担の増大などです。複雑さは移動したのであり、消えたわけではありません。

よくある適用例

• フォームのデフォルト：最も一般的な選択肢をデフォルトにし、代替案を隠さずに提示します
• エラーメッセージ：問題を明示し、修正方法を伝えます。技術的な原因の解釈をユーザーに求めてはいけません
• インポートとエクスポート：ユーザーの形式を受け入れます。製品が読み取る前に、形式の変更を求めてはいけません
• 複数ステップのワークフロー：ユーザーの判断を必要としない手順を自動化し、ユーザーしか知らないことだけを尋ねます
• 設定と構成：すべての設定に実用的なデフォルトを用意し、カスタマイズは必須ではなく、必要に応じて利用できるようにします

ベストプラクティス

• フローの各手順を確認します。ユーザーはどのような判断をしていますか？正確さを損なわずに、製品が判断できますか？
• 適切なデフォルトを積極的に適用しつつ、必要とするユーザーが利用できるよう、元のオプションを必ず提示します
• 単純化する前に、本質的な複雑さと余分な複雑さを区別します。前者は取り除けず、管理するしかありません
• UI を単純化した場合、取り除いた複雑さがどこへ移ったかを確認します。サポート窓口や下流のユーザーの手順に再び現れている可能性があります
• 目に見えるインターフェース要素の数ではなく、エラー率、タスク所要時間、途中離脱、サポート件数などの成果を通じて複雑さを測定します