ユーザーが実際に実装する必要があるよりも詳細な情報を求めるのは普通ですか？
初めてのアプリケーションを世界にリリースし、フィードバックを求めました。ユーザーが多くの詳細を求めているので、私はフィードバックに驚きました。彼らは、ボタン、ノブ、スライダーで満たされたユーザーインターフェイスを望んでいるようです。ユーザビリティについて私が読んだすべては、これがまさに避けるべきことであると私に伝えていますが、それはユーザーが求めているものです。
だから私は、ユーザーが求めているものをユーザーに提供する必要があるのか、それともユーザーが本当に必要以上の詳細を要求するのが一般的であるのかを理解しようとしています。
合計で多数の提案があるかもしれませんが、ほとんどのユニークな提案は少数のユーザーからのものであることがわかります。これは、アプリケーションが一般にリリースされた後の典型的なものです。ユーザーは、コア機能を超えて複数の異なる用途にアプリケーションを使い始めるため、コアを超えてあらゆる方向に拡張するために、より多くの機能と柔軟性が必要になります。これは、追加機能の90％が10％のユーザーによって使用されているケースであり、機能ごとに異なる10％です。最終的には、グループとしてのユーザーがより多くの詳細を求めているように見えます。実際には、各ユーザーはもう1つ詳細を要求するだけです。
悲しい点は、ユーザーが一般的に不要な機能のユーザビリティコストを理解できないことです。 10人のユーザーを集めて改善について話し合い、1人だけがXを調整するコントロールを必要としている場合、他の9人はもう1つのコントロールが害を及ぼすことはないと考えているため、反対しません。これにより、ユーザーは機能が多すぎて使用できないデバイスを購入するようになります。彼らが目にするのは、彼らが望む主要な機能のパッケージの箇条書きだけです。彼らは他のすべての弾丸をサポートすることから生じる害を理解していません。
物事のあり方に満足している静かな少数派（または多数派？）に注意してください。 「何も変えないでください。それは私を混乱させるだけです。」少数のユーザーが意図したニッチなユーザーから製品を引きずり出すことに注意してください。たぶん、一部のユーザーは、他の誰かからのより適切な製品を使用した方がよいでしょう。
最後に、ユーザーが言ったことが何をするかについてのユーザーの声に注意してください（「ああ、ええ、私は常にジリチウム比を微調整します私にできることであれば"）。これらは、時が来たときに実際に行うこととは弱い関係にあります。伝える唯一の方法は、機能をデプロイする前にそのプロトタイプをテストすることです。このようなテストには、コア機能のユーザー回帰テストも含まれ、新機能がそれらを妨害しているかどうかを評価する必要があります。一部のユーザーが本当に詳細を使用しても、それだけの価値はないかもしれません。
結論：少なくとも提案された形で、ほとんどのユーザー提案を拒否することを期待する必要があります。
ただし、これはフィードバックを無視する必要があるという意味でもありません。あなたの場合：
ユニークな提案を求めているユーザーの数でランク付けします。トップランクの提案は実装の最有力候補ですが、応答するユーザーの過半数が機能を必要とする場合、allユーザーはその機能を望んでいます。
ユーザーが各機能を必要とする理由を調べます。ユーザーに質問できる場合は、質問してください。それ以外の場合は、持っている他のデータ（ヒットログなど）から抽出してみてください。追加の調査を行う必要があるかもしれません。おそらく、ユーザーの目標をすでにサポートしていますが、ユーザーはそれを認識しておらず、解決策は発見可能性や文書化の方が優れています。多分、彼らはXを調整する柔軟性を望んでいないが、実際にはXを別の値に固定する必要がある。たぶん、複雑さを増やさずに目的を達成する別の方法を見つけることができます。
目標を理解し、上位の機能を1つの単純な機能に組み合わせることができるかどうかを確認します。特定の詳細が相互に関連している可能性があるため、それらを1つのコントロールに組み合わせることができます。機能をより高いレベルに抽象化できる場合があります（32の異なる設定の代わりに、32の異なる方法で組み合わせることができる設定は5つだけです）。多分あなたは設定を自動化することができます。
製品のUIの他の要素や製品の全体的なビジョンと一致するように機能UIを設計します。ユーザーは素晴らしいアイデアを持っているかもしれませんが、それは慣例が非常に異なる別の製品での経験からのものです。 UIに組み込むことはできません。
追加する真の機能（ある場合）を決定したら、段階的開示の方法を検討して、機能Xを必要としないユーザーの90％が、機能Xを必要とする10％によって中断されないようにします。たとえば、ユーザーがオンデマンドでダッシュボードに表示するコントロールを選択できるようにすることができます。
Simple Simplicity で、複雑さを伴わずに機能を拡張する方法について詳しく説明します。
これは、ユーザーから引き出すのが最も簡単な種類のフィードバックです-色の選択や追加機能の詳細。
「意図」の部分が重要だと思います。ユーザーがアプリケーションを使用して解決しようとしている問題。したがって、フィードバックを提供したユーザーに連絡する方法がある場合、またはユーザーのランダムな選択だけでも、この質問への回答が適切であることがわかります： ユーザーが必要とするものであり、必要なものではない
実際、ごくわずかなフィードバックしか受け取らないのはまったく正常なことです。したがって、ユーザーからの意見を聞くのは良いことです。
これらのリクエストを整理し、フィルタリングして、優先順位を付けてください。アプリケーションのユーザビリティを危険にさらすために何もしたくありません。単にノーと言わなければならない要求もありますが、実装する価値のある他の要求があるかもしれません。これらの要求の背後にある意図を見つけるようにしてください。多くの場合、誰かが解決しようとしている問題を述べ、解決策を提案します。問題が有効であっても、彼らの解決策は最良のものではないかもしれません。したがって、最もエレガントなソリューションを見つけるのはあなたの仕事です。
また、 servoice または GetSatisfaction のようなサイトにサインアップすることも検討します。その後、ユーザーは機能のリクエストに投票でき、多かれ少なかれあなたのためにあなたの仕事を優先します。
フィードバックする人々は、変化を望む自己選択グループであることを覚えておいてください。元のインターフェースに完全に満足している別の大きなグループがいる可能性があり、追加のコントロールをたくさん追加し始めると不幸になる場合があります。
これが事実であるかどうかを知る唯一の方法は、適切なユーザー調査を整理することです。
ユーザーがフィードバックをするとき、彼らは問題があると言っています。彼らが何を必要としているのかを発見するのはあなたの仕事です。それを発見するには、「なぜ」の質問を何度も尋ねる必要があります。なぜそのボタンが欲しいのですか？なぜそれが重要なのですか？なぜこれをやろうとしているのですか？
多くの質問をした後、新しいデザインをテストして、インターフェースの変化が遅いことを確認し（インターフェースの変更は常に消化するのが難しい）、これらの変更が本当に役立つことを確認する必要があります。