リクエストではなくユーザーのニーズに焦点を合わせることが重要なのはなぜですか？
この質問はデジタル製品の設計を念頭に置いて書かれていますが、デジタルだけに合わせたものではありません。
問題に対する「最良の」ソリューションを設計するためには、ユーザーの要求、問題、および要望に反応するのではなく、それらに焦点を当てる必要があることは、かなり受け入れられています。
したがって、理想的には、「アプリにXを実行してほしい」に反応するのではなく、代わりにwhyユーザーがアプリにxを実行することを望んでおり、それを解決するより良い方法があるかどうかを確認する必要があります。根本的な問題。
私はしっかりとした推論を探しています。理想的には、よく書かれた記事と、おそらくそのような意見をサポートするための関連する例でバックアップされています。
上記が当てはまる場合、それをどのように証明しますか？
ユーザーは必要なものを求めるのが苦手で、必要なものを求めるのが得意です。
私自身の最近の経験からの事例証拠：
一部のデータについてPDFレポートを生成するボタンを要求する部門がありました。数か月後、彼らはスプレッドシートの形式でレポートを要求しました。その後数か月さらに列を追加するように求めましたが、最近では、このレポートに表示する完全な階層を要求しました。
最初は、リクエストは合理的で、開発チームが追いつくのは簡単でした。しかし、最終的には、レポートが扱いにくくなり、小さな変更があるたびに修正に数日を要しました。また、使用しなければならないクエリは非常に複雑で、スプレッドシートとして合理的にレンダリングして作成する方法がありませんでした。センス。
彼らはレポートをまったく必要とせず、必要に応じてクエリを調整できるカスタマイズ可能なWebページを必要としないことがわかりました。他のすべての部門が求めていたものであり、私たちができると思ったのはそれだけなので、彼らは報告を求めました。
ユーザーはボックスの中に何が入っているかを尋ねるだけですが、UXはより良い方法があるかどうかを確認するためにボックスの外を見る必要がある場合があります。
オンラインとオフラインの2つの例を以下に示します。
1.列車の到着
- 定期的に電車を待つことに不満を抱いている地下鉄の乗客線路上でより多くの電車を求める。世界の大都市圏の交通機関にとって、これは明らかに非常に費用のかかる要求です。
- 乗客の分析ニーズは、待機中のuncertaintyが待機時間と同じくらい重要であることを示しています。不確実性は、乗客がスケジュールへの影響や、待機中にできること（コーヒーを飲む、新聞を買うなど）を予測するのが難しいことを意味します。
ニーズの分析は、別のソリューションを提案します。これは、より多くの列車の代わりにはなりませんが、不安な乗客を落ち着かせるのに大きく役立ちます。待ち時間の不確実性を排除するために、到着を訓練するカウントダウンを乗客に提示します。
![enter image description here]()
この記事 は、結果がどれほど重要であるかを文書化し、乗客が情報がない場合、待ち時間を過大評価する傾向があることも指摘しています。カウントダウンサイネージは現在、世界中のトランジットステーションに設置されています。
2.製品選択の表示
- 多くの選択肢はより良いショッピング体験につながると信じているため、消費者はショッピングの際により多くの選択肢を求めます。
- 選択肢が多すぎると、消費者にとって圧倒的な決定につながり、ショッピングカートの放棄や購入の遅延につながる可能性があることは、十分に文書化されています。 選択のパラドックス と 魔法の数7 を参照してください。ただし、この効果については多くの研究が利用可能です。
- 結果として、より多くの選択肢を求める消費者の欲求にもかかわらず、スマートコマースサイトは実際にconstrain顧客に提示される選択肢の数ニーズは選択肢が少ないことを認識しているためそれ以上ではありません。
たとえば、Amazonは製品グリッドとページネーションを使用して、顧客に圧倒的な選択肢を感じさせないようにしています。これは、Amazonの製品結果ページで、画面ごとに6（マジックナンバー7に近い）の選択肢が表示されています。ブラウザのサイズをどれだけ大きくしても、表示される列の数は3です。
![enter image description here]()
Amazonは製品の結果にさまざまなレイアウトを使用しますが、デフォルトのレイアウトは、顧客の圧倒を避けるために、画面上の選択肢を意図的に減らすことがよくあります。
シンプソンズのエピソード「オー・ブラザー、どこでアート・トゥ」を見たなら、ホーマーの異兄弟が彼に「平均的なシュマックのための」車の設計を自由に統治させたときに何が起こったかを思い出すべきです。 最終結果 は高価であり、ばかげているように見え、必要なすべての機能を備えていても、ユーザーのニーズを完全には満たしていませんでした。
もし会社が本当に平均的なジョーのために車を作りたいと思ったら、彼らは複数のユーザーからの提案を取り入れ、典型的なユーザーが彼らから得る利益とそれらを実装するコストを比較検討したでしょう。ユーザーがやりたいことを盲目的に行うと、最終的にはホーマーになります。
フォードの創設者からの古いものから始めましょう：
（ 実際にはフォードが言った証拠は実際にはありません 。免責事項についてユーザーEvil Closet Monkeyに感謝。
UXデザイナービュー
なぜ彼らが欲しているのか何を望んでいるのかを知ることが重要なのですか？：
単にUXデザイナーとして最高のソリューションを設計する必要があるため、これを行うにはすべてのUX変数を評価する必要があります（アフォーダンス、使いやすさ、スキャン可能性、主題に関する研究など）およびそれらの間のバランスほとんどの場合、ユーザーはこれを行うことができませんユーザーが何を望んでいるのかわからず、多くの場合必要なものも知らないためです
それからあなたの仕事はそれらに尋ね、それらをテストするので、あなたが考える1つ以上の解決策を提案できるようにそれらの変数に関する十分な情報を得ることができますベスト。
ユーザー/クライアントが何かを要求するとき、それはそれらの変数を知るためのプロセスへの入り口にすぎません。
From Jakob Nielsen：First Rule of Usability？ユーザーの声を聞かないでください 記事：
しかし最終的に、ユーザーデータを取得する方法は、使いやすさの基本的なルールに要約されます。
- 人々が実際に何をしているのか見てください。
- 人々が言うことを信じないでください。
- 人々が彼らが将来するかもしれないと予測することを確かに信じないでください。
ユーザーの要求を額面価格に集中させることが問題になる2つの問題があります。
最初はとして知られています
Einstellung Effect
これは、最適なソリューションを見つける際のパターン追跡の悪影響です。
Einstellungは、機械化された精神状態の発達です。 Einstellungは、しばしば問題解決セットと呼ばれ、問題を解決するための「より良い」またはより適切な方法が存在する場合でも、特定の方法で特定の問題を解決する個人の傾向を指します。 Einstellung効果は、新しい問題を解決する際の以前の経験の悪影響です。
ユーザーが問題の解決策を要求した場合、それは特定のユースケースに最適な解決策ではなく、経験した既存の解決策に似ている可能性があります。
同様の問題は、ユーザーが問題に遭遇し、（定義により）問題領域の専門家ではない場合に、次善の解決策/ kluge /回避策を考え出し、実際の問題を定義する代わりにこのklugeを要求するときに発生する可能性があります。
これは一般に XY問題 として知られています。
X-Y問題は、時々呼ばれるように、助けを求める人々の側と助けを提供する側の両方の両方で、膨大な時間とエネルギーの浪費につながる精神的なブロックです。多くの場合、次のようになります。
- ユーザーがXを実行したい。
- ユーザーはXの実行方法を知りませんが、Yを実行するだけで問題を解決できる場合は、解決策を見つけることができると考えています。
- ユーザーはYの方法も知りません。
- ユーザーがYのサポートを求めています。
- Yを使ってユーザーを助けようとする人もいますが、Yは解決したい奇妙な問題のように思えて混乱しています。
- 多くの相互作用と時間の浪費の後、ユーザーが本当にXの助けを望んでいることが明らかになり、YはXのための適切なソリューションでさえなかったことが明らかになりました。
問題は、人々が1つのアプローチに行き詰まり、一歩後退できなくなったときに発生します。これらの人々は、全体像を新たに見直すことにオープンなままであり、Xに戻る道を見つけ、別の解決策を探し続けるかもしれません。
この Meta Stackexchange質問 は、XY問題についても説明しています。
Einstellung効果またはXY問題のいずれかから生じる次善のソリューションを生成しないようにする方法は、根本的な問題を取り除くか、prima facieリクエストの背後にある原因を引き起こします。
私の逸話：私たちはコンピューター化されたマシンの新しいバージョンを作り上げていました。 1つの要件は、30秒で起動することでした。何桁も失敗しました。それは大きな抗議を引き起こしました。理由を尋ねると、前回のバージョンでは頻繁にクラッシュし、かなり頻繁に再起動する必要があったため、最終バージョンでは制作時間が大幅に短縮されたとのことでした。新しいバージョンははるかに安定していたため、ダウンタイムがなくなりました。
エンジニアとして、新しくオープンしたオフィスタワーブロックの例が与えられました。エレベーターが3基付いていました。入居者が建物を埋めると、会社員がリフトを待つのに時間がかかりすぎるという苦情が届きました。リフトのキューイングアルゴリズムを修正するために、高価なコンサルタントに手掛かりを与えます。苦情の減少なし。追加のリフトを構築するキュー評価。全く取引しません。長すぎる待機に関する苦情が続いています。結局のところ、ある男が数百もの問題を解決することを提案しています。シニカルだが、パントを取る準備ができていたので、彼らは彼に挑戦した。彼はロビーの3つの側面に全身鏡を取り付けます。苦情はゼロになります。ポイント？ -他のユーザーは、ユーザーの要求に応じて、「オフィスワーカーをより早くデスクに連れて行こう」と試みていました。この男は問題を解決していました-人々が自分のデスクに早く到着しないことについて不平を言うのを止める方法。フィッティングミラーを使用すると、女の子は鏡で自分を眺めながらロビーに立ち、男性はロビーに立って女の子を眺めることができます。だれも数分長く立つ必要があると文句を言った人はいません。これは、あなたが尋ねていた質問のいとこですが、実際の問題を解決する例であり、ユーザーが解決したいと言っている問題ではありません。
ユーザー要求は通常、ユーザーが問題の解決策であると認識していることに基づいて形成されます。問題は、彼らの解決策が最良の解決策ではないかもしれず、実際、それは彼らの問題をまったく解決しないかもしれないということです。 StackExchangeに関する多くの質問は、解決しようとしている実際の問題（「XY問題」と呼ばれます）に対するより良い解決策を求めるのではなく、部分的な解決策を修正する方法を求めています。ユーザーはこれを行います常時。これは専門家にも適用されます。
基本的な例は次のとおりです。
- ユーザーが提案する解決策は、実際に彼らが抱えている問題を解決するものではありません。これは厄介なことです。通常は、ユーザーが実際に「必要な」ものを使用しているかどうかを監視することでそれを見つけることができますが、場合によっては強制することもあります。
- 問題全体をカバーするより簡単な解決策があります。ドメインの知識をミックスに取り入れることができます-おそらくユーザーが知らないことを知っています。おそらくユーザーは自分のソリューションが最も安いと考えていますが、実際には、基礎となるシステムについて何かを理解しているので、より安いソリューションを見つけることができます。これも非常に一般的です。
- ユーザーは、実際に問題だと思っていることを解決する必要はありません。問題のpartを解決することで解決できます。膨大なリソースで問題全体を解決するのではなく、問題の一部を安価に解決することで、顧客をより幸せにすることができる場合がかなりあります。ロボットでの作業をすべて積み上げるのではなく、なぜ人間はまだ作業を続けているのでしょうか。ある時点で、解決策を積み重ね続けることは経済的に意味がありません。
これらすべての結果は、あなたがしている必要のない仕事をしているということです、もちろんそれはあなたが顧客のリソースを浪費していることを意味します（それはお金、時間、または両方です）。
有名なHenry Ford（mis-）の引用は基本的に2番の変形です。人々が実際に抱えていた問題は、より早く場所に行く必要があるということでした。彼らが考え出した解決策は「ただより速い馬を作る」ことでした。これは長い間有効でした。心に留めておいてください。私たちは長い間、さまざまな特性を持つ馬を選択的に飼育してきたため、愚かではありません。ベンツやフォードのような人々がより良い解決策を示すことができた理由は、彼らがいくつかの点を追加したからです：
- より速く、より強い馬を作ることはますます難しくなっています。これは、それ以上を取得するのが非常に高価になるという制限に達したことを意味します。
- かつてないほど簡単に鉄鋼や石炭を購入することができます。それらは人工馬を作るために使用することができ、それはより安くそしてより速くなるでしょう。
- 馬はひどく複雑です。私たちが持つことができる最も単純なものは、原動力を直接車軸に加えるワゴンです。ホイールはきちんと整っていることがわかっているので、動かしてみましょう。ああ、そして私たちは列車について知っています！彼らは基本的に同じことをします。小さい電車を作ろう！
- Railsがなくても電車を使えるようになり、人々が買うのに十分安い（2番目の部分はFordを有名にした）ことができれば、人々は馬の代わりにそれらのミニトレインを購入することになり、誰もが満足するでしょう（ただしもちろん馬のブリーダー。ああ、それに私たちには石油もあります-石油エンジンは石炭エンジンよりもはるかに実用的です！
しかし、この間ずっと、目的は何であれ、旅行をより簡単、安く、より速く、より快適にすることでした。ユーザーが実際に何を要求したとしても、そもそもそれがユーザーの望みです。
実行notユーザーは愚かだと思います。そうではありません。ほとんどの場合、ミックスに追加の知識を取り入れることができます。また、重要なこととして、キャッシュされた考えを無視することもできます（「常にこの方法で行われている」）。ピープルキャッシュたくさん。
私はソフトウェアデザイナーであり、常にこの問題に遭遇しています。
多くの非技術者の問題は、抽象化されないことです。彼らは本当に後退して機能要件を明確にすることはできません。彼らの認識は、私がこのボタンを必要とする問題を抱えているということです。彼らが問題を説明するように求められたとき、彼らはどちらかできないか、またはしません。設計能力が最も低い人々は、設計の役割に自分自身を挿入しています。
ボタンと出力は設計上の決定事項です。非常に特定の出力を生成するには非常に費用がかかります。ソフトウェア設計者が機能要件を持っている場合、より低いコストでニーズに対応できることがよくあります。これは特に、大量のデータと多数の同時ユーザーに当てはまります。
ニーズとリクエストの非常に現実的な例を挙げましょう。
最近、BUGレポートで、エクスポートにはスペースを含むわかりやすい長い名前を使用する必要があると報告されました。私は3回返信しましたが、それはSQL XMLで行われ、長い名前は使用できず、バグではありません。これは設計どおりです。そのXMLを解析するユーティリティがあります。そこで彼らはエスカレーションすることを決めました。私は彼らが40分で100,000行のエクスポートを取得していることを指摘しました-1行目の名前は表示名でなければならないので本当にそれを捨てる必要がありますか？マーケティングは言ったが、ユーザーは名前が何を意味するのか知りません。私は彼らに言ったが、ユーザーはそれらのエクスポート名を制御している-彼らは20文字以下でなければならず、スペースがなく、文字で始まる必要がある。ユーザーが行っていることは、以前の構成を取り、次のプロジェクトの表示名を編集して、古いエクスポート名を残すことです。マーケティングは堅調でしたが、輸出名は編集していません。ユーザーがエクスポート名を編集したくないので、40分で実際に100,000行のエクスポートを実行し、エクスポートを完全に再設計する必要があります。これは、1か月を超える作業です。マーケティングはしっかりしていて、XMLで表示名を使用できない場合は、XMLをよく知っている人を見つける必要があるかもしれません。これがXMLの仕組みです-制限があります。以前は表示名に制限がありましたが、3年前、ユーザーは制限を望まないので削除してくださいと言っていました。妥協案として、制限付きの個別のエクスポート名がありました。ユーザーがエクスポート名を編集したくないので、これは本当にすべてですか？
もう1つのハードリクエストは、Xページに移動することでした。ユーザーは、Xページで検索を実行し、翌日に来て、中断したところから再開したいと考えていました。ただし、同じページXではありません。他に100人のユーザーがデータを編集していて、その検索では同じ結果が返されません。私は彼らにXに行かせるとマーケティングに言った、彼らは同じページXを取得しないとそれは壊れていると思うだろう。さらに悪いことに、誰かがドキュメントをレビューするタスクを持っているだろう。 30ページで、そのドキュメントはレビューされません。結果を静的リストに保存する機能があります-それは彼らが使用する必要があるものです。ユーザーは結果を保存するために追加の手順を実行することを望んでおらず、ページXが代替であるという誤った認識を持っていました。マーケティングは彼らが求めたことを言った。ユーザーがページXを理解していなかったためにリリースされるべきではなかったドキュメントがリリースされ、顧客は弾道論に出ました。彼らが望んでいるものと彼らが必要としているものは必ずしも同じではありません。
この古典的なソフトウェアエンジニアリングイメージは、追加する価値があると思います。これは、顧客の問題だけではありません。どこにいても混乱が生じます。
さらに、それを理解することは、実際にはUXジョブでさえありません。
私の経験では、まともなプロジェクトマネージャーは、混乱を解消し、顧客が理解しようとしている言語で顧客が達成しようとしていることを正確に話すことができるため、節約された時間から多大な価値を得ることができます。
私の逸話：たぶん25年前、私は地方自治体の公共料金請求グループの契約作業をしていた。既存のパッケージは良好でしたが、顧客アカウントへの最初の問い合わせでは、多くの顧客の質問にすばやく回答するために必要な画面が多すぎました。
私は数年にわたってほとんどすべてのトラブルシューティングを行い、定期的に個々のアカウントのある種の概要が必要だったので、すぐに最初のメインの問い合わせ画面の個人用バージョンを作成しました。私が変更したのは、一連の多分「0」/「1」の値を、行の下部近くの空の部分に配置することだけでした。
これらの視覚的な「スイッチ」は、「所有者」または「居住者」のアカウントを表示しているかどうか、「ビジネス」か「住宅」かどうか...などをすばやく教えてくれました。それに慣れるのにほとんど時間がかかりませんでした。ユーザーの多くの質問に対して、複数の画面を何度もクリックすることを避けるため。
しかし、ある日、アプリケーションのユーザーが私のデスクにいて、彼女が抱えている問題を調査しているところを見ていました。その画面が私がしているシーケンスで現れたとき、彼女はすぐにそれらの小さな「指標」に飛びつきました。
「待って！あれは、何ですか？」
さて、誰が知っていましたか？今日、それはおそらく「ダッシュボード」のようなものになるでしょう。しかし、当時は、そのグループのユーザーが知られるようにならないと生活することができなかったのは些細なことでした。
TL; DR-私が自分で実際にそのアプリを操作して物事を理解しようとした経験がないとは知りませんでした。すべてのインジケーターはすでにUIで表現されています。それらに移動するために複数のユーザーアクションを実行しただけです。実際にすでに提示されている情報を求める人は誰もいませんでした。
ここでの多くの回答はユーザー/顧客のリクエストの問題を説明しているので、ユーザーが本当に必要なものを見つける必要があるのでなぜ繰り返すべきではないと思います。ヒントhowを与えたいだけです：
ユーザーが本当に必要とするものはrequirementsと呼ばれます。
そして、ユーザーは前述の理由で要件を伝えることができないため、これらの要件が何であるかを見つけることは、すべてのエンジニアの仕事です（またはそうでなければなりません）。開発/設計プロセスのその部分はrequirements engineと呼ばれます。
そのトピックの詳細については、 SWEBOK（by IEEE） か、要件エンジニアリングに関する他の本またはWikiの記事を参照してください。
私のお気に入りの本は 要件-エンジニアリングと管理-（クリス・ルップによる） -これはドイツ語でのみ入手可能です（または少なくとも英語版は見つかりませんでした）。
ユーザーのニーズに応えるソリューションを作成するのがあなたの仕事であり、あなたが彼らよりもよく知っていることが期待されているという理由だけで、そうでなければ彼らはあなたの仕事を得るでしょう。
最初に、彼らのリクエストを聞くことは良いことだと言っておくべきだと思います。ユーザーは完全な馬鹿者ではないため、自分の問題を十分に認識しており、何年にもわたって毎日直面している状況を確認する必要があり、それがどんなに悪くても、その解決策を完全に見つけることができます。したがって、彼らが彼らに必要なものを尋ねると、彼らは彼らが解決策を望んでいることを伝え、彼らが解決策であると考えるものを提示し始め、それを作るようにあなたに伝えます。そして正直なところ、私は時々それをやったことがあります。それは彼らが完全なバカではないからです。彼らはあなたよりも自分の仕事をよく理解しているので、彼らの命題は徹底的に分析されるべきです。彼らが提案する解決策は非常に関連性があり、私は時々彼らの本当のニーズを見た後で自分自身を見つけることができなかった。最も重要なことは、彼らが経験するさまざまな思考プロセスのために、彼らのソリューションは彼らがそうでなければ表現しない彼らのニーズについての追加の事柄を明らかにすることができます。
しかし、あなたは彼らがしていないことを知っています。うまくいけば。彼らの知識は、彼らが経験したもの、彼らが遭遇した構造、アーキテクチャ、ソフトウェアによって形作られ、彼らがソリューションを考えるとき、彼らは彼らが見た作品を彼らが働くと思うものに組み立てます。しかし、彼らはデザイナーではありません。あなたはそれらよりも多くの部品を知っており、それらをはるかに効率的に組み立てて、彼らが考えることすらできないことをすることができます。多くのさまざまな経験を持つ人々は、あなたと同じくらいこれが得意で、間違いなく聞く価値がありますが、他の人は悪い、非効率的な、限られた解決策を作る傾向があります。
すると、ユーザーが全体像を見ることはめったにありません。彼らは主に自分のデスクの仕事に焦点を当てており、彼らはマシンの単なる歯車であることを完全に認識しているが、通常は隣の歯車以外は見ない。彼らのビジョンは限られているので、彼らのソリューションもそうです。彼らが望むのはあなたが彼らの仕事を改善することだけだからです。彼らは自分の仕事が好きで、変化が好きではないからです。そして彼らはその仕事を続けたいと思っています。彼らは自分の仕事を時代遅れにする何かを提案することはほとんどありません。彼らの一部はあなたを潜在的な敵とみなし、彼らに合うようなことをするようにあなたを操ろうとします、そしてあなたはこれらの変な人々に耳を傾けない方がいいでしょう。したがって、彼らの要求はプロセス全体にとって非常に有害であり、逆効果になる可能性があります。
最後に、ユーザーは主に物事の機能面について考えます。実際、ユーザーがそれ以外のことについて考えているのを見たことがありません。彼らは、技術的な考慮事項や、要求の背後にある時間とお金の制約を理解していません。それは、彼らが決して直面したことのない側面だからです。
それらが私よりあなたがあなたの仕事よりもあなたの仕事が上手である主な理由ですが、私たちは確かにもっと見つけることができましたが、私はあなたが要点を見ていると思います。リクエストを聞くことは確かに便利ですが、あなたは単に彼らよりも優れたデザイナーです。結局のところ、製品設計は誰にでも手の届くところにあります。それは、いくつかが他のものより優れているということだけです。
できるだけ簡潔に：
ほとんどのリクエストは便宜上行われるため、すべてのユーザーが必要なものを正確に知っているわけではありません。
お客様：Xでレポートを印刷します。次に、Mikeがこのデータをアップロードできるように、Webフォームが必要です。
アナリスト：同じデータですか？ MikeのグループにXデータの画面を表示するだけでいいですか？
お客様：できますか？本当に！それは多くの仕事を節約するでしょう
Analyst：そして、すべてのデータ検証、エラー、非一貫性、遅延を含む新しいレポートとフォームをコーディングするのに役立ちます。
お客様：それは安く、速く、より良いということですか？すごい！
リクエストではなくユーザーのニーズに焦点を合わせることが重要なのはなぜですか？これが私たちが直面した例です。
製品チームは開発チームに来て、データを収集するために作成する調査フォームを要求しました。
開発チームは、製品チームが将来の調査を行うことを計画しているかどうかを具体的に尋ねました。彼らはノーと言った。
開発チームは、動的な調査ツールを作成することを決定しました（念のため）。
その後すぐに製品チームは別の調査を依頼し、次に別の調査を依頼しました。彼らは現在、12の追加調査を求めています。
開発チームは、最初に動的調査ツールを構築した結果、新しい調査リクエストごとに10分を費やしています。
開発チームが製品を聞いていた場合の問題を想像してみてください。
非常に多くの場合、ユーザーは実際のコストと関連する経済性に気づかずに、可能であると信じるものを要求します。同じ人々に、最先端の人工知能に課税するようなことを求め、さまざまな順序でソートされた出力を生成することが可能であることに驚かされました。
どれくらいの頻度で何かが必要になるかという問題は、正しく答えられることが重要です。一般性と再利用のために設計することが賢明ですが、それはコストを課します。何度か私は間違っていて（Digを十分に深く掘り下げていなかった）、文字通り一度だけ実行する必要がある、非常に高度に設計された（したがって高価で遅延した）製品を提供しました。私の悪い。
XY問題を参照した Digital Chrisの回答 について詳しく説明します。それは実際にはさらに言語の問題にまで及びます。
ユーザーと開発者は異なる視点から来ています。彼らは当然、必要なものを説明するためにさまざまな言語を開発しています。理想的な世界では、誰もが欲望とニーズを定量化するために客観的な用語を使用しますが、現実的にはそれは難しいです。これはソフトウェアでは特に難しく、開発者はしばしば根本的に異なる言語を話します。
したがって、誰もが自分のニーズを共通の言語に投影しようとします。そうすることで、彼らは彼らが要求から望んだものの味の多くを失います。
このフレーバーのないリクエストは、開発者と顧客の間の接続を確立するのに非常に役立ちます。ただし、そこから、実際に何をすべきかを説明する一般的な方法を見つけるために、外側に拡張する必要があります。これは多くの場合、ユーザーが何かを求めている「理由」を見つけるという形をしています。