ユーザーが本当に望んでいることをどうやって見つけ出すのでしょうか？[閉まっている]

Question

どこかで読んだことがあります (出典は忘れました、ごめんなさい - MS Office 開発者のブログだったと思います)。ソフトウェアや Web サイトにどのような機能が欲しいかについてユーザーにアンケートを行うと、あらゆる些細な機能が欲しいと言う人は少なくありませんが、収集された指標によると、最終的にはほとんどの人がこれらの機能の 99% を使用していないことがわかります。このブログ投稿の一般的なメッセージは、人に何を使用しているかを尋ねるべきではなく、自分で追跡する必要があるということでした。

これにより、次にどのような新機能を追加するかを検討する際に、卵が先か鶏が先かという不幸な状況が生じます。この機能がすでに導入されていないと、実際にどの程度使用されているかを測定できません。リソースが限られている (そして大幅に制限されている) ため、すべての機能を追加してから未使用の機能を削除する余裕もありません。

ユーザーにとって役立つものをどうやって見つけますか? アンケートが唯一の選択肢である場合、特定の方法で質問を構成する必要がありますか (例:可能性のある機能のリストは表示しないでください。それが先導してしまうからです)?

Answer 1

一般的な信念に反して、あなたは彼らに尋ねないでください 。まあ、彼らは彼らがあなたが望むものをあなたに伝えるときに彼らの言うことを聞きません。彼らは彼らが今持っているものを使用しながらそれらを見る。もし彼らが何も持っていないなら、あなたは彼らにプロトタイプを与えるのに十分に耳を傾け、それから彼らがそれを使うのを見ます。人がソフトウェアを実際に使用する方法は、彼らが実際に望んでいると言うものよりもはるかに多くを伝えます。彼らが本当に必要なものを見つけるために彼らが何をするか見てください。

Answer 2

オプションを提供し、重要度順に並べてもらいます。あなたが言ったように、ユーザーはすべてのものを望んでいますが、これはあなたが最も欲しいものを伝えることができます。

Answer 3

彼らに伝えます。それからあなたの両方が知っています。

（いいえ、ユーザーは自分が何をしたいのか教えてくれません。それは仕事です。ユーザーがもっと仕事をしたいなら、彼らのために仕事をするソフトウェアを探しません。）

Answer 4

前世の逸話：

新しいリリースを計画しており、アプリケーションにいくつかの新しい機能を追加したいと考えていました。ユーザーを集めて、システムで見たいものをブレーンストーミングし、各「機能」を配置しました。ホワイトボード上の黄色の付箋に。次に、同様のリクエストをグループ化し、重複またはほぼ重複を排除しました。

次に、各粘着性のあるものをテーブルの前にカップを置いて置きました。各ユーザーは「投票」するために10ペニーを獲得しました。彼らが望んだ機能について。彼らは、必要に応じて各カップに多くのペニーを入れることができます。次に、各カップのペニーの数を数え、投票順で上位5つの投票ゲッターを実装することを選択しました。

ブレーンストーミングと分類中に機能に情熱を傾ける人々が好転し、その機能に投票しない（または軽く投票する）のを見たのは驚きでした。

もちろん、このような手法は、ユーザーベースにすぐにアクセスできる場合にのみ機能します（これは、社内で開発したエンタープライズシステム用です）。

Answer 5

尋ねます。

（いいえ、ユーザーが何を望んでいるかわからない。はい、たくさんの愚かな答えを得るでしょう。多肢選択式の調査を避け、代わりに自由形式の回答を検討することを選択します。収集する情報は貴重です。）

もちろん＆＃8212;ユーザーが最も気に入っている機能に投票することをいつでも許可できます...

Answer 6

ユーザーは、望んでいることを知るよりも、望んでいないことをよく知っています。

Oracle eBusiness Suiteの実装を行うチームを持ち込みました。彼らは、過去に非常にうまくいった興味深いアプローチを取りました。しかし、それは私たちの環境では驚異的でした。

私たちは文化的な問題を抱えていたため、ユーザーの誰もが自分の望んでいることを言うために首を突き出そうとしませんでした。私は過去のユーザーとの歴史がありました。それらから要件を取得しようとすると、石から血を取得しようとするようなものでした。しかし、ライブに移行すると、ビッチが始まります。

とにかく、実装チームはすぐにOracle eBusiness Suiteをインストールしました。ユーザーに基本的なトレーニングを提供します。その後、約4週間ごとに6か月間、苦情に対応するために基本インストールをカスタマイズしました。

Answer 7

