💬 Design Term ＃デザイナー英語＃デザイナー＆＃デベロッパー、英語環境でのコラボレーション

世界のトップ・ブランドは、企業戦略の重要な要素として、デザインを採用しています。 
しかし、デベロップメントなしのデザインはどこにも行けません。

ウェブサイト、アプリ、ソフトウェアなどなど、すべてに至るまで、デザインが豊富なコンテンツを構築するには、デベロッパーと効果的にコラボレーションする必要があります。

ほとんどのデザイナーとデベロッパーは、プロジェクトを成功させるには良いコラボレーションが必要になることは知っていますが、その隔たりを埋めるのは簡単ではありません。役割分担、作業スタイル、またプロセスの相違など色々な問題が生まれてきますが、共感を心がけたり、新しいテクノロジー、およびベスト・プラクティスの使用により、デザイナーとデベロッパーは調和のとれた関係を育むことができます。

適切なプロセスにより、チームは、より良い顧客体験を促進し、かつてないほど堅実なビジネス結果を生み出すデザインを実装できます。今回は、デザイナーとデベロッパーが一緒に作業する時にコラボレーションを促進するためのベスト・プラクティスと簡単な方法を英語表現を交えてご紹介します。

InVisionのデザイナーのデベロッパー・コラボレーション・ガイドをまとめてみました。

1. デザイナーvsデベロッパー

Relationships matter. It's that simple.

簡単に言って、両者の関係は重要です。

When everyone is aligned on the product vision and scope, it’s much easier to keep a project on track.
全員がプロダクト・ビジョンとスコープが一致していると、プロジェクトを軌道に乗せるのがはるかに簡単になります。誰もがそれを信じて取り組んでいます。

Successful teams come together. They have chemistry. They have a shared vision that everyone believes in and is working towards.
成功したチームは団結しています。彼らにはケメストリーがあります。誰もが信じて取り組んでいる共通のビジョンを持っています。

As a designer, you can't do it all. Well, with some basic coding knowledge and a little know-how, you can—but you won’t be nearly as effective as with a cross-team effort.
デザイナーとして、すべての作業を一人ですることはできません。いくつかの基本的なコーディングの知識と少しのノウハウがあれば、それは可能ですが、チームでの取り組みほどは効果的ではありません。

When you know someone doesn’t respect you, there is no trust. And when there’s no trust or autonomy, people don’t do creative work.
誰かがあなたを尊重していないことを知っているとき、そこに信頼は生まれません。そして、信頼や自律性がないとき、人々は創造的な仕事をしません。

One of the most important things for designers is to have a strong collaborative partnership with engineers. 

デザイナーにとって最も重要なことの1つは、エンジニアとの強力な協力関係を築くことです。

No great design work happens without that partnership being in place.
そのパートナーシップが確立されていなければ、優れたデザインは生まれません。

2. デザイナー、デベロッパーのリレーションシップ

These relationships aren't just built around kind words and active listening, though—they're forged through thoughtful action.
これらの関係は、親切な言葉や積極的に耳を傾けることで構築されているだけではありません。思慮深い行動によって築かれています。

Friction is created when marketers and designers fail to appreciate the scope of work required for a given request or bring the developers into planning discussions far too late in the process.
マーケターとデザイナーが特定のリクエストに必要な作業の範囲を理解できなかったり、デベロッパーがプロセスの非常に遅い段階で議論を計画したりすると、摩擦が生じます。

Designers face these same challenges when working with developers.
デザイナーは、デベロッパーと協力するときにこれらの同じ課題に直面します。

Actions speak louder than words.
行動は言葉よりも雄弁です。

To deliver top-notch creative work, designers and developers need relationships centered on trust, appreciation, and respect.

一流の創造的な仕事を提供するために、デザイナーとデベロッパーは信頼、感謝、そして尊敬を中心とした関係を必要とします。

There’s a lot that can happen in building rapport with engineers.
エンジニアとの信頼関係を築くと、さまざまなことが起こり得ます。

You build empathy out of spending time with people and understanding their perspectives... so when we’re working through a project, we have those relationships to rely on.
人々と時間を過ごし、彼らの視点を理解することから共感を築くことができます。またプロジェクトを通して働いているとき、お互いに頼り合うことができます。

Once these teams learn to come together and collaborate effectively as one, the sky's the limit to what they can design, prototype, and build together.
これらのチームが1つになって効果的にコラボレーションすることを学ぶと、設計、プロトタイプ作成、および構築できるものの限界がなくなります。

3. 最適なコラボレーション・ワークフロー

Every company and every team will work a bit differently, but
there are a few essential elements you'll need to create an optimal connected workflow between design and engineering.
すべての会社とすべてのチームは少し異なって働きますが、
デザインとエンジニアリングの間で最適な接続ワークフローを作成するために必要ないくつかの重要な要素があります。

Your processes may be casual or codified—regardless, these workflow steps will help.
プロセスはカジュアルまたは体系化されている場合がありますが、これらのワークフロー手順が役立ちます。

