自分の意見をユーザーの声として代弁させない

自分の意見をユーザーの超えとして代弁させない

格言:大本あかね / 記事作成:あやぱん / イラスト:ナユミ

チームで課題や施策を提案するときに、自分の意見なのにユーザーの声として代弁していませんか?
とくに開発に関わっている方は、自分の意見や感覚を過信して「ユーザーはそう思うに違いない」と、思い込むことがあります。実際にユーザーがどう思うかは、利用しているユーザーに聞かなければわかりません。
「自分の意見は一般的だ」と思い込んでしまうと、開発者視点のプロダクトになってしまうため、注意が必要です。

ユーザーと開発者は視点が違う

ユーザーがプロダクトを使用するコンテキストを理解しないまま、開発してしまうことがあります。開発者としてバイアスもかかっているため「ユーザーとして利用していない自分の意見は一般的ではない」ということをまず理解する必要があります。

以下の図は「Don’t Make Me Think」の翻訳本である「ウェブユーザビリティの法則」の書籍で取り上げられている制作者とユーザーのサイトの見え方を表した図です。
1枚目の図は、開発者であるデザイナー自身が見たサイトの様子です。隅々まで細かくデザインされたサイトが見えています。また、自身が開発しているためどこをクリックしたらどんなページに遷移するかの導線も明確でしょう。 デザイナーが作ったサイト

(引用:「ウェブユーザビリティの法則」より)

一方、2枚目の図は同様のサイトをユーザーが見た場合の見え方です。視覚的にはサイト全体が見えているものの、実際にユーザーが目にするのは自分に関わる情報のみに着目します。「チケットを買いたい」と考えているユーザーは「チケット」の文字に着目しそれ以外はほとんど認識していません。どのページに行けば自分の求める情報があるのかも分からないため、手がかりのありそうなボタンをとりあえずクリックして探す動きをします。
ユーザーが見るサイト

(引用:「ウェブユーザビリティの法則」より)

ユーザーと開発者では、コンテキストや視点・前提知識が全く違います。「そもそもユーザーと自分たちは状況が違う」「ユーザーに完全になりきることは難しい」ということを理解することが必要です。

ユーザーの声はユーザーから直接聞く

ユーザーの声を知るには、リサーチが必要です。調査手法は様々なので、「何を調査したいのか」を考えてから調査手法を決定することが大切です。
本当のユーザーに対してリサーチできるのがベストですが、操作性を検証するユーザビリティテストは、簡易型やセルフで行うことも可能です。
ただし、前述の通り開発者はユーザーと違う視点を持つため、ユーザビリティテストにおいても開発者は被験者の対象にならないので注意が必要です。本当のユーザーを呼ぶことができないけれどテストをしたい時には、家族や友人・違う部署のメンバーなど、身近で開発に関わっていない方に簡易的に行うのがおすすめです。

ユーザビリティテストの実施方法については、定期ワークショップも開催しているので、ぜひご参加ください。
https://uxdaystokyo.com/articles/event-info/self-usability-test/

blank

あやぱん

現在、スタートアップのWeb制作会社でディレクター・プランナーをしています。UXの知識をつけて、色んな人と関わりながら学んでいきたいと思い、UX DAYS TOKYOに参加。「コンテキストの理解と実践」ワークショップ登壇。