見出し画像

フィードバックの射程を捉える

皆さんは、プロダクト開発に携わるデザイナーとしてフィードバックを受ける機会はどのくらいあるでしょうか。

画像6

フィードバックの場は、仕様の抜け漏れやの技術的懸念の確認、デザイン以外の観点を得るための貴重な機会になります。特にジュニアデザイナーの時期は、引き出しが少ないこともあり、たくさんのフィードバックを受けることが推奨されると思います。

では、ただ闇雲にたくさんのフィードバックを受けれればそれでよいのでしょうか。それが無限にできる環境であればそれに越したことはありませんが、仕事という決められた時間枠のなかに無限の時間はありません。そのため、フィードバックを効率的に受け取りにいくことは重要なことだと考えられます。

そこで今回この記事では、フィードバックの種類を分類し、ステークホルダーとの関係性を同心円状に整理することで自分との距離感を明らかにし、対象ごとのフィードバック内容を明らかにしていきます。

本記事の要点
・フィードバックの種類を分類して自分を中心とした同心円状に整理する
・各ステークホルダーとの距離関係と、受けることのできるフィードバック内容を明らかにする

これまで暗黙的に行っていたことを改めて目に見える形で整理した結果、いろいろ見えてくるものがありました。


デザインをアウトプットするプロセス

唐突ですが、皆さんはもし、プロダクト開発におけるデザインをアウトプットするプロセスって「あるべき姿から逆算するの?」それとも「具体的に表現したい部分を積み上げていくの?」という問いを与えられたときに、どんなふうに答えるでしょうか。

僕の回答としては、プロダクト開発におけるデザインをアウトプットするっプロセスは、

「逆算」と「積み上げ」のアウトプットの連続

によって組み立てられていくものだと考えました。つまり、デザインは完成形に向かっていくプロセスの中で逆算と積み上げの両方を連続的に行っているわけです。

そのとき、なぜその連続性が生まれるかを整理していくと、全体のプロセスの中に「フィードバック」という機会が含まれているからだということに気がついてきました。

ざっくりですが図に起こすとこんなイメージです。

画像1

①あるべき姿を定義(定義まではいかなくても認識を揃える)
②あるべき姿から逆算をして作り上げるべきデザインの輪郭を明らかにする
③そのデザインに対してフィードバックを受ける
④フィードバック結果をマージして積み上げる

デザインは、この連続によって組み立てられていくものだと考えます。

この整理きっかけとして、フィードバックがプロセスに組み込まれていることを改めて理解し、これまで得られた自身のフィードバックの体験を思い返したところ、それは分類できそうな気がしてきました。

フィードバックの分類と距離による整理

これまで自分が受けてきたフィードバックは、下記に分類できます。

フィードバックの分類
・チーム内フィードバック
・プロジェクト内フィードバック
・プロジェクト外フィードバック
・(社外フィードバック)

これを自分を中心とした同心円状で整理すると、こんな感じの距離関係であることが理解できます。

画像2


ここでさらに「説明コスト」「時間調整コスト」「得られるフィードバック内容」を付け加えます。(得られるフィードバック内容は、あくまで一例です。)

説明コスト
より効果的なフィードバックをもらうための状況説明

時間調整コスト
フィードバックをしてくれる相手と自分のスケジュール調整など場のセッティング

得られるフィードバック内容
フィードバックで得られる情報の傾向

画像3

図に加えるとこんな感じの関係性です。

画像4

円の中心に近い人からのフィードバック
・説明コストや時間調整コストが低い
・(プロジェクトの詳細を把握しているので、)仕様など具体的な観点からのフィードバックを受けることができる
円の中心から離れた人からのフィードバック
・説明コストや時間調整コストは上がる
・普遍的な規則や法則に則った観点のフィードバックが増える

ただ、外側に向かうほど説明コストや時間調整のコストが上がるため、必要に応じてフィードバックの機会を定例化することは大事なんじゃないかと思います。

また、距離感に応じてコミュニケーションも変わってくると気がつきました。距離が近ければ、抜けや漏れはないかどうか確認を取ることは重要です。

逆に、距離が遠くなれば、抜けや漏れの確認ではなく、気づくことはないか。(気づきのための観点の提供も大事)という問いかけでフィードバックをもらうことが、新しい観点をもらえるきっかけにもなるため重要になってきます。

自分を取り巻くデザイン観点のフィードバック対象者を整理したことまとめ

自分との距離が近い人(チームメンバーやプロジェクトメンバー):
・説明コストや時間調整コストは低い
・フィードバック内容は、抜けや漏れを中心に受ける

自分との距離が遠い人(プロジェクト外メンバーや社外の人):
・説明コストや時間調整コストが高い
・フィードバック内容は、普遍的な規則や法則に則ったことを中心に受ける
・定期的な進捗共有やコミュニケーションの機会を定例化するなどの工夫をする必要がある

プロジェクト健康管理のメトリクスとしての図の応用

思考の整理のために図を起こしましたが、これはプロジェクトのステークホルダー整理でも使えそうかもと思いました。

プロダクト開発では、下記に様々なステークホルダーが登場すると思います。

・チームメンバー
・プロジェクトメンバー
・プロダクトの仕様決定権を持つプロダクトオーナー
・決済権を持つ事業責任者
・スクラムマスター
・ドメインエキスパート
など

それぞれをプロジェクトの状況に合わせて先程の円の図に置いていきます。

画像5

プロジェクトがある程度安定して走っている状況であれば、上記のような納得のいく距離関係が生まれているのではないでしょうか。

プロジェクト初期など関係値が構築されていない段階では、プロダクトオーナーや事業責任者が限りなく外側に置かれてしまったり、逆に事業責任者がプロダクトの細かい仕様のフィードバックにコミットし過ぎているということなどが見えてくると思います。

そういった場合には、役割に応じたリソースの配分調整が必要なので、チームとして、プロジェクトとして、足りていないスキルやどんな人が足りていないのかが把握しやすくなるかもしれません。

UIデザイン、エンジニアリングやマネージメント、組織について考えたことなどを徒然と書いております。リアクションいただけると励みになります!