Webデザインのモックアップ仕様をフロントエンド開発者に伝える方法は？
スライスのためにWebサイトの設計仕様をフロントエンドの開発者に伝えるためのベストプラクティスを探しています。
開発者がデザインの視覚的表現よりも多くの情報を必要とすることを知っているので、コミュニケーションの便利な方法を探しています詳細なデザイン仕様のさまざまな要素間のピクセルやパディングなど、グラフィックモックアップの=それらをHTMLとCSSに効果的に分割できるように設計します。 Adobe Illustrator CS5を使用して、グラフィックモックアップを作成しています。私たちはフロントエンドの開発者と協力関係にあります。
質問：Webデザインの仕様を開発者に明確に伝えてWeb上で実行できるようにするための良い方法やベストプラクティスは何ですか？
フロントエンドエンジニアが使用しているツールでフロントエンドを構築するのが最善の方法だと私は思いました。私たちの場合、それはAngular Materialです。
したがって、Angular Material（私が学んだときに学んだ））を使用して、ほとんどのアプリケーションを構成するさまざまな要素（リスト、ボタン、フォーム要素、テーブルなど）を示すスタイルガイドを作成しました。私は既製のAngular Material要素をできるだけ使用して、ブランディングや特定の用途に対応するために最小限のオーバーライドを行いました。フロントエンドチームは、HTMLとCSSをコピーすることをお勧めします。たとえば、テーブルのように何かを使います。たとえば、それには使いやすさの理由があります。それは、テーブルの外観を概算するために多数のdivを使用して構築する必要はありません。
現在、私は一般に、正式なプレゼンテーションまたはダーティなユーザーテストで利害関係者に機能を「販売」するために高解像度のコンプが必要であり、その後、フロントエンドエンジニアのために低解像度のワイヤーフレームで機能とさまざまな状態を詳しく説明します。
要素にわずかな変更が必要な場合や、スタイルガイドに含める必要のないまったく新しい1回限りの要素がある場合は、フロントエンドチームで高解像度のコンプを行うこともあります。これは、フロントエンドチームがスタイルガイド要素を結合する方法（間隔が少なすぎる/多すぎる）を取得できない場合や、追加の要素（線、設定する異なる背景）がある場合があるため、いくつかの要素がどのように結合するかを示すのにも役立ちます別のものなど）。必要。
新しいアプリケーションや複雑な機能の場合は、トランジションやアニメーションを伝えるために高解像度のHTMLプロトタイプを実行することもあります（ハッピーパスのみ）。実際のユーザーテストの時間を取得した場合（すべてがまれです！）、ハッピーパスHTMLプロトタイプも作成します。エンジニアリングチームはこれが非常に役立つと感じており、すべてのプロトタイプを作成してほしいと思っています。
個人的には、私は Balsamiq が大好きです。情報とやり取りに焦点を当てることができ、不必要な詳細にはならないからです。これは、受け渡されて合意が必要な機能設計に適したレベルです。
ただし、これは詳細な特定のレイアウトに変換する必要があります。これは実際の開発者が行うのが最善であり、ビジュアルデザインに特化した担当者によるアジャイルレビューサイクルを使用することもできます。実際のコードから抽象的なピクセルレベルのデザインを前もって抽象的に作成することでうまく機能するのを見たことはありません。作業が多すぎて、十分な効果が得られません。基本的な実装を行うプログラマーの隣にビジュアルデザイナーを配置し、REALデータを含めて、視覚的に魅力的なものになるまで詳細レイアウトを微調整することをお勧めします。
言われていることのすべては、プロジェクトの初期にAdobeを使用してサンプルレイアウトを作成するビジュアルデザイナーと協力してきました。これらは一般的なアイデアを得るのに役立ちますが、異なる要件間の詳細な相互作用について十分に理解できないため、詳細な作業には役立ちません。私たちは常にそれらを捨て、ビジュアルデザイナーをコードに直接関与させます。
詳細はブログの投稿 Iガイドラインリソース をご覧ください。
最近のプロジェクトでの経験を考慮して、設計/開発フレームワークを採用または作成することが、フロントエンド開発者と設計仕様を伝達する最も効率的かつ効果的な方法であると考えています。
bootstrap関連する開発フレームワークの人気と、Google Material Design関連の開発フレームワークの出現は、これらのアプローチがデザイナーや開発者にとって多くのコミュニケーション問題を解決し始めていることを示しています。
最良の方法は、PSDファイルに設計仕様で注釈を付けることです。これには2つの利点があります。1つ目は、設計者が設計がどのように見えるかを正確に確認できること、2つ目は、CSSに設計仕様に直接注釈を付けることができる（または設計者と開発者にとって最も便利な方法で）。次に、ファイルをより小さなサイズの画像にエクスポートしてスタイルガイドに貼り付けるだけで、現在または後でプロジェクトに取り組んでいる他のデザイナーや開発者が参照できます。
ベストプラクティスは、フロントエンドを構築することです。 UXチームは、成果物の一部としてプレゼンテーション層を提供できる必要があります。インタラクティブデザインは本質的にインタラクティブであるため、静的ドキュメントで簡単に完全に注釈を付けることはできません。
確かに、スタッフ、企業の政治、または予算のために、それが常に実行できるとは限りません。したがって、それを除けば、いくつかの作業が必要になります。 1つのオプションは、さまざまな量のドキュメントです。しかし、それはあるタイプのドキュメント（PSDまたはワイヤーフレーム）を別のドキュメントセット（HTML、CSS、JS）に変換する以外に何の役にも立たないドキュメントであり、結局、通常はとにかく捨てられます。
そのため、ドキュメントの余分なレイヤー全体をスキップすることをお勧めします。 UXチームにフロントエンド開発チームと緊密に連携してもらいます。毎日のスタンドアップはこれを処理するための素晴らしい方法です。開発者はプリミティブから作業を進めることができ、インタラクションと視覚的な詳細が洗練されているため、UXチームは必要に応じて微調整や提案を行うことができます。
私はあなたが言うように私自身をウェブデザイナー/フロントエンドデザイナー、あるいは多分フロントエンド開発者と考えていますか？ （私の作業がphotoshop、css、html、js/jqueryの間で行われる時間の基本的に90％）
イラストレーターを使用してWebレイアウトを送ったことがないので、ピクセル単位の正確なパディング/マージンを説明することはそれほど難しいことではありませんでした。他の誰かがcssを実行しているときにデザインに取り組んだ過去、私は通常psdを自分でスライスし、画像を1つずつ開発者に渡し、どこに行くべきか、高さ、幅、およびその他の仕様を説明しましたあなたの典型的なCSSより少し凝ったものであるなら、それを実装するためのある種の戦略が必要でした。
とはいえ、これが異例のケースだという印象を受けました。2人の会社ではなく、より大きな組織の場合は、スキルセットが重複しているため、作業を分割するのではなく、自分でコーディングしていました。
ホバー状態などの操作に関する限り、注釈を付けるか、開発者に個別に説明する必要があります。 psdを渡す場合は少なくとも、ホバー状態と明確にラベル付けされた別のレイヤーを用意しますが、自分で画像をスライスして画像Spriteを渡す場合は、何をすべきかは明らかです。
標準的なプロセスは1つではないようです。各組織は、オフィスの人々のスキルセットに基づいて、少し異なる方法で仕事を分割すると思います。
余談ですが、illustratorを使用してWebサイトをモックアップするメリットはありますか？
フロントエンド開発者が「スライス」、つまりhtml/cssへの変換を行う場合（最新の開発者ワークフローでは決して実行されない古いスライスと混同しないように、場合によっては）、. psdが必要になります。ファイル。そこから、組み込みのツールを使用してすべてを測定します。デザインについては、svgファイルとしてエクスポートする必要があるベクトル形状が必要でない限り、PhotoshopはIllustratorよりも優れたツールです。
彼らに必要なのは、彼らがプロジェクトに使用するフレームワークを尋ねることです。
例：彼らがbootstrap（99％を使用）を使用する場合）、それを考慮する必要があります
コンテナは左右に15pxのパディングを持っています行は左右に-15pxのマージンを持っていますcol- *は左右に15pxのパディングを持っています
つまり、コンテンツは左から15pxで始まり、text1とtext2の間に30pxの距離があります...
あなたがこの措置に従えば、フロントエンドの開発者はあなたを愛するでしょう:)彼らはフレームワークに逆らう必要がないので
彼らがずっと習慣になっているなら、彼らが本当に速いサイトを必要とするなら良い習慣、彼らはあなたの創造性を解き放ちます:)
...
ライブスタイルガイドが最善のアプローチですが、グリッドシステムを考慮せずに設計した場合、開発者は常にピクセルの完成度を競い合うため、特に問題はありません。同じことが最初にデスクトップを設計し、次にモバイルを設計した場合にも当てはまります。広告開発は最初にモバイルで行われます。
最善のアプローチは、開発者と話し合い、参照として何を望んでいるかを確認し、プロジェクトを手放すのではなく、常にオープンにしておくことです。