オプションを表示しないことをお勧めします。あなたが指摘するように、それが利用可能であれば、人々はそれを持っているためだけにそれを欲しがるでしょう。多くの場合、ユーザーは特定の機能を開発するための追加コストを認識しておらず、それを使用する可能性について言及したため、単にそれを必要とします。

他のオプションは、追加できる可能性のあるすべての機能のリストを表示し、各機能に価格を付けてからユーザーに尋ねます。機能Yの支払いを希望しますか？

Answer 8

自分のドッグフードを食べる

可能な限り自分で作成したアプリケーションを使用してみてください。その後、アプリケーションを改善する方法がわかります。

Answer 9

37 Signals-Getting Real の本によると、あなたは何もしない、あなたはしない彼らが望むものを記録しても、何もアクションなしで読んだ後にメールを削除するだけです。

ものを実装/修正することになると、ユーザーが頭から望んでいる最も重要なことを思い出すでしょう。明らかに、これには少しのユーザーベースが必要です。

Answer 10

機能をコストに関連付ける必要があります。誰もが機能を望んでいますが、すべての機能にお金を払う価値があるわけではありません。最も重要な機能はどれかを尋ねます。ユーザーはどちらに支払いを希望しますか？ユーザーが提供する優先順位に基づいて機能を開発し、ユーザーがそれ以上支払いを希望しない場合は停止します。製品をできるだけ早く手に入れて、機能しないものと追加する必要のあるものについて本当のフィードバックを得ることができます。ユーザーが実際のソフトウェアにアクセスできる場合、より良い情報を取得できます。これは、特定の顧客向けに特別に開発している場合に最適です。実際の顧客にアクセスできない場合は、より良いフィードバックを得るために、無料でユーザーに製品をシードすることを検討してください（パブリックベータと言うことができますか？）。

Answer 11

ユーザーは、どの機能が必要なのかわかりません。どの機能が提供されるかわかりません。 ＆quot;機能＆quot;タスクの達成と目標の達成を支援する以外は何も意味しません。そして、それらがどのように関連するかを非常に不完全に理解しているので、そこから始めるべきです。

彼らが知っていることは、あなたよりもはるかに良いことです。そして、それが彼らの仕事を成し遂げる方法です。

コンピューター/ソフトウェアの概念と用語がユーザーとデザイナーの間の議論に漏れ始めるとすぐに、あなたは軌道に乗り始めます。

非常に多くの場合、ユーザーは現在使用しているソフトウェアの何が問題であるか、または改善される可能性があるという点で要件に集中します。時間が経つにつれて、彼らも仕事と仕事をするために使用するソフトウェアの区別を失います。

これを解決するのは非常に難しい、非常に重要な問題です。

Answer 12

ユーザーが「本当に」何を知っている唯一の方法必要なのは「ある」ことです。ユーザー。 プログラミングカンフーブラックベルトレベル。

＆quot;亀裂を通り抜ける水のようになります。断定的ではなく、オブジェクトに適応してください。そうすれば、ラウンドまたはスルーの方法を見つけることができます。あなたの中に硬直したものが何もないなら、外側のものはそれ自身を明らかにするでしょう。 あなたの心を空にし、形を失います。形のない、水のような。カップに水を入れると、カップになります。ボトルに水を入れると、それがボトルになります。ティーポットに入れると、ティーポットになります。今、水が流れるか、それがクラッシュすることができます。友達に水をやる。＆quot;

水/顧客になれば、今すぐになります。

ブルース・リーは優れたプログラマーになると思います。

非常に深刻です。これが私が働く方法です。理解できないことはできないので、物事を行う前に理解する必要があります。私が理解し、私のコスモターが私が理解していることを知っているとき、私は良い仕事をすることができます。理解しなければ、誤解が生じるでしょう。あなたは正しいレベルの理解が得られたときに知っている唯一の人であり、あなたはその知識を得る責任があります。

Answer 13

1. Delphi at Oracle

   長所：精度は素晴らしい 短所：メッセージを解釈できる場合、多くの人はこれを実行できません（多くの場合、見たいものを見ている）。また、厄介になることがある嘆願を必要とします（一般的な意見に反して、あなたのhecatombは同じ種類の家畜の100である必要はありません）。

2. サイキック

   長所：正確なポイント。

   短所：まれ。精神的に不安定になりやすく、不気味な生物に対して非常に脆弱であり、それらから不必要な注意を引く可能性があります。また、人間の心であるミステリーを整理して、必要な情報に到達するには経験が必要です。また、ユーザーが嘘をつくので、彼らが実際に助けが必要なことをしている間、あなたはまだ被験者を調査する必要がある。

