デザインを単純化しすぎると、エンジニアは不幸になり、混乱する
私がテスラーの法則を初めて知ったのは、自分のデザインが 「シンプルすぎる 」という理由でリジェクトされた時でした。
デザイナーとして、この言葉は奇妙に聞こえます。私たちはしばしば、「シンプルで、直感的で、使いやすい」デザインを目指します。しかし、デザインを単純化しすぎるだけでなく、そうすることでユーザーエクスペリエンスを損ねたり、他の人に複雑さを押し付けることにもなりかねません。
デザインを単純化しすぎると、ユーザー・エクスペリエンスが損なわれることが多い
テスラーの法則を説明するために、税金のような複雑なテーマを考えてみましょう。もし税務ソフトが、あなたの名前、社会保障番号、従業員ID番号の入力を求めたとしましょう。
税務ソフトは数分かけて、「納税はすべて終わりました、還付金はこちらです。申告して終了しますか？」と言います。
手作業で詳細を確認したい、あるいはソフトウェアが何をしたのか見てみたい、と躊躇する人も少なからずいるかもしれません。これは、私たちがこのプロセスに一定レベルの複雑さを連想しているからです。
デザインを単純化することで、バックエンド開発者を悲しませるだけでなく（そのようなシステムを構築する方法を考え出す）、ユーザーはそれをそれほど便利だとは思わないでしょう。
税金の場合、ユーザーは以下のことを再確認するかもしれません：
税金控除の対象となるものがカウントされているか。
正しいW-2書類が提供されているか
最大限の還付を受けているか
など。
この場合、単純化しすぎるよりも、既存のユーザーのワークフローを改善したほうがよいでしょう。
この問題は、機器設定ページが却下されたときに直面したものです。ユーザーはトグルを使っていくつかのオプションをオン・オフするためにここに来るのですが、ほとんどのユーザーは1つか2つのトグルを選択するためにここに来るのです。
私はそれらをデフォルトでオンにすることで、「シンプルにしようとしすぎ」たのです。理論的には、これでユーザーは設定ステップを省略できるので、かなりの時間を節約できたはずです。現実には、この行為はエンジニアリングに複雑さを押し付けることになります（つまり、テスラーの複雑さ保存の法則）。
システムには常に生得的な複雑さが存在する
システムの複雑さの総和は一定です。ユーザーとシステムとのインタラクションをより単純にすると、舞台裏の複雑さは増大します。 -Lawrence Tesler
もし特定のデフォルトが有効になっていたら、データ収集アーキテクチャを完全に変更する必要があったでしょう。セットアッププロセスでこれがいつオンになったかは言うまでもないのです（スムーズなデータ転送を保証するためにネットワークpingのようなテストを行いたいかどうかも）。
しかし、テスラーの法則は極めて複雑なデザインには当てはまらないのです。数え切れないほどのデザインが「単純化」を優先し、しばしばユーザー（とエンジニアリング・チーム）を犠牲にしてきました。例えば、QRコードは長い間、最大の違反者の1つでした。
ウェブサイトアドレスなどの間違いを避ける簡単な方法のつもりが、当初は頭痛の種となりました。ユーザーは専用のQRコード・アプリケーションをインストールし、あまりぼやけていない写真を撮り、システムがそれを認識できることを願う必要がありました。
しかし、QRコードははるかに一般的になり、ユーザーがQRコードを利用するのはずっと簡単になりました。何が起こったのか？複雑さが軽減されたのではなく、ユーザーの代わりにシステムが複雑さを引き受けたのです。最近の携帯電話にはカメラにQRコードリーダーが内蔵されているので、ユーザーはカメラをオンにする必要があります。
これは、単純化に関してデザイナーが取るべきアプローチです。テスラーの「保存と複雑性の法則」を適切に扱うには、通常、3つのポイントを覚えておくことが不可欠です：
- 明らかな複雑さを減らす
- コスト／価値分析を通じて、さらに単純化することの価値を評価する
- ユーザーではなく、システムが残りの複雑さを背負うようにする
明らかな複雑さを減らす
うまくいけば、このことをある程度認識できるはずです。それでも、明らかな複雑さとは、ユーザーがタスクを完了するのに役立たない（あるいは阻害する）追加機能に基づいています。
例えば、ユーザーがアカウントにサインアップし、パスワード付きのプロモーションメールを受け取り、ログインし、購入をクリックしなければ商品を購入できないとします。この場合、これらの追加のステップは、必要のない複雑さの追加です。
このステップに従うには、ユーザーが特定のページで達成しようとするタスクについて考え、どのような要素がプロセスの助けにならないかを調べます。すべての追加ステップが悪いわけではないことを覚えておいてください：2ファクタ認証は、ユーザーに追加ステップを要求しますが、多くの場合、ユーザーにとって必要であり、全体として役に立ちます。
これらの要素を減らしてみて、ユーザー（またはチームメンバー）がこれらの機能を削除することに不満を持つかどうかを見てみましょう。もしそうであれば、次のステップを検討してください。
複雑さを減らすための追加的な努力がそれに値するかどうかを評価する
時には、複雑さを軽減するために開発者が多くの労力を必要とする方法がありますが、それはユーザーにとって価値があるものです。
このような場合、デザイン者は類似のものを使ってユーザーの価値（とコスト）を検討する必要があります: 重要度の評価
これを行うには、次のものを掛け合わせます（週単位の価値の例で）
- ユーザが問題の複雑さに遭遇する1週間あたりの平均頻度
- 週間アクティブユーザー数（WAU）、ほとんどのアナリティクスツールに存在する指標
- 価値/コストst：複雑さの変化からユーザーが受けるインパクト（または複雑さによって発生するコスト）を表す。
この例では、計算が合わないのです。私の変更によってユーザーは5分短縮され、週間アクティブユーザーは1,000人いましたが、ユーザーはほとんどこのページに来ませんでした（2ヶ月に1回くらいは来ていたかもしれません）。その結果、このオプションを進める意味はありませんでした。代わりに、別のデザインオプションであるプリフィルドフィールドを使い、ユーザーが何かをトグルする時間を節約しました。
目的に応じて、システムまたはユーザーに残りの複雑さを合わせる
最後に、これ以上複雑さを減らすことができないときは、残った複雑さを誰に担ってもらいたいかを考えることになります。
多くの場合、特に初心者のユーザーには、システムにこの複雑さを引き受けてもらいたいのです。そうすることで、システムはバックグラウンドですべての重労働をこなし、ユーザーにはスムーズでシンプルな体験のように感じられます。
しかし、常にそうであるとは限りません。時には、より複雑なタスクに取り組めるようなツールのカスタマイズやパーソナライズをユーザーに提供するために、幅広い選択肢を示したいこともあるでしょう。
例えば、ユーザー全員がタッチスクリーンで絵を描くような単純なドローイング・アプリケーションはたくさんあります。しかし、PhotoshopやIllustratorのような、より複雑なアプリケーションもあります。
これがテスラーの法則を利用する方法です。
ほとんどのデザインには複雑さが内在している
一時期、誰もが 「Googleのようなシンプルさ」を求めていました。空白のページに検索バーが1つあるだけで、複雑さが1つのフィールドに集約されます。
しかし、ほとんどのウェブサイトはそれを実現することができないのです。プロダクトの一部として、ユーザーがそうすることを妨げる何らかの生来の複雑さが常に要求されるのです。
実際、グーグルも複雑さを追加しています。
つまり、答えは常に、さらにシンプルにしようとすることではないのです。
明らかな複雑さを減らし、複雑さをさらに減らすことの価値を確認し、残った複雑さをシステムが引き受けるのか、ユーザーが引き受けるのかを決めるという3つのステップを踏むことで、ターゲットとするユーザーに合ったシステムをデザインすることができるのです。
