設計プロセスを決定するためのリソース/アドバイス？
私は、Webアプリを設計しているときにどちらが最適なプロセスであるかについて、仲間と議論を重ねてきました。私たちの開発フェーズはうまく機能していますが、設計/要件収集フェーズには変更の余地があると思います。
要件収集のフェーズ、次にワイヤーフレーミングのフェーズ、そしてグラフィックデザインと同時に開発するフェーズがあるべきだと思います。すぐに開発を始めるべきだと言う人もいます。
あるプロセスを別のプロセスで使用する理由を説明できるリソースや研究はありますか？初めに追加のフェーズが長期的に私たちを助ける理由を他の人に納得させるのに苦労しています。
すぐに開発を始めるのは大変なことです。私は一度やったことがあり、真剣に後悔しています。
そのアプローチIMOの主な問題は、組織がプログラミングリソースのコミットをすぐに開始し、後で必要なUI調整を行うことに非常に消極的になることです。これは、ソフトウェアが「十分に」機能するためです。
場合によっては、ページのレイアウトの調整やワークフローの改善など、UIの調整がわずかです。ただし、場合によっては、必要なUIの変更が広範囲に及ぶため、すでに配置されているほとんどのUIを破棄する必要があります。
1つの例は、元に戻す/やり直しのサポートの追加です。この機能を事後に追加することは非常に困難です。元に戻す操作についてユーザーに視覚的なフィードバックを提供できる必要があります。対話の一部がダイアログ内またはメニューを介して行われ、これらの対話に影響する変更が画面に表示されない場合、元に戻すには、UIの適切な部分をスクラップする必要があります。
UIを最初に設計する必要があるのは、次の2つの理由だけです。
それはお金を節約します。 UIを最初に理解させないことは、一部の作業が2回行われることをほぼ保証します。少なくとも。
これにより、関係者はプロジェクトの範囲を理解する必要があり、UI設計を事前に承認する必要があります。これは、機能を要求するときに関係者に拘束力を行使することを奨励することにより、 featuritisを回避する に役立ちます。
これがお役に立てば幸いです。
私が仕事をしている大規模なプロジェクトで一般的に使用しているものは効果があるようです（ただし、より広範なITプロジェクトよりもWebショップで使用されています）。まず、ニーズ分析と要件収集から始めます。
高レベルの要件のサインオフされたドラフトを通過するとき（私はUX/PMの担当者です）、通常、アプリが何をしなければならないかに焦点を当てた要件がありますが、完了するのに最適なリソースではありません技術要件なので、私はそれを開発コードに渡します。開発リードは、疑似コードなどの詳細な技術要件を行います。
それらが行われている間、私はワイヤーフレームと相互作用の仕様の最初のカットを行います。詳細なモックアップなしで関係者からフィードバックを得ることができるので、この段階でより多くのlo-fiプロトタイピングを始めています。また、自分のワイヤーフレームに戻って、lo-fiプロトタイプに基づいて調整を行うこともできます。ワイヤーフレームが完成したら、通常は詳細な技術設計が順調に進んでおり、相互作用部分も完成させることができます。
この時点でのみ、通常は時間をビジュアルコンプに投入し、それが承認された後にのみ、忠実度の高いプロトタイプを作成します。良いことは、この時までに、繰り返しのフィードバックがいくつかあり、微調整が行われ、最終的にサインオフが完了することです。
忠実度の高いプロトタイプは、最終的なアプリがどのように機能するかをかなり正確に表したものであるため、アプリ全体の構築は比較的短いフェーズです。もちろん、潜在的にアルファ版、ベータ版、製品版のテストと調整サイクルが必要なので、...
お役に立てれば。
あなたもリソースを求めたので…これが私が読むことをお勧めするリソースです：という本はどのようにデザインしますか？多分あなたのニーズに対してそれは少し一般的すぎると思うかもしれませんが、私は自分で良いデザイン/開発プロセスを検索したときにそれが役に立つと思いました。
これは、非常に一般的なものから始めて、多くの設計プロセスの短い説明（主に視覚化）を提供します。ソフトウェアの設計と開発に固有の設計プロセス（Webアプリケーションの設計に完全に適用可能）は2番目の部分を占めますが、最初の部分もチェックすることをお勧めします。
http://www.dubberly.com/articles/how-do-you-design.html
（この本は2005年から「ベータ版」のようで、おそらく完成しないかもしれません...または、何かが足りなくてすでに出版されているかもしれません。とにかく、PDFは無料でダウンロードできます。）
あなたが明示的に研究を求めるので（それのために+1！）：
プロセス全体についての決定的な研究は見つかりませんでした（たとえば、「設計に費やされたプロジェクトリソースの27％が最適です」と言っています）。
ただし、 Code Complete は、しっかりとした設計フェーズをサポートする多くの研究を引用しています。それはデスクトップ開発から来ていますが、研究は幅広いプロジェクトから取得され、ウェブ開発に適用されます。
攻撃の主なラインは、プロジェクトコストのエラーです：設計フェーズ中に行われたエラーは、特に遅れて検出された場合、最もコストがかかります。
（そして、いいえ、設計段階がないことは、設計エラーを発生させることができないという意味ではありません。それは残念ですよね？）
これはあなたの質問のいくつかに答えるはずです。
単に個人的な経験に基づいています...あなたは最初から本格的な開発を始めたくありません。また、ワイヤーフレームが完成するまで、設計や開発を待つ必要もありません。重要なのは、すべてが並行して協調して動く必要があるということです。
その上、たくさんの依存関係があります...特定の開発環境、アジャイルvsウォーターフォール、プロジェクトの複雑さなど。