（G）UIはどの段階で設計する必要がありますか？
これを読みやすくするために省略記号を取り出します。
学校での大規模なグループプロジェクトでは、関係者が何を求めているかについてあいまいな説明を行いました。私は私たちに提案しました：
- GUIをスケッチする私たち全員が要求されていることを理解し、問題を見つけ、お互いに質問し、一般的に明確にするために、私たち全員が同じことを考えます
- ユースケースを作る
- フィードバックのためにすべてを関係者に提示する
- それから要件を導き出す
- リストに関するフィードバックを得る
- バックログを作成する
- およびthenについて説明します＆pickツール、言語、フレームワーク、標準など.
1〜2人のメンバーが私に同意し、大多数が反対票を投じました。大多数が望んでいること：
- いくつかの種類のツールの機能について話し合う
- 次にユースケースを作成します
- 次に、要件を導き出します
- その後、バックログ
- その後GUIデザイン
私が最初にデザインを、最後にツールを必要とすることを除いて、ほとんど同じことですが、彼らは最初にツールを、最後にデザインを望んでいます。また、私は彼らが望むよりも多くのフィードバックが欲しいです（私は彼らにこれを主張することができると思いますが、主な問題はGUIとツールの選択です）。
彼らは私の論理的根拠に納得していませんでした（最初に問題を見つけてから解決策を選びます）、私は彼らの論理的根拠に納得しませんでした（作業方法を選択しないと問題を見つけることができず、最初に全体的なバックエンド機能/ APIを定義しないと設計方法を知ることができません。あるツールを使う準備に時間を浪費し、それがまったく必要ないことに気付くと思いますが、読んだり準備したりするのに時間を費やしていない何かが必要ですが、私にはわかりません。私は経験不足から何かが欠けています。
これを行う正しい方法は何ですか、そしてその理由は何ですか？
実際のビジネスの観点から、ツールはやることリストの後ろにあります。私はあなたの提案されたリストに同意しますが、いくつかのことを少し移動します：
機能要件。 RAMソフトウェアが必要とする量については話していませんが、実行が期待されるものです。要件を間違えると、ハードワークがウィンドウの外に片手で投げ出される可能性があります。 ...ええと、誰も欲しくないものを作るかもしれません。そして、現実の世界では誰もそのためにお金を払うつもりはありません。要件をまっすぐにしてください。また、利害関係者に実際にやりたいことの例を挙げてもらう必要があります。これは、「ユースケース」を作成するための良い出発点になります。
タスク＃1で学習した内容に基づいて、ユースケースを作成します-顧客が望むものを個別のシナリオに分解します。それらは長くする必要はありません。たとえば、ログイン、アバターのアップロード、ショッピングカートの保存、コメントの残しなど、顧客がやりたいことを単純なリスト（またはリストのリスト）にすることができます。 ..
これで、＃2に基づいて、大まかなGUIスケッチを作成できます。
利害関係者と会い、ユースケースとGUIスケッチに関するフィードバックを入手します。変更を加え、必要に応じて再会します。
初期機能に同意したら、それを提供できるツールの選択を開始します。誰かが本当にクールなAIフレームワークを使いたいと思うかもしれませんが、プロジェクトが単純なショッピングWebサイトである場合は、おそらくそれは必要ありません。
このリストは単なる提案です。教室でもオフィスでも、仲間の学生と議論に基づいた話し合いをすることは、プロセスの非常に重要な部分です。
最も重要なことは、余裕がある限り何も決めないことです。
開発の過程で2、3回変更する意思があり、能力がある限り、最初に何をしてもかまいません。それは反復的なプロセスであると思われます。決定がより重要であるほど、最終決定を下すまでの待ち時間が長くなります。あなたは最終的にそれが正しいものになりたいからです。
したがって、直感に基づいてツールを選択し、プロトタイピングを開始できます。設計ドキュメントの作成を開始できます。データベーススキーマを作成できます。解決しようとしている問題をしっかりと理解するまで、他の部分の選択を制限するものはありません。
徐々にいくつかの部分が所定の位置に収まるはずです。
現在の状況を理解する前に、任意の部分をコンクリートに注ぐことは失敗のレシピです。
これが学校向けの大規模なグループプロジェクトであると言う場合、10人以上の生徒が一緒に取り組むことになっている課題を意味していると思います。その場合：
共同作業の方法を学ぶことが重要です。
商用ソフトウェアの成功は、Atariビデオゲームの時代と初期のApple IIオフィスツール。今日のソフトウェアプロジェクトは共同作業です。（最新のビデオのクレジットを読む）以来、個人の努力の結果ではありません。信じられない場合はゲーム。）学生が初めて大規模なコラボレーションを行うように求められる学術課題では、多くの場合、1人がすべての作業を行い、他のすべての人が不平を言うことになります。失敗の結果を考慮する必要があります。 。
このプロジェクトの成功の結果は、チームの全員が関与して生産的になることであり、結果として得られる作業成果物は、誰もが自分で達成できるよりも優れています。
あなたは彼らの作業計画が間違っていてあなたの計画が正しいことを「大多数の大多数」に納得させようとすることによってそこに到達するつもりはありません。むしろ、チーム全体が理解する必要のあることがたくさんあり、そのうちのいくつかは相互に依存しており、インストラクターは意図的に完全な情報を事前に提供していないことを認識する必要があります。
特にタイトルのGUIの質問について：多くの人々（ビジネス関係者を含む）は、（抽象的なではなく）視覚的な参照のコンテキストで要件と機能についてより快適に議論できるため、可能なGUIのスケッチを早期に作成しておくと役立ちます。 ）。しかし、それらの議論では、基礎となるGUIのメタファーが間違っているか、ユーザーがデスクトップWebアプリではなく電話アプリ（またはその逆）のほうが適しているか、または他のいくつかの初期の動作仮定がベースから外れていることがわかります。初期のスケッチと完成したデザインを混同しないでください。
何から始めても（GUI、ツール、機能要件など）、最初のステップは暫定的なものです。それらは、チームメンバーがお互いに、そして利害関係者に売り込んでいるアイデアです。最終的な解決策は、おそらくそれらのいくつかと、まだ考えていない他のものの組み合わせになるでしょう。