インタラクティブなプロトタイプの成果物のベストプラクティスは？
Axureプロトタイプをクライアントに初めて紹介します。 Axureは非常に詳細なアノテーションと仕様を提供しますが、このプロジェクト（内部で使用するためのスケジューリングアプリケーション）はやりすぎだと思います。プロジェクトマネージャーはVisioのフローとPhotoshopのコンプに慣れていますが、設計/承認プロセスを向上させたいと思っています。 UI、注釈、仕様で推奨される詳細レベルを確認したい。私の質問はAxureに固有のものではありませんが、それは私が使用しているツールです。
改訂：成果物への質問に再び焦点を当てたいと思います。どの成果物をクライアントが見るのに重要であり、どの程度まで開発しますか？たとえば、Axure仕様は開発チームには役立つかもしれませんが、UX/UI設計の承認サイクルでは、それらは役に立たないと思います。
プロトタイプを作成する理由は、静的画面の表示では伝えられないアイデア/コンセプト/ソリューションを伝えるためです。
私は常に、アプリケーション/ Webサービスのフローを感じたり理解したりするときにプロトタイプを作成するというルールを使用しています。
何かがどのように感じられるかをシミュレートできるのは、プロトタイプです。
たとえば、Googleサジェストのように機能する検索機能を表示したい場合、クライアントは参照だけでは何を意味するのかわからないでしょう。次に、プロトタイプを作成してそれを表示します。
アプリケーションのフローは、通常のUXの盲点の1つだと思います。アプリケーションを作るものの多くは、クリックの間に何が起こるかです。
プロトタイプについては、理解しやすい方法で機能を説明および例示できる詳細レベルに到達する必要があると私は言います。
ただし、プロトタイプが完成したと誰も信じていないことも非常に重要ですまたはほぼ完成した）製品。その場合、お客様は明日配送できるとお客様が考えるリスクを冒します...または、細部（化粧品）の詳細についての議論に行き詰まることがあります。つまり、最終製品です。
一般に、未完成/未完成のプロトタイプまたはモックアップは、ユーザー入力、批評、および代替ソリューションを招きます。これにより、ユーザーは既存のプラクティスの潜在的な変容を見ることができます（Ehn＆Kyng 1991、p。652）。また、最終製品と間違われることはほとんどありません（Ibid .; Beyer＆Holtzblatt 1998、pp。372-3）。 （これがまさに私が好きな理由です Balsamiq Mockups 。）
一方、機能的なプロトタイプは、ユーザーが具体的な使用状況で実際に体験できるようにします（Bødker＆Grønbæk1991、p。198）。
プロトタイプでは、完全性の試みに疑問の余地はありません。その機能は、情報システムの特定の側面に光を当てることです。最も不確実性が高い側面に特に重点が置かれます。 ...プロトタイプは、それらの側面についてなされた仮定の正確さを検証するために使用されます。生産システムとは対照的に、プロトタイプは通常不完全であり、完全に機能することを意図していません。 （1990年フォンク、20-1ページ）
参考文献
Beyer、H.＆K. Holtzblatt（1998）。 コンテキストデザイン：顧客中心のシステムの定義。カリフォルニア州サンフランシスコ：Morgan Kaufmann Publishers
Bødker、S.＆K.Grønbæk（1991）。 "Design in Action：Prototyping by Demonstration by Cooperative Prototyping"、in Kyng、M.＆J. Greenbaum（編）、Design at Work（pp。197-218） 。ニュージャージー：Lawrence Erlbaum Associates
Ehn、P.＆M. Kyng（1991）。 "段ボールコンピューター：モック-イット-アップまたはハンズオンフューチャー"、Wardrip-Fruin、N。およびN. Montfort（編）、The New Media Reader（ 651-62ページ）。マサチューセッツ州ケンブリッジ：MIT Press
Vonk、R。（1990）。 プロトタイピング：CASEテクノロジの効果的な使用（pp.20-33）。 Englewood Cliffs、NJ：Prentice Hall Inc.
成果物の性質は、プロジェクトの範囲、行っている作業、および扱っているクライアントの種類によって異なります。あなたが直面しなければならない最大の課題はクライアントが期待することを決定するであり、それを提供する（または必要に応じて期待を調整する）です。
たとえば、私の同僚は最近、エネルギー部門のクライアント向けにインタラクティブなプロトタイプをHTML、CSS、JavaScriptで作成しました。モックアップが必要なUI（再設計）は非常に複雑なため、クライアントと話し合うための最善の方法は非常に忠実度が高いことでした。彼はクライアントを手に取ってプロトタイプを反復するプロセスを案内したので、クライアントは現在のUIが間違っていたこと、そしてなぜ私たちの改善が必要で価値があるのかについて多くを知ることができ、このようなUIを再作成するために必要な作業量についての良い洞察。仕事は、インタラクティブなプロトタイプを提供することだけでした。この作業に基づいて、クライアントは次のステップを評価します。 （現在、アプリの次のバージョン全体を再設計および実装するように契約していると言えば十分です。）
このプロセスからの重要なポイント：
プロトタイプの忠実度をクライアントの期待に合わせる。優れたプロジェクト管理とは、期待を管理することであり、プロトタイピングプロジェクトでも同じです。したがって、クライアントが何を見る必要があるかを理解し、プロトタイプのタイプをそれと一致させて、作業を最もよく伝えることができます。インタラクティブプロトタイピングでは、「高忠実度」を解釈して、灰色と白の画面だけでなく、実際の色、タイポグラフィ、サイズなどをできるだけ最終的なアプリに近づけてモデリングすることを意味します。上記のプロセスで私たちが省略した唯一のものは、ハウススタイルの適用でした（たとえば、すべてを恐ろしい緑の色合いに変える;-)）。
設計プロセスについてできるだけ透明性を保つ。他のいくつかの人が述べたように、プロトタイピングプロセス中の1つの危険は、クライアントがプロトタイプが最終製品と同じであると考え始めることです。上記の例では、私の同僚はコードベースの保守性などに焦点を当てていませんでした-彼は設計している特定のユースケースのために一緒にハッキングしただけです。しかし、彼は設計プロセスをクライアントにうまく伝え、何が起こっているのかについての各ステップを説明し、これがどれも最終的なものではないという事実を強調したので、クライアントは彼らが得ているものを理解することができました。これは避けるべき重要な落とし穴ですが、適切な期待管理はかなり良い仕事をすることができます。
あなたがしていることとその理由を文書化する。インタラクティブなプロトタイプでは不十分です。クライアントが理解できる方法で提示する必要があります-直接作業している製品所有者だけでなく、すべての利害関係者設計プロセスに関与していなかったチェーンのアップ。私の同僚は、彼が取り組んだ画面の特徴を紹介するミニチュアWebサイトを作成し、物事がどのように機能しているかのさまざまな部分を強調する簡単なコードを書きました。このメタデータは、完成したプロトタイプの成果物が完了時に組織内で渡されるため、ワイヤが交差したり混乱したりしないようにするために非常に貴重です。
それでは、インタラクティブなプロトタイプの成果物のベストプラクティスは何でしょうか。正直なところ、それはすべて優れたコミュニケーションと期待の管理についてです。クライアントが何を期待するかを理解する必要があります。それが終わったら、難しい部分はあなたの後ろにあります-今、あなたは出て行ってあなたのデザイン作業をすることができます！
PS。私たちの製品をプラグインするためではありませんが、私の同僚はこのプロセス中にそれを使用し、ツールの多くの利点が明らかになりました。たとえば、すべてのプロトタイプをオンラインで即座に共有できるという事実により、クライアントの進捗状況を常に最新の状態に保つことができ、電話でクライアントに説明することもできました。これは、クライアントが私たちのオフィスにいなければならないか、何が起こっているのかが分からないという古い状況を大きく改善しました。
Axureと他のいくつかのツールを試してプロトタイプを作成しましたが、プロトタイプはROIが非常に高く、時間の無駄であるという結論に達しました。 PowerPointを使用してストーリーボードを作成する、はるかに成功した方法に戻りました。
スライドマスターを使用して、アプリのバニラブランクを壁紙として貼り付けます。次に、コンボボックスなどのいくつかのコントロールを最後のスライドに保存します。最後に、ユーザーがクリックする場所を示すためにアニメーション化するカーソルの画像があります。
非常に速く、非常に簡単で、誰でもそれを開いて変更することができます。そして何より、デザインビジョンを明確に伝えます。
これがお役に立てば幸いです。
答えは、提供しようとしていたプロトタイプの種類によっても異なります。 1つの（静的）Webページだけの場合は、多くのオプションが残されます。 PhotoshopやIllustratorなどのデザインツール、さらには手描きのスケッチ。複数の状態のWebページ、ユーザーフロー、および/またはカスタマイズされたユーザーインターフェイスを含む可能性がある、より完全で複雑なストーリーでは、通常、 Balsamiq 、PowerPoint、およびWordの組み合わせを使用します。
- モックアップを作成するBalsamiq。
- モックアップやスクリーンショットを編集するためのPowerPoint。コールアウトを追加して、必要な詳細を追加します。これは非常に便利です。流れについて説明するとき。
- Word（または任意のワードプロセッサ）を使用して、より完全な背景と設計の決定を文書化します。何人かの優れた製品担当者やデザイナーとの共同作業の経験から、私は多くの場合、細かく決定したことを思い出せないため、これは開発する良い習慣だと思います。
問題は効果的なツールを見つけることに関するものでしたが、私見では、設計上の決定について直接話し合うことができる（または仮想的な方法で行うこともできる）チャンスに勝るものはありません。
「クライアントにとってどの成果物が重要であり、どこまで開発できるか」
UIの相互作用と意図を完全に伝える成果物は重要です。あなたはそれを達成するために必要な限りそれを開発します。その答えの詳細は、プロジェクトとクライアントに完全に依存しています。
余談ですが、これはアジャイル開発が支援しようとするものです。考えられることは、クライアントに「タッチ可能な」成果物をより早く届けることができるので、避けられない微調整がより早く行われるということです。
迅速なプロトタイピングには、Balsamiq www.balsamiq.comまたはMockingbird gomockingbird.comを使用します。より詳細な対話計画を提供する必要がある場合は、Axureにアクセスしてください。
アートワークされたデザイン（Photoshopで）とAxureを組み合わせて非常に現実的なデモを作成し、ワイヤーフレームを解釈する能力や欲求を持っていない（より上級の）関係者にデザインのアイデアを売り込むことで、かなり良い結果が得られました。
他の人が示したように、何がレビューされているかによります。 Balsamiqモックアップのように、構造と相互作用を取得するためのモックアップ。 Balsamiqsの画像は、モックアップが何であるか（提案された構造）でなく（デザインコンプ）ではなく、グラフィックデザインよりも構造に焦点を当てることができます。ビジュアルデザインに移るのはその部分が完了した後のみです。構造が既に合意されている場合は、デザインの承認にフラットファイルを使用できます。あなたが本当に避けたいのは、アプリケーションの動作をまだ決定していないときに使用する適切な緑の色合いについての議論に入ります。
要約すると：
インタラクティブプロトタイプのベストプラクティス
- 画面間の流れを表示する
- アプリケーションが完了していないという期待を設定し、フィードバックを招待するために、UIを洗練させないでください。
- アジャイル手法を使用し、クライアントに複数の反復を提供して、コーディングを開始する前に設計の問題を解決します
- クライアントがインタラクションを理解するために必要な完全性のレベルでのみ、UIと注釈を完成させます。完全性のレベルはクライアントによって異なります
これらは私の重要なポイントです。他に何か追加する人はいますか？