フロントエンド開発者がデザイナーの仕事に力を与える方法

この記事は主に、ユーザーインターフェイスの実装を楽しんでいるが、一緒に仕事をしているデザイナーとの期待を一致させるのに苦労しているフロントエンド開発者の皆さんを対象としています。 おそらく、あなたは「UI開発者」または「UXエンジニア」と呼ばれています。 あなたが持ち歩くタイトルに関係なく、あなたの仕事（そして私の仕事）は、デザインファイルに命を吹き込む以上のもので構成されています。 また、設計ワークフローと開発ワークフローの間のギャップを埋める責任もあります。 しかし、その橋を渡るとき、私たちは複数の課題に直面します。

今日は、過去数年間にデザイナーとより効率的にコラボレーションするのに役立った実用的なヒントを皆さんと共有したいと思います。

UI開発者としての私たちの仕事は、デザイナーがWebの仕組みを学ぶ旅を支援するだけでなく、彼らの現実を知り、言語を学ぶことでもあると信じています。

UXデザイナーの背景を理解する

そこにあるほとんどのUXデザイナー（Webデザイナーまたはプロダクトデザイナーとも呼ばれます）は、PhotoshopやIllustratorなどのツールを使用してデザインの世界で最初の一歩を踏み出しました。 おそらく彼らはグラフィックデザイナーでした。彼らの主な目標は、ロゴとブランドアイデンティティを作成し、雑誌のレイアウトをデザインすることでした。 彼らはまた、マーケティングデザイナーであった可能性があります：看板の印刷、バナーのデザイン、インフォグラフィックの作成。

これは、ほとんどのUXデザイナーが初期の頃を印刷用のデザインに費やしたことを意味します。これは、現在のメディアである画面とはまったく異なるパラダイムです。 それが彼らの最初の大きな挑戦でした。 印刷を扱うとき、デザイナーはピクセルの配置を気にしましたが、固定領域（紙）を気にしました。 動的なレイアウト（画面）と競合する必要はありませんでした。 テキストの分割や相互作用の状態について考えることも、彼らの仕事の一部ではありませんでした。 デザイナーはまた、パフォーマンスの制約を受けることなく、色、画像、タイポグラフィを完全に自由に使用できました。

幸いなことに、独学のUXデザイナーコミュニティからは、開発の基礎を教え、デザイナーがコーディングを学ぶべきかどうかを話し合い、開発者へのハンドオフを最適に実行する方法を理解するために多くの努力が払われてきました。 同じことが開発側にも当てはまりました（これについては後ほど詳しく説明します）。 ただし、2つのフィールド間でまだ摩擦が発生しています。

一方では、設計者は、実装が自分の設計と一致しないたびに不平を言ったり、明確な説明なしに開発者によって拒否されたときに誤解されたりします。 一方、開発者は、それが真実ではないかもしれないときに、設計者が技術的なことを知っていることを当然のことと思うかもしれません。 私たちは皆、それよりもうまくやれると信じています。

新しい考え方を受け入れる

私たちが構築しているウェブサイトやアプリは、さまざまな画面サイズで表示されます。 各人は複数のデバイスでそれらを使用します。 私たちの共通の目標は、彼らの旅の中でおなじみの体験を作り出すことです。

開発者として、デザイナーがピクセルの配置にこだわりを持っていると考えるとき、それがなぜであるかを理解する必要があります。 それは忠実さと一貫性を超えていることを認識する必要があります。 それは一緒に働くすべての部分の合計についてです。 それは結束です。 私たちはそれを受け入れ、それを達成するために最善を尽くさなければなりません。 設計原理の基礎を学ぶことは良い出発点です。 適切な色を選択することの重要性、階層がどのように機能するか、および空白が重要である理由を理解します。

注： 「DesignforDevelopers」と呼ばれるオンラインコースと「RefactoringUI」と呼ばれる本があります。どちらも始めるのに最適です。 これらを使用すると、細部にまで気を配ったユーザーインターフェイスを実装し、デザイナーとのコミュニケーションを大幅に活用できます。

デザイナーの意識を拡大する

当然のことながら、デザイナーはあなたと同じようにWebを知っていると思うかもしれません。 まあ、そうではないかもしれません。 実際、彼らはそうする必要はありません！ 開発者として、Webの現在の状態を最新の状態に保つのは私たちの責任です。

私はこのスペクトルの2つの側面に取り組んできました。ブラウザーの互換性を考慮せずに、何でも構築できる（複雑なフィルター、新しいスクロール動作、カスタムフォーム入力など）と考えるデザイナー。 次に、「Webの制限が低い」ことを想定し、何かを実装することは不可能であると自分たちで想定している設計者がいます。 私たちは彼らにウェブデザインの真の可能性を示し、制限が彼らのスキルを妨げないようにする必要があります。