４. 優先順位から始める

It's easy to get into "that's not my job" arguments when there's no context for a specific project. 

特定のプロジェクトのコンテキストがない場合、「それは私の仕事ではありません」という議論に入るのは容易です。



Start with the big picture. 

まずは全体像から始めます。 



What's the ultimate goal of this email template, landing page, user interface, or mobile app? Is it to improve the user experience, boost functionality, rebrand, or something else?
このメール・テンプレート、ランディング・ページ、ユーザーインターフェース、またはモバイル・アプリの最終的な目標は何ですか？
ユーザー・エクスペリエンスの向上、機能の強化、ブランド変更などを目的としていますか？

When kicking off a new project, consider using Atlassian’s Roles and Responsibilities play.
新しいプロジェクトを開始するときは、Atlassianの役割と責任を使用することを検討してください。

This play helps to define everyone’s duties from the get-go so you have crystal-clear expectations throughout the project.
これは最初から全員の義務を定義するのに役立ち、プロジェクト全体を通して明確な期待を抱くことができます。

When teams gain context, they start to see beyond their respective work.
チームがコンテキストを取得すると、それぞれの作業を超えて見え始めます。

Designers begin to see that it might be worth scaling back the amazing visuals to improve page load time to ultimately improve the experience for the end-user.
例えば、
デザイナーは、ページの読み込み時間を改善して、最終的にエンド・ユーザーのエクスペリエンスを改善するために、ビジュアルを縮小する価値があるかもしれないことに気付き始めます。 



And developers may realize that it's worth the extra effort to create more responsive designs to accommodate different devices and clients.

また、デベロッパーは、さまざまなデバイスやクライアントに対応するために、よりレスポンシブなデザインを作成する価値があることに気付くかもしれません。

Start with priorities, and many of your conflicts will sort themselves out naturally.
優先順位から始めてください。そうすれば、対立の多くは自然に解決します。

5. まとまりのあるチームを作成、および維持

When it comes to design and implementation, some designers and developers are going to butt heads.
デザインと実装に関しては、一部のデザイナーとデベロッパーは頭を悩ませようとしています。

—that's why it's important to build relationships outside of projects.
そのため、プロジェクトの外部で関係を構築することが重要です。

Whenever possible, create harmonious teams with members who'll work well together—not just a hodgepodge of talented designers and developers.
可能な場合はいつでも、才能のあるデザイナーやデベロッパーの寄せ集めだけでなく、一緒にうまく機能するメンバーとの調和のとれたチームを作成してください。

When working on projects, you don’t always get to choose the team you work with.

プロジェクトに取り組むとき、一緒に仕事をするチームを常に選択できるとは限りません。

Sometimes you have to play the hand you’ve been dealt. When bringing a new team together, consider the 4 stages of team formation:
時々あなたはあなたが配られたハンドをプレーしなければなりません。 新しいチームをまとめるときは、チーム形成の4つの段階を考慮してください。

6. チーム形成の4つの段階

Forming:
Team members are generally polite and positive, but there’s still some anxious energy in the air as roles are defined and relationships are formed.

形成：
チームメンバーは一般的に礼儀正しく前向きですが、役割が定義され、関係が形成されるため、空中にはまだ不安なエネルギーがあります。

Storming:
As time goes on, conflicts eventually arise, and these are dealt with in the storming process.

ストーミング：
時間が経つにつれて、最終的に競合が発生し、これらはストーミングプロセスで処理されます。

Work styles are questioned and stress enters the equation.
働き方が問われ、ストレスが方程式になります。

Norming: Team members resolve their differences and begin
to find where they each fit in the group puzzle.

ノーミング：
チームメンバーは違いを解決して開始します。それぞれがグループパズルのどこに収まるかを見つけるために。 


Often, teams will cycle between storming and norming from time to time as they resolve emerging conflicts and establish new normals.

多くの場合、チームは、新たな対立を解決し、新しい法線を確立するときに、ストーミングとノーミングの間を循環します。

Performing:
Performing is the stage where processes, structures, and relationships work without friction. Teams thrive at this stage, delivering their best work with the least amount of stress.
パフォーマンス：
パフォーマンスは、プロセス、構造、および関係が摩擦なしに機能する段階です。 チームはこの段階で繁栄し、最小限のストレスで最高の仕事を提供します。

Once you've formed your dream team, keep the cohesive vibes going.
夢のチームを結成したら、まとまりのある雰囲気を保ちましょう。

Meet regularly and keep all parties in the loop. Maintaining a close-knit team with frequent communication will prevent technical impracticalities from road-blocking any projects.
定期的に会い、すべての関係者を常に把握してください。 頻繁にコミュニケーションをとる緊密なチームを維持することで、技術的な非実用性がプロジェクトの妨げになるのを防ぐことができます。


7. 前もってすべてを求める

