フィードバックとの向き合い方
序
おおよそデザインというものは、ただデザイナーの独力で行えるものではなく、常に内外問わず、「誰がしか・何がしか」の意図やコンテキストを含んでいる。
デザインの表層はシンプルに見えても、うちに混沌とした複合的な思惑を孕むのがデザインである。
また、何らかのアウトプットがあったとして、それを届ける対象が不在なのであれば、それは「アートを呼称した何か」であるか、もしくは「デザインっぽい何か」であり、デザインは他者との関係なしにはそもそも成立し得ない。
デザインに対する、誰かの反応・感想・意見・批判を、まるめてフィードバックと呼ぶとする。これはデザインの作り手側・受け取り側を問わない。
フィードバックの受ける側の課題
序文の導入がやや哲学的に振れたので文体が硬い。この調子で書き続けることは困難なので、ここからはいつも通りの感じで書いていきます。
😇 いつも通り、僕自身がデザイナーのため、デザインを主体として書いていますが「デザイン」を「仕事」と読み替えてもらっても読めると思います
この記事では、なにがしかのアウトプットをした時に、それを見る人がいる以上、内外問わずフィードバックは必ず発生するのだけど、それを受け取る側が、どう取り扱ってデザインをより良くしていくか、みたいなことが書きたかったりします。
フィードバックのやり方、みたいな話はよく聞く気がするんですが、受けて側の話ってあんまりされてないような気がしたので…
さて、デザインを作っていく過程でよくある問題のパターンを記憶の扉を開らきつつ書いていきます。
フィードバックがうまく集まらない
フィードバックが多くてどうしたらいいかわからない
フィードバックを取り入れてみたものの全体としてまとまらない
フィードバック偉い人A偉い人Bで真逆だけど…（詰んだ…？）
フィードバックをもらったけど「そもそも論」だし…（キックオフからやり直す？）
フィードバック細かすぎてつらい（そこの色指定、Gray-4がGray-3になってるの気づく？）
これ以上具体的に書くと人生に問題が発生しそうなのでこのくらいにします。あと、つらくなってきた。
やや抽象化すると、
フィードバックの収集
フィードバックの処理
フィードバックの捉え方
このあたりをどうにかすると良さそうです。
そしてこれらは、受け手側がフィードバックにどう向き合いどう扱うか、ということでおおむね解決できそうです。
フィードバックは「する側」に問題があることももちろんありますが、それをどうこうするのはカロリー高いし、完璧はそもそも無理なので、「受ける側」がうまく取り扱う方が生産的だと思っています。
フィードバックにどう向き合うか
フィードバックはデザインをより良くするためのタネ
繰り返しになりますが、デザインは、それを見る人がいる以上、内外問わずフィードバックが発生するものです。
それは肯定的であったり否定的であったり、あるいはほとんど何の反応もないというようなケースもあります。そのどれもが（無反応ですら）一つのデザインに対する「反応」であるという認識を持つと良いと思います。
論理の飛躍のない論文が何も語っていないのと同じように、何の反応も示されないアウトプットはデザインではなく「デザインっぽい何か」です。
得られたフィードバックがどんな反応であるにせよ、受け手側はデザインをより良くするタネをもらったと受け取り、それを生かす方策を考える方が生産的だと思います。あと、そう思ってると変に病みません。
フィードバックの「事実」と「解釈」を分ける
フィードバックを受ける時に、「事実」と「解釈」という軸で整理をしてみるのも一つの手法として取り入れやすいです。特にたくさんのフィードバックを整理選別する際に有用です。
このテキスト、色が薄くて読みづらい
このテキスト、ウェブアクセシビリティガイドのコントラスト比を保てていない
この2つのフィードバック、おそらく結果としては同様の修正をいれることにはなるフィードバックですが、前者は観測者の「薄いから読みづらい」という解釈が入ってます。後者はデータに基づく指摘なので事実としていいでしょう。
フィードバックが事実であり、誤ったデザインであれば直す、解釈が含まれるのであれば、事実もしくは事実に近いかどうかを検証し、これも直すべきであれば直す。シンプルに対応しましょう。
もちろん、「事実」「解釈」どちらのフィードバックが良い悪いという話ではないです。
デザインが公開される直前の場合、デザインの穴を埋めてブラッシュアップに役立てるという意味で「事実」のフィードバックを多くもらうほうが品質を高めることができますし、デザインがまだプロトタイプレベルの場合、「解釈」を含んだフィードバックの方が改善に繋げやすいということもあり、どちらも有用であることには変わりありません。
良くないのが、「事実」「解釈」がごっちゃになると（おおむね「解釈」が「事実」として扱われることが多いのですが）最終的なアウトプットにまとめる時に、1つのデザインとして整合性が取れなくなる事態を招きやすいことです。
1つのデザインに対して100の「事実」を修正するのは容易ですが、100の「解釈」を統合し修正するのは比較的困難です。
大量のフィードバックの波に飲まれそうな時には、まずは「事実」のフィードバックを片付けて、集中するべき「より良くするためのタネ」を選別するようにすると、思考がシンプルになって良いかと思います。
よりよいフィードバックを集める「タイミング」と「縛り」
デザイン、特にUIデザインなどはさらに顕著ですが、フィードバックをする側に専門性がなくても、反応しやすく意見が言いやすい分野でもあり、フィードバックは比較的集まりやすいとも言えます。
その上で、フィードバックが集まらない、良いフィードバックが得られないと感じる場合は、おおむね以下のケースかと思います。
フィードバックを受ける側がフィードバックを怖がっている
フィードバックを集めるタイミングを間違えている
フィードバックをする側が何を求められているか把握していない
1つ目の「フィードバックを怖がる」については、アウトプット慣れしていなかったり、完璧主義だったり（デザイナーには比較的多い）、フィードバックを「批判」と捉えてしまっていたり、過去に悪いフィードバックをもらったトラウマだったり…と色々と理由はあるのですが、
前述の通り、フィードバックはデザインに対してのあたりまえの「反応」であるので、それが否定的であったり感情的であったりしたとしても気にする必要はなく、怖がる必要もありません。
これは「フィードバックを集めるタイミング」にも関わりますが、「デザインを人に見せる」時に完璧であろうとするのではなく（そもそも無理なので）、中途半端に思える状態でも人に見せて、フィードバックを得る方が結果デザインはより良くなる、と思います。
フィードバックは怖くないです。
2つ目の「フィードバックを集めるタイミングを間違えている」についてです。
例えば99%仕上がっている状態のデザインがあったとして、「ご意見ください！」とフィードバックを求められたらどうでしょうか？
おそらく重箱の隅をつつくようなフィードバックしか得られないでしょう。
逆に紙にペンでざっくりと書いたワイヤーフレーム（デザインを行う前の設計図のようなもの）の場合はどうでしょうか？
開発経験のある人ならこの段階でどういうフィードバックを行えば良いか、経験値でわかるかもしれませんが、そうでない人にとっては何をフィードバックしていいのやら…となると思います。
フィードバックを受けるタイミングは重要です。前者の例ではタイミングが遅すぎ、後者では早すぎです。
「どのような完成形になるのか想像はできる」が「骨子はできているが細部までガチガチに詰まり切っていない」ちょうど良いタイミングでフィードバックを得るのが良いと思っています。感覚でしかないですが、6〜７割の完成度、というところでしょうか。
慣れていないと「中途半端な状態でフィードバックもらうなんて…」と思うかもしれませんが、より良いデザインのために積極的にデザインを「晒す」勇気も大事かもしれません。
詳しくはこちらで↑
3つ目の「フィードバックをする側が何を求められているか把握していない」ですが、これも前述の例を使って説明すると、この時フィードバックを受ける側は「ご意見ください！」とざっくりと聞いています。
やりがちなのですが、フィードバックを求める時にはざっくりではなく、具体的にどこにフィードバックが欲しいのか、あらかじめ開示しておく（縛りを設ける）とより良いフィードバックが得やすいです。
この縛りがない状態で、デザインに対してユーザーのインタビューを行ったり、会社内でのレビュー会などを行っても、チグハグなフィードバックになってしまう恐れがあります。
プロダクトのリリース前の機能チェックをしたかったのに、未来の改善案しかでてこなかった
デザインの大枠の構成に意見をもらいたかったのに、文字のサイズや機能のバグなど細部の指摘にとどまってしまった
前者では「事実」のフィードバックが欲しく、後者では「解釈」のフィードバックが得られると良い結果と言えるのですが、事前の「縛り」を共有しておかないと、不毛な時間になりがちです。
「どこを見て、どんな種類のフィードバックを得たいのか」が明確であれば、99%仕上がっている状態のデザインであろうが、紙にペンでざっくりと書いたワイヤーフレームであっても、適切なフィードバックをもらえる可能性は高まります。
「あなたたちの」フィードバックはオーダーではない
フィードバックをオーダーにするのは「デザイナーである私」
意外に長くなったのでこれで最後にします。というかこの項を書きたかっただけなのに長くなってしまった…
「フィードバックはオーダーではない」当たり前ですが現場にいると忘れがちです。全部のフィードバックを取り入れたらデザインはおかしくなる、わかり切ったことなのに、人は忘れる生き物です。
フィードバックはバイアスがかかりやすく、自分より経験が多い、会社での地位が高い、プロダクトの長年の利用者である、単純に声が大きい、などはフィードバックをオーダーと勘違いさせやすい例です。
何度も繰り返しますが「フィードバックはデザインをより良くするためのタネ」なので、それはオーダーではなく、その取捨選択と統合はフィードバックの受け手であるデザイナーの責任として「決定」されます。
あえてデザイナーと書きましたが、デザイナーの仕事の9割9分まではフィードバックの取捨選択・統合であると思っていたりします。
前述の通り、フィードバックには様々な人の「解釈」が少なからず入り込みます。それはフィードバックをする側の様々なコンテキストや思惑が反映され、時には人によって逆のことを言われて困ったり、同じようなフィードバックがあったとしても、どちらが優れたものか迷うこともあるでしょう。
それでも強い気持ちでフィードバックを取捨選択し、時に不均衡にみえる解釈を統合しより良い選択肢とすることが、デザインを取り扱う人の役割・責任であり、フィードバックに真摯に向き合う姿勢であると思います。
終わりに
この記事は「数十人のエンジニアとビジネスサイドのメンバーがいる組織にジュニアのデザイナーが一人突っ込まれフィードバックの渦に巻き込まれて無になった」という事例を聞いて僕自身が無になり、発生したものです。
デザインに幸あれ。