3. ほくろを植える

   長所：新しいガジェット。新しい毒！計画内の計画内の計画。赤ちゃんは変なショーです。ユーザーを支援するために必要な情報に加えて、あらゆる種類の魅力的なことを学ぶかもしれません。

   短所：高価。エージェントがあなたをオンにするか、もっと簡単に学ぶことができなかったものを学ぶことに失敗する可能性が残っています。発見された場合、組織は資産を転換または清算する可能性が高く、これはリソースの膨大な投資を意味します。組織が往復する場合があります。

4. 推測

   長所：平均から優れた想像力と問題解決スキルを持つ人々のグループを連れて行き、ゴーストバスターズ、リトルチャイナのビッグトラブル、またはビッグリューボウスキーからの引用で彼らに酒を飲ませ、彼らに刺激を与えます。誰がそれがどこに行くかを知っていますが、それは楽しく、彼らは何か面白い/有用なものを生み出すかもしれません。

   短所：ユーザーのニーズを満たす可能性はあなたが思っているよりも高いですが、それほど良くありません。

5. ユーザーに質問

   長所：ユーザーはプロセスの一部として権限を与えられていると感じます。

   cons：彼らが何かを決めなければならないまで、その時点であなたは自分でいる。ユーザーが非常に経験豊富なユーザーである場合を除き、その場合、ユーザーはおそらく何が欲しいかをよく知っています。しかし、この惑星には4人の経験豊富なユーザーしかいません。彼らのために仕事をする人は誰も知りません。神話上の獣かもしれません。

6. 気にしているように見せてユーザーに質問し（実際にはそうではない場合でも）、ユーザーが関与する重要なワークフロー/プロセス/などを実行していることに注目し、ユーザーの行動に注意を払います。

   長所：ユーザーをだまして自分の意見が重要だと考えるようにします。 ユーザーが嘘をついている-意図的または悪意を持っていない-実際にそれらを見ることができます実際に問題を把握し、ソリューションを構築するためのより良い基盤を提供します。また、あなたはサイキックのルートを避け、したがって、約束から始まり、あなたとサイキックがこの世のものではない怪物のような言いようのないものに食われる長い曲がりくねった道を避けます。プロセスを観察することは完全にZenに似ており、これは開発者の神秘性に適しています。

   短所：Oracleへのロードトリップはありません（EPICになります）。スパイはもっとセクシーです。ひよこはスパイを掘る。ゴーストバスターズ|リトルチャイナのビッグトラブル|ビッグルーボスキーはおそらく関与していない。他のオプションよりも仕事のように感じます。

Answer 14

機能についてユーザーに尋ねると、機能について話をするように求められます。

ユーザーが本当に望んでいるものを見つけたい場合、 ユーザーの目標と動機を理解することについて話します。これを行う最も簡単な方法は、機能ではなく、ユーザーが製品やそのような製品をどのように使用するのか、なぜ使用するのか、どのように自分の生活に合うのかについてのユーザーインタビューです。

ユーザーが製品で何をしようとしているか、なぜそれをしたいのかを理解したら、ユーザーが要求した機能が本当に必要なものであるかどうかについて十分な情報に基づいた判断を下すことができます。

理想的には、あなたの問題は単にリクエストを聞くのではなく、ユーザーを理解することだと思います。

Answer 15

これはすでに多くの良い答えがある古い質問ですが、私がやったように検索で将来ここにたどり着く人々のために、少し個人的な経験を追加したいと思いました。

プロジェクトが成功するために可能な限り迅速にオーディエンスを獲得する必要がない場合（webappなど）、それがより多くの内部プロジェクトまたは固定クライアントまたはクライアントのタイプ向けに販売される製品の場合、あなたの最善の策は、37signalsの道を行くことだと思います。最初に最も基本的な作業サイクルの最も基本的なタスクを達成するために必要な絶対最小をユーザーに提供し、その後、彼らの言うことを聞きます仕事を適切に行うために客観的に欠席しています。彼らが望むものや欲しいものではなく、本当に必要なもの。そして、本当に必要なものを確実に知る唯一の方法は、持っていないときです。

私は、イントラネットベースの「会社の中心」の開発チームでデザイナーとして働いていました。その戦略に従ったアプリで、結果は素晴らしいものでした。最初の週：みんな腹を立てました。それが終わったとき、承認の90％+、そしてアプリはまだシンプルで美しいものでした。そして、完全に満足していない人のほとんどは、なぜそれが望んでいることができなかったのかを理解しているようで、ほとんどすべての人の主な要求は、私たちがやったことは何でも、アプリをシンプルに保つことでした。

