デザイントーク：InVisionのAarronWalterとのより良いデザイナーと開発者のコラボレーション
公開: 2022-03-11世界中のデザインに携わるソートリーダーやトップの人々の洞察を共有することを目的としたデザイントークシリーズへようこそ。 さまざまな状況で、さまざまな目的で、さまざまなアプローチを通じて設計に取り組む専門家にインタビューします。 これらのシリーズでは、すべての読者に知的で創造的なインスピレーションを提供したいと考えています。
設計者は開発者と協力するのに苦労することが多く、その逆も同様です。 両側のチームはお互いから途方もない量を学ぶことができましたが、それでも抵抗の層が残っています。 今週のゲストは、InVisionのデザイン教育担当副社長であるAarron Walterで、デザイナーと開発者のコラボレーションについて話します。
Aarronは、製品チームの運営と設計の指導における15年の経験を活用して、企業が設計のベストプラクティスを制定するのを支援しています。 彼はMailChimpでUXプラクティスを設立し、製品を数千人のユーザーから1,000万人以上に成長させるのを手伝いました。
彼の設計ガイダンスは、ホワイトハウス、米国国務省、および数十の主要企業、新興企業、ベンチャーキャピタリスト企業を支援してきました。 彼はABookApartからの感情のためのベストセラーの本DesigningforEmotionの著者です。 Twitterで@aarronを見つけて、デザインについての考えを共有します。Aarronの詳細については、aarronwalter.comをご覧ください。
デザインベターポッドキャストでは、アーロンウォルターとエリウーラリーが、問題の解決方法とキャリアパスについてのストーリーを共有するデザインリーダーとインフルエンサーにインタビューします。 ゲストには、David Kelley（IDEOの共同創設者およびStanford d.schoolの創設者）、Julie Zhuo（Facebookの製品およびデザイン担当副社長）、Jake Knapp（Sprintのベストセラー作家）などが含まれます。
こんにちはアーロン、ToptalDesignブログにあなたを迎えることができて光栄です。 火星の開発者と金星の設計者ですか？
私の経験では、デザイナーと開発者はおそらく彼らが認識しているよりも多くの共通点を持っていますが、私たちが物事について考える方法には確かにいくつかの明確な違いがあります。 設計者は設計システムについて考えるのが大好きで、開発者は保守が簡単なモジュラーコードについて考えます。 しかし、私たちがそれを行う方法は少し異なるかもしれません。
開発者は自分の仕事を細かく分割する方法を見つけました。デザイナーは全体を「ケーキ全体」と考える傾向があり、ケーキ全体をどのように食べるかを考えます。
これは彼らが頭を突き合わせ始めるポイントです。 エンジニアは、コードを小さなステップで出荷し、アジャイル手法の一部として非常に迅速に何かを作成できることを望んでいます。 デザイナーは、全体的な方法で大きな一歩を踏み出したい傾向があります。つまり、一貫したエクスペリエンスを提供したいと考えています。 これは、これら2つのグループの論点になる可能性があります。
開発者を私たちの視点に少し引き込むために、デザイナーは何ができるでしょうか？ デザイナーは、出荷されたすべての小さな機能がエクスペリエンスにも関係していることを開発者にどのように理解させますか？
ここで両側が曲がる機会があります。 デザイナーは、開発者に、すべてを待って構築し、それをこの美しく完全なエクスペリエンスとして公開する必要があることを納得させようとすることがあります。
しかし、作成サイクルが長すぎると、製品が死ぬリスクがあります。 人々は興味を失い始めます。 彼らはこう言うかもしれません。「これは実際にビジネスに価値を生み出しているのでしょうか？ 私たちはこのことに多大な時間とエネルギーとリソースを費やしていますが、なぜそんなに時間がかかるのですか？」 設計者は、ビジネスのサイクルについてもっと考える必要があります。
Appleが電話（問題のあるハードウェアの一部）を出荷する場合、数十億ドルの費用がかかる可能性がありますが、ソフトウェアが出荷されて問題が発生した場合は、パッチを適用して修正し、再度出荷することができます。 このようにプロセスにアプローチすることで、よりエレガントに開発作業サイクルに戻ることができます。
設計者は、エンジニアを設計プロセスに早い段階で関与させて、下流だけでなく初期の構想段階に含まれていると感じさせることで、2つのグループ間のギャップを埋めようとすることもできます。 デザイナーはこう言うかもしれません：「私たちはこの素晴らしいアイデアを思いついた、私たちのためにそれを作ってください！」 そしてそれは開発者に彼らがアイデアプロセスの一部ではないと感じさせます。 彼らはただの手であり、他の誰かが脳です。
設計者と開発者の間の最も機能不全の関係は、明確な分業がある場合に発生します。 融合し始め、それらのチームが協力すればするほど、より良いものになります。 その結果、複数の視点と共有された所有権が存在することになります。これは、設計者と開発者が効果的に連携するための鍵となります。
お互いの空間をよりよく理解することについて…
チームはお互いのスペースをよりよく理解するために何ができるでしょうか？ 設計者は開発に精通している必要がありますか、またはその逆ですか？
まず、設計者と開発者は顧客ともっと話し合い、問題の領域について一緒に学ぶことができます。 彼らは朝、コーヒーを飲みながら3〜4人の顧客と話すことができました。 誰もが非常に迅速に学び、懸念事項についての共通の理解に到達することができました。
第二に、作業プロセスの観点から、設計者と開発者は、流暢ではないかもしれませんが、互いの言語をある程度理解していることが重要です。 設計者がコーディング方法を知っている必要がある、または開発者がタイポグラフィを習得する必要があるという意味ではありませんが、少なくとも共通の理解があります。
設計者が開発者が理解できる言語で物事を組み立てることができれば（「そのようなものは機能せず、ビジネスにとっては悪い」）、開発者はすぐに問題を理解するようになります。 それはデザイナーにとって自然なことではありませんが、定性的にだけでなく、定量的に自分の仕事の価値を伝えることに優れている必要があります。 営業チーム、マーケティングチーム、エンジニアリング、製品、経営幹部、これらすべての人々は数で話し、量的に話します。
とはいえ、デザインは非常に価値のあるものをもたらすと私は信じています。数えられないものもあると思います。 顧客体験、喜び、製品への愛情は非常に貴重であり、それを定量化するのは困難です。
ただし、品質コンポーネントによって定量化可能なROIがもたらされることは、定量化可能です。
はい、設計によりカスタマーサポートのコストを削減し、解約を削減し、オンボーディングの速度を上げることができます。 そのような指標を使用して目標を設定すると、設計をビジネス目標に合わせるのに役立ちます。 設計者がそれを実行できるほど、設計者はより理解されるようになります。 その設計が企業内で競争上の優位性として評価されるほど、より多くの投資の可能性が高まります。
デザイナーと開発者のコラボレーションの落とし穴について…
一緒に作業している設計者と開発者が遭遇する最大の落とし穴のいくつかは何ですか？
最大の落とし穴の1つは、言語が共有されていないこと、目標が共有されていないこと、比率が非常に不均衡であることです。 1人の設計者と75人のエンジニアからなる部門横断的なチームが存在する場合があります。 それは非常識に聞こえますが、それはかなり一般的です。
それらの状況の大部分は良くありません。 その孤独なデザイナーは駐在員です。 彼らは、文化に完全に適合しない奇妙な土地で見知らぬ人です…そして彼らの価値観は、同僚全員の価値観とは異なります。
そのような環境では、UX機能を主張することは、デザイナーにとって非常に困難です。「より魅力的なエクスペリエンスを生み出すため、このアニメーションを製品に含める必要があります…」と言うエンジニアが75人いる場合、「それは250以上です。コード行と2日間の追加作業。 本当に価値がありますか？」 そして、おそらくそうではありません。 彼らにとって、それは「フロスティング」のように見えるでしょう。 しかし、UXデザイナーに対するこれらのアニメーション化されたマイクロインタラクションは、実際に顧客体験を形作ります。 それらだけではありませんが、重要です。
設計者と開発者の比率が不均一な場合、それは非常に問題になります。 ただし、解決策があります。 Slackのような企業は、「ペアデザイン」でこの問題を解決します。 あるチームに1人のデザイナーと10人のエンジニアがいて、別のチームに同じ比率がある場合、それらのソロデザイナーは、週に約8時間一緒に作業し、互いに解決策を提示します。あなたにとって意味がありますか？ これを行うためのより良い方法はありますか？」 彼らはお互いが動けなくなるのを助け、島にいるように感じないようにすることができます。
UXの重要性を伝えるデザイナーについて…
設計者は、HCDを本当に理解していない開発者に対して、人間中心の設計の重要性をどのように強調できますか？ たとえば、設計者は、機能の追加が必ずしも顧客に役立つとは限らないこと、製品の使用経験がその機能よりも重要であることをどのように伝えますか？
それを行うにはいくつかの効果的な方法があります。 ほとんどの設計者は、開発者に直接伝えることによって、おそらく効果のない方法でそれを行っています。 人々はそれが欲しいと言いますが、それは実際には製品をより複雑にするだけです」と開発者は答える可能性があります：「私はあなたが正しいとは思わない、それは意見です。 これはお客様から聞いているので、フォローする必要があります。」
正面から取り組むのではなく、横向きに「問題空間を一緒に理解しましょう」と言うのが一番です。 明日はお弁当を買いましたので、5人のお客様にご紹介させていただきます。
お客様が実際に商品を使っているのを見ると、エンジニアが席に座り込んでいるのを見て、「かなり使いにくいものを作ったので、欲求不満になります」と気づきました。 エンジニアは、デザイナーと同じように素晴らしい仕事をしたいと思っています。 多くの場合、彼らは単に彼らの仕事の結果を見る機会がありません。
ジェフ・ゴセルフが「成果ではなく成果」に焦点を当てるべきだと説いていることを聞いたことがあるでしょう。 これは、「さらに5つの機能を出荷した」という結果と、「解約率を10％削減した」という結果であるという考え方を再構成できるもう1つの方法です。
デザイナーと開発者のコラボレーションの未来について…
多くの企業と話をし、多くの設計チームと開発者チームが協力しているのを目にします。 ツール、環境、および方法論は変化しています。 デザイナーと開発者の関係の将来はどうなるのでしょうか？
塩水と淡水が混ざり合うと汽水が発達し、エンジニアリングツールと設計ツールが融合します。 設計のすべてがここにあり、エンジニアリングのすべてがそこにあるという引き継ぎのように感じるプロセスの代わりに、それらは融合し始めます。
その点で、デザイナーはJiraで多くの時間を費やし、ユーザーストーリーを考え、エンジニアリングの考え方も考え始めています。 逆に、エンジニアがInVision Inspectのようなツールを使用して、設計システムの仕様と内訳を確認し、すべてがどのように組み合わされているかを理解しているのを目にしています。 これらのツールと分野の融合により、共通の理解が深まっています。
開発者であろうとデザイナーであろうと、あなたはあなたの主要なパートナーの視点を理解し始めることができます。 それはあなたがデザイナーとしてエキスパートコーダーでなければならないという意味ではありません。 しかし、Gitの使用方法や、HTMLやCSS、おそらくJavaScriptの記述方法について少し知っていれば、デザイナーを殺すことはありません。 これは実際に、デザイナーが物事がどのように構築されているかを理解し、デザイナーと開発者のより良いコラボレーションを促進するのに役立ちます。
Toptal Designブログでさらに読む：
- 開発者のための設計へのアプローチ方法
- デザイントーク：UXリサーチャーのCaitriaO'Neillとの共同研究
- デザイントーク：PamelaPavliscakによる感情的にインテリジェントなデザイン
- デザイントーク：ニック・ディサバトとの価値に基づくデザインの追求
- UXデザイナーからUXコンサルタントに移行する方法