「チームの合意形成」のためのデザインフィードバック ~ 前編 ~
こんにちは! 初登場 TigerspikeのUXデザイナーの川合です。
9月に入りましたが、まだまだ暑いですね。Tigerspikeでは、9/1にメンバー全員で仕事から離れ、奥多摩でBBQやラフティングをしてリフレッシュしました。みなさんはいかがお過ごしでしょうか？
今回は、デザインフィードバックについて書こうと思います。Webサービスやプロダクトを開発するデザイナーやエンジニアにとってフィードバックは大切なプロセスですよね。
「デザインフィードバック」とは、検討中のデザインについてチーム内で意見をもらい、ブラッシュアップすることが主な目的ですが、「チームの合意形成」にも大きく貢献します。今回は、私の経験を踏まえながらご紹介します。
デザインフィードバックのよくある失敗
フィードバックを受ける・与えることは、デザインの合意形成において非常に重要なプロセスの1つです。プロジェクトを円滑に進めるためには、フィードバックを通して、ユーザー視点でデザインを評価し、何に注力すべきかを正しく判断する必要があるからです。
チームやステークホルダーとフィードバックを繰り返すことは、共通の意思を確立し、より良いデザインにブラッシュアップすることができます。質の高い効率的な合意形成ができれば、時間短縮だけでなく、共創を促進し、結果としてサービスの質を高めることにもなるでしょう。
一方で、デザインフィードバックの目的そのものが大雑把であったり、曖昧であるために議論の方向性がズレてしまい有益な会話や議論が生まれない、「共創」したいのに、いつしか自分基準の意見を言い合う「競争」になってしまった経験などはありませんか。
各々が自分自身の見解を述べずに、他の誰かのフィードバックにただ賛同すればいいと考えていたら「合意形成」を得るという点では容易と感じるかもしれませんが、それでは貴重なアイデアや意見を逃してしまい、正しい合意形成とは言えません。
そうなってしまう理由は、これまでの経験において以下の3点が主な原因でした。
- デザインフィードバックの目的、前提条件が共有されない。
- 色や形など表面的な見た目の意見ばかりにフィードバックが集中する。
- チーム内で意見を言う場があまりない、意見に偏りがある。
私は以前、Webサービスやソフトウェアを開発する会社に勤めていたのですが、入社当初はこのような壁に何度もぶつかっていました。
失敗から学んだ心がけておきたいこと
どうすれば曖昧なフィードバックを避け、質の高いフィードバックを得られるかポイントを整理しました。
1.前提条件を確認しよう
デザインフィードバックは、デザインに期待される解決策を達成すると思われるかどうかを判断する方法の1つです。デザインの目的そのものがシェアされていない状態では、個人的な色の好みであったり、他社のサービスに比べると〇〇が異なるなど、表面的なフィードバックが優先されてしまいます。もちろん、表面的なフィードバックが必要となる場合もありますが、多くの場合は本質的なフィードバックからデザインを判断をすることが多いはずです。
解決しようとしているデザインの問題について何の説明もなく、いきなり解決策の話を始めるのではなく、それがデザインの目的とどう関連しているか、前提条件を明らかにする必要があるということです。
前提条件は、下記の3つのポイントを抑えるとスムーズに共有することができます。
1.解決しようしている課題は何か (デザインの目的)
「〇〇の課題について解決策を考えています」
2.具体的なユーザーの人物像、望ましい体験を生み出すストーリー（ペルソナやシナリオ）
「ユーザーは家でスマートフォンを使いながら、〇〇しています」
3.望ましい体験を実現するデザインのコンセプト（デザイン原則）
「〇〇の情報の優先度が高く、視線移動を考慮し、情報を見つけやすくします」
デザインフィードバックでは、デザインの目的と文脈の共通理解は重要なポイントです。そうすることで、実際に生み出されるデザインは目的にどれくらい近いか？まったく異なるものか？目的に反する働きをするか？導くことができます。
2.フォーカスする対象から適切な方法を選ぼう
目的のために機能していると考えられるデザインの要素(色・形・コンテンツ・レイアウトなど)は何かを考えます。次に、その要素からデザインが有効か検証する最も効率的な方法を選びます。
ここで言う「効率的な方法」というのはデザインにおいて、フィードバックの目的を達成するための「アウトプットに要する時間」とします。そして多くの場合、「アウトプットに要する時間」は、「ビジュアルの完成度」と「操作フローの完成度」に比例し、完成度が高いほど実際の製品に近しいものであるため、作るのに時間を要します。
「アウトプットに要する時間」＝「ビジュアルの完成度」×「操作フローの完成度」
すべてのプロジェクトに当てはまるとは限りませんが、今回は目的別に4つのパターンにデザインのフィードバックを分類しています。
a. ビジュアル 低＋操作フロー 低 (e.g. 手書きスケッチ)
素早く、低予算で何度も繰り替えすことができる。アイデアやコンセプト、機能の俯瞰などにフォーカスしたフィードバックを得やすい。
b. ビジュアル 低＋操作フロー 高 (e.g. ワイヤーフレームによるクリック可能なプロトタイプ)
ユーザビリティの評価、ユーザーの導線などにフォーカスしたフィードバックを得やすい。
c. ビジュアル 高＋操作フロー 低 (e.g. モックアップやビジュアルデザイン)
コンセプトの提示、関係者へのプレゼンテーション、デザインテイストにフォーカスしたフィードバックを得やすい。
d. ビジュアル 高＋操作フロー 高 (e.g. html.cssによるプロトタイプ)
既存サービスの部分的な改善、製品版へリソースの流用、ユーザーへのユーザビリティテストなどで用いられ、実際の利用体験にフォーカスしたリアルなフィードバックを得やすい。
例えば、ユーザーの課題に対して解決策となるアイデアを素早く視覚化し、より具体的なアイデアへ議論を展開したい場合は、それがイメージできる要素を含んだラフスケッチを作成し、アイデアのフィードバックを得ることにフォーカスします。その場合、色やトーンといったビジュアルのフィードバックにフォーカスする必要がないため、あえて色彩を含まないグレースケールで表現することが考えられます。
長くなりましたが、今回はここまでとなります。前編ではデザインフィードバックにおいて、前提条件の共有と適切な方法の選択が大切という内容でした。後編は、デザインフィードバックを行う上で必要なマインドセットについて、Tigerspikeで取り組んでいることなどを踏まえてご紹介したいと思います。
3.さいごに
現在Tigerspikeでは、一緒に楽しく仕事ができる仲間を募集しています。詳細は弊社HPもしくはGreenをご覧ください。みなさんのご応募お待ちしています。
