見出し画像

フルリモートでユーザーテストが成立するか試してみた

パジェロ｜COMPASS

株式会社COMPASS デザイナーのパジェロです。
自分が所属している開発チームで本格的なユーザーテストが必要になったので、フルリモート体制でどこまで成立するか試してみました。この記事はその覚え書きです。ほぼ社内共有用につき乱文ご無礼です。

背景

僕がデザインを担当する社内向けCMSに、UIの大規模改修を行うタイミングが巡ってきました。
とにかく最速で機能を揃えた、という状態でずっと使ってきて数年経ち、だいぶユースケースも固まってきたので、ユーザビリティと実装拡張性を強化する目的で抜本的に見直そうという動きです。

まずは段取りをつけよう

今回の対象であるCMSは結構な機能と画面数を擁するプロダクトなので、何ヶ月もかけて一気に最後まで完成させるのではなく、機能ごとに区切って短いサイクルでユーザーテストをしながら進めることにしました。できるだけ早い段階でユーザーにとって本当に価値があるかどうかを確かめることが重要だと思ったからです。

さらに、せっかくの機会なのでフルリモート体制でのユーザーテストがどのくらい成立するか試してみることにしました。弊社は普段の業務をほぼフルリモートで行っているため、ユーザーテストも同じ環境で実施できたほうが心理的にも時間的にもハードルが低く済むと考えたのと、定性的なユーザーテストの目的を「素早く繰り返し学習すること」だとした時に、うまくいけばとても効果的だと思ったからです。

今のチームでは本格的なユーザーテストを実施した経験があまりなく、特にフルリモートでのユーザーテストは初体験だったので不安でしたが、ユーザーテストを高頻度で定期的に繰り返す機会というのもそんなに巡ってくるわけでもなく貴重な経験なので、開発チームにノウハウとして蓄積することも意識して進行を組み立てていきました。

改修対象の機能を「ユーザビリティと価値の検証が可能な最小単位」まで細かく分割し、以下の検証サイクルを繰り返すことにしました。

  1. ワイヤーフレーム作成

  2. ユーザーテスト設計

  3. モックアップ作成

  4. ユーザーテスト実施

  5. テスト結果分析

  6. 仕様・デザインFIX

いざ実践

1. ワイヤーフレーム作成

情報設計と体験の軸が伝わるようにざっくりWFを組みます。検証したいのは主にユーザビリティ（理解できるか、使えるか、使いやすいか）と価値（使いたいか、魅力を感じるか）なので、そこが最低限確かめられるレベルのアウトプットを目指します。

ユーザーに当てる前に開発チームのメンバー（PO、エンジニア、QA）にヒューリスティックにレビューしてもらって致命的な問題点を潰しました。

2. ユーザーテスト設計

検証単位ごとに確かめたいことを整理しながら、テスト内容を組み立てていきます。なるべく一回の所要時間を短くするために、最小限の工程で多くのことが学べるように工夫しました。この設計書がテスト実施時の台本も兼ねるようにしました。

3. ユーザーテスト実施

ワイヤーフレームをもとに作っておいたモックアップをユーザーに操作してもらい、その様子を録画しつつ観察します。設計で作ったシナリオに沿って必要な数のモックアップを用意し、専用のリンクからアクセスしてもらうようにしました。
操作中はカメラをオンにしてもらって被験者の表情や目線の動きにも注意しました。
最後にインタビューで、一連の観察から気になったところをピックアップして深堀りしました。

4. テスト結果分析

被験者ごとにメモしておいた「観察で気づいたこと」「インタビューでの深堀り内容」をもとに修正箇所を特定して根拠とともに整理し、開発チームメンバーに共有して方向性の認識合わせをします。

5. 仕様・デザインFIX

方向性が決まったら、具体的な仕様やデザインを詰めてFIXさせ、実装フェーズに移行します。エンジニアさんが実装している間に、自分は次の機能のワイヤーフレーム作成に取り掛かっていきます。

わかったこと

フルリモートでユーザーテスト意外といけるということがわかりました。
対面で実施するよりも得られる情報は減っているかもしれませんが、それでも操作している様子をリアルタイムで観察することで大きな発見がありました。重要な問題点を発見することもできたし、思いもよらない新しいアイデアに巡り合うこともできました。
リモートの利点として、操作してる様子は対面よりもむしろ観察しやすいと思いました。細かいカーソルの動きと目線の動きをセットで即座に見て取れるのは画面共有ならではのメリットだと思います。
また、対面で実施する場合に比べて、場所の移動が不要で時間的拘束が少ないので、コンパクトかつスピーディーに実施できることもメリットだと思いました。そのおかげで、デザイナー自身がデザイン作業と並行してユーザーテストをすべて実施するというスケジュールを実現することができました。冒頭にも書きましたが、定性的なユーザーテストの目的は「素早く繰り返し学習すること」なので、この点はとても重要だと感じました。

この記事は検証サイクルを2回実践した段階で書いています。ひととおりの計画が完遂するまでにあと10回以上同じサイクルを回していくことになるので、今後の経過もレポートしていければと思います。

おわり

COMPASSではデザイナーに限らず色々な職種で積極的に採用活動を行っています。興味がある方はお気軽にご連絡ください。

COMPASSの公式noteもよかったらご覧ください。

この記事が気に入ったらサポートをしてみませんか？