投稿では、新しいものではなく、常に関連するトピック、つまりデザイナーとフロントエンド開発者の関係を分析します。 この記事は、作業プロセスがまだ構築されていない初心者およびチームに役立ちます。 人生のいくつかの例を考えて、意見の相違を避ける方法を見つけてください。
確かにHabrのほとんどの読者はそのような状況に直面していました。
1.不明な用語
レイアウトコメントの代わりに、開発者が理解できない用語を受け取ったか、デザイナーがレイアウト用語を理解していません。 これは、誰もが自分の分野の製品を検討しているという事実によるものです。 したがって、一般的な用語集を使用する必要があります。
たとえば、デザインにはリーディングという概念があり、文字通り「行間」を意味します。 レイアウトのアナログは行の高さです。
これは興味深い質問を招きます-デザイナーはコードを理解する必要があり、開発者はデザインの原則を理解する必要がありますか？ 「デザイナーと開発者が協力する理由」の記事で、著者はこれについてアドバイスしています。 ギャップを埋めるために、開発者とデザイナーは同じ言語を話し、可能であればスキルセットを拡張する必要があります。
設計者と開発者の両方が基本的な知識を持っている必要があります。
- 色やフォントなどの設計の基本
- 最適なグラフィック形式とキャリブレーション
- HTMLとCSS
- 設計および開発動向
- ユーザーのニーズと欲求
- グリッド、フレーム、およびワイヤーフレーム
現実には、すべてが完璧ではないため、レイアウトを学びたくない場合やデザイナーを非難したり、開発者が自分のやり方でインターフェイスを見ていると非難したりしないでください。
ヒント。 同僚にいくつかのポイントをより詳細に説明してください。おそらく、彼はこの分野の知識をさらに発展させたいと思うでしょう。
2.することは不可能です
そのため、開発者はデザイナーに答えることができ、これには多くの理由があります：システムの制限、リリースの近接性、人の負荷。 しかし、設計者はこれらの技術的ポイントを常に完全に理解しているわけではなく、単にこれを行いたくないと考えるかもしれません。
ヒント。 なぜできないのかを尋ねる/説明する-簡単に言うと、「指で」、少し後でやってみる、または初期バージョンをもっと簡単にする。
3.レイアウトを変更しました
設計者は、さまざまな理由でレイアウト内の何かを変更できます。調査、システムの変更、アプリケーションプロセスの変更です。 ここで類似点はこれです-私たちはすべて明確に定義されたタスクを必要とします。 誰かがどこかで何かを変更し、誰にも話していない場合、誰もそれを知りません。 微小な変化に同意することは非常に重要です-これはまったく難しいことではありません。
ヒント。 レイアウトを変更してタグを作成し、優先順位を付けるようにデザイナーに依頼します。 これは視覚的な方向付けに便利なソリューションです。 以前は、多くの場合、レイアウトとuiクジラのバージョンで共有フォルダーを作成していました。 現在、そのような変更はzeplinでよく認識されています 。
4.これはレイアウトに含まれていなかったので、自分で思いついた
要素の状態が示されていない場合、またはレイアウトでプロセスの機能が考慮されていない場合は、デザイナーに対しては行わないでください。 誰もが何かを忘れたり、考えたりすることはできません。私たちは皆人間です。 いずれにせよ、誰もが自分の仕事をする必要があります。
これはかなり物議を醸すケースであり、私の友人のデザイナーのほとんどはそれに満足していませんでした。 しかし、 反対意見があります。
5.レイアウトがレイアウトと一致しません
これはすべての設計者にとって苦痛なので、設計レビューを必ず行ってください（それなしでは、設計作業は完了したとは見なされません）。 設計者はすべてのピクセルに気付き、いくつかのささいなことや間違いを修正するのに役立ちます。 ただし、確認後、レイアウト全体をやり直す必要がある場合があります。 これを回避するには、 Perfect Pixelなどのツールを使用してチェックします。
それでも製品がレイアウトと異なる場合、その理由は理想的なデータにある可能性があります。 lorem ipsumを使用しないでください。 コンテンツは常にソリューションの一部であり、偽のコンテンツでは重要なインターフェースのケースを見ることができません。
6.設計の不一致
開発者は、レイアウト内の要素の値を理解することはできません;要素は、アプリケーション領域または一般に受け入れられている直感的なユーザーインターフェイスに対応していません。
ヒント。 それについてデザイナーに伝えてください。 もちろん、批判は必ずしも楽しいものではありませんが、建設的で正しいフィードバックは製品にとって常に有用です。
このアイコンの意味を理解しますか？
一般的なヒント
最初にチームに会うときは、話し合うだけです。あなたがそれぞれどのようなことをしてきたのか、将来のシステムや既存のシステムの機能を調べてください。
明確で一貫したワークフローに同意します。 共通の環境で働き、お互いに興味を持ちます。 両側でクリエイティブに挨拶します。 フィードバックを共有します。
尊敬は重要な側面ですが、ボタンのようにオンにすることはできません。仕事でそれを獲得する必要があります。 このために必要なもの：
- 聴けることを示す
- 批判ではなく解決策を模索する方法を知っていることを示す
- 自分の仕事と同僚を大切にしていることを示す
- 常に発展し、働いており、知識を共有し、他の人を教育する準備ができていることを示す
- この特定の製品を作ることがあなたにとってどれほど重要かを示してください
- 最後に、結果を改善する機会があれば、他の参加者との違い、矛盾、イデオロギー的摩擦を克服する準備ができていることを示します。
製品を作るためにあなたのすべての強みを発揮する準備ができていて、あなたのすべての非難を出すのではなく、それは良いことです。
まとめ
実際、完璧なレシピはありません。 制約は理由のために作成され、チームプレイはそれらを克服するのに役立ちます。 現実には、すべての開発は設計であり、すべての設計は開発です。 一方が他方なしでは存在できません。
似たような話がありますか？ あなたがそれらをどのように解決したか、または解決しなかったかをコメントで共有してください。
PS助けてくれてありがとうボリス・マヌコフスキーとデザイン・センター・スベルテク
PPSすべてのハッピーラジオの日！