コーディング方法ではなく、コードを教える

これは矛盾しているように見えますが、私には耐えてください。コーディング方法を知ることは、開発者の仕事の中核です。 私たちはペースの速い業界で働いており、毎日新しいものが登場しています。 設計者にコーディング方法を学ぶように要求することは、私たちからの偽善的な要求です。 しかし、私たちは彼らがコードを理解するのを助けることができます。

一緒に仕事をしているデザイナーの隣に15分間座って、要素の仕様が正しいかどうかを自分で確認する方法と、それらを変更する方法を教えます。 Firefox PageInspectorはこれに対して非常にユーザーフレンドリーだと思います。

今日では、レイアウトを視覚化し、CSSアニメーションをデバッグし、タイポグラフィを微調整することは喜びです。 彼らが探索できるように、Codepenのようなすぐに使えるコード遊び場を見せてください。 レイアウトパラダイムがどのように機能するかを理解するために、すべてのCSS仕様を知る必要はありません。 ただし、日常業務に力を与えるためには、要素がどのように作成され、動作するかを知る必要があります。

開発プロセスに設計者を含める

デザイナーを招待して、スタンドアップミーティングに参加し、QAプロセスに参加し、実装の視覚的な詳細を改善する間、一緒に座ります。 これにより、Webの制約を理解し、すぐに、機能の実装に時間がかかる理由を認識できるようになります。

設計者に設計プロセスにあなたを含めるように依頼する

あなたは彼らが「物事をきれいにする」以上のことをしていることに気付くでしょう。 調査プロセスとユーザーテストの方法について詳しく学びます。 あなたは彼らがあなたに示すそれぞれのデザイン提案について、他のいくつかの研究が以前に落とされたことに気付くでしょう。 設計者が変更を要求するときは、その背後にある理由を尋ねてください。そうすれば、行われている決定について詳しく知ることができます。 最終的に、あなたは彼らが空白と配置にうるさい理由を理解し始めるでしょう、そしてうまくいけば、すぐにあなたもそうなるでしょう！

フロントエンド開発を設計プロセスの中核部分として扱い、設計を開発プロセスの中核部分として扱うことが重要だと思います。 誰もが設計と開発のサイクルに参加する機会を得るという考え方を提唱することは、私たち全員がお互いの課題をよりよく理解し、素晴らしい経験を生み出すのに役立ちます。

異なるツールを使用する場合がありますが、同じ言語を話す必要があります

お互いのワークフローをもう少しよく理解し始めたので、次のステップである同じ言語を話す時が来ました。

コードエディタの先を見る

周囲に注意を向け始めると、問題に取り組む準備が整います。 ビジネスをよりよく知り、デザイナーが言わなければならないことに耳を傾けることをいとわないようになります。 それはあなたをプロジェクトへのより豊かな貢献を持つチームメンバーにするでしょう。 私たちの専門知識を超えた分野で協力することは、有意義な会話と相互信頼を生み出すための鍵です。

契約としてのUIシステムの使用

設計者に設計システムを共有するように依頼します（設計システムを使用しない場合でも、開始するのに遅すぎることはありません）。 これにより、使用する色を手作業で選択したり、余白を見つけたり、テキストスタイルを推測したりする手間を省くことができます。 UIシステムに精通していることを確認してください。

コンポーネントベースの概念については、すでにご存知かもしれません。 ただし、一部の設計者は、あなたと同じようにそれを認識しない場合があります。 コンポーネントがユーザーインターフェイスをより効率的に構築するのにどのように役立つかを示します。 その考え方を広め、類似しているが等しくない名前にさようならを言います：ヘッダーとヒーロー、価格情報と価格セレクター。 ユーザーインターフェイスの一部（別名「コンポーネント」）を構築するときは、同じ名前を使用して、デザインファイルとコードファイルの両方に反映できるようにします。 次に、誰かが「提案の招待ウィジェットを微調整する必要があります」と言うと、誰もが何について話しているのかを正確に知っています。

信頼できる正しい情報源を認める

ユーザーインターフェイスは最初に設計ファイルで作成されるという事実にもかかわらず、信頼できる唯一の情報源は開発側にあります。 結局のところ、それは人々が実際に見るものですよね？ デザインを更新するときは、特に多数の人が関与するプロジェクトでは、その開発状況についてサイドノートを残すことをお勧めします。 このトリックはコミュニケーションをスムーズに保つのに役立つので、誰も（あなたを含めて）不思議に思うことはありません。 それはバグですか、それともまだ実装されていませんか？ 」

債務を管理下に置く

つまり、技術的負債についてはすべてご存知でしょう。これは、期限を守るために過去に取った近道のために、何か新しいものを実装するためのコストが高い場合に発生します。 同じことが設計側でも起こり得、私たちはそれを設計債務と呼びます。

