期待管理

Question

私が協力している開発者のチームに、ユーザーのモックアップを見せてアイデアを探り、要件を完全に理解できるように説得するのに苦労しています。

最終製品に実際に表示されるものは何も保証されておらず、最終的にモックアップのように見えない可能性があることをユーザーに繰り返し伝えることを誓いますが、チームは疑わしいです。彼らは、過去の同様のセッションで、最終的に製品に（おそらく技術的な理由で）気に入っていないものが現れたときに失望感を抱かせたと述べています。

他の人はこれをどのように処理しますか-開発者とユーザーの両方で？

brad · Answer

次の2つの問題があるようです：

ユーザー要件の確認/理解;そして
テストは良いアイデアだとチームに納得させる。

ユーザー要件の確認/理解

ユーザーの要件を理解または検証しようとするとき、私はあらゆるタイプのモックアップまたはプロトタイプを使用しないようにします。この段階では、問題を理解しようとするのではなく、解決を試みます。また、この段階で、要件の実現可能性を開発者とテストします。

たとえば、ユーザーはxを作成するために自分のコンテンツをアップロードしたいと考えています。これを開発者に伝えて、開発者に制約を与えます。

制約を受けたら、1つ以上のソリューションを設計します。これは個別のアクティビティにすることも、開発者、ユーザー、利害関係者などと一緒にブレインストーミングを行うこともできます。設計が完了したら、開発チームと一緒にこれらを調べ、考えられる技術的な問題を特定します。

チームを説得する

チームのメンバーが既に否定的な結果が発生する場合は、まずユーザーと一緒にテストを行います。私の経験では、一部の開発者はテストがどうなるかについて非常に異なる考えを持っていました。彼らがプロセスを通過すると、それはより理にかなっています。また、開発者にセッションを観察させます。

さらに、紙のプロトタイプまたはローファイデザインを使用すると、これらの予想される可能性に対処できますが、正直に言って、私はデザインのアイデアをテストしたことがなく、その後のセッションでそのユーザーに失望を表明したり、前のセッションの機能。

期待に応える上で、セッションのコンテキストをできるだけフレームに収めるのが最善の方法だと思います。これは、テストしているアイデアであることをユーザーに伝えることです。人々は通常それを理解しています。

IgorJ · Answer

最終製品に実際に表示されることが保証されているものは何もないこと、およびモックアップのように見えないことになる可能性があることを繰り返しユーザーに伝えることを誓います

何度も試してみましたが、うまくいきませんでした。

問題＃1：ユーザーは進行状況について誤った感覚を持っています-何を示しているかを顧客に説明するためにあなたが言うことも、行うこともできません実際にはモックアップのみです。彼らは自分の目で見ることができ、フードの下の配線は「唯一」残っています。

問題＃2：あらゆる種類の設計フィードバックが得られます-この時点では通常は必要ありません。システムの基本的な構造と機能に同意するのに苦労している間は、フォントと色、視覚的アイデンティティ、および何もないことについての議論（少なくとも有害ではない場合）は少なくとも逆効果です。

問題＃3：開発者はGUI仕様のモックアップを混乱させるでしょう-私たちは私たちが望むことを言うことができますが、開発者の心理学（および抽象化の力）はそうではありません通常のユーザー心理とは異なり、結局のところ私たちはホモ・サピエンスです。つまり、モックアップはさまざまなアイデアをテストし、顧客との相互理解をテストするための単なる手段であることを開発者に説明するのは非常に困難です。開発者は言うまでもなく、30秒間考えずにモックアップを実際の画面に単にコピーします。通常、モックアップを作成する人は、実際のGUIのより正確な表現を作成するために、モックアップを作成する人がツール/フレームワークをよく理解している必要があると不平を言います。

それで、あなたは何をしますか？

まず、少なくとも最初は、「ニース」のモックアップは行いません。ペンと紙を使用してください。または描画ボード。または、大ざっぱな/白黒のルックアンドフィールを持つモックアップツール。このようにして、モックアップはそのモックアップだけであるコミュニケーションです。

第二に、モックアップで正式で複雑な「プロセス」を導入しないでください。これにより、「仕様」の考え方が簡単に呼び出されます。関連する画面をいくつか描画し、ライブワークショップでユーザーにコメントを付けたり、さらに画面を描画したりするだけです。

ところで、コーディングが始まる前に、そうしたいと思うでしょう。いくつかの「メイン」アプリケーション画面から始めて、それらが合理的に固定されている場合にのみ、何らかの種類のシナリオ（使用する方法論にかかわらず）に進みます。これは、顧客を自然なビジネスコンテキストで獲得することが重要であるためです。直ちに。

私はこのすべてに非常に不満を感じていたので、10年ほど前に自分のツールを作成しました（ MockupScreens 、実際には非常に人気になりました）。

ああ、そして私が知っている無料と商用の両方のツールの中で最も包括的なリストは次のとおりです： http://c2.com/cgi/wiki?GuiPrototypingTools

ツールを選択するときは、ツールの目的を事前に知っておいてください。

