プロジェクトにデザイナーがいない場合、開発者はUIモックアップを行う必要がありますか？
私はプロプライエタリなWebアプリケーションを作成する小さなチームと協力しており、UXは私たち自身がそれを操作する人になるのでそれほど優先度は高くありませんが、私たちは彼らの仕事をより簡単にするよう努めています。
新しい画面の作成を開始する前に、開発者としてUIモックアップを作成する必要がありますか？派手すぎず、同僚と話したり、参照モデルを作成したりするための一般的なレイアウト。コードを盲目的に書く前に、それをいくつかのUMLダイアグラムの作成と比較していました。
私の同僚の1人は、これは途方もないことであり、それを行うのは私の仕事ではないと言います。
私は非常に頻繁にそのようなプロジェクトで働いており、その答えはかなりのYESであり、できるだけ早くです。
人々はそれがはるかに簡単です 批判する ゼロからソリューションを作成するよりも、いくつかのドラフトを改善します。だから私は二つの理由で早めにドラフトを始める：
- 情報の提示方法について、問題の専門家に印象を与えます。
- 問題と情報構造に関する私の現在の理解を示してください。
まれに、私が同意したことを実際に提供したという証拠があることもいいことでした...
モックアップは素晴らしく、開発者がモックアップを行うべきではない理由はありません。 （プロジェクトにUIデザイナーがいる場合でも、開発者がUIレイアウトの大まかなドラフトを作成するのに便利です。）
実際の画面のように見えるモックアップを作成しないことを強くお勧めします。これらをエンドユーザーと共有する場合、エンドユーザーは、色やテーマなど、重要ではないことに集中することがよくあります。私がお勧めすることは、紙に手書きのスケッチまたはホワイトボードのスケッチを作成することです。または、コンピューターでそれらを使用する場合は Pencil Project またはVisio（ here は、手書きのように見えるJonathan AbbettのVisioステンシルです）のようなものを使用します。
そのとおり。
他の人にあなたの仕事のやり方を言わせないでください。そして、あなたの言うとおり、データモデルに対してUMLを行うのと非常によく似ています。あなたが開発者であると仮定すると、あなたの仕事は高品質のソフトウェアを提供することです。モックアップがそれを助けるなら、それはあなたの仕事の一部です。
忠実度の低いモックアップを実行します。実際の画面のように見せないでください。フォントやピクセル、境界線の調整に時間をかけすぎると、ユーザーは機能に集中するのではなく、そのような細部にこだわります。 balsamiqのようなものがこれに最適です。間違いなく他の同様のツールがあります。モックアップを用意すると、プロジェクトの機能をユーザーや開発チームの他のメンバーと話し合うのがはるかに簡単になります。
「新しい画面」を設計するときは、最初にユーザーや同僚とUIの大まかなアイデアについて話し合う必要があります。これを「コード内」または「UML内」のユーザーと話し合うことはできません。これは単に機能しないだけです（プログラマー間では機能しません）。また、最初の2つまたは3つのスケッチを破棄するか、少なくともUI要素を大幅に再配置する必要があることを期待する必要があります。
したがって、これをすばやく実行できるグラフィカルUI設計ツールがある場合は、それを使用するのが理にかなっています。ただし、UI要素を手動でコーディングする必要があり、UI要素を破棄または再配置するのに多大な労力が必要な場合は、最初にUIを「コーディング」しない方が当然のことです。グラフィカルな描画ツールを使用するか、単純に鉛筆と紙を使用して、個別のモックアップを作成する方がはるかに効率的です。
必ずしも。モックアップがほとんど役に立たない理由は少なくとも2つあります。
まず、これからやろうとしていることを行うことに関して確立された業界慣行がある場合、先に進んでそれを正確に行うことができます。 UIデザインの技術を推進することはありませんが、それも同様です。
第2に、エンドユーザーは、自分にとって何が良いのか、なぜそうなのかを知らないことがよくあります。彼らは、プログラムを（実際のデータまたはモックデータと共に）使い始めるまで、そのことを知ることができません。静的モックアップの量はそれを助けることはありません。
適度に柔軟なWebフレームワークを使用すると、「前のN画面のような別のUI画面」の場合、作業中のプロトタイプから開始して、移動しながら再配置できます。気の利いたことをするときはいつでもモックアップをして、同僚と話し合ってください。
常に！
私は小さな会社で働いており、私は唯一の「ソフト」IT担当者です。私はすべての要件、設計、コーディング、テスト（誰かが常に私のテストを検証しますが）、データベース設計などを行います。
設計段階でコーナーをカットしないでください-エンドユーザーに感謝します。 [〜＃〜] will [〜＃〜]エンドユーザーを満足させるためにやり直すことになるので、自分にも感謝します。モックアップが手書きの紙にすぎない場合でも、何を期待するかがわかります。何かを落書きするのに10分かかると、1週間の時間を節約できます（そこにいて、それを完了しました）
コーディングにも役立ちます。これにより、実行する必要があること、それを達成するための最も効率的な方法、および邪魔になる可能性のある障害について考える機会が得られます。
たとえば、テーブルxyzで日付をキャプチャしていないため、作成する必要がある「単純な」レポートが最初に考えたよりも難しい場合があります。また、視野を広げ、チームや上司を示したり、最低限以上のことをしたり、「それは私の仕事ではない」という枠から外れたりする可能性のある将来のキャリアの機会に使用することもできます（<---真剣に、その人にならないでください、私たちは皆彼を憎んでいます）またはそれはあなたにさらなる学習の機会を与えます。
これをより一般的な方法で見てみましょう。
- 下書きを作成することは良い考えですか？
- 誰が下書きを作成する必要がありますか？
下書きを作成することは良い考えですか？
下書きを作成すると、主に2つの利点があります。まず、フォーカスが提供されるため、実際の作業が高速化されます。第二に、作業が完了する前に作業の方向性を議論することが非常に簡単になります。
ドラフトを作成することの欠点は、時間がかかることです。作成に4時間かかる何かのために精巧なドラフトを2時間かけて作成するのはほとんど意味がありません。
あなたのケースでは、モックアップのレベルは、プロジェクトに入る作業の推定量とドラフトの利点を考慮する必要があります。これらに応じて、モックアップは、ポストイットの10秒の落書きと完全にインタラクティブなWebサイトの間にある可能性があります。非常に大規模で高額なプロジェクトの場合、チーム全体が数週間ドラフトに取り組み、その間にドラフトのドラフトを作成することは珍しくありません。
誰が下書きを作成する必要がありますか？
ここで手の込んだ答えは必要ありません。ドラフトを作成するメリットがある場合は、ドラフトを作成します。誰かがあなたのためにドラフトを作成することから利益を得る場合は、誰かにあなたのためにドラフトを作成するよう依頼してください。