ワイヤーフレーミングとプロトタイピングの定量化できるメリットは？
ワイヤーフレーミングとプロトタイピングの定量化可能な利点についていくつかの情報源を考え出そうとしていますが、結果を見つけるのに苦労しています。 「要件のフェーズの削減、品質の向上など」をたくさん見ました。しかし、私はさらにいくつかの数字で研究を探しています。
編集：私は質問のタイトルを更新して、私が求めていることをより適切に反映しました。必ずしもワイヤーフレームとプロトタイピングの従来のROI計算を探しているわけではありませんが、直接的な結果である定量化可能な利点を探しています。たとえば、「ワイヤーフレームとプロトタイプの実装の直接的な結果からのやり直しの30％（任意の数）」を表示できる研究は、私が探しているものです。
「UXのROI」の質問にある「開発者の時間の50％がやり直しに費やされている」などのいくつかのメトリックを使用していますが、これは私のケースに役立ちますが、ワイヤーフレーミング/プロトタイピングから直接の特定の結果が望まれます。
編集2：
最終的にはこの質問の目標ではない多くの「アドバイスの答え」を受け取っています。ここUX.SEにいる私たちのほとんどは、プロトタイプと一般的な利点を理解しています。私は、できれば科学的分析から導き出された、定量化可能なデータを探しています。
これが私が見つけた抜粋です、それは私が探している情報のタイプです：
「UCLAで実施された実験では、一部の開発チームは従来の開発方法論を使用し、他の開発チームはソフトウェア開発プロセスでプロトタイプを採用しました（インターフェースを特に重視していません）…プロトタイピンググループによって作成された最終システムのコードは、約40％しかありませんでした最終的に、プロトタイピンググループは、他のグループよりも45％少ない労力でタスクを達成しました。」
http://eprints.cs.vt.edu/archive/00000179/01/TR-89-42.pdf -ページ5。
編集3：
私が求めている情報のもう1つの素晴らしい例。これは、Todd Zaki Warfel著の「プロトタイピング：実務家向けガイド」の本からです。
英国のコンサルティング会社は、要件指向のプロセスからプロトタイピング指向のプロセスに切り替えました。プロセスの変更により、次の利点が生まれました。
プロトタイプと16ページの補足ドキュメントの作成に必要な時間と労力は、200ページの仕様ドキュメントに必要な半分以下です。
ビルド時間とコストの見積もりが50％正確になりました
開発チームによる明確化の要求が80％削減されました
リリース後のやり直しとバグ修正の量は、同様の以前のプロジェクトの25％に減少しました
その答えは簡単です。
有益であるのはプロトタイプの性質です。
それが有益でない場合、あなたはそれを間違っています...
それが有益でない場合は、プロトタイピングではありません定義...
プロトタイピングを開始するとき、youは、プロトタイピングの理由を知る必要があります。 あなたはどのようなメリットがあるかを知る必要があります。プロトタイピングの目的がわからない場合は、削除してください。 ... ... ...またはトピックについて読んでください;-)
回答の2番目の部分を更新しました
Scott Overmyerの論文（2002年から）、「 革命的対進化的ラピッドプロトタイピング：ソフトウェア生産性とHCI設計の懸念のバランスをとる 」を紹介しました。この論文は、プロトタイピングがどのように参考になるかについて言及しています "Wikipediaでの時間とコストの削減" 。
以前はこの論文は入手できませんでしたが、著者は academia.ed に関する論文をアップロードしました。
つまり、このペーパーは革命的なプロトタイピングと進化的なプロトタイピングを比較し、これらの方法のハイブリッドソリューションを提唱しています（このペーパーは2002年に書かれたため、プロトタイピングアプローチの状況はそれ以来発展してきました）。
5つのケーススタディが分析されます（著者は、そのような研究を文献で見つけるのは難しいことを強調しています）。
ケーススタディ＃1：革命的なプロトタイピング。プロトタイピング作業は、10人年のソフトウェア開発作業全体の約6％を占めていました。 5回の反復により、システムのいくつかの側面について優れた洞察が得られました。配達は成功しました。
ケーススタディ＃2：1200〜1500のグラフィックおよび表形式のディスプレイを使用した非常に大規模なソフトウェア開発作業。データはユーザートライアルから収集され、システムシミュレーションモデルへの入力として使用されたため、システムアーキテクチャ全体のパフォーマンス予測がより正確になりました。
ケーススタディ＃3：48の「フォーチュン1000」企業のフィールドスタディ。革命的なプロトタイピングは、情報システム開発の「愚かな空」の概念であると結論付けています。要件の定義に革新的なプロトタイピングをうまく採用できなかったシカゴの銀行の例を使用します。その場合、エンドユーザーは6つの革新的なプロトタイプのそれぞれを開発するために平均250時間を費やしました。システム開発者は、プロトタイプ化された各アプリケーションが運用システムを構築するために75〜225時間を費やしました。これは、プロトタイプごとに30〜90％の冗長な作業を構成します。
（注：このケーススタディは1987年に行われました。Windows領域の前とインターネット領域の前。これらの数値がまだ有効かどうかはわかりません。）
ケーススタディ＃4：設計、実装、評価の12サイクルで実行される進化的なプロトタイピング。各サイクルは約2週間続き、合計で2年間のプロジェクト期間です。その間、32,745行のコードから412モジュールが生成され、2,613時間（65人/週）の労力がかかりました。興味深い数字の1つは、12,957行のコードが作業中に破棄され、その約6分の1が最終最適化フェーズ中に破棄されたことです。
ケーススタディ＃5：1984年の学生による実験。プロトタイピング（および指定）の作業は11週間にわたって行われました。
これら5つのケースから導き出された結論：
革命的なラピッドプロトタイピングは、ユーザーの要件に関連する問題に対処するためのより効果的な方法であり、したがってソフトウェア全体の生産性が大幅に向上すると主張されています。
進化的プロトタイピングを使用してシステムパフォーマンスの問題に対処できますが、この手法が、ラピッドプロトタイピングを介したマンインザループシミュレーションと組み合わせたアーキテクチャモデリングおよびシミュレーションより優れているかどうかは不明です
インタラクティブシステムの場合、ソフトウェア要件とシステム開発のための進化的プロトタイピングと組み合わせて、ユーザー要件のための革新的なラピッドプロトタイピングの恩恵を受ける可能性があります。
最善の方法は、これらの資産がある場合とない場合のスプリントサイクルに費やされた時間と労力を調べることです。または、そうする場合、それを人々が利用できるようにする特別な理由はありません。個人的には、これを追加のアセットセットの作成と維持のコストと比較検討する必要もあります。
または、開発チームの現在の取り組み/見積もりを見て、開発コストの削減や組織に適用可能なトレーニングの取り組みにおいて、UX関連の作業を増やす可能性について推測することもできます。 UXのROIについてはすでにたくさん書かれていると思いますが、今は人々が自分の組織のコンテキストでこれをフレーミングし始める時期です。
以下のJ. Nielsenの記事ではROI、ワイヤーフレーミング、プロトタイピングについて触れていませんが、その結論はあなたの質問に当てはまります。ユーザー5人程度が、ユーザビリティの問題の約80％を発見するのに役立ちます。
今では製品開発プロセスの問題になります。プロトタイプをテストし、UXが適切になるまで繰り返し、開発リソースを書き込む前に、UXのROIを向上させます。
http://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/
編集3のフォローアップ
例によると、製品とプロジェクト管理の主要なメトリックを確認する必要があります。
数量化できる部分は「時間と材料費」です。
何かを構築するには、プロトタイプを作成する必要があります。それは極端な一端のスケッチかもしれませんし、現場で最終的な材料を操作することは他の端でしょう。
たとえば、家を建てる場合、基礎から始める必要があります。
定義されたプロトタイププロセスで：プロパティのナプキンスケッチ、プロパティの家のスケッチ。他に何も行われなかった場合でも、少なくとも財団がどこに行くべきかについてかなり良い考えがあります。
定義されたプロトタイププロセスなし：穴を掘って、基盤を構築します。ここは良い場所ですか？番号？穴を埋め、新しい穴を掘り、別の基礎を構築します。ここは良い場所ですか？
ポイントは、製品を完成させるには、このプロセスを実行する必要があるということです。そして、より高価な最終製品/材料で行われなければならないそのプロセスのより少ない、それはより安くなります。
コードコンテキストで言えば、ソリューションを1つのオプションに絞り込むためのホワイトボード上の3つのクイックワイヤフレームは、3人の開発者が実際のコードを使用して比較する3つの異なるソリューションを考え出すよりもはるかに安価です。
Nielsen Normanグループがそれを支援できるはずです。彼らのサイトをすばやく検索すると、次の記事が返されました。
http://www.nngroup.com/articles/usability-roi-declining-but-still-strong/http://www.nngroup.com/articles/when-high -cost-usability-makes-sense /
...とりわけ。プロトタイプでのテストと同様に、ユーザビリティ調査への投資の回収は測定可能な影響を与えます。両方のデータセットの組み合わせは、ラピッドプロトタイピングのROIを定量化するのに十分でしょうか、それとも機会費用データも探していますか？
（あなたの意図ではありませんが）あなたの質問は本質的に「他のものと比較してワイヤーフレーム/プロトタイピングを使用して計画することの利点は何ですか？」この質問の問題は、他の部分には計画がないことと、ワイヤーフレーム/プロトタイピングと同等のものの両方が含まれることです。このようなシナリオでは、統計的に（または財政的に）健全な比較を行う方法はありません。
つまり、xとyを比較する必要があります。つまりワイヤーフレーミングと計画なし。つまりワイヤーフレーム対フローチャート。
あなたの質問のポイントがより一般的な用語で計画の利点を尋ねることだったなら、あなたは（他のほとんどの答えが示唆するように）ワイヤーフレームをはるかに超えて見るべきです。ワイヤーフレーミングなどの特定の手法を選択したい場合は、それらを比較する代替案も定義する必要があります。
ここで言及されているすべてのコメントについて、より有効な推論を得るために話題から外れています。
建築家のナリガンジーは、オフィスやドローイングがなくても働いていたと言われています。同様に、「ビジュアルスコーピング」または「シームレスな調整」を使用してアイデアを導き、ある程度の推測でそれを剪定しました（彼が描いた可能性があります）小さなサムネイルやスケッチで触覚をつかむ）の場合、その場合、彼の製品のROI（物事を練る時間）は生きているアーティファクトと見なされ、クライアントは従来の描画方法のルートがなくても、そこに住んでいて幸せです。 （彼の方法ではオーガニックかもしれませんが、最終製品がありました）-結果！しかし、そうであってもクライアントは、何が形作られるかを知らずに常に暗闇にいます。危険な提案。
「ナリはオフィスなしで働いていて、プロジェクトの図面を作成することはほとんどありませんでした。ナリは自分のサイトで多くの時間を費やし、職人と密接に協力し、しばしば自分自身で建設プロセスに参加しました」とWikipediaから抽出されました。
これをUXの実践と重ね合わせる場合でも、私はこのアーキテクトがワーカー、職人、およびサイト自体とチームを組む方法と同じようにとどまることができます-UXガイは他のチームメンバーと協力する必要がありました。
目に見える結果が出ますが、UXでは直接コーディングを構築できますが、他の人的リソースに依存する必要があったため、これはそのアーキテクチャーの場合は非常に優れています。製品は無形であり、速度、サーバー、データベースなどの多くの複雑な要素があるためです。知識のない技術知識は、UXリードが自分で実行するのを遅くしたり、事実上不可能にしたりします。
すべて言った-ワイヤーフレーミングまたはモックアップは結果を見つける方法ですが、それ自体ではありませんa result！このルートをたどらずに、直接コーディングによってNari Gandhiの場合と同様に結果が得られる別のルートを選択することができます。
私はあなたの質問に直接的な調査ポイントはありませんが、定性的な測定では、基本的な基礎やプロトなしで費やされた時間は誰でも推測できると確かに言うでしょう-これは時間の消費（定量化可能）であり、多くのバックループやループに終わります迷路です。これほどまでに共同作業を行わない限り。
なぜこのデータを探しているのか、私はとても興味があります。
これらのアクティビティのROIはあなたが行った作業に基づいて測定されるため、ワイヤーフレーミング/プロトタイピングのROIの定量化可能な結果が見つかることはないでしょうしない =する。
単一のWebフォームまたはダイアログボックスを作成する簡単な例を見てみましょう。このフォームまたはダイアログのワイヤーフレームを作成するためのROIを測定するには、次のことを行う必要があります。
- ワイヤーフレーム/モックアップを作成する
- ワイヤーフレーム/モックアップが気に入らないと判断する
- どうしても必要ないことがわかっている場合でも、フォーム/ダイアログを実装してください。
- ＃3の開発時間と＃1にかかる時間の差を測定します。
彼らの正しい心の誰もこれをしません。実世界での経験があれば誰にとってもメリットが明白であるため、このトピックに関する研究はないでしょう。
ワイヤーフレーミングとプロトタイピングは、ソフトウェア設計プロセスの一部です。それは、物理的なオブジェクトを製造する前に図や青写真を操作することと同じです。物理オブジェクトを製造する前に、それを設計する際のROIを求める人はいません。