ワイヤーフレームのオーバープランニングはありますか？

Question

37 Signalの Getting Real により、機能仕様ドキュメントのワイヤフレーム化と記述は、Webアプリケーションや動的なWebサイトの構築に不要な仲介者のステップであると確信しました。

これらのステップのオーバーヘッドは重要ですか？ HTML / CSSまたはPhotoShopドキュメント（デザイナーが直接作業できるようにする）でのプロトタイピングは、Visioなどのソフトウェアを使用するよりも優れたオプションですか？個人的には、後者に向かって動いていますが、確信はありません。

Answer 1

＆quot;計画の失敗は失敗の計画です＆quot; -またはそのようなもの。

ワイヤーフレームはWebアプリに限定されません。あらゆるシステムの高レベルの概要が必要な場合はいつでも広く使用されます（単に他のシステムと呼ばれます）。

何をすべきかがわかっているときの機能仕様＆amp;どうやってそれをやるのは本当にやり過ぎだ。意図の概要図で十分です。そして、それは不要になることはありません 。主に、あなたがやりたいことの範囲と意図/目標に集中するのに役立ちます。

無駄な努力を防ぐことに焦点を当てる必要があります-他のすべてのオブジェクトに影響を与える重要な何かが欠落していることを途中で見つけることは、あなたが発見したいものではありません。この場合のワイヤーフレームは、ほとんどの主要な機能的ニーズの検出に役立ちます。絶対に必要な場合にのみ、機能仕様について詳しく説明する必要があります。 Photoshopを使用してデザインすることも「無駄な努力」です。 -進化的プロトタイピング（RADテクニック）をCSS / HTMLで使用する方がはるかに優れています-ただし、ペンとあなたの意図の紙のモックアップ。

Answer 2

37Signalsは、PhotoshopをスキップしてHTMLに移行することを提唱しています。 http://www.37signals.com/svn/postsをご覧ください。 / 1061-why-we-skip-photoshop 。事前計画の評価に同意します。長い目で見れば、HTML / CSS / JSで実用的なプロトタイプを作成するのに時間を費やすことができるとは思えません。

Answer 3

実際には、「理想」を探したくない物事を行う方法。代わりに、明確で具体的な目的のために理解したことを使用してください。

モックアップを使用すると、膨大な時間と労力を節約できます。作成と保守に費やす余分な時間になる可能性があるため。

実生活の例＃1：モックアップは1日を節約しました。政府にとって大きなシステムであり、期限はばかげています。

理由：あらゆる種類のアーキテクチャドキュメントを作成するのに月が経ちましたが、HWとSWの両方のアーキテクチャが非常に詳細に固定されており、実際にはすでに存在しているため、実際にはまったく不要です。

解決策：顧客と一緒にモックアップを作成し、開発者にメモを添えて画面を渡すまで、20日間の半日を費やしました。開発者はいくつかの明確化を要求する必要がありましたが、アーキテクチャが修正され、要件が明確で視覚化されていたため、必要な機能をすぐに開発することができました。

実際の例＃2：モックアップはその日台無しになりました。 「認識」された大きな政府システムモックアップの必要性。

これは、世界で最高のものを悪夢に変える人間（または企業？）の能力を示しています。

大規模な政府機関は、大規模なコンサルタント会社に、問題を解決するために大規模なIT会社を率いるように依頼しました。政府機関は、プロセスを支援し、スピードアップするために、政府の主題専門家の大きなアドホック機関を設立しました。

月は大きな言葉で、使用する適切な方法論とそれらを使用する適切な方法を決定しました。もちろん、あらゆる種類の妥協は、誰かの感情や重要性を傷つけないために行われました。

結果：Swアーキテクチャは、モックアップを含むすべてのソースとなりました。どちらが最初に設計され、2番目に描かれるべきか。 OOADとシーケンス図からのアクションのマッピング、UX図の作成、UI論理オブジェクトとコンテンツバンドルの認識、実際の画面の描画と正式なユースケースへの組み込み、UCは1か月に1回の公式ワークショップでユーザーに提示され、これらのワークショップは、誰かが時間をすり抜けていると考えたため、要件を受け入れる会議として2倍になりました。

これらのワークショップでは、それぞれ約30ページの長さのUCを強制的に理解することはできませんでした（非常に形式的で、データ属性などを説明するテーブルが多数あります）。顧客からフィードバックがあったときは、モックアップについてでした。しかし、モックアップを変更すると、シーケンス図、コンポーネント図、操作モデル、UX図、トレーサビリティマトリックスのチェック、UCテキストの更新などが変更されるため、フィードバックは推奨されません。 （「顧客を気にせず、彼らは決して満足しません。」がモトでした）。機能が制限されたv1.0の公開後、ドキュメントを気にする人はいなくなり、その多くがドキュメントになりました。開発者は、システムを立ち上げて稼働させるために、毎日無数の小さな変更を行い、自分の人生のために戦っていました（昨日の変更の後、何か他のものが壊れた後）。

これは、モックアップを使用する方法ではありません。プロジェクトは計画よりも約2年長く続きました。

つまり、理想的な方法論を探してはいけません。または、あなたが理解していない方法論。現時点での目標は何ですか？その目標を達成するためにあなたが知っている最速の方法は何ですか（他の方法は考慮しません）？頑張れ。

Answer 4

それはおそらくあなたが誰と働いているかによるでしょう。あなたとデザイナーの場合、機能仕様はあまりにも面倒かもしれません。しかし、私の仕事では、経営陣はプロジェクトの最後に何を取得するかを正確に知りたいので、反復開発を実装するのは本当に大変でした。通常、反復はワイヤーフレーム、機能仕様、およびモックアップで定義されます。.：）

Answer 5

ワイヤーフレームを行う主な目的は、要件を明確にすることです。 要件を明確に文書化することは常に推奨され、要件を視覚化するよりも良い方法はありません。ワイヤフレームはここで非常に役立ちます。製品所有者（クライアント）に、最終製品に何を期待するかについて明確なアイデアを提供します。また、製品の所有者から承認されると、開発チームに開発対象を明確に伝えることができるため、開発時間を大幅に節約し、競合を回避できます。 私の意見では、プロジェクトが小さい場合でも、ワイヤーフレームはプロジェクトの円滑な実行に常に役立ちます。

Answer 6

自分が何をしようとしているかをどれだけよく理解しているかにかかっていると思います。あなたがクライアントのために働いていて、彼らが要件の方法であまり表明していないなら、あなたは非常に速い反復でアプローチを望むかもしれません。すでに十分な理解があり、間違った方向であったために捨てることを心配することなく、より実質的なものを作成できる場合、より多くの時間が費やされます。いずれにせよ、クリック可能なプロトタイプは、実際のサイトが最終的に必要なものを判断するのに大いに役立ちます。プロトタイプについて合意が得られれば、アプリケーションがプロトタイプと一致すれば、完成したことがわかります。