この記事の翻訳は、記事「 開発者を養うことと世話をすること（またはなぜ私たちがそのような不平を言っているのか）」によって促されました。
その記事の著者は、以下のトピックに答えています。 写真を完全に視覚化するには、さまざまな角度から見る必要があります。 著者は、デザイナーの側から見ることを提案しています。 誰が気にする-猫の下。
過去10年間ほどハイテク志向の企業で働いているデザイナーとして、私は開発者との仕事に多くの時間を費やしています。 これらのコラボレーションは、私がこれまで経験した中で最も建設的で実り多い仕事上の関係です。
デザイナーも、開発者とこのような関係を作成できます。個人的な偏見（デザイナーと開発者の両方）を突破して、効果的なパートナーシップのためのスペースを作成するだけです。 成功した場合、そのメリットは、これを達成するために必要な痛みや小さな変更をはるかに上回ります。
私はコンサルティング、アカデミー、そして世界で最も有名な開発会社の1つで働いていました。 開発者の行動をさまざまな角度から見て、多くのタイプのデザイナー（非常に技術的なものから概念的なもの、視覚的なものなど）と協力しました。
開発者の目から見た私たちの評判を損なう、デザイナーの悪い振る舞いのいくつかの定評のあるパターンがあります。 技術志向の企業での設計へのアプローチを明確にすることで大きな成功を収めました。その過程で、開発者との長期的な信頼ベースの効果的な関係が形成されましたが、残りの設計者は失敗しました。 優れた設計者は、優れた開発パートナーがいれば指数関数的に仕事を改善できますが、そのためには微調整が必要です。
効果的な設計および技術的関係を作成するための最善のヒントを以下に示します。 私の目標は、双方の偏見を減らし、デザイナーと開発者がより良い製品を作成するための強力な同盟を結ぶのを助けることです。
1.使用するツールを使用する
新しいチームに参加するデザイナー、または新しいプロジェクトを開始するデザイナーとしての最初のステップは、簡単な質問をすることです。「仕事はどうですか？」。 多くの設計者は、慣れ親しんでいるツールやプロセスを使用するのを間違えたり、前のチームで成功したりしています。 しかし、ソフトウェアの状況は急速に変化し、各チームはユニークです。
開発チームにどのように働きたいか、どのツールを既に使用しているかを尋ねるだけで、分岐のプロセスを回避できることがわかりました。 一部のチームは、一致するドキュメントを作成してバグを追跡したり、ソフトウェアを使用してバグを発見したりしています。 電子メールを送信したり、Pivotal Trackerなどの柔軟なツールを使用したりする人もいます。
デザインの成功の鍵は、そのテクニックがどれだけ優れているかではなく、デザインの相互作用においてどれだけ成功しているかであり、デザインが可能な限り理想に近いものになるようにします。 真に優れたデザイナーは、効果的なデザインインタラクションに必要なツールに適応できます。新しいツールの学習に少し時間がかかったとしても、開発との摩擦を減らすことで道を開くことができます。
2.開発サイクル全体に参加する
設計者は、製品開発サイクルの最後までアクティブ化されていなければ、開発者との関係を簡単に破ることができます。 部外者がいくつかの詳細な変更を行って飛び込むと、立ち上げに取り組んでいる開発チームは失望します。 （そして、起動する前よりも早くオンにしないと、あなたは実際には部外者です。）
開発者には、フロントエンドを開発するだけでなく、製品または機会のライフサイクル全体に参加するデザイナーが必要です。 設計者は、基本的なデータ構造、ストレージ、検索、およびインターフェイスフレームワークを作成するという重いエンジニアリングタスクを（関係していない場合でも）よく知っている必要があります。 デザイナーはチームの他のメンバーと一緒にすべてのステップを祝福し、促進する必要があります-たとえカーブであっても、コミックサンズのリンクの＃00Cセットを使用したハーフメイドのプロトタイプ
多くの場合、私は同僚のデザイナーが初期のプロトタイプデザインの美学や相互作用に介入するのを見ています。 エンジニアが以前は考えもしなかったことに対するデザイナーの初期の批判は、次のレビューへのデザイナーの参加には寄与しませんでした。 その結果、デザイナーは、発売の1週間前に意味のある変更を要求することになり、ほとんどの場合、それらを変更しません。
3.改善が必要なものについて具体的に説明します。
多くのデザイナーは、完成した「ピクセル完璧な」レイアウトを開発者に提供した時点で完了したと考えています。 設計者は、製品または機会がリリースに近づき、フロントエンドが仕様を考慮していないときに緊張し始めます。 しかし、開発者の最新のビルドに応答する代わりに、「これは私のレイアウトと一致しません。これを紛失した場合のレイアウトです」-具体的に！
デザイナーは、ほとんどの人が気付かないような細部まで気付くように訓練されています。 開発者は意図的に詳細を見落とすことはありません。これは、主な機能やバグのないコードの作成などの優先事項ではありません。 これらの種類の部品を探す訓練を受けていないため、これらのエラーに気付き、できるだけ具体的に指摘するのはデザイナーの仕事です。
ライブデモのスクリーンショットとレイアウトを並べてバグレポートを送信します。 変更する必要があるものの詳細な説明とともにスクリーンショットにコメントします。 見せて伝える 。 私は通常、コメント付きの「前と後」のスクリーンショット付きのバグを送信し、箇条書きリストのように修正する必要があるものを要約します。 したがって、視覚的記述と言語的記述の両方には、より速くより意識的な動きの形式があります。
チーム内のある分野または別の分野でより強力な開発者を配置できるため、ビジュアルデザインの洗練とは別に相互作用の改善を送信することさえしました。したがって、これらのカテゴリに分割すると作業を分割しやすくなります。 一般に、開発者は、準備ができたときに体系的に促進および削除できる改善点のリストに非常によく反応します。 これは私にとってもう少し手間がかかりますが、より少ない作業で変更を取得する方が適切です。
4.実際の会話は良好ですが、追跡できません。
私が知っているデザイナーの多くは、プロダクトマネージャーまたは開発者と直接会ってデザインの詳細を開発することを好みます。 これは素晴らしいことであり、チームの結束を助けることができますが、これの副作用は「ペーパートレース」 （プロトコル、レコード-at。翻訳 ..）がないことです。あなたが2人のチーム（あなたとあなたの開発者）幅広いアクセスおよび対応チーム向けに文書化されています。
そのため、設計の改善について開発者と生産的な個人的な議論をしている場合でも、表に戻って、すぐにこれをレターまたはバグレポートにまとめてください。 これにより、チーム全体が反応する機会が得られ、決定に関するレポートとして機能します。 文書化された理論的根拠を伴わない決定は、物事が終わりに巻き込まれたときに誰でも変更する可能性があります。
5.開発者と一緒にビールを飲む
チームメンバーの社会化の力を過小評価しないでください。 それらを知り、彼らにあなたを知らせてください。 自分がデザインビジョンを実現するために頼れる一連のスキルだけでなく、誰かが自分を自分として大切にしていると感じた場合、信頼とコミュニケーションを改善できます。
開発者！ こんなに簡単に降りるとは思わなかったのですか？ デザイナーがあなたの人生を楽にするためにできるすべてのことで、デザイナーとより良い関係を作るためにあなたがする必要があるいくつかのこともあります。
1.最初の答えを「いいえ」にしないでください。
デザイナーにとって、新しいアイデアに興奮し、それについて話し合い、次にその可能性を本当に説明する前に地面に釘付けにされることほど失望することはありません！
多くの開発者（特に私が長年働いてきた開発者）は、「重要に見えないものに対してはあまりにも多くの作業を必要とする」ため、通常、設計のアイデアや革新に対して否定的に反応します。 私を信じて、デザイナーはあなたが何かをできるだけ実行可能にするために一生懸命働いていることを理解しています。それを斜めに見ても壊れません。
しかし、チームがデザイナーと開発者の両方を必要とする理由があります。 私たちの仕事は、人々が使いたくなるような、直観的で楽しく革新的な体験をすることです。 そうでなければ、開発者のすべてのハードワークは何もありません。
デザイナーは新しいアイデアを楽しんでいることに熱心かもしれませんが、すぐに言うのではなく、デザイナーがこのアイデアにとても興奮している理由を理解するために少し時間をかけてください。 より低いコストで同じ効果を達成する方法について、彼女または他の開発者と話し合ってください。 。
2.「フィッティングとフィニッシュ」-開発者のトラブルではありません
「フィットとフィニッシュ」は、自動車業界で使用される用語です。 これは、すべてがエラーや逸脱なしにマシンで行われ、マシンが完全に準備ができていることを意味します。 翻訳。
さまざまな分野で、さまざまなことが非常に重要であると考えられています。 優れたデザイナーにとって、細部へのこだわりと真に洗練された体験の創造が最重要です。 これらの詳細は重要であり、説明が難しい場合がありますが、通常、製品に対するユーザーの潜在意識に影響します。 多くの小さな詳細なエラーが蓄積され、製品が専門家ではない、または信頼できないという感覚を生み出します。 それどころか、よく磨かれたアプリケーションは、アプリケーションが完璧に設計されているが、ずさんなインターフェイスを備えているという強い感情的な印象を与える可能性があります。
デザイナーが開発者にアイコンを3ピクセル左に移動するか、同じベースラインに沿って2つのテキストブロックを配置するように要求する場合、この変更は重要ではないように見えますが、このようなもののセットは実際に違いを生む可能性があります。
3.ローンチ前にデザイナーとの報告会を行う
デザイナーがあなたと協力しようとしている場合、たとえ小さな変更であると思われるとしても、新機能の事実に直面して彼を罰しないでください。 チームの他のメンバーと同じようにデザイナーを扱います。 デザイナーは他のチームと同様に製品の成功に関与しています。
デザイナーと解析を行うときは、送信する前にデザイナーが応答するか、変更を提案するか、繰り返すかを確認してください。 プロジェクトデザイナーを「あなたの情報のため」としてのみ表示することは、送信することと同じくらい悪いことです。私はそれをあなたのデザイナーにまったく見せません。
私の経験と、過去数年にわたって開発してきたアプローチが、デザイナーと開発者の間の強力な同盟関係の構築に役立つことを願っています。 最終的には、より強力な製品の作成とユーザーエクスペリエンスの向上につながると考えています。
PS謝罪します。 本当に急いだ。 何人が再読しませんが、...
エラーとタイプミスを送信（および送信）したすべての人に感謝します。