あなたはそれを次のように考えることができます：UXとUIの不一致が高いほど、負債（技術的および設計）が高くなります。 最も一般的な不整合の1つは、同じアクションを表すために異なる要素を使用することです。 これが、悪いデザインが通常悪いコードに反映される理由です。 私たちの設計上の負債を真剣に扱うのは、設計者と開発者の両方としての私たち全員の責任です。

アクセス可能であることは、それが醜い必要があるという意味ではありません

開発者としてもデザイナーとしても、ようやくアクセシビリティを仕事に取り入れ始めていることを本当にうれしく思います。 しかし、私たちの多くは、アクセシブルな製品を設計することは難しいか、スキルと創造性を制限していると考えています。

私たちが自分たちだけのために製品を作っているのではないことを思い出させてください。 私たちは、あなたとは異なる方法で製品を使用する人々を含む、すべての人々が使用する製品を作成しています。 現在のユーザーフローを明確かつ一貫性のある状態に保ちながら、個々の要素にアクセスしやすくする方法を考慮に入れてください。

たとえば、設計者が拡張された選択入力を作成する必要があると本当に信じている場合は、彼らの側に立ち、さまざまな能力を持つ幅広い人々が使用できるように、アクセス可能な方法で設計および実装するために協力します。

デザイナーに貴重なフィードバックを提供する

デザインを進めていくと、やむを得ず質問が出てきます。 しかし、それはあなたがデザイナーの過ちや彼らの野心的なアイデアについて不平を言い始める理由ではありません。 デザイナーはあなたを精神的に駆り立てるためにそこにいるわけではありません。彼らはあなたがあなたの仕事をするために何が必要かを常に直感的に知っているわけではありません。 真実は、過去には、あなたもこのことについて知らなかったということです。ですから、忍耐強く、学習の方法としてコラボレーションを受け入れてください。

以前のフィードバック、より良い

フィードバックのタイミングは非常に重要です。 フィードバックワークフローはプロジェクトの構造に大きく依存するため、万能のソリューションはありません。 ただし、可能であれば、初期段階から定期的なフィードバックのワークフローを目指す必要があると思います。 オープンコラボレーションのこの考え方を持つことは、将来の予期しない大きな繰り返しの可能性を減らす方法です。 後でデザイナーに最初のフィードバックを与えるほど、必要に応じて新しいアプローチを検討するためのコストが高くなることに注意してください。

簡単な言葉で抽象的なアイデアを説明する

パフォーマンスはデザイナーの以前の仕事の問題ではないと言ったときのことを覚えていますか？ Web用に最適化されたSVGを作成する方法を知らなくても、びっくりしないでください。 多くの異なるフォントをロードする必要があるデザインに直面した場合、リクエストの数を最小限に抑える必要がある理由を説明します。おそらく、可変フォントを利用することもできます。 読み込みが速くなるだけでなく、より一貫性のあるユーザーエクスペリエンスも提供します。 設計者が学びたがらない限り、何かを説明するときにあまりにも多くの専門用語を使用することは避けてください。 これは、コミュニケーション能力を向上させ、考えを明確にする機会と見なすことができます。

仮定を決定に変えさせないでください

設計仕様に関するいくつかの質問は、コードで手を汚したときにのみ表示されます。 物事をスピードアップするために、私たちは自分たちの仮定に基づいて決定を下したくなるかもしれません。 しないでください。 仮定を決定に変えるたびに、UIを実装するために設計チームがあなたに与える信頼を危険にさらすことになります。 疑問があるときはいつでも、あなたの疑問に手を差し伸べて明確にしてください。 これは、あなたが彼らと同じように最終結果を気にかけていることを彼らに示します。

自分で回避策を実行しないでください

難しすぎる設計を実装するように求められた場合は、 「不可能」と言ったり、安価な代替バージョンを自分で実装し始めたりしないでください。 これにより、設計が期待どおりに実装されていないことがわかった場合、設計チームとの摩擦がすぐに発生します。 彼らは怒って反応したり、何も言わずに敗北したり欲求不満を感じたりするかもしれません。 なぜそれが不可能なのかを簡単な言葉で説明し、別のアプローチを提案すれば、それはすべて回避できます。 独断的な振る舞いを避け、新しい解決策に協力することを心がけてください。

グレースフルデグラデーションとプログレッシブエンハンスメントのテクニックについて彼らに知らせ、理想的なソリューションとフォールバックソリューションを一緒に構築します。 たとえば、フレックスボックスからCSSグリッドにレイアウトを拡張できます。 これにより、機能の主要な目的を尊重すると同時に、Webテクノロジーを最大限に活用することができます。