Bring your development team into the process as early as possible—don’t wait until you’ve finalized your designs to get feedback from your friends in engineering.
できるだけ早く開発チームをプロセスに参加させてください。デザインが完成するまで待ってはいけません。エンジニアリングの友人にフィードバックを求めてみましょう。

Initiate the Hot Potato process from the get-go.
最初からホット・ポテト・プロセスを開始します。

It's better to ask for everything upfront than ask for this, that, and more down the road.
これ、あれ、そしてもっと先のことを求めるよりも、前もってすべてを求める方が良いです。

When you approach your developers, provide all the specs you'll need.
デベロッパーにアプローチするときは、必要なすべてのスペクスを提供してあげてください。

Don't make the engineers dig through emails, Slack conversations, documentation, and more to find the information they need.
エンジニアに、必要な情報を見つけるためにメール、Slackの会話、ドキュメントなどを掘り起こすようなことは避けてください。

Inspectを使用すると、エンジニアリングの最高の仲間とのコラボレーション方法を変革します。詳細については、こちらをご覧ください。

8. 仕事に適したツールを使用する

Whether you're using Freehand, the real-time digital whiteboard, to brainstorm with the team, Prototype to transform your static designs into clickable prototypes, or Design System Manager (DSM) to connect your design and code, you need a synergetic platform that make the workload easier for you and your developer pals.
リアルタイムのデジタルホワイトボードであるFreehandを使用してチームとブレインストーミングを行う場合でも、Prototypeを使用して静的なデザインをクリック可能なプロトタイプに変換する場合でも、Design System Manager（DSM）を使用してデザインとコードを接続する場合でも、相乗効果のあるプラットフォームが必要です。

Twilio SendGrid's Marketing Campaigns, for example, lets you build emails with visual drag & drop WYSIWYG editors or feature-rich HTML code editing. Plus, once your developers build the responsive templates, it's easy for you to edit pixel by pixel without breaking structural code.
たとえば、Twilio SendGridのマーケティングキャンペーンでは、視覚的なドラッグ・アンド・ドロップのWYSIWYGエディターまたは機能豊富なHTMLコード編集を使用してメールを作成できます。 さらに、デベロッパーがレスポンシブテンプレートを作成すると、構造コードを壊すことなく、ピクセルごとに簡単に編集できます。

9. 次回のために考え、そして改善する

The workflow shouldn't end with the project. 

ワークフローはプロジェクトで終わるべきではありません。

To improve future collaborations, you’ll need to have a post-mortem of sorts. You can learn more about post-mortems in the free book Principles of Product Design.
将来のコラボレーションを改善するには、ある種の事後分析が必要になります。 事後分析について詳しくは、無料の書籍「プロダクト・デザインの原則」をご覧ください。


Meet together as a team and hash out (politely) the good, bad, and ugly:
チームとして一緒に集まり、上手くいったこと、思うようにいかなかったもの、良くない点を語り合います。
• What went well?
何がうまくいきましたか？
• What went wrong?
何が上手くいきませんでしたか？
• How can we prevent this hiccup from happening in the future?
この問題が将来発生するのをどのように防ぐことができますか？
• Why did this roadblock occur? How can we avoid it?
なぜこの障害が発生したのですか？ どうすればそれを回避できますか？
• Did we meet our deadline? Why or why not?
•締め切りに間に合いましたか？ なぜまたはなぜそうではないのですか？
• What are our learnings and takeaways?
•私たちの学習とポイントは何ですか？

The purpose of this meeting is not to point the finger of shame and blame.
この会議の目的は、恥と非難の指を指すことではありません。

It's to discover gaps and friction so that you can collectively plan how to patch them up and prevent future issues.
ギャップと摩擦を発見して、それらを修正して将来の問題を防ぐ方法をまとめて計画できるようにすることです。

Post-mortems and retrospectives (retros) aren’t the same thing. Post-mortems happen after a project is completed, while retrospectives happen during the process. 事後分析とレトロは同じものではありません。 事後分析はプロジェクトの完了後に発生しますが、回顧展はプロセス中に発生します。

Retrospectives encourage change to occur throughout the process to improve the final result.

ふりかえりは、最終結果を改善するために、プロセス全体で変化が起こることを奨励します。

10. まとめ

これで、次のプロジェクトに取り組む準備が整いました。 うまくいけば、それぞれの成功したコラボレーションは、デザイナーとデベロッパーの間の調和を高め、最終的に最適なワークフローを生み出すでしょう。

効果的なデザイナーとデベロッパーのコラボレーションが大きな影響を与えます。より良いコラボレーションはより良いプロダクトにつながります。そして、より良いプロダクトは顧客の幸せにつながります。

私も、色々勉強中なので、皆さまの、ご意見・ご感想をお聞かせください。お読み頂きまして、ありがとうございました。

メルボルンを拠点にビジュアル・デザイナー、UXスペシャリストとして働いています。 主にデジタル・プロダクトの制作に携わっています。