繰り返しますが、最初に人々を引き付ける必要がある製品またはWebサイトで作業している場合、それは実現不可能であるか、物事を大幅に遅らせる可能性があります。ただし、ユーザーベースをある程度制御または余裕がある場合は、このアプローチをお勧めします。

Answer 16

機能を要求しません。あなたは問題を求めます。痛みポイント。彼らが現在のソリューションについて嫌いなものを見つけてください。何が彼らの時間に食い込んでいるかを調べる。

それらが好きではないことがわかったら、それらの問題の解決策を構築します。

実際の問題を解決すると、人々が喜んでお金をくれる本当の製品を作成していることになります。

しかし、重要なことは、研究段階でそれらを尊重することです。調査はまだ調査を行うのに優れていますが、多数の質問をすると、彼らはあなたを嫌います。あなたは彼らの時間を尊重し、調査ツールを使用する必要があります。調査ツールは、彼らを引き付け、素晴らしい印象を残します。

Answer 17

ユーザーは自分が何を望んでいるのか分かっていないのは証明された事実です。彼らに尋ねる必要があるのは、現在のものの何が問題なのか、つまりソフトウェアにどのような問題があるのか​​、ということです。なぜ x 機能と y コントロールを使用しないのですか?なぜインタラクション x は彼らにとって効果があったのに、インタラクション y は彼らに目を測ろうとさせたのでしょうか?

もちろん、これらの質問をできるようにするには、現地調査を行って、どのような機能が使用されているか、ユーザーが示すパターンを確認し、そのデータを分析する必要があります。この分析により、ユーザーが断固として正確に答えることができる、より具体的な質問の基礎が得られます。

Answer 18

真面目な人は、彼らを仕事でビデオテープに録画し、彼らが達成しようとしていることと、あなたの製品がどのように彼らを助けることができるかを分析します。これは、ユーザビリティエンジニアリングと呼ばれる分野全体の一部です。テクニックの優れた紹介は、Jakob Nielsenの本 Usability Engineering です。恥知らずなハックスターになる前に、ヤコブは非常に優れた科学者であり、ユーザーが必要とするものを理解する安価な方法について多くのことを学びました。予算が限られている場合は特に便利です。最も感銘を受けたのは、紙のプロトタイプを使用したことです。これは、まだビルドしていないソフトウェアをモックアップするのに最適な方法であり、次にビルドするものについての質問に答えるのに役立ちます。この手法が実際に動作するのを見るまで、この手法がどれほど効果的であるか信じられませんでした。

PS単に質問した場合の動作の一例：Microsoft Office 2007の機能要求の90％は、Microsoft Office 2003に既に存在する機能に対するものでした。その場合、ユーザーが必要とするのはより良い検索方法でしたすでにそこにあったもの。私はこれについて読んだ場所を見つけることができればいいのに...申し訳ありませんが、リファレンスがありません。

Answer 19

特定のクライアント向けに注文するものを構築するのではなく、販売する製品を構築しているという文言に基づいて想定しています。

そのコンテキストでは、まず自分自身でユーザーになり、必要な機能を必要な方法で構築することから始める必要があると思います。製品を進化させると、他のユーザーからのフィードバックが必要になりますが、少なくともこれで開始でき、鶏卵のサイクルを断ち切ることができます。

機能の実際の使用状況を測定する場合、ディスカッションフォーラムを設定して、追加した機能に関するフィードバックを得ることができます。

Answer 20

個人的には、顧客からのハンドオフアプローチが好きです。高度な要件を提供し、実装を提供します。あなたのソフトウェアチーム/会社/部門は専門家であることになっています。恐ろしいことであるが、顧客がパイプしてそれを修正すれば間違いを犯すだろうが、一般的にあなたとあなたの開発者に実装を任せることは解決するのが楽しいジレンマである。

研究、研究、研究。他のデザインから学び、独自のキックデザインを作成します。簡単ではありませんが、開発者に大金を無料で支払っていません。

Answer 21

これはいい質問です。

FPSゲームを構築している場合、ユーザーの99％が「あなたのゲームにXがあればいいのに」と言うことは決してないので、何を含めるべきかを自分で知る必要があります。経験豊富なベータテストチームがここでお手伝いします。

会計アプリケーションを作成している場合、業界とユーザーが製品を使用するときに達成しようとしていることを理解し、それらの目標に合わせて機能セットを集中する必要があります。

