私はどこかで読んだことがあります（ソースを忘れてしまいました、申し訳ありませんが、MS Office開発者のブログだと思いますか？）。多くの場合、彼らはすべての小さなことを望んでいるとは言いませんが、収集されたメトリックは、最終的に、ほとんどの人がこれらの機能の99％を使用しないことを示しています。ブログ投稿からの一般的なメッセージは、人々に何を使用しているかを尋ねるのではなく、自分で追跡する必要があるというものでした。
これは、次に追加する新機能を見つけようとするときに、不幸な鶏が先か卵が先かという状況につながります。この機能がすでに導入されていないと、実際にどれだけ使用されているかを測定できません。有限の（そしてひどく拡張された）リソースがあるので、すべての機能を追加してから未使用の機能を削除する余裕もありません。
ユーザーにとって何が役立つかをどのように見つけますか？調査が唯一の選択肢である場合、特定の方法で質問を構成する必要がありますか（たとえば、可能な機能のリストを表示しないでください。そうすると、質問が先導されるため）。
一般に信じられていることとは反対に、あなたは彼らに尋ねません。ええと、彼らが何を望んでいるかをあなたに言うとき、あなたは彼らの言うことを聞きません。彼らが今持っているものを使っている間、あなたは彼らを見ます。彼らが何も持っていない場合は、プロトタイプを提供するのに十分なほど彼らの話を聞いてから、彼らがそれを使用するのを見ます。人が実際にソフトウェアをどのように使用しているかは、彼らが実際に望んでいることよりも多くのことを教えてくれます。彼らの行動を観察して、彼らが本当に必要としているものを見つけてください。
選択肢を与え、重要な順に並べてもらいます。あなたが言ったように、ユーザーはすべてを欲しがりますが、これにより、ユーザーが最も欲しているものを伝えることができます。
あなたは彼らに言います。そしたら二人ともわかる。
(いいえ、ユーザーは自分が何を望んでいるのかを教えてくれません。それは仕事です。ユーザーがもっと仕事をしたいのなら、彼らは自分の仕事を代わりにやってくれるソフトウェアを探しているわけではありません。)
前世の逸話：
新しいリリースを計画しており、アプリケーションにいくつかの新機能を追加したいと考えていました。私たちはユーザーを集めて、彼らがシステムで見たいと思っていることについてブレインストーミングを行い、それぞれの「機能」をホワイト ボードの黄色の付箋に貼り付けました。次に、同様のリクエストをグループ化し、重複またはほぼ重複を排除しました。
次に、カップを前にしてテーブルにそれぞれの付箋を置きました。各ユーザーは、必要な機能に「投票」するために 10 ペニーを受け取りました。各カップに好きなだけペニーを入れることができ、必要に応じてすべてのペニーを1つのカップに入れることができました。次に、各カップのペニーの数を数え、上位 5 つの投票ゲッターを投票順に実装することを選択しました。
ブレーンストーミングや分類をしているときに機能に情熱を注いでいた人々が好転し、その機能に投票しない (または軽く投票する) のを見るのは驚くべきことでした。
もちろん、このような手法は、ユーザー ベースにすぐにアクセスできる場合にのみ機能します (これは、社内で開発したエンタープライズ システム用でした)。
あなたは彼らに尋ねます。
（いいえ、ユーザーが何を望んでいるのかわかりません。はい、多くの愚かな回答が得られます。多肢選択式の調査を避け、代わりに自由形式の回答を確認することを選択してください。収集した情報は非常に貴重です。 ）。
もちろん、ユーザーが最も気に入っている機能にいつでも投票できるようにすることができます...
ユーザーは、自分が何を望んでいるかよりも、何を望んでいないかをよく知っています。
私たちは、Oracle eBusiness Suite の実装を行うチームを招集しました。彼らは、過去に非常にうまくいった興味深いアプローチを取りました。しかし、私たちの環境では驚異的でした。
私たちは文化的な問題を抱えていました。つまり、ユーザーの誰もが自分の言いたいことを口に出して言いませんでした。過去からのユーザーとの歴史がありました。それらから要件を取得しようとすることは、石から血を取り出そうとするようなものでした. しかし、ライブに行くと、愚痴が始まります。
いずれにせよ、実装チームは、箱から出してすぐに Oracle eBusiness Suite をインストールしました。ユーザーに基本的なトレーニングを行います。その後、約 4 週間ごとに、次の 6 か月間、苦情に対応するためにベース インストールをカスタマイズしました。
オプションを表示しないことをお勧めします。あなたが指摘するように、それが利用可能であれば、人々はそれを持っているという理由だけでそれを欲しがるでしょう. 多くの場合、ユーザーは特定の機能の開発に余分なコストがかかることを認識しておらず、あなたがその可能性について述べたのでそれを望んでいます。
もう 1 つのオプションは、追加できる可能性のあるすべての機能のリストを表示し、それぞれに価格を付けて、ユーザーに、機能 Y を追加するのに X ドルの価値があるか、またはどれだけ追加するかを尋ねることです。機能 Y に支払いますか?
できるだけ自分で作成したアプリケーションを使用するようにしてください。その後、アプリケーションを改善する方法がわかります。
37 Signals - Getting Real book によると、あなたは何もせず、彼らが望むものを記録することさえせず、何の行動も起こさずに一度読んだらメールを削除するだけです。
実装/修正に関しては、ユーザーが頭の上から望んでいる最も重要なことを思い出すでしょう。明らかに、これには少しのユーザーベースが必要です。
機能をコストに結び付ける必要があります。誰もが機能を望んでいますが、すべての機能にお金を払う価値があるわけではありません。最も重要な機能はどれか、ユーザーが喜んで支払う機能はどれかを尋ねます。ユーザーが提供する優先順位に基づいて機能を開発し、それ以上支払う気がなくなったら停止します。何が機能しないのか、何を追加する必要があるのかについて実際のフィードバックを得ることができるように、製品をできるだけ早く彼らの手に渡してください。ユーザーが実際のソフトウェアにアクセスできると、はるかに優れた情報が得られます。これは、特定の顧客向けに特別に開発している場合に最適です。実際の顧客にアクセスできない場合は、より良いフィードバックを得るために、製品に人々を無料でシードすることを検討してください (パブリック ベータと言えますか?)。
機能は求めません。あなたは問題を求めます。痛みのポイント。現在のソリューションについて彼らが嫌っている点を見つけてください。自分の時間を無駄にするものを見つけてください。
何が気に入らないかがわかれば、それらの問題に対するソリューションを構築できます。
実際の問題を解決することは、人々が喜んでお金を払ってくれるような実際の製品を作成していることになります。
しかし、研究段階でそれらを尊重することも重要です。調査は依然として調査を行うのに最適ですが、1ダースの質問をすると、彼らはあなたを嫌うでしょう. 彼らの時間を尊重し、彼らの関心を引き、大きな印象を残す調査ツールを使用する必要があります。
ユーザーが「本当に」何を必要としているのかを知る唯一の方法は、ユーザーに「なる」ことです。そのプログラミング カンフー黒帯レベル。
「亀裂を通り抜ける水のようになりなさい。主張してはいけませんが、対象に順応してください。そうすれば、それを通り抜ける方法を見つけることができます。あなたの中に何も硬直していない場合、外にあるものは明らかになります。心を空にしてください。形のない. 形のない, 水のように. カップに水を入れるとカップになります. ボトルに水を入れるとボトルになります. ティーポットに入れるとティーポットになります. 今, 水は流れたり流れたりします.クラッシュする可能性があります。私の友人に水を与えてください。
あなたが水/顧客であるとき、あなたは今でしょう.
ブルース・リーは優れたプログラマーになると思います。
とても真剣です。これが私の働き方です。わからないことはできないので、理解してからやらないといけません。私が理解し、私の顧客が私が理解していることを知っているとき、私は良い仕事をすることができます. 理解がなければ誤解が生じます。あなたが正しいレベルの理解を持っていることを知っているのはあなただけであり、その知識を得る責任があるのもあなたです.
ユーザーは自分が欲しい機能を知りません。どのような機能が提供されるかわかりません。「機能」は、タスクを達成し、目標を達成するのに役立つ場合を除いて、何の意味もありません。彼らは自分たちがどのように関係しているかを完全には理解していないので、そこから始めるべきです。
彼らが知っていることが 1 つあります。おそらく、あなたよりもはるかに優れています。そして、それが彼らの仕事を成し遂げる方法です。
コンピュータ/ソフトウェアの概念と用語がユーザーと設計者の間の議論に漏れ始めるとすぐに、あなたは脱線します。
多くの場合、ユーザーは、現在使用しているソフトウェアの問題点や改善の余地がある点に焦点を当てます。時間が経つにつれて、彼らでさえ、自分の仕事と、仕事をするために使用するソフトウェアとの区別を失います。
これを解決することは非常に難しく、非常に重要な問題です。
これはすでに多くの良い答えがある古い質問ですが、私のように検索を通じて将来ここにたどり着く人々のために、個人的な経験を少し追加すると思いました.
あなたのプロジェクトが (ウェブアプリのように) 成功するためにできるだけ早く聴衆を獲得する必要がない場合、それが固定クライアントまたはクライアントのタイプ向けに販売される内部プロジェクトまたは製品である場合、私はあなたの最善を信じています賭けは 37 シグナルの道を行くことです:最初に最も基本的な作業サイクルの最も基本的なタスクを達成するために必要な絶対最小値をユーザーに与え、次にユーザーが目的を達成するために何が欠けているかを客観的に聞くことに耳を傾けます。正しく機能します。彼らが望んでいるものや欲しいものではなく、彼らが本当に必要としているもの. 本当に必要なものを確実に知る唯一の方法は、それを持っていないときです。
私はその戦略に沿ったイントラネットベースの「会社の心臓部」アプリの開発チームでデザイナーとして働きましたが、その成果は素晴らしいものでした。最初の週: 誰もが腹を立てていた. それが終わったとき、90% 以上の承認があり、アプリはまだシンプルで美しいものでした. そして、完全に満足していなかった人々のほとんどは、なぜ自分たちが望んでいたようにできないのかを理解していたようで、ほぼ全員の主な要望は、私たちが何をしたとしても、アプリをシンプルに保つことでした.
繰り返しになりますが、最初に人々を引き付ける必要がある製品やウェブサイトに取り組んでいる場合、それは実現不可能であるか、物事が大幅に遅れる可能性があります. ただし、ユーザーベースをある程度制御または余裕がある場合は、このアプローチを強くお勧めします.
機能についてユーザーに尋ねると、ユーザーは機能についてあなたに話すよう促されます。
ユーザーが本当に何を望んでいるのかを知りたい場合は、ユーザーの目標と動機を理解することについて話している. これを始める最も簡単な方法は、ユーザーインタビューです。機能についてではなく、ユーザーがあなたの製品をどのように使用しているか、製品を気に入っているか、なぜ使用しているか、どのように生活に適合しているかについてです。
ユーザーがあなたの製品で何をしようとしているのか、なぜそれをしたいのかを理解すると、人々が要求した機能が本当に必要なものであるかどうかについて、十分な情報に基づいた判断を下すことができます.
理想的には、あなたの問題は、ユーザーの要求を聞くだけではなく、ユーザーを理解することだと思います.
ユーザーが自分が何を望んでいるかを理解していないことは証明された事実です。彼らに尋ねる必要があるのは、現在あるものの何が問題なのか、つまり、彼らがあなたのソフトウェアでどのような問題を抱えているのかということです。なぜ彼らは x 機能と y コントロールを使用しないのですか? なぜインタラクション x が効果的だったのに、インタラクション y が彼らの目を測ろうとしたのか?
もちろん、これらの質問をするためには、フィールド スタディを行い、どのような機能が使用されているか、ユーザーがどのようなパターンを示しているかを確認し、そのデータを分析する必要があります。その分析により、ユーザーが決定的かつ正確に回答できる、より具体的な質問の基礎が得られます。
ユースケース。
彼らはその機能で何をしますか?
それはこのように動作します。
人は行動します。私たちは、彼らが行動を起こすのを助けるソフトウェアを構築します
行動を起こすためには、人は決断を下さなければなりません。私たちは、意思決定を支援するソフトウェアを構築します。
人が行動を起こすには情報が必要です。情報を収集して提示するためのソフトウェアを構築します。
すべての機能は、アクション、決定、または情報でなければなりません。そして、接続は直接的な方がよいでしょう。意思決定や行動につながらない情報は、「あると便利」でさえありません。それはジャンクです。
ユーザーは多くのことを言います。彼らは何をしますか？彼らはどのような決定を下しますか？彼らはどのような情報を必要としていますか?
編集
誰もがユースケースをうまく説明できるわけではないことに注意してください。一部の人々はビジョンを持たず、ビジネス (または個人) の価値をどのように生み出しているかを理解せずに、今日何をしているのかを単に説明します。彼らは、自分が下すべき決定を本当に理解していない可能性があり、必要な情報について漠然としています。
他のユーザーは、自分がどのような価値を生み出し、その理由を知っており、ユース ケースについてよく話し合うことができます。彼らは、価値を創造する別の方法を思い描くことができます。彼らは自分の行動の選択肢を明確にすることができます。意思決定には多くの代替実装がなく (ソフトウェアではなく人が意思決定を行います)、必要な情報もあまり変わりません。
あなたが彼らだと想像してください
本気なら、彼らの仕事をビデオに撮り、彼らが達成しようとしていることと、あなたの製品が彼らをどのように助けることができるかを分析します。これは、ユーザビリティ エンジニアリングと呼ばれる分野全体の一部です。テクニックの良い入門書は、Jakob Nielsen の著書Usability Engineeringです。恥知らずなハックスターになる前、Jakob は非常に優秀な科学者であり、ユーザーが何を必要としているのかを安価に把握する方法について多くのことを学びました。予算が限られている場合は特にお勧めです。私が最も感銘を受けたのは、紙のプロトタイプを使用したことです。これは、まだ作成していないソフトウェアをモックアップするのに最適な方法であり、次に何を作成するかについての質問に答えるのに役立ちます。このテクニックが実際に使われているのを見るまで、私はそれがどれほど効果的であるか信じられませんでした.
PS 人々に聞いただけでどうなるかの例: Microsoft Office 2007 に対する機能要求の 90% は、Microsoft Office 2003 に既に存在していた機能に対するものでした。これについて読んだ場所を見つけられたらいいのにと思います...参考にならなくてすみません。
あなたの言い回しに基づいて、あなたは販売する製品を作っているのであって、特定のクライアントのために注文するものを作っているのではないと思います。
その文脈では、まず自分がユーザーになって、必要な機能を自分の望む方法で構築することから始めるべきだと思います。製品を進化させるには、他のユーザーからのフィードバックが必要になりますが、少なくともこれで開始でき、鶏と卵のサイクルを断ち切ることができます。
機能の実際の使用状況を測定することに関しては、ディスカッション フォーラムを設定して、追加した機能に関するフィードバックを得ることができます...時間に縛られている場合は、それほど複雑なことは必要ありません。
私は個人的に、顧客からのハンズオフアプローチが好きです。それらは高レベルの要件を提供し、実装を提供します。あなたのソフトウェアチーム/会社/部門は専門家であるべきです。確かに間違いを犯すことはありますが、もしそれがひどい場合は、顧客がパイプを鳴らして修正しますが、一般的に、実装を自分と開発者に任せることは、解決するのが楽しいジレンマです。
リサーチ、リサーチ、リサーチ。他のデザインから学び、独自のキック デザインを作成します。簡単ではありませんが、開発者に大金を無料で支払うことはありません。
それは良い質問です。
FPS ゲームを構築している場合、何を含める必要があるかを自分自身で知る必要があります。ユーザーの 99% が、「あなたのゲームに X があればいいのに」と連絡することは決してないからです。ここでは、経験豊富なベータ テスト チームがお手伝いします。
会計アプリケーションを作成している場合は、業界を理解し、ユーザーが製品を使用して何を達成しようとしているのかを理解し、それらの目標に合わせて機能セットを集中させる必要があります。
1 つの企業で 100 人のユーザー向けのカスタム アプリを作成している場合、10 人ほどのソフトウェアの熱心なユーザーとチャットすることができます。彼らは、すべてのフォームを最初から最後まで知っており、文書化されていないショートカット キーをすべて発見し、多くのデータ検証ルールを回避する方法を見つけ出した人です。
通常、ユーザーは、自分が何を望んでいるのか、何かを望んでいるかどうかを常に把握しているわけではありません。私たちの会社では、営業担当者が既存の顧客や潜在的な顧客のところに行き、製品を見せて、なぜ彼らがそれを欲しがっているのかを説明します。
大学時代、私たちは「ユーザー主導の開発」と呼ばれるものを教えられました。ここでは、実際に顧客のところに行き、人々がどのように働いているか、どのようなツールを使用しているかを観察し、何が彼らの生活を楽にするかを見つけようとする必要があります。次に、モックアップを作成し、再び顧客のところに行き、それをユーザーに提示し、フィードバックを得てから、モックアップの改善に進みます。全員が多かれ少なかれ行動方針に同意したら、実装を行い、修正フィードバックをできるだけ早く得ようとしているものを定期的に顧客に示します。
重要なのは、製品を欲しがっている管理者ではなく、製品を使用するユーザーと話すことです。そうでなければ、プレー全体があなたに何ももたらさないでしょう。
PS「何が欲しいの？」と直接尋ねる 危険な質問かもしれません... バビロン 5 - 何が欲しいの?
原則に基づいて:
鶏が先か卵が先かの問題のようです。PageRank の計算によく似ています。ページのページ ランクは、そのページにリンクしている他のページの PageRank に依存します。PageRank を計算する 1 つの方法は、反復によるものです。
繰り返しがカギ！
A. 投票
すべてのユーザーが必要とする機能の詳細なリストを収集します (必要な各機能を列挙させます)。
次に、リストを確認して、機能に投票できるようにします。たとえば、機能を配布するために 100 ポイントを与えます。機能に複数のポイントを与えることができます。
B. 分析
ビジネスモデルを分析し、必要と思われる機能を列挙します。これが必要な理由は次のとおりです。
C. 実装
A と B からリストを分析し、マージし、一部を削除し、一部を改善します。埋め込む。
D.テスト
ユーザーでテストします。彼らの不満を聞いてください。よく見る - 彼らがよく使う機能 - 彼らが行き詰まっているもの - などなど
E.反復
いわゆる市場調査です。
いいえ、これは男を掘り下げるものではありませんでした。確かに、UCD の担当者が現場でユーザーの要求を取得するために使用する手法はたくさんありますが、それらは市場調査員が使用するツールとまったく同じです。カードソーティング、プライオリティリストなどはすべて市場調査用語です。