アニメーションに関しては、現実になりましょう。デザイナーが作成するのと同じくらい、次のすごいアニメーションを実装することにワクワクしています。 私たちと彼らの違いは、私たちがWebの制約をよりよく認識していることです。 ただし、それで自分のスキルを制限しないでください。 ウェブは急速に進化するので、私たちはそれを優先して使用する必要があります。

次回、プロトタイプに命を吹き込むように求められたときは、それを前もって拒否したり、すべて自分でやったりしないようにしてください。 自分をプッシュする機会としてそれを見てください。 アニメーションはWeb開発で最も厄介な部分の1つであるため、デザイナーと直接、または同期されたプライベートリンクを共有して、各キーフレームを改良するようにしてください。

理想的な状態を超えて考える—一緒に

これが問題です：それはあなたのすべてではありません。 デザイナーの課題の1つは、ユーザーを本当に理解し、プロダクトマネージャーに販売するための最も魅力的な方法でデザインを提示することです。 時には彼らは理想的な状態を超えていることを忘れ、開発者もそれを忘れます。

これらのギャップが発生しないようにするために、設計者とシナリオ要件を調整します。

• 最悪のシナリオ
  最悪の可能性が起こっているシナリオ。 これは、デザイナーが固定コンテンツにノーと言って流動的にするのに役立ちます。 タイトルが60文字を超える場合、またはリストが長すぎる場合はどうなりますか？ 同じことが反対の空のシナリオにも当てはまります。 リストが空の場合、ユーザーは何をすべきですか？
• 相互作用状態
  ブラウザは、ホバリングしてクリックするだけではありません。 デフォルト、ホバー、フォーカス、アクティブ、無効化、エラーなど、さまざまな状態があり、それらのいくつかは同時に発生する可能性があります。 彼らに適切な注意を向けましょう。
• 読み込み状態
  ローカルでものを構築するとき、モックを使用して、実際にロードするのに時間がかかることを忘れる可能性があります。 デザイナーにもその可能性を知らせ、ロードにそれほど時間はかからないことを人々に認識させる方法であることを示してください。

これらすべてのシナリオを考慮に入れると、開発フェーズで前後に移動する時間を大幅に節約できます。

注：アクセス可能な製品に一歩近づくための不正なユーザーインターフェイスを修正する方法について、ScottHurffによるすばらしい記事があります。

変更要求を受け入れる

開発者は、誰かが自分のコードにバグを見つけたことにあまり満足していないことで知られています。特に、それが設計者によって報告された設計バグである場合はそうです。 その周りにはたくさんのミームがありますが、これらのデザインのバグが何気なく却下されたときに、それらのバグがエクスペリエンスの品質とあなたの関係の両方を複合的に腐敗させる可能性があることを反映したことがありますか？ まるで眠りにつくように、ゆっくりと起こります。 少しずつ、そして一度に。 デザイナーは、無関心と恨みが高まり、何も言われなくなるまで、「ほんの少しの詳細です」と言い始めるかもしれません。 その後、被害はすでに発生しています。

この状況は2つあります。同僚と仕事の両方です。 それを起こさせないでください。 あなたの反応を着色している​​ものに取り組んでください。 デザイナーが「うるさい」というのは不便かもしれませんが、エンジニアが注意力と熱意を浅く解釈している可能性もあります。 誰かがあなたの実装が（まだ）完璧ではないとあなたに言うとき、あなたのエゴを脇に置いて、あなたが最終結果を洗練することにおける彼らの努力をどのように認識するかを彼らに示してください。

たまにオフレコ

私たちは皆、提供するタスクと完了するためのロードマップを持っています。 ただし、最高の作業のいくつかはオフレコで行われます。 TO DOボードにはログインしませんが、問題ありません。 信頼関係のあるデザイナーを見つけたら、彼らのワークスペースに忍び込み、新しい実験を一緒に探求してください。 あなたはそこから何が来るのか決してわかりません！

結論

デザインチームから学ぶことをいとわないときは、さまざまな考え方も学びます。 新しい経験を生み出すために目を磨きながら、経験から他の分野とのコラボレーションの考え方を進化させます。 共有することが私たちをより良くするものだからです。

この記事は、多くの素晴らしい人々のフィードバックなしには実現できませんでした。 デザイナーと開発者の間の誤解についてバランスの取れた視点を共有するのを手伝ってくれたデザイナーのJasmineMeijerとMargaridaBotelhoに感謝します。

SmashingMagの関連資料：

• MasonGentryによる「 DesignForDevelopers 」
• レイチェル・アンドリューによる「共同作業：設計者と開発者がどのようにコミュニケーションを取り、より良いプロジェクトを作成できるか」
• StefanKalteneggerによる「フロントエンド開発者が設計者と開発者の間のギャップを埋めるのにどのように役立つか」
• 「Webデザイナーと開発者はどのポッドキャストを聞くべきですか？」 リッキー・オンスマン