1つのビジネスで100人のユーザー向けにカスタムアプリを作成している場合は、ソフトウェアの多数の熱心なユーザーとチャットできます。彼らは、すべてのフォームを完全に知っており、文書化されていないすべてのショートカットキーを発見し、データ検証ルールの多くを回避する方法も見つけました。

Answer 22

あなたが彼らだと想像してください

Answer 23

ユースケース。

その機能を使用して何をしますか？

このように動作します。

• 人々は行動を起こします。私たちは、彼らが行動を起こすのを助けるソフトウェアを構築します

• 行動を起こすには、人が決断を下さなければなりません。意思決定を支援するソフトウェアを構築しています。

• アクションを実行する決定を下すには、情報が必要です。情報を収集して提示するソフトウェアを構築します。

すべての機能は、アクション、決定、または情報でなければなりません。そして、接続は直接的な方が良いでしょう。決定や行動につながらない情報は、「持っておくべき」ものではありません。 -ジャンクです。

ユーザーは多くのことを言います。彼らは何をします？彼らは何を決定しますか？どのような情報が必要ですか？

---

編集

すべての人がユースケースを説明できるわけではないことに注意してください。一部の人々はビジョンがなく、ビジネス（または個人）価値をどのように生み出しているかを理解せずに、彼らが今日何をするかを単に伝えます。彼らはどのような決定を下すべきかを本当に知らないかもしれず、必要な情報についてあいまいです。

他のユーザーは、作成する値とその理由を知っており、ユースケースについて十分に議論できます。彼らは価値を創造する別の方法を思い描くことができます。彼らは自分たちの行動の選択肢を明確にすることができます。決定には多くの代替実装がなく（ソフトウェアではなく決定を下します）、必要な情報もあまり変わりません。

Answer 24

1. 見てください。
2. 仕事のボトルネックを特定する
3. そのボトルネックをエレガントな方法で解決するものを作成する
4. 彼らに使ってもらいましょう
5. 全員が満足するまで繰り返します

Answer 25

原則に基づいて：

1. ユーザーは自分の欲しいものを知っていますが、 彼らが本当に必要なものを知らない。
2. あなたは それを正しくするつもりはない 初めて。

鶏と卵の問題のようです。 PageRankの計算によく似ています。ページのページランクは、そのページにリンクしている他のページのPageRankに依存します。 PageRankを計算する1つの方法は、反復です。

反復が重要です！

A。投票

1. すべてのユーザーが必要とする機能のbiiiigリストを収集します（必要な各機能を列挙させます）。

2. リストを確認し、機能に投票できるようにします。たとえば、機能で配布するためにem 100ポイントを与えます。機能に複数のポイントを与えることができます。

B。分析

ビジネスモデルを分析し、必要と思われる機能を一覧表示します。 これが必要な理由は：

• ユーザーが時々大きくならない 写真
• これは本当に素晴らしい ユーザーが考えることはないだろうという考え 百万年。

C。実装

AとBのリストを分析し、いくつかをマージ、削除、改善します。実装します。

D。テスト

ユーザーでテストします。彼らの苦情を聞いてください。見る   -彼らが頻繁に使用する機能   -立ち往生するもの   -などなど

E。反復

Answer 26

通常、ユーザーは自分が何を望んでいるのか、何が欲しいのかを常に知っているわけではありません。当社の営業担当者は、既存および潜在的な顧客に商品を見せ、彼らがそれを必死に望んでいる理由を説明します。

大学時代、「userp-driven development」と呼ばれるものを教えられました。ここでは、実際に顧客のところに行き、そこで働く人々の様子を観察し、彼らがどのツールを使用するかを観察し、何が彼らの生活を促進できるのかを探らなければなりません。次に、モックアップを作成し、顧客に再度アクセスしてユーザーに提示し、フィードバックを取得してから、モックアップの改善に進みます。全員が多かれ少なかれ行動の方針に同意したら、実装を行い、できるだけ早く修正フィードバックを取得しようとしているものを顧客に定期的に表示します。

重要なのは、製品を望むマネージャーではなく、製品を使用するユーザーと話すことです。そうしないと、プレイ全体では何も得られません。

PS直接尋ねる＆quot;あなたは何が欲しい？危険な質問かもしれません... Babylon 5-何が欲しいですか？

Answer 27

「Market Research」と呼ばれます。

いいえ、これは男を掘り下げたものではありませんでした。確かに、ユーザーの要件を取得するためにUCDの人々がフィールドで使用する多くのテクニックがありますが、それらは市場調査者が使用するツールとまったく同じです。カードの並べ替え、優先リストなどはすべて市場調査の用語です。