非デザイナーに知ってほしい、デザインのフィードバックでは「何を伝えて」「何を伝えない」べきか

社内のデザインチームや外部のデザイン会社が作成したデザインに対してフィードバックをするとき、どのようにフィードバックすべきか、効果的なフィードバックができているのか、悩んだことはないでしょうか。

本記事では、デザインのフィードバックをする際に、何をどのように伝えればよいかを明確にするためのポイントを紹介します。特に、ビジネス職の立場でデザイナーと関わる方に向けて、効率的かつ効果的なフィードバックを行うために意識するべき点や確認するべき観点を解説します。

これまでi3DESIGNでデザイナーとして働いてきた経験を踏まえ、実務で役立つ具体的な視点やノウハウを盛り込んでいます。記事の内容は、フィードバック時のチェックリストとしても活用していただける構成になっていますので、ぜひお役立てください。

なぜデザインのフィードバックが難しいのか

デザインに対してフィードバックするとき「なんとなく違う」「もっと良くなりそう」という感覚は持っていても、それを言語化してデザイナーに伝えることは難しいものです。

その理由の一つに、デザインをフィードバックする観点が曖昧であることが考えられます。デザインを判断する基準や観点が明確になっていないため、担当者によってデザインに対する解釈が様々になり、非効率的なデザイン修正が発生しているケースをよく目にします。

例えば、以前「色のバランスが合っていないと思います」というフィードバックをいただいたことがありました。一見シンプルな指摘ですが、実際にデザインの対応をする上では解釈が分かれてしまい、社内のデザイナー間でも「どこの配色が合っていないのか」が曖昧な状況でした。

さらに、クライアントのメンバーの方々の間でも「この色の明るさが気になる」「いや、この配色が悪いのでは？」と意見がバラバラで、最終的にいくつものパターンを作成し、調整が難航した経験があります。

「色のバランス」という言葉が悪いわけではありませんが、指摘箇所や意図が曖昧だと解釈が人によってさまざまに分かれるため、コミュニケーションに時間がかかります。その結果、プロジェクト全体の進行にも影響が出る、といった事態につながりかねません。

デザイナーとしては、フィードバックの背景や意図を補足してもらえると非常に助かります。では、具体的にどう伝えればよいのか。次の章で、効果的なフィードバックの伝え方を解説していきます。

フィードバックの基本原則

一般的なフィードバックの原則は、デザインに関するフィードバックにもそのまま応用できます。基本的な原則を具体例とともに紹介し、デザイナーとのコミュニケーションをスムーズにするためのポイントを解説します。

1. 根拠を明確にする

指摘内容の理由や意図を伝えることで、フィードバックを受け取った人は納得し、原因を考えることができます。デザインに対してのフィードバックでは、デザイナーが別のアプローチを考えることができたり、誤った修正を防ぐことにも繋がります。

2. 具体的な表現を心がける

曖昧な表現は相手に伝わりづらく、フィードバックの効率を低くします。

デザインに対してのフィードバックでは、「なんとなくカッコ悪い」「もっと良くなりそう」と感覚的な違和感だけでなく、どの部分がどう改善できそうか、を具体的にすると建設的な議論をしやすくなります。

3. フィードバックまでの時間を空けすぎない

フィードバックのタイミングは、プロジェクト全体の効率や品質に大きく影響します。

フィードバックの間隔が空いてしまうと、デザインの記憶がそれぞれ曖昧になり、チーム全体の認識にズレが生じ、完成形のイメージがばらばらになることがあります。また、関連している箇所の修正ができなくなり調整が後回しになる場合や、一度修正したデザインを再検討する必要が出てきて、さらなる時間と労力を要することになる場合もあります。

そういった問題を防ぐためには、各フェーズごとにフィードバックを行う期間を設けたり、どのような観点でフィードバックするかの基準を作成してフィードバックに迷う時間を減らす取り組みが効果的です。

4. 属人的な意見である可能性を意識する

フィードバックをする際には、自分自身の好みや感覚にとどまらず、プロジェクトの目的や対象ユーザーに即した意見を伝えることが大切です。

例えば「この画面は爽やかな印象にしたいので、水色のほうが良いと思います」というフィードバックがあったとします。このようなコメントを受けたとき、デザイナーは「本当に水色がベストなのか？他にも爽やかな色はあるのではないか？」といったことを考えます。