高忠実度または低忠実度？ライブワークショップでプロトタイピングさえしますか？
PDF/Wordドキュメントを介して通信するか、単純なスクリーンショットを作成するだけですか？
ツールを使用して仕様に近いものを作成するか、それを使い捨てモックアップに使用しますか？
ターゲットプラットフォーム（開発中のシステムのプラットフォーム）は何ですか：デスクトップ、Web、スマートフォンなど？
実際の使用シナリオを提示するために、実際に見えるデータを画面に取り込みますか？（これについては、数十の「メイン」画面があると予想できますが、文字通り数百の「子」が、あちこちにある画面上のデータに違いがあるだけです
ツールからどのレベルの操作が必要ですか？（ほとんどのツールには、ボタンをクリックするなど、すべてに配置できる「リンク」がありますが、一部のツールはほぼ完全にインタラクティブです）
などなど

adrianh · Answer

いくつかのランダムな考え：

値に焦点を当てます。開発者側を説得する上で、フィードバックの値について詳しく説明します。間違ったものを構築したり、正しく構築したりするのにどれくらいの費用がかかりますか？
コストは価値がありますか？開発者は正しいです。あなたがそれを示す人々の何人かも、機能Xが最終リリースになると思います。ユーザーに伝えることは何でも。ユーザーに何を見せても。これが起こることを受け入れます。質問は次のようになります-他のすべての人のために物事をより良くすることで得られる価値に見合う、イライラしているユーザーは少数です。
ローファイのプロトタイプを使用します。紙のプロトタイプで話し合う問題は、「完成した」ものよりもはるかに少ないことがわかります。
次のリリースではありません。ユーザーと一緒にいるときは、これが次のリリースのためのものか、現在取り組んでいることだと言ってはいけません。将来のリリースのオプション、または次のリリース以降の作業のオプションを検討しているとしましょう。あなたが実装の日付を将来にプッシュする場合-人々はそれを期待して不満を抱く可能性が低くなります。
プロトタイプは適切なツールですか？プロトタイプは、要件を理解するために今必要なものですか？ユーザーの期待を高める可能性が低いものは、より良いツールでしょうか？たとえば、文脈インタビュー？
テストを行うときに移動する良いアイデアがテストされているが構築されていない場合、それはテストが早すぎることを示しています（ユーザーは通常、テストした悪い機能を削除することに不満を言っていません） ;-)。より頻繁に、そして開発サイクルの後半でテストします。ユーザーに迷惑をかける前に、次のリリースで機能が実現可能かどうかについての情報を入手してください。繰り返しになりますが、実装されていない「優れた」機能で多くのプロトタイプ作業を行っている場合、プロトタイピングがその初期段階で適切なツールではないことを示している可能性があります。

Skuirrel · Answer

エイドリアンとブラッドからの素晴らしい答え。私が現在の会社で仕事を始めたとき、私は同様の問題で少し苦労しました-彼らは以前にUXでの作業の経験がなく、UIは私の前のCEOと開発者によって設計されました。

私の追加：

信頼の構築開発者と透過的あなたがするすべてのこと
それらをテストセッションと計画に含める（可能な場合）。彼らはプロセスに対するより多くの所有権と制御を感じます-「船上」にいる可能性が高く、彼らはあなたが何をしているのか、そして非常に重要な側面を学びます：彼らはあなたから中古品について聞くよりもテスト結果をよりよく理解します。たとえば、1つの開発/セッションをローテーションできますが、適切なユーザビリティラボにアクセスできない場合は、テストを妨害しないように注意する必要があります。
内部テスト参加者による最初のテストを実行することを検討してください。実際のエンドユーザーを可能な限り密接に表しています。これは通常、より速く簡単に整理でき、期待値管理はそれほど問題になりません。
「パイロット」テストセッションを整理するチームで教育したい人と一緒にテストがどのように機能するかを理解してもらい、うまくいけばある程度の信頼を得ることができます。
可能であれば、authorityを使用できる位置にいることを確認して、ユーザビリティテスト/プロトタイプテストをいつ実行するかを決定します。
少し時間がかかる可能性があることを了承してください、私の場合、ポイントを通過するのに数か月かかりました。CEOは、非現実的な期待を生み出したり、ユーザーから何か有用なものを得ることができるかについて同様の懸念を持っていました。私たちの将来の製品の研究。

orangedrum · Answer

あざけるな。あなたはユーザーエクスペリエンスをテストしようとしています！鳥をからかってみましたか？ https://gomockingbird.com/

バルサミコもあります http://www.balsamiq.com/products/mockups

非常に明確に「理論的なモック」である体験を迅速にプロトタイプ化するので、ユーザーはこれらを製品に直接関連付けません。また、それらを単純にしてください。複雑な場合はアプリケーションを分解し、ユーザーが実行する可能性のある特定のタスクをテストします。これらはテストと見なされ、テスターに期待を与えるものではありません。ユーザーに特定のタスクを実行する時間を計ることもできます。また、複数を指定して、どちらが好ましいかを確認することもできます。

テスターに機能が必要かどうかを尋ねることはありません。彼らはいつもイエスと言うでしょう。彼らがどのような体験をしたいかは決して尋ねません。ヘンリーフォード氏は、「もし私が顧客に何が欲しいのか尋ねたら、もっと速い馬を求めていただろう」と述べています。

あなたの方がよく分かっている。質問しないでください。テスト。経験。改善する。より速い馬を作るのをやめるようにあなたの会社に言ってください。