ユーザビリティレビューまたはUI仕様？
現時点では、UI/UXが現在のソフトウェア開発サイクルにどのように適合するかを確認しようとしています。新しい製品をワイヤーフレーム化する別の部門があります。
新製品および既存製品の仕様段階には、ワイヤーフレームと技術仕様が含まれます。
初期の段階でどちらが最適であるかはわかりません。私のワイヤーフレーミングへの関与は遠いため、そのような変更は別の人によって行われます。
- ワイヤーフレームでユーザビリティレビューを行い、内部フォーカスグループ、意見、ベストプラクティスに基づく改善/修正のフィードバックを提供します。
- ワイヤーフレームに基づいてUI仕様を作成する
- ユーザビリティレビュー、フォーカスグループを実行し、受信したプライマリワイヤフレームを修正します（ソフトウェア開発サイクルを効果的に変更します）。
ここで読んだことはありますが、ユーザビリティテストは通常ワイヤフレームでは実行されません http://www.loop11.com/wireframe-usability-testing/ これは、新製品を合理化するための良い方法です。
基本的に、私の役割は、完成したワイヤーフレームにOKを与えることです。ワイヤーフレーム、ベストプラクティス、およびドキュメントを修正して修正をサポートするための最良の方法は何でしょうか。
Jakob Nielsenは最近、最も有用なユーザビリティアクティビティについての良い記事を書きました http://www.useit.com/alertbox/field-study-vs-user-test.html 。理想的には、ワイヤーフレームを作成する前に（ユーザーのニーズとメンタルモデルを理解するために）ユーザー調査を行い、ワイヤーフレームを使用してユーザビリティ調査（デザインがユーザーの目標をサポートしているかどうか、およびユーザビリティの問題があるかどうかを確認する）の両方を行います。ワイヤーフレームを使用してユーザー調査を実行することの大きな利点は、UIのアーキテクチャを変更する可能性があることです。プロセスの後半で、開発作業がすでに始まっている場合は、はるかに困難です。
質問に基づいて、通常はワイヤーフレームの準備ができたときにプロセスに関与するので、仕様を作成する前にUIが機能することを確認するために、ユーザーの前に配置することができます。多くの場合、タイミングは制約であり、参加者の採用にはしばらく時間がかかる場合があります。私が貴重だと思ったのは、バイアスを回避するためにプロジェクトに関与していない同僚とすばやくユーザビリティ調査を行うことです。通常、社内のユーザーにメールを送信して、誰かが参加したいかどうかを確認できます。私の見解では、人々はユーザビリティ研究を楽しいと感じており、社内で採用することは難しくありません。もちろん、理想的には、実際のユーザーに似た参加者を見つけることができます。
答えは：bothです。
前：
ユーザーはUIの言語を話します。したがって、ユーザーが必要とするすべての要件、変更要求は、UIの言語、ユーザーインターフェイスの言語でのみ可能です。
ユーザーがクラスに新しいメソッドを追加することを要求した場合、（s）彼はあまりにも多くを知っています、そして通常それはシステムが実際に書かれた方法ではなく、システムに関するユーザーのメンタルモデルは何ですか（そして時には一般的なプログラミングは）。
したがって、UIはユーザーが話す言語であるため、要件の収集に役立っています。
ユーザビリティは常に事前にUX業界でテストされており、Googleは紙のプロトタイピング、つまりワイヤーフレームの「祖先」をテストしました。
設計段階では、元のソフトウェアエンジニアリングの意味で、変更のコストを削減するためにありました。半完成品の変更を行うには、はるかに時間がかかります。
バランスは、デザインの詳細度（デザインのコスト）とユーザーにとっての意味のバランスです。
ソフトウェアエンジニアは、何でもそうですが、本格的に行きたいです。私は通常、1つのスプリント（およびすべての国の真新しい車）の価格から東ヨーロッパの家を購入できること、および「このスプリントをこの機能と次の反復で再び始めましょう」、これはまさにこのためです。通常、スプリントで行われたことは、それが次善であっても残ります。
使い捨てにするためには、低コストのデザインを提供できる必要があります。
完全なUIを実行すると、コストが高くなり、顧客（またはあなた）はそれを完全に破棄することに消極的になります。少ないほど良い。
ワイヤーフレームをクリック可能にするためのツールがあります。最も一般的なものはPowerPointですが、それらの束を見ることができます here 。
また、私は通常、フロントエンドファーストのソリューションを採用しています。つまり、クリック可能で機能しないフロントエンドを最初に実行し（たとえば、JavaScriptモックデータストアを使用）、ユーザーがフロントエンドであるため、後でバックエンドに接続します。問題を伝えることができます。
後：
完璧なものはないため、完成した製品が完成したら、意図したとおりに機能するかどうかを確認する必要があります。通常、トレーニングではなく、主要なユーザーにインターフェースで特定のタスクを実行するよう依頼します。通常は、以前に合意した、アプリケーションの構築に使用されたユーザーストーリー/ユースケースシナリオのバリエーションです。
また、可能な場合はいつでも、最初の数週間はオンになっている（または、あまりリソースを消費しない場合は常に）アプリケーションに測定/監視メソッドを追加し、何を行うかについて事前に主要なメトリックを作成します改善として見たいです。古いバージョンがあったときはいつでも、比較するために、古いバージョンは同じ種類の監視を事前に取得します。
ユーザーにとって、UIはシステムです。インタラクションに関しては、おそらくUIの仕上げよりもインタラクションフローの方が重要です。特に、技術的および心理的な意味で、ユーザーも、ユーザーも作成者はそれと完成したアプリケーションを区別できます。それは彼らの頭の中では行き詰まっていますが、特定のソリューションに対して技術的にも行き詰っています。
基本的に私の役割は、完成したワイヤーフレームにOKを与えることです
よくあることですが、私はこのアプローチのファンではありません。
「ok」の意味についても異なります。
「ワイヤーフレームは大丈夫です。今度はUXプロセスを終了しましょう」と言うだけの場合、それで問題ありません。
ただし、「ワイヤーフレームは問題なく、UXは完了し、これをビルドする」として扱われることがよくあります。
後者の問題は、製品がワイヤーフレームではないことです。製品は、ワイヤーフレーム、UI、ユーザーテスト、バックエンド開発などです。
そのため、私はサインオフが必要なものとして扱われることのないワイヤーフレームの大ファンです。ワイヤーフレームは、実際のユーザーエクスペリエンスを作成するために、進行中の内部ドキュメントとして扱う必要があります。 UXは、特定のワイヤーフレームではなく、サインオフする必要があるものです。
使いやすさの質問に具体的に答えるために、私はいつでもできる限りそれを行うと言います。ワイヤーフレームでそれができるなら、素晴らしい。やれ。あなたがUIとプロトタイプでそれを行うことができれば、さらに良いです。やれ！ （基本的に、できる限りユーザーテストを行います）。