このように、「AだからBにして」というような理由付けがあるとき、デザイナーとしては「本当にAならばBなのか？Cもあり得るのではないか？」といった具合に、深掘って考えていきます。

そのため、フィードバックを伝える際には、自分の要望が客観的な理由に基づく意見なのか、それとも個人的な好みが含まれている意見なのかを少し考えてみていただけると、デザイナーとのやり取りがよりスムーズになるかもしれません。

デザインフィードバックを行う際に確認したい観点

一つ前の章では一般的なフィードバックについて説明しました。

ここからは特にデザインへフィードバックをするときに、何を意識し、どのような観点でフィードバックをするべきか、について具体例とともに紹介したいと思います。

1. ビジネス目線とユーザー目線のバランスが取れているか

ビジネス上の数値目標を達成するために、ユーザー体験を悪化させるデザインの事例を「ダークパターン」と呼びます。

デザインのダークパターンは以下のような例があります。

• 文章やデザインによって、ユーザーに選ばせたい操作や選択肢を強調したり、誘導したりする。
• プランの解約や退会の導線を隠し、ユーザーが解約や退会をしにくいように手間のかかる操作を強制する。

ダークパターンの他に、CVボタンを目立たせるためにサイズを極端に大きくしたり、デザインのトーンから逸脱した色を使用することは、結果的にデザインの世界観を損ない、ユーザーからの印象を悪くしてしまう原因となります。

こうした手法は一時的にビジネス上の成果を得られるかもしれませんが、長期的なユーザーの信頼やブランドイメージに悪影響を及ぼす可能性があります。

フィードバックを行う際には、「デザイナーはユーザー目線に立ってデザインしている」という前提を意識することが大切です。

もちろん、必ずしもビジネス目線が悪いわけではありません。重要なのは、ビジネス目線とユーザー目線のバランスを意識することです。

ユーザー目線を追求するとビジネスにおけるゴールの達成が遠ざかるように感じることもあるかもしれません。しかしデザイナーが考える「ユーザー目線」は、長期的にはビジネスのゴールにもつながる可能性があることを理解し、フィードバックを行う際にはデザイナーの視点を考慮に入れるよう心掛けていただけると嬉しいです。

2. アクセシビリティが考慮できているか

アクセシビリティは、多様なユーザーがシステムを平等に利用できるようにするための取り組みです。視力が低い方や高齢者など特定のニーズを持つ方だけでなく、例えば明るい屋外でスマートフォンを使う際に画面が見えにくい場合など、誰もが直面する利用環境の課題に対応します。

例えば、以下のような観点でチェックしてみてください。

• 文字はストレスなく読むことができるか
  • 文字と背景のコントラストが低かったり、文字サイズが小さすぎたりすると、ユーザーは認知負荷が増え、画面の拡大などの操作をしなくてはいけなくなります。
• 色に依存したデザインになっていないか
  • 例えば、ユーザーにエラー状態であることを伝えるときは、”どの部分が原因でエラーになっているのか”、を明示すべきです。
  • しかし、エラー状態であることを赤い線や赤い背景色だけで表現してしまうと、色覚特性を持つユーザーにとっては状態の認識が困難になります。
• キーボード操作でコンテンツにアクセスできるか
  • スクリーンリーダーなどの支援技術を使用しているユーザーやマウス操作が困難なユーザーは、キーボードでコンテンツにアクセスします。
  • Tabキーなどでフォーカスを移動することができるか、画像やアイコンなどのコンテンツはスクリーンリーダーで読み上げることができるか、などを確認します。

こうした基準は、ウェブアクセシビリティの国際的な指針であるWCAG（Web Content Accessibility Guidelines）に基づいて定義されているため、プロダクトのアクセシビリティを判断する一つの基準になります。

3. 実装が可能かどうか

デザインは、ユーザー体験の観点だけでなく、技術的に実現可能かどうかも考慮する必要があります。
例えば、Webアプリとネイティブアプリでは、使用する開発言語や環境が異なるため、それぞれで実現可能な機能や表現に違いがあります。また、基盤となるシステムの設計によっては、特定の機能を実装することが困難な場合もあります。

