第二部：技術領域への案内
プロダクトデザイナーと上手に協働するための心得
はじめに
Wantedly のエンジニアには、課題発見からリリース、そして結果分析までの一連の改善ステップを、オーナーシップを持って進めることが期待されます。その中のフロントエンドの実装において、プロダクトデザイナーと上手くコミュニケーションをとって協働することは、改善スピードを上げるためにも、またプロダクトの品質を上げるためにも重要なスキルになります。
本章では、Wantedly のエンジニアとして、プロダクトデザイナーとのコミュニケーションのあり方や、プロダクトをスムーズに開発するために気をつけることを説明します。前半では、一般的にデザイナーと協働するために心得ておくと良いことを、後半では、スムーズに仕事を進めるための心得について、リリースまでの全体像を説明した後、各ステップごとに気をつけるべきことを説明します。
上手く協働するための心得
デザイナーと上手く協働するテクニックは色々とあると思います。また、一緒に働く人によって、上手く協働する方法はそれぞれ異なることもあるでしょう。一方で、普遍的に大切なこともあります。中でも、 Communication Between Designers and Engineers, WWDC2017 で紹介されている項目が良かったので紹介します。
この発表では、iOS アプリを実装する上で、デザイナーと協働するために次の 4 つが大切であると紹介しています。
- 共通言語で話す
- 唯一の情報源を持つ
- 幅広い観点を持つ
- 語るよりも見せる
この項目に沿って、Wantedly ではどのように気をつけるべきかを説明します。
共通言語で話す
UI を説明する言葉がバラバラであったり、エンジニアとデザイナーとで異なる用語を使っていると、デザインに対して認識の齟齬が発生してしまい、デザイナーが意図していないデザインを組んでしまうことがあります。
デザイナーとエンジニアが共通の言語でデザインについて会話することは、コンテキストの共有を促し、よりスムーズなコミュニケーションを促進します。
例えば、ボタンについて考えてみます。もう少しボタンを強調したいと思った時、デザイナーにどう説明しますか？
この場合、Wantedly では、Elevation を用います。例えば、「このボタンの Elevation を上げるとどうですか？」というように話します。「このボタンの影を
box-shadow: 0px 2px 6px rgba(0, 0, 0, 0.1), 0px 0px 0px 1px rgba(0, 0, 0, 0.02) にするとどうでしょう？」というより、よっぽど楽に議論ができると思います。一般的に、デザインシステムは、デザイナーとエンジニアの両方が、アプリケーションの構築方法を一致させるために話すことのできる言語として機能します。Wantedly でも、デザインシステムを共通の言語として、普段からコミュニケーションを取っています。
さらに、コードベースでも同じコンテキストで UI を記述できることを目的に、デザインシステムライブラリを作っています。詳しくは Web フロントエンドアプリのデザインシステムライブラリ を確認してください。
唯一の情報源を持つ
デザインの参照元が複数あると、どれが信頼できるデザインか分からなくなることがあります。参考にするデザインは必ず一つの情報源にしておきましょう。
Wantedly では、新しいデザインに関しては Figma を使って一元管理していますが、古い画面などは Zeplin にある場合もあります。なので、デザインの情報源がどこなのか、最初にデザイナーに確認しておくと良いでしょう。
幅広い観点を持つ
デザインだけでなく、デザインの外側にあるものについても考えることが重要です。具体的には、ユースケース、リソースキャパシティとの兼ね合い、アクセシビリティの観点も考えることが重要です。
例えば、Web やモバイルアプリの標準から外れてカスタム UI を作るのは、かなりコストの高い作業であると認識するべきです。Communication Between Designers and Engineers, WWDC2017 では具体的な例として、カスタムされた UI ではなく、iOS 標準のテーブルを使うべきだと主張しています。大抵の場合は、デフォルトであったりライブラリが提供しているフレームワークを使う方がアクセシブルであり、実装工数もかかりません。
Wantedly の場合、デザインはデザインシステムに則って実装されるので問題はないことが多いです。ただし、フロントエンド実装において難しいポイントは抑えておくと良いでしょう。Web アプリで例を挙げると、「...続きを読む」のようなデザインを実装する場合です。truncate + inline block の組み合わせは、デフォルトの CSS では対応できず、複雑な制御を行う必要があるため実装コストがかかります。
実装コストがかかる場合、デザインにフィードバックする段階で指摘できると良いです。頑張ってデザインを実装するのではなく、デザイナーに正直に実装が難しいことを伝えて代替案を検討することも考慮に入れましょう。
また、さまざまな状態についても熟慮するべきです。デザインはあくまでも状態の一部を切り取ったものにすぎません。その画面が取りうる状態によってデザインが変わります。提示されているデザインで全ての状態がカバーできるか、状態が変化した時の接続に問題がないかなどをあらかじめ確認しておきましょう。
語るよりも見せる
実際にデザインや実装を見ながら話す時間を設けましょう。デザインを見ながら、または見せながら議論することで、デザイナーからは実装が意図と合っていないという不満を、エンジニアからは仕様が詳細でなかったために心の隙間が埋まらないという不満を解消できます。
見せ方ですが、なるべく静的な画面のキャプチャーではなく、動くものを実際に同期的に見せましょう。そのために、フィードバックする時間や、デザインチェックする時間など、デザイナーと議論する時間を同期的に作ります。
また、全て完成してから見せるのではなく、見せられるものができたら早めに見せましょう。特に大きな施策を動かしている時は、大きな手戻りを防ぐためにも気をつける必要があります。UX は、一発目のデザインで完成しているのではなく、実装していく中で洗練されるものです。
次の節からは、実際に行っているステップを紹介し、その中で気をつけるべきことをより具体的に説明していきます。
スムーズに仕事を進めるための心得
Wantedly では、プロダクトデザイナーと一緒になって、ユーザーの課題解決のために施策やプロジェクトを進めます。具体的には次に示すようなステップで仕事を進めます。
デザインをフィードバックする時間と、実装をチェックするデザインチェックの時間は、なるべく同期的に設けるようにしましょう。フィードバックやデザインチェックは、状況によっては手戻りが発生することもあります。特にデザインチェックで手戻りが発生した場合、修正したら直接リリースして大丈夫だろうと思わず、リリース前には必ずデザインチェックをお願いしましょう。
次節からは、各ステップで気をつけることを説明していきます。
デザイナーを巻き込む
課題を言語化して伝える
デザイナーにデザインをお願いするときには「なぜやるのか？」を伝えることが最も大切です。次のことを伝えましょう。
- 課題の仮説
- 解決方法の案
課題に対しての解決方法は一つだけではなく、デザイナー視点で見たときにより良い解決方法に気づくこともあります。そのため、「ユーザーにとって何が課題であるか？」を具体的に伝えることが重要です。
課題の仮説では、事実も含めて書くことでより仮説の信憑性が増すため、一緒に伝えると良いでしょう。課題について深く認識することがより良いユーザー体験につながり、また重要な課題であると認識できることが、デザイナーのモチベーションにもつながります。
解決方法の案では、その解決方法が本当に課題の解決になっていることを確認しましょう。また、解決方法を言葉だけで 100%理解してもらうのは思ったより難しいので、プロトタイピングすることがお勧めです。プロトタイピングには Miro などのボードを使うことが多いです。
また、デザイナーが後から優先度判断がしやすいように、課題仮説を見やすい場所に記述したり、実施する施策の一覧を参照できるようにしておきましょう。
プロジェクトをスムーズに進行させるための Tips
プロジェクトの存在理由や目標の目線を合わせておくために、Kick-off などの早い段階で、デザイナーを巻き込むようにしましょう。
また、次の事柄をあらかじめデザイナー側と握っておくと以降のステップがスムーズに進みやすいです。
- スケジュールを握る
- いつまでにデザインが必要か
- いつデザインチェックをするか
- コミュニケーションの方法を握る
- 同期的にコミュニケーションをとって進めるべきか、非同期コミュニケーション（Slack 上のやりとりや GitHub の Issue/PR など）で十分か。
- なるべく同期的にやるべき。
- 意思決定を握る
- どこまでエンジニア側で対応して良いか
- 文言や考慮もれのエッジケースがあった場合、必ずデザイナーとチェックすべきかどうか
デザインのフィードバック
クリティカルシンキングでフィードバックを行いましょう。自分の感覚でデザインの良し悪しをフィードバックするのではなく、提示されたデザインが課題を解決しているか、ユーザーにとって悪い体験になっていないかなどの観点から、ロジカルにフィードバックすることが大切です。
また、「幅広い観点を持つ」の節で説明したことで、問題がないかこのタイミングで確認しましょう。抜けていた仕様がある場合などは、そのデザインもこのフィードバックのタイミングで議論します。
実装
デザイナーの意図通りにスタイルを実装していくことが大切です。そのためにも、まず、デザインシステムに則ってデザインを組みます。なるべくデザインシステムのライブラリを用いるようにしましょう。また Figma などの成果物をしっかりと見ることも大切です。例えば、そのコンポーネントが margin を持つのか、それともコンポーネント自体が高さを持っているかなど、成果物の通りになるように、デザインを組みましょう。
スタイルの崩れは伝播します。一つコンポーネントのスタイルが崩れてしまうと、それが全体に波及します。無駄に margin を使っていないか、必要のない場所で important や z-index を使っていないかなど、CSS の記述にも気をつけましょう。余裕があれば Learn CSS などのサイトで体系的に CSS を学んでおくとより良いです。
実装のデザインチェック
大きな手戻りを防ぐためにも、なるべく早めにデザイナーとデザインチェックをする時間を設定しましょう。
また、前節で書いたように、全体を通したユーザー体験に問題がないかをチェックするためにも、静的なキャプチャーではなく、実際に動いているものをデザイナーにチェックしてもらいましょう。実際にデザイナーが触って確認できるように、キャプチャや Gif の他にも、QA 環境の URL を用意しておくと良いです。
まとめ
前半では、デザイナーと上手く協働するための心得について 4 つ紹介しました。大切なこととして、共通の言語を用いてコンテキストを共有すること、Figma などのツールを用いること、デザイン以外の側面にも気を向けること、デザインを実際に議論する場を適切に設けることがあります。また、後半では、スムーズに仕事を進めるための心得について、実際に 5 つのステップでデザイナーと関わりながら仕事をすることと、それぞれのステップで気をつけるべきことを説明しました。
デザイナーと上手く協働することで、より早く、より品質の高いプロダクトをユーザーに届けることができるようになります。 一方で、現実では、リモート環境であったり、リソースが限られている場合であったり、外部のデザイナーと協力する場合であったり、様々なケースがあります。その場合も臨機応変に対応しながら、デザイナーと協力して、より良いプロダクトを一緒に作っていきましょう。