デザイナーは、良いプロダクトを作る上で欠かせないポジションです。
プロダクトマネージャー（PdM）は、デザイナーやエンジニアと密に連携しながらプロダクトを作り上げていかなければなりません。
しかし、経験不足なチームだとデザイナーと上手く連携できずにプロジェクトが失敗してしまうケースもあります。
デザイナーと上手く意思疎通できず、ころころとデザイナーが代わり、常にデザイナーを募集し続けている会社もよく聞きます。
デザイナーには、プロダクトに関わる全てのデザインをディレクションしてもらう必要があります。
また、担当者のセンスによるところも大きいので、デザイナーがころころ代わってしまえば、プロダクトに統一感も出ませんし、メンバーも疲弊してしまいます。
どのようにデザイナーとコラボレーションし、いいプロダクトを作り上げていけば良いのか。
今回は、自身の経験をもとに、デザイナーに依頼するときのポイントを紹介します。
少しでも参考になったら幸いです。
こんな方におすすめ
どのようにデザイナーに依頼すれば良いか知りたいエンジニア
プロダクトマネージャーを目指していて、デザイナーとの仕事の進め方に不安がある人
デザイナーを含めたチームビルディングに悩んでいるマネージャー
目次
ターゲットと想定ユースケースを明確にする
まずは基本的なポイントにはなりますが、意外と背景を十分に説明せずに、要求もしくはワイヤーフレームだけ渡して依頼するパターンが多く見受けられます。
デザインとは、ユーザが触れる全てのインターフェースを定義し具体化しなければなりません。
ボタンの配置、配色、全ての遷移まで、見た目はシンプルでも、ユーザが達成する全てのシナリオを矛盾せずにシンプルに設計することはとても膨大な思考が必要になります。
当然アウトプットとして考えられるパターンは膨大にあるのです。
その膨大なパターンからユーザの特性、コンテキスト（文脈）、目標などの制約から最適なパターンを選び出さなければなりません。
その「制約」をどこまですり合わせておくかが重要です。
まずは、Who（誰に）、What（何を）、Why（なぜ）提供するのかを言語化し、十分議論しながら明確にしましょう。
依頼の抽象度を事前にすり合わせる
次に、その「制約」はどこまで確定しているのかをすり合わせます。
ワイヤーフレームまで固まっていて、カラーや詳細を詰めて欲しいのか。機能要件だけ伝えて導線含めたユーザ体験から設計して欲しいのか。
ターゲットやユースケースは一つか、もしくは複数あり得るのか。
要はデザイナーにどこまで考えてもらいたいかのスコープを事前に率直に伝えるということです。
ビジネス的もしくは開発的にある程度要件は決まっていて、あまり自由度が必要ない場合は粒度を細かく依頼する必要がありますし、逆に大きくユーザ体験の変更を目指す場合はその背景や目的を伝えて一緒に考えることもできます。
個人的にはあまりガチガチに要件を固めずに、ビジネス上の課題や想定ユースケースなど、Whyの部分を厚めに伝えて一緒に議論しながら作り上げた方が良いアウトプットが出せると思います。
レビュープロセスを決めておく
デザイナーが最終的にアウトプットするものは、ワイヤーフレームやモック、そして各種素材等になります。
しかし、詳細まで作り上げてからレビューを行っていたのでは、仮に差し戻しがあった場合に大きな手戻りが発生する危険性があります。
大きな手戻りが発生してしまうと、デザイナーそしてレビュアーにとって大きな作業ロスとなってしまいます。
Unsteady Stepsそのため、まずは大まかな方針を粗いメモレベルでも良いので決定してから、次の行程に進めるなど考えた方が良いでしょう。
一例ですが、以下のステップで進めると手戻りも少なく効率的に進めることができます。
- ワイヤーもしくは配色のパターンを出して、基本方針を合意する
- 象徴的なページのモックを作りレビューを実施
- 全てのページについてモックを作成（最終チェック）
もちろん途中で社内やユーザにヒアリングなど行う場合は、そういった外部のレビューも考慮してプロセスを設計する必要があります。
技術的な制約を説明する
依頼時に制約を要件として伝える話をしましたが、中には技術的な制約が存在するケースもあります。
エンジニアリングに知見のあるデザイナーであればともかく、経験がなければ中々イメージできない部分だと思います。
ユーザ体験から考えてベストだと思ったアイデアが、実装コストや実現性の妥当性が確認されずにデザインされてしまい、いざ実装するとなったときにエンジニアから差し戻されてしまうケースも多々あります。
Webにしろモバイルアプリにしろ、プラットフォームにおける実装上の原理原則が存在します。
その原理原則から大きく離れてしまうと、パフォーマンスに問題が出たり、必要以上に実装コストがかかってしまう危険性があります。
プロダクトマネージャーが、上流工程でデザイナーに技術的な制約を伝えられることのメリットは大きいです。
フィードバックを適切にファシリテーションする
デザインのフィードバックに対するアプローチは、会社やプロジェクトによって様々でしょう。
中には体制的にフィードバックをあまり実施しないというケースもあるでしょう。
しかし、実装してからの修正は時間的にもエンジニア工数的にも大きなコストがかかります。
可能な限りデザイン段階でフィードバックを実施し、手戻りがないか十分確認することをおすすめします。
では実際にどのようなフィードバックを行えば良いのか？
以下の通り、フィードバックのアプローチは無数にあります。
- プロダクトマネージャーやプロダクトオーナーによるレビュー
- 社内の他のチームにヒアリングを実施する
- ユーザに協力してもらいながらユーザビリティテストを実施する等
注意点として、闇雲にフィードバックを集めても、実際には不要もしくは優先順位の低いフィードバックを拾ってしまう危険性があることです。
実際のユーザと遠い人のフィードバックを受け入れてしまうと、個人的な好みの話になってしまったり、本質からズレたものになってしまいます。
フィードバックを取り入れる際には、次の観点を意識してファシリテーションするようにしてみましょう。
- フィードバックの目的と対象を定義する
- インタビュー相手に背景やコンテキストを伝える
- フィードバックの優先順位をつける
良いプロダクトを作るために誰からどのようなフィードバックを貰えば良いか
ゴールから逆算して考えることで、良いフィードバックプロセスを設計できるようになると思います。
相手のケイパビリティ（特性）を見て依頼する
最後になりますが、人と人が協力してモノを作る上で欠かせないことが相手のことを知ることです。
つまり、相手のケイパビリティ（特性）を判断しながら、依頼の仕方を考えてみるということです。
一口にデザイナーと言ってもそれぞれ得意分野やバックグラウンドが異なります。
コピーライティングが得意な人。UIが得意な人。UXまで設計できる人。ブランディング（世界観）から作れる人など。
これはどういうメンバーを採用、アサインしてチームを作るべきかに繋がる話でもあり、プロジェクトの特徴やフェーズによって設計が必要なポイントでもあります。
もちろん依頼の仕方やレビュープロセスなども同様です。
筆者は今まで5人以上のデザイナーとプロダクト開発をしてきましたが、一度として同じやり方で仕事をしたことはありません。
相手が何が得意で、何が苦手かを把握しながら、どうやったら最高のアウトプットが出せるのか、お互い議論しながら考えてみましょう。
まとめ
いかがでしたでしょうか。
今回は専任のプロダクトマネージャーとデザイナーがチームにいる前提でお話ししました。
会社によっては一部役割を兼任していたり、その他のロール（役割）が存在するケースもあるかと思います。
またtoC向けtoB向けなど、プロダクトの性質やチームの状況によっても、誰がどういう役割を担うのかは変わってきます。
しかしデザイナーは、プロダクトマネージャー（PdM）と同様にプロダクトを作る上で欠かすことのできないロールです。
特に近年だと、プロダクトにおけるデザインの重要度も高まっています。
国内でもプロダクトの初期段階から、専任のデザイナーを置くケースも増えてきました。
プロダクト開発チームとして、デザイナーとどのようにコラボレーションすべきかはとても重要なテーマだと思います。
今回は経験に基づいた内容を紹介しましたが、少しでも皆様のプロダクト開発に役立てたら幸いです。
