プロジェクトにデザイナーがいない場合、開発者はUIモックアップを行う必要がありますか？

私はプロプライエタリなWebアプリケーションを作成する小さなチームと協力しており、UXは私たち自身が操作するので優先順位は高くありませんが、仕事を楽にするよう努めています。

開発者として、新しい画面の作成を開始する前にUIモックアップを作成する必要がありますか？派手なことは何もありません。ほとんどの場合、同僚と話し合って参照モデルを作成するための一般的なレイアウトです。盲目的にコードを記述する前に、いくつかのUMLダイアグラムの作成と比較していました。

私の同僚の一人は、これは馬鹿げていると言い、それをするのは私の仕事ではありません。

私は非常に頻繁にそのようなプロジェクトに携わっており、答えは圧倒的なYESであり、できるだけ早くです。

人々は、ゼロから解決策を考え出すよりも、ドラフトの改善を批判する方がはるかに簡単だと感じています。そこで、次の2つの理由でドラフトを早期に開始します。

• 問題の専門家に、情報の提示方法に関する印象を与えます。
• 問題と情報構造の現在の理解を示してください。

まれに、同意した内容を実際に配信したことを示す証拠があると便利でした...

モックアップは素晴らしく、開発者がモックアップをしてはいけない理由はありません。（プロジェクトにUIデザイナーがいる場合でも、開発者がUIレイアウトの大まかなドラフトを作成すると便利です。）

実際の画面のように見えるモックアップを作成しないことを強くお勧めします。これらを、色やテーマのような問題ではないことに焦点を当てるエンドユーザーと共有する場合。私がお勧めすることは、紙に手書きのスケッチまたはホワイトボードのスケッチを作成することです。あなたがコンピュータの使用中のようなもの、それらをしたい場合や鉛筆プロジェクトまたはVisioを（ここでは手描きを見てジョナサンAbbettからいくつかのVisioのステンシルがあります。）

そのとおり。

他の人にあなたの仕事のやり方を教えさせないでください。そして、あなたは正しいです、それはあなたのデータモデルのためにUMLをすることに非常によく似ています。あなたが開発者であると仮定すると、あなたの仕事は高品質のソフトウェアを提供することです。モックアップがそれを助けるなら、それはあなたの仕事の一部です。

低忠実度のモックアップを行う-実際の画面のように見せないでください。フォント、ピクセル、境界線の調整に時間を浪費することになり、ユーザーは機能に集中するのではなく、そのような詳細に執着します。balsamiqのようなものがこれに最適です。他の同様のツールは間違いありません。モックアップを手に入れると、プロジェクトの機能をユーザーや開発チームの他のメンバーと簡単に議論できます。

「新しい画面」を設計するときは、最初にユーザーや同僚とUIの大まかなアイデアについて話し合いたいと思います。これを「コード内」または「UML内」のユーザーと議論することはできません。ユーザーは単に機能しません（プログラマー間でも機能しません）。そして、最初の2つまたは3つのスケッチを破棄するか、少なくともUI要素を大幅に再配置する必要があることを期待する必要があります。

そのため、これをすばやく実行できるグラフィカルUIデザインツールがある場合は、それを使用するのが理にかなっています。ただし、UI要素を手動でコーディングする必要があり、UI要素を破棄または再配置するのに多大な労力が必要な場合は、最初にUIを「コーディング」しない方が明らかに理にかなっています。グラフィカルな描画ツールを使用するか、単に鉛筆と紙を使用して、個別のモックアップを作成する方がはるかに効率的です。

必ずしも。モックアップがほとんど役に立たない理由が少なくとも2つあります。

まず、あなたがやろうとしていることを行うことに関して確立された業界慣行があれば、あなたは先に進み、まさにそれをすることができます。UIデザインの技術を推進することはありませんが、それも同様です。

第二に、エンドユーザーは多くの場合、自分にとって何が良いのか、なぜそうなのかを知りません。彼らは、プログラムの使用を開始するまで（実際のデータまたはモックデータを使用して）知ることができません。それに役立つ静的モックアップはありません。

「以前のN画面のようなちょうど別のUI画面」のための適度に柔軟なWebフレームワークを使用すると、作業中のプロトタイプから始めて、進行に合わせて再配置できます。モックアップを作成し、何か面白いことをしようとするときはいつでも同僚と話し合ってください。

常に！

私は小さな会社で働いており、唯一の「ソフト」なIT担当者です。すべての要件、設計、コーディング、テスト（誰かが私のテストを常に検証しますが）、データベース設計などを行います。

設計手順でコーナーを絶対に切らないでください-エンドユーザーは感謝します。エンドユーザーを満足させるためにやり直しをすることになりますので、あなた自身にも感謝します。モックアップが手書きの紙に過ぎない場合でも、何を期待すべきかがわかります。何かを走り書きするのに10分かかると、1週間の時間を節約できます（そこに行って、それを行いました）

また、コーディングにも役立ちます。それはあなたがする必要があること、それを達成するための最も効率的な方法、そして邪魔になるかもしれない障害について考える機会を与えます。

たとえば、テーブルxyzの日付をキャプチャしていないため、作成する必要がある「単純な」レポートは、最初に考えたよりも難しい場合があります。また、視野を広げ、チーム、上司を示したり、最低限以上のことを行ったり、「自分の仕事ではない」というボックスの外に出たりする可能性のある将来のキャリアの機会に使用することもできます（<---その男にならないでください、私たちは皆彼を嫌います）またはそれはあなたにさらなる学習の機会を与えます。

これをより一般的な方法で見てみましょう。

• 下書きを作成するのは良い考えですか？
• 誰がドラフトを作成する必要がありますか？

下書きを作成するのは良い考えですか？

ドラフトの作成には、主に2つの利点があります。まず、フォーカスが提供されるため、実行される実際の作業が高速化されます。第二に、作業が完了する前に作業の方向性を議論することが非常に簡単になります。

ドラフトを作成することのマイナス面は、時間がかかることです。作成に4時間かかるものについては、2時間かけて精巧なドラフトを作成しても意味がありません。

あなたの場合、モックアップのレベルは、プロジェクトに入る推定作業量とドラフトの利点を考慮する必要があります。これらに応じて、モックアップは、ポストイットの10秒の落書きから完全にインタラクティブなWebサイトまでのどこにでも配置できます。非常に大規模で高価なプロジェクトの場合、チーム全体がドラフトを数週間作業し、その間にドラフトのドラフトを作成することは珍しくありません。

誰がドラフトを作成する必要がありますか？

ここで詳細な回答をする必要はありません。ドラフトを作成することでメリットが得られる場合は、ドラフトを作成します。他の誰かがあなたのためにドラフトを作成して利益を得る場合は、他の誰かにあなたのためにドラフトを作成してもらいます。

あなたの同僚は絶対に正しいです。通常、内部アプリケーションの外観は事前定義されています。また、このようなアプリケーションでは、ユーザーは最先端のUIを探していません。彼らが望むのは、機能し、合理的に使いやすいものだけです。UIを根本的に変更する予定がない限り（内部アプリの場合は強くお勧めします）、既存のルックアンドフィールに従ってください。モックアップは素晴らしいですが、あなたの場合、痛みを増すだけです。