厳しい現実は、 開発プロセス全体がデザイナーの参加によって行われるべきであることを示しています 。 最適な効率を実現するには、設計者は絵を描くだけでなく、それを埋め込むこともできる必要があります！ この記事では、 デザイナーがサイトをタイプセットできる理由についていくつかの考えを共有したいと思います 。
現実的で実行可能なデザインを作成します。
最終製品がどのように実装されるかについて明確なアイデアを持って、デザイナーはより現実的で実行可能なアイデアを提供します。 デザイナーの仕事はサイト開発プロセスの不可欠な部分であるため、特にサイトの使いやすさ、表示のしやすさ、アクセシビリティを考慮して、デザインをネットワークの現実にうまく実装できるようにする必要があります。 サイトのユーザーフレンドリーなインターフェイスは、ナビゲーションの利便性と明確な論理的編成だけでなく、ユーザーに必要なすべての情報を整然とした方法で提供します。 サイトのレイアウトが正しく機能するかどうかを確認する唯一の本当の方法は、自分でそれを行う方法を学ぶことです。
コミュニケーションを簡素化
実際、一部の人々によって開発され、他の人々によって具体化された製品は、特にWebサイト、ソフトウェア、ゲームなどの無形の製品について、すべての参加者の期待に応えることができません。 通常、すべては、期待されることと実際に実行できることの間の妥協で終わります。 誰もが一般的なアイデアをキャッチしているように見えたが、正確にそれを伝えることが判明したときはめったになかった。 このための万能薬は、デザイナーがアイデアを生み出すだけでなく、実装のメリットを享受できるようにすることです。 その後、情報の混乱、誤解、歪んだ送信が排除されます。
便利な開発サイクル
実際には、完成したデザインが常に最終的な選択肢である必要はありません。 つまり、元の本質を失うことなく、システムの技術的な制限に合わせて変更および適応できるように、柔軟でなければならないということです。 このような繰り返し不可避な変更は、設計者のみが実行できます。 1人のデザイナー/開発者は、開発者がデザイナーにレイアウトを再送信する必要がある場合に比べて、必要な変更をはるかに迅速に行うことができます。 さらに、このような状況では、設計者と開発者の間で摩擦が発生する可能性があり、しばしば発生します。
より良い、より調和のとれた結果。
デザイナーが作曲家と、開発者がアンサンブルまたは指揮者のリーダーと比較されるとき、ソフトウェア、サイト、ゲーム、およびオーケストラ音楽の作成の間で類似点を描くのが好きです。 指揮者自身が作曲家だったらどうなるか想像してみてください。 これは交響曲に本当に素晴らしい音と魅力を与えると思います。 結局のところ、それは彼の技術のマスターによって書かれただけでなく、彼のクリエイターの指導の下で演奏されました！
開発時間の節約
デザイナーがサイトをタイプセットする方法を知っている場合、デザイン段階とタイプセット段階は、同時にではないにしても、次々と直接行われます。 開発に費やす時間が短縮されたことがわかりました-そして、誰が作業をより効率的にしたくないのでしょうか？
デザイナーは市場の要件を満たし始めます
今日、需要を維持するために、デザイナーはポートフォリオを絶えず拡大し、競争力を向上させる必要があります。もう1つのスキルだけでは不十分です。 多くの場合、デザイナー、ユーザーインターフェイスの開発者、コピーライター、プロジェクトマネージャーなど、すべての取引の達人でなければなりません。
設計作業を実践する方法を理解し、開発者に任せないことで、価値を高めます。 さらに、履歴書の横に示されているサイトの設計スキルとレイアウトは、誰も気にしませんでした。 それどころか、これは従業員をより人気が高く不可欠なものにします。これは、企業再編（総貯蓄）およびスタッフ削減（大量解雇）の経済的に混乱した時期に不可欠です。
ただし、このシナリオは、デザイナーがイノベーションを組版する際に欠点があります。
Lukas Mathisが「デザイナーはプログラマーではない」という題の私たちのトピックに関する物議を醸す記事に書いたように[1]：
デザイナーが独自のアイデアを実装する場合、2つの異なるタスクがあります。高品質のコードを作成し、素晴らしいユーザーインターフェイスを作成することです。 これら2つのタスクは互いに矛盾しています。 自分で設計を実装する必要がある場合は、コードの品質のために何かを放棄する必要があり、これは設計に損傷を与えます。
ウェブサイトのデザイナー自身が2つの問題を抱えています。すばらしい新しいアイデアがいつか厄介なコードに変換されるかを知ることと、既存のコードがユーザーインターフェイスの品質に影響を与える場所を知ることです。 したがって、ユーザーインターフェイスには多くの小さな詳細が含まれており、これらの小さな詳細がコードの不要な混乱につながるため、2つのタスクは互いに矛盾しています。
ここからは、ウェブ開発の純粋主義者によってなされた難しい決定が続きます。 彼らは、デザインと開発の明確な区別を主張する古い学校を支持しています。 実際、 デザイナーは人のために作成し、開発者はコンピューターのためにプログラムします 。 したがって、ユーザーの認識を重視する設計者は、最もユーザーフレンドリーなユーザーインターフェイスを作成し、開発者は最高のプログラミング決定を行う必要があります。 これは合理的な粒度ですが、ユーザーインターフェイスでの作業中にコードを抽象化しようとして失敗していることに気づきましたが、最終的には、技術的な実装と使いやすさに関連する制限を念頭に置く方が便利です。
おわりに
上記のすべてを考慮すると、開発中のプロジェクトの量によって、最終的にその中のデザイナーと開発者に割り当てられた役割を決定できます。 小規模なアプリケーションはプロジェクトマネージャーによって正常に制御できますが[2]、大規模なシステムは確実に専門の担当者が管理する必要があります。
[1]-マシス、ルーカス「 デザイナーはプログラマーではない 」。
[2]-ジョエル、スポルスキー。 「 プログラムマネージャーになる方法 」。