ユーザーからより洞察に富んだUX要件を抽出する方法
私たちは反復リリースを行っているため、ユーザーUI/UXの要件が多数寄せられているのがわかります。これは、主要な領域に集中できるので非常に便利です。
当然、これらのリクエストは "システムはXを実行する場所Yにボタンを持っている必要があります"の形式です。時々これは適切ですが、多くの場合、この提案は実際の目標を達成するには不十分な方法です。
私は現在、状況と目標を通してユーザーと話す会話でこれを解決します。これは機能しますが、2つ目の問題があります。1つ目は、固定されたアイデアからユーザーを「巻き戻す」 "But I WANT a BUTTON"、2つ目は、現在のコンテキストから外れているものについてはその場で考えます。これは当然のことながらエラーが発生しやすく、また抽象的に考えれば少数の人々が少し不快になります。
検索で推奨質問は見つかりませんでした。まだフォーマットを試していませんが、まずまずの高品質なセットから始めたいと思います。
したがって、問題は、より洞察に富んだUX要件の要求をユーザーに求めるための既知の効果的な形式は何かということです。
私は、変更に影響を与えるために、最初のレポートを作成するときにプロンプトを表示する必要があると想定しています。私たちの現在のユーザーベースは、適度に教育を受けたホワイトカラーのオフィスワーカーです。
彼らがUI拡張リクエストを開始する問題ロギングフォームのいくつかのアイデア：
質問または段落
Q. What Goal do you need to achieve?
Q. How are you currently reaching this goal?
Q. How frequently do you do this job?
Q. What change would help you achieve your goal?
Q. Describe impact the change make to you and others?
vs.
Hi, to help us make the best possible UI for you, please take
a moment to tell us about the Goal you need to achieve. Describe
what it is, and how you are achieving it today. What is the
impact of the current UI on your daily work.
説明：その「巻き戻しと分析」の会話で本当に役立つ応答をありがとう。それらを使用します。
ただし、私が奨励しようとしているのは非常に狭く、つまり、ユーザーが連絡する前に、ログに記録する最初のレポートで、ユーザーに彼らの目標についてより広範かつ抽象的な考えをさせる（これは非現実的な行かもしれません）
これと同じ質問を過去に解決しようとしました。これが私の解決策です。
短くしてください。それらを活動に導きます。
- 問題を選択してフォーカスします：
「私は現在不可能である何かをしようとしています」
または「私は何かをしている、そしてアプリは私が期待したことをしていない」 - 活動について尋ねる：
「問題が発生したときに何をしようとしましたか？」
これは最初のポイントとアプリの調子に基づいて変化しますが、あなたはアイデアを得ます。 - 期待について尋ねる：
「アプリで何をしたいですか？」
上記と同じ警告。
例えば …
行動の障害を解決する
ユーザーを特定の提案から逆戻りさせるのは難しい（「このボタンが欲しい！」）という心理的な根拠があるという重要な観察を行います。
同意する。理由と魅力を使用して、ユーザーを特定のUX提案に固執することはできますが、そのための労力は、感情的な疲労、自信の喪失、または最悪の場合、デザイナーとしてのあなたとの対立と、プロセスが逆効果になった場合の製品。
どうすればこれを回避できますか？
- 簡単な観察は、すべての問題とその最適な解決策について、可能な提案が[〜＃〜] lot [〜＃〜]あることです：
![enter image description here]()
したがって、提案/要件から始めるのは避けますよりも簡単です問題や目標を中心にユーザーエンゲージメントを直接開始する。
- 提案/要件から始めることは、ユーザーを（右から左に）問題に戻してから解決策に進む必要があることを意味します。これは、ホワイトカラーワーカーにとって、解決策に向かって前進することが合理的な直感であるため、心理的に直観的ではありません。 、問題に逆戻りしない。
![enter image description here]()
これは、最終的にユーザーの提案を探している場合でも当てはまります。これは、最初に問題または目標でユーザーを開始できる場合、その品質結果の提案はより良くなります。
この出発点はどのような質問ですか？
これは私が過去に使用したいくつかです：
- このインターフェースは、作業の速度を上げるのに役立ちますか？より正確またはより多くのエラーで？欲求不満の増加または減少はありますか？
- システムで最も時間を浪費している場所はどこですか？
- 最も多くのエラーを誤って作成した場所はどこですか？
- このインターフェースについて最も嫌いな点は何ですか？
- このインターフェースの何が一番好きですか？
- 設計をやり直して、[より速く/苦痛が少ない/エラーが発生しにくい]ようにするために、どのプロセスをご希望ですか？
ここには潜在的な質問がたくさんありますが、行動モデルが状況に合ったセットを調整するのに役立つことを願っています。
質問に回答の一部がすでに含まれているため、これは質問に完全には回答しません:)
ユーザー（場合によってはクライアント）が"But I Want a BUTTON"を要求する部分については、いくつかの便利なテクニックがあります。
- ユーザー/クライアントの問題を再確認します。私は彼/彼女を解決策の提案から問題の特定に移します。これは、元の問題に到達するために多くのwhysを必要とする場合があります。
- 私はデザインソリューションの全責任を負うことをユーザー/クライアントに思い出させます（結局、5年間デザインを研究して、それを実行できるようになりました。時々、彼/彼女にこれらの言葉を話しました）。
- 最後に、ユーザー/クライアントに、ニーズの異なるさまざまなタイプのユーザー向けに設計していることを思い出させます。私はすべてのニーズを満たすことができず、それを行うとデザイン全体が台無しになります（ペルソナを作成する場合は、ペルソナが必要な機能にどのように集中できるかを彼/彼女に示すことができます）。ソリューションの種類や外観に関係なく、問題を解決することを彼に保証します。
注：デザインの大きなバグのように見えるものはいつでも再設計できます:)
これは数人の人々を混乱させると確信していますが、ここではそれが起こります。
これはユーザーの問題ではないと私は個人的に信じています。ユーザーが洞察に満ちたUX要件を持つことはなく、これがyour専門知識が必要な理由です。
20年以上コンピューターを使用している最も教育を受けた人々でさえ、コンピューターとインターネット全体で苦労しているため、リクエストを送信することさえも、大きな最初のステップです。
平均的なコンピューターユーザーが質問や問題を提起するとき、あなたは手を握り、彼らが達成しようとしていることを観察できる必要があります。知覚された解決策ではなく、問題を明らかにしてもらい、冷静に「何ができるか見てみよう」と言うことができます。基本的に、ユーザーが開始したXY問題が発生しています。
はい、あなたは技術的な観点からあなたが何をしているのか驚くべきことを知っていますが、ホームランを打ちたい場合は、クライアント/ユーザーとの関係を育てる必要があります。
ここで対処する2つの問題があります。提案された変更が何を達成することになっているのかを適切に理解することと、顧客からの抵抗や不満を回避することです。修正するにはどうすればいいですか？」.
私の経験では、これを電子メールでうまく解決することは非常に困難です。これらのタイプのディスカッションでは、対面の会議の方がはるかに効果的ですが、電子メールによる非同期通信よりも通話の方が優れています。
両方の側面に対する私の一般的なアプローチは、「このリクエストのコンテキストを明確にするために探しているので、正しく理解できるようにする」ことです。
会話中に、ユーザーがこれで何が達成できると思うかが明確である場合、私は次のように始めます。「理解するために、これで解決される問題は...と思います推測を挿入 ...そして、あなたはそれを試して修正しようとしています... うまくいくかもしれませんが、それを達成するための最良の方法ではないかもしれません。それは正しいですか？」
これは議論を招き、しばしばそのトピックについてより自然な会話になります。
提案された解決策について話し合うことを避け、問題に焦点を当てた会話を続けてください。何がリクエストを促しているのか、それがどのように彼らの仕事に悪影響を与えているのかを理解するようにしてください。提案されたソリューションよりもすぐにユーザーに明らかな利点を提供できると思われるその場で何かを思い付くことができない場合を除いて、どのように対処するかについて話し合うことは避けてください（たとえば、「私は思いついた... [問題を引き起こす状況]を回避できるように[無効にする]ボタンを追加することについて説明してきましたが、ウィジェットを自動的に無効にしてクリックする必要がない場合は、それでも機能しますか？ "）。あなたはまだ「ノー」を得るかもしれませんが、-なぜについての詳細な説明を得る可能性ははるかに高く、それは機能しないので、より多くのコンテキストを獲得します。
面談後、解決策への取り組み方を決定します。顧客の提案よりも良い方法があると判断した場合は、あなた（またはプロジェクトマネージャー）が、計画していることに関する簡単な説明と、ソリューションを選択した理由のリストを作成する必要があります。顧客の提案。
お客様が戻って「いいえ、私のやり方で」と言わないことを保証するものではありませんが、その可能性は大幅に減少します（特に、ソリューションを提案しているお客様がお客様の最終的な発言でない場合）意思決定プロセス）。
私はこの問題についてトースターに完全に同意します。なんと素晴らしい反応でしょう。私はこれをコメントとして投稿しますが、まだ十分な評判がありません。
私は "S-T-P"アプローチを使用しました。これは、トースターのソリューションの中核と考えています。
つまり、SituationTarget提案
状況現在の状況から始めます。今日は何をしますか？元気ですか？失いたくないものは何ですか？どのような問題が発生し、放射性降下物は何ですか？
Target成功はどのように見えますか？すべてを正しく行うと、プロセスはどのようになりますか？私たちのシステムはユーザーの自律性と即時のフィードバックを提供しますか？エラーはどのように検出および識別されますか？晴れた日と雨の日のシナリオは何ですか？
Proposalこれは最後に来るもので、最初の2つが完了すれば、もっと簡単になります。通常、3つの中で最も難しい。ここで優先順位付けが行われます。リスク報酬の分析と議論もここで行われます。
この記事をご覧ください： http://dailykaizen.org/2007/06/19/situation-target-proposal-stp/
より洞察に富んだ要件を抽出するためのさまざまなユーザーインタビューテクニックがあります。
私はContextual Inquiryの大ファンです。これは、要件を抽出し、ユーザーから得られない可能性があるユーザーのニーズを洞察するのに最適な方法です。典型的なQ/Aセッション。
Contextual Inquiryの基本的な前提は非常に単純です。顧客がどこにいるのかを確認し、顧客が働いている様子を観察して、顧客にその仕事について話します。そうすれば、顧客の理解を深めるしかありません。このコンテキストデザインブックから詳細を読むことができます
重要な概念は、ユーザーとの関係を構築することです。いくつかの方法があります。
- 収集されたすべてのデータは匿名化され、100％匿名であることを前もってユーザーに伝えます。
- 公開する可能性のあるすべてのデータが表示されることを伝えます
- 日常の作業環境に移動します（ラボに来たり、快適ゾーンを離れたりしないでください）。
- 彼らは専門家であり、あなたは彼らのワークフローがどのように行われるかを学びたいと思っていることを彼らに納得させます。私は見習いマスター関係のように言いたいです
- 形のないものを削除します。つまり、現在行っているアクションを実行している間、観察して話をさせている正式なレビューはありません。
- 観察するにはさまざまな方法があります。実際に彼らと一緒にタスクを実行することもできます（彼らが何をしているのか、彼らが何をしたいのかを理解しているかどうかを確認するように教えます）。メモする。特定のものは、さまざまな状況により適しています。
- 隠された要件を見つけるために、人々の発言と実際に彼らが行うことの違いを観察できないかどうかを確認してください。
- 2時間程度に制限してみてください。これにより、正式性が低下し、一般的に保護されなくなります。
- 人格的になり、彼らに時間を与えてくれたことに感謝し、うまくいっていたとしても感謝して行動する
要件が満たされた後
- フロー図またはシーケンス図を作成します。ワークフローの順序でピースを接続します。
- ギャップがあるように見える場合は、何かを逃したかどうかを確認してください。そうすれば、xyzzyを実行する必要がありますが、とても面倒なので、忘れてしまいました。
ユーザー要件のあるGotchas
- これが私たちが通常行うことではなく、私たちが行うことであると彼らが説明するときに注意してください。何かが一般的なプロセスの一部であるとしても、それらは通常、すべての部分に従いますか、それらが説明していない欠けている部分があります。
これはユーザーの要件を抽出する強力な方法ですが、習得し、合理化し、完璧にするためには確かに少し労力が必要です。 コンテキストインタビューの難しさに関しては、uxmatters.comのこの記事を最後に参照してください。
（ニーズを取得するために何を尋ねるべきですか？）：以前に議論した他の専門家がいるように、私は「なぜ」と尋ねることも信じています。これはUXに固有のものではなく、一般に問題解決に数十年前に使用されています。要件の本もこれを強調しており、問題の根本に到達するために少なくとも5つの理由を尋ねるように開業医に奨励しています（顧客がボタンを持つソリューションを提案しました）。これは、ニーズ/要件をよりよく理解するのに役立ち、顧客/ユーザーが彼/彼女が提案しているものの背後にある実際のニーズを実現する機会を与えます。
（潜在的な解決策から問題まで）：A3などの一般的な問題解決手法でも、解決策を提案する前に問題を深く理解する必要があることを強調しています。これは、トースターの回答でわかります。ここでは、ユーザー/顧客はソリューションに焦点を当てていますが、より創造的で潜在的に優れた設計ソリューションを可能にするために、問題の領域に戻る必要があります。
（アンケート/インタビュー/観察：データ収集のアプローチ）：私は個人的に、ユーザー/顧客のビューをよりよく調査できる観察と自由回答式のインタビューのファンです。それを対話として維持することは、双方がより良いコミュニケーションを持つのに役立ち、誤解を防ぐと信じています。また、このようなインタビューや質問では、「目標」などの抽象的なハイレベルな用語を使用することはお勧めしません。これは一部の人々にとって消化しにくく、実りある議論をすることを妨げる可能性があります。代わりに、「なぜここにボタンが必要だと思いますか？」
アンケートを使用せざるを得ない場合は、リッカート規模の質問と未解決の質問を使用して、ユーザーにシステムについて今感じていることを考えてもらうことをお勧めします。たとえば、システムは、必要なすべてのタスクの実行をサポートしてくれます毎日：まったくそう思わない->強く同意し、その後に未解決の質問を続けることができる。
（責任はこれですか？）：これはUXエキスパートの仕事であり、顧客やユーザーの手を握り、彼らが「ソリューション」ではなく「ニーズ」を思いつくのではなく、彼らのニーズを探るのを助けることに同意します。