エンジニアのユーザーテスト参加のススメ

f:id:marikoGp:20210903164157j:plain GoodpatchでUXデザイナーをしている村上と申します。 突然ですが、開発を担当しているプロダクトのエンドユーザーの反応を実際にみたことはありますでしょうか?

この記事ではGoodpatchのとあるクライアントワークにてエンジニアがUXデザイナーの実施するユーザーテストに同席した際の経験をインタビューして、まとめてみました。

ユーザーテストとは

すでにご存知の方も多いかもしれませんが、ユーザーテストとはプロダクトを実際のエンドユーザー(又はエンドユーザー候補)に使用してもらい、その反応やその後のインタビューを通じて改善ポイントを探ることです。

なお、今回はある程度ユーザーテスト設計や運営を行えるUXデザイナー/リサーチャーいて、そこにエンジニアが同席をするという前提で執筆しているため、ユーザーテストの設計や運営に関する詳細は省かせていただきます。

ユーザーテストにエンジニアがどうやって参加するのか

事前準備

プロジェクトの体制にもよりますが、UXデザイナー/リサーチャーがいる場合はユーザーテストの設計やテスト時のメインモデレーターはその人に任せてしまう方が良いでしょう。 一方、プロトタイプの種類にもよりますが、テクニカルプロトタイプを準備する場合は、テストシナリオに合わせて被験者がリアルな利用体験を得られるようなプロトタイプをエンジニアが作る役割を担う場合があるかもしれません。

ユーザーテスト実施時

当日はテスト現場に同席し、モデレーターが話している間はユーザーの発言や行動から印象に残った箇所のメモを取ったり、疑問があった場合は最後のインタビュータイムで直接ユーザーに質問をしたりする場合が多いです。実際の段取りは事前にモデレーターとすり合わせておくとスムーズでしょう。

テスト結果のまとめ及び改良方針の検討

ユーザーの発言やテスト結果を事実としてまとめ、その解釈と改善方針をデザイナーとエンジニアで共同で議論しながらワーク形式でまとめていきます。

例えば、画像のように、オンラインホワイトボードかまたは付箋等を使ってまずはユーザーの発言を並べ(緑付箋)、それに対して各々が分析した結果(黄色付箋)を記載していきながら対応方針をその場でディスカッションしていきます。

f:id:marikoGp:20210903163031p:plain

ユーザーテストにエンジニアが参加するメリット

その1 伝達のタイムラグがないのでクイックに検証サイクルを回せる

実際にテスト現場やインタビューを見ているので、UXデザイナー/リサーチャーがテスト結果をまとめるのを待たずにリアルタイムで結果を知り、改善策に取り掛かることができます。

その2 伝聞にならないので情報の欠落なく結果を理解できる

どんなにテストやインタビューの結果が素晴らしくまとまっていても、どうしても間に別の人の解釈が混じってしまうと抜け落ちてしまう情報があります。その点自分の目と耳で見た一次情報の場合、より正確に実際のユーザーの反応を理解することができる可能性が高まります。また、デザイナー視点だと見逃してしまう大事な情報を、エンジニア視点でみた時に気が付けることもあります。

その3 仕様や機能の優先度決めを全員がユーザー視点を取り入れて納得感高く決められる

通常ユーザーテストやインタビューにエンジニアが参加していない場合、仕様や機能の優先度を決めるときは開発工数での議論が主になってしまいがちです。ところが、デザイナーとエンジニア双方がユーザーの生の声を聞いていると、その情報を共通認識とした上で議論ができるので、優先させるべき機能や仕様を全員が納得感を持って決断をすることができるようになります。(実際にはここにビジネス観点も入ってきますが、それでもビジネスサイドのプロダクトマネージャーも合わせて同じインプットがあれば理想の状態と言えるでしょう。)

まとめ

何をしたらいいか分からなくても、ユーザーテストやインタビューに同席してエンジニアの視点で感じたことや思ったことを素直に共有するだけでもプロダクトの改善に関する有益な気づきをチームに与えられる可能性が大いにあります。

大規模な開発プロジェクトになるとこういったコラボレーションも難しくなりがちですが、新規事業の初期のプロトタイピングフェーズなどにおいては今回ご紹介したようにエンジニアの方もユーザーテストにガッツリ参加することを検討してみてはいかがでしょうか。


Goodpatch には、デザインと技術の両方を追求できる環境があります。 少しでもご興味を持ってくださった方、ぜひ一度カジュアルにお話ししましょう!