私はWebアプリに取り組んでおり、社内での最初の調査と議論に基づいて、ワイヤーフレームをかなり遠くまで取得しました。ビジネス関係者は、潜在的なクライアントにワイヤーフレームのいくつかのデモを設定することに熱心であり、私はそれらをより多くの研究のための機会として使用したいと思っています。どのような質問をするか、避けるべきこと、アプローチなどについての一般的なアドバイスはありますか?
TIA
ニックスターのプロトタイピングの第一法則:利害関係者の年功序列と、忠実度の低いプロトタイプからの相互作用を視覚化/概念化する能力には反比例の関係があります。シニアになるほど、より忠実さが要求されます。
彼らができないかしないかは一種の議論の余地があるが、それを人生の事実として受け入れる。それらは、細部(例:コピーなど)によって気が散ったり、方向転換したりします。その後に続くトンネルビジョンは、伝えようとしているもの(一般的には常にではありません)を含みません。
Marty Kaganの "An Open Letter To the Design Community" を読んでください。すべての私見のための必須の読書。
個人的には、自分の設計の反復にはワイヤーフレームを使用し、利害関係者に提示する必要のあるものにはAxureを使用しています。
ワイヤーフレームの表示に慣れていない場合に直面する可能性のある2つのハードル:
インタラクティブなワイヤーフレームを使用している場合は、技術的な問題や適切にリンクされていない問題に遭遇する可能性が高いことを覚えておいてください。完全に無関係な役に立たないコードについては、ビルド時に来ます。
より広いコンテキストでは、ビジネスのニーズ(自然な視点)をユーザーのニーズから分離させるようにします。クライアントの提案が明らかにエンドユーザーにとって機能しない場合に、いくつかの「疑似証拠」を提供できるように、いくつかの簡単なペルソナを事前に構築してみてください。
HTH
私は何百ものワイヤーフレームを外部のクライアントから内部の幹部まで全員にデモしました。そして私が与えることができる最高のアドバイスは、最初にあなたの主要なペルソナと彼らが達成したい1つまたは複数の目標を中心としたストーリーを作成することです。次に、あなたのデザインとそれがあなたのペルソナの生活を向上させる方法を紹介するストーリーを伝えるために必要なイベントとワークフローをスクリプト化します。
実際、私が今まで行ったワイヤーの最高の再生は、スクリプト化されたシナリオで実際のクライアントにワイヤーをウォークスルーさせ、1000時間の手作業を節約して、1つのコメントで終わった方法を示したものです。それを持っている?"
私見、ワイヤーフレームは本当に内部設計ドキュメントです。それらは物事を具体化し、すべてのビジネス要件を引き出すのに役立ちますが、実際にはクライアントよりも内部のUXチーム向けです。
プッシュバックできる場合、最良のアプローチはエンドクライアントのワイヤフレームをデモしないことです。忠実度を低く保つには、粗雑なインタラクティブプロトタイプを作成することをお勧めします。世界中のすべてのボックスとラインは、テキストを入力したとき、または要素がクリックされたとき/上に置かれたとき/発生するはずの例が何であれ、精通していないビジネスユーザーがデザインをほぼ把握するのに役立ちません...起こります。
AxureまたはBalsamiqのようなものでさえ、簡単に低fiプロトタイプを実行し、提案された設計ソリューションのフローと状態を示す相互作用を含めることができます。