詳細な内容だとデザイナーも技術的な観点での知見が足りず、実装可能かの判断ができない可能性もあるため、知識や経験のあるエンジニアに確認を依頼するのも有効な方法です。

4. 全体のデザインとの整合性が取れているか

見た目や操作、文章表現などが統一されていると、アプリケーションを通して一貫した体験や印象をユーザーに持ってもらうことができ、ユーザビリティを向上させることに繋がります。

全体のデザインとの整合性が取れていない例としては、以下のような状況です。

• アプリケーション全体の文末表現は「〜〜しましょう。」「〜〜です。」を使用しているが、一部の文章では「〜〜しよう！」「〜〜だよ。」が使用されている。
• CVを重視するために、あるボタンだけ派手な色になっている。
• 同じ文脈で使用される同じ機能だが、操作方法が異なる。

全体のデザインの整合性が取れていないと、ユーザーはエラーを起こしやすくなり、操作方法を学習する負担が多くなります。

デザイン全体を俯瞰し、個別の要素だけでなく全体のバランスや整合性を確認することでユーザビリティをより良くするためのフィードバックを行うことができます。

5. 具体的な「指示」をしない

フィードバックの基本原則「2. 具体的な表現を心がける」では、具体的な表現を心がけることでデザイナーへのフィードバックの質が上がるという説明をしました。

デザインへのフィードバックにおいて「具体的な表現」は良いのですが、その上で「具体的な指示」はしない方が望ましいです。

具体的な指示をしてしまうと、ある課題に対して本質的な原因を解決する機会が失われてしまい、結果的にベストなユーザー体験を設計できない可能性があります。

この例の場合、ユーザーがボタンにすぐ気づけるようにするには「ボタンの位置を上に移動する」以外にも、ボタンの色や画面全体のレイアウトを変更するなど、さまざまな選択肢が考えられます。

具体的な指示を出してしまうと、デザイナーの発想力や想像力に対する制限になってしまうことがあるため、課題に対する解決策をデザイナーが自由に考える余地を残しておいてもらえると嬉しいです。

デザインフィードバックに使えるツール

最後に、デザインへのフィードバックをする際に、実際に開発の現場で使用されているツールを紹介します。

1. デザインツール（Figmaなど）

UIを作成するためのツールには「Figma」「Adobe XD」「Sketch」などがあります。

例えば、Figmaはデザインやプロトタイピングに特化したクラウドベースのツールで、UI/UXデザインやワイヤーフレーム作成、モックアップの作成に広く使用されています。

デザインツールのコメント機能を使用してフィードバックするときのメリットとしては、デザインやモックアップに直接コメントを書き込むことができる点です。該当箇所にコメントを残し、作業が完了したら非表示にできるため、迅速なフィードバックとデザイン修正が必要なケースに向いています。

デメリットとしては、コメントが大量についた場合の管理コストが高いことです。デザインツール上のコメント機能ではフィードバックの優先度や種類が一目では判断できないため、全てチェックして常に内容を把握する作業が発生します。

2. 表計算ツール（Excel、Airtableなど）

データテーブルのようにしてフィードバックをまとめるメリットは、フィードバックの内容に対して、優先度や期日、起票者、担当者、該当箇所などをプロパティとして整理することができる点です。対応ステータスのプロパティを用意すれば、修正の進捗状況を管理することもできるため便利です。

デメリットは、デザインツールとフィードバックの表を行き来して確認したり、更新したりする手間がかかる点です。

3. スライド作成ツール（Power Point、Google スライドなど）

スライド作成ツールでフィードバックをまとめるメリットとしては、簡単にデザインを作成してイメージを伝えることができる点です。

前提となるコンセプトを一連の流れで伝えた上でフィードバックしたいときや、画像や資料などを使ってイメージを伝えたい時に便利です。

デメリットは、表計算ツールと同じく、デザインツールとフィードバックの表を行き来して確認したり、更新したりする手間がかかる点です。また、スライドのページ数が多い場合、どこに該当の指摘があったのか振り返ることが困難になります。

まとめ

デザインのフィードバックには一定の専門知識が求められることもありますが、確認すべきポイントを把握していれば、効果的かつ効率的なフィードバックを行うことが可能です。本記事が、フィードバックの質を向上させ、より優れたプロダクトの作成につながる一助となれば幸いです。