BtoB/SaaS製品のユーザビリティテストの「カベ」【前編】
こんにちは、ドリーム・アーツのUX Engineering Office（以下UEO）のオーモリです！
今回はBtoB・SaaS製品のユーザビリティテスト特有の課題と、とった解決策についてのご紹介です。
ユーザビリティテストが必要になった背景
そもそも「なぜ使いやすさをユーザビリティテストで測定する必要があったのか」というと、
ちょうどドリーム・アーツの主力製品であるSmartDB（スマートデービー）のフォーム作成画面の大幅な刷新を控えていたため、「刷新後のUIがユーザーにとって使いにくいものになっていないか」を調査する必要があったことが大きな理由です。
（結果に関しては、ぜひサポートサイトをご覧ください！☀️）
💡SmartDB（スマートデービー）とは
エンタープライズ向けのSaaS製品で、Webデータベースとワークフロー機能を備えたノーコード開発プラットフォームです
BtoB製品ならではのハードル
とはいえ、初めてのテストにはさまざまなハードルがありました。 特に苦労したのはBtoB製品特有の課題です。
※ 解決策がサクッとわかるように「▶︎」で結論を先に記載しています
①こちらが求めている「ちょうど良い」被験者の確保が難しい🙁
▶︎解決策：社内でのユーザビリティテストの実施
SmartDBのようなBtoB・SaaS・エンタープライズ製品でのテストの被験者選びでは、以下の項目がとても重要でした。
製品の基本構造・操作がわかっているか（全くの初心者ではない） →複雑な操作を行うことが多く、全く事前知識がないとテストにならない
製品を使うシーンに精通している、またはその周辺知識があるか →実業務での使い方の想定が被験者にないと、メンタルモデルとのズレを観察できない
被験者を製品の習熟度でレベル分けした上でアサインできるか →全体の傾向把握時に被験者の属性情報として必須
※3は、大量にテストができる場合はテスト前にはいらない観点ですが、限られた回数の中で行う場合はテストの信憑性を確かにするために事前に必要な情報でした。
条件を満たす対象者として一番良いのは「実際に利用されているユーザー」での実施ですが、BtoBの場合、そうもいかない理由も多いです。
いろんな理由はありますが、一番大きいのは、実際に利用されているお客さんへの依頼のハードルが高いこと。 これは会社としてコネクションがある先方の担当者が意思決定者であり、実際の利用者ではないことが大きいのかなと思います。
🗣️ちなみに、一度は外部委託で被験者を募るサービスなども検討しましたが、ユーザビリティテストとなると操作をしてもらう必要があり、全く製品を利用したことがない被験者では高い質のデータが取れないため見送りました。
②機密保持の観点から実現が困難🙁
▶︎解決策：社内でのユーザビリティテストの実施
上記で「実際のお客さんにお願いするハードル」について書きましたが、機密情報の取り扱いという大きなハードルもあります。
BtoB製品のうち、主にエンタープライズ向けのSaaSでは、この問題は避けては通れないのではないでしょうか。
大前提として、ユーザビリティテストでは普段の業務に近い環境で行動を観察できることが望ましいのですが、 たとえば、お客さんが実業務で使っている画面を見せてもらうとなると、社内の機密事項を社外の人間に見せることになってしまいます。
特に、SmartDBは業務の中心を担うデータベース＆ワークフローツールのため、そこが大きなネックとなり、依頼は難しかったです。
（＋これも影響して、後述の「標準的なシナリオ設定」にも難しさが生じていました。）
③機能と使い方が「1:1」ではなく、「1:♾️」🙁
▶︎解決策：シナリオ/タスクの３通りの作成手法（後編記事）
SmartDBでは「１つの機能」に対して「使い方」が大量にあるので、「xx機能をテストしたいんです！」といっても「一体どこを……？」となる状態になっていました。
想像しにくいと思うので例えを出すと、「フィルタ定義」というSmartDBの中のさまざまな機能で使われる「条件（分岐）」だけを定義する機能では、 「フォーム入力部品の表示or非表示」「一覧に出すレコードの制御」「一覧画面での特定情報のマークアップ」「通知」etc...などがあります。
とはいえ、開発は機能単位で行われるため、機能の使用性をテストするにはシナリオが必須でしたが、以下の課題も浮上していました。
④柔軟な設定が可能な製品のため、標準的な使用シナリオの把握が困難🙁
▶︎解決策：シナリオ/タスクの３通りの作成手法（後編記事）
SmartDBはお客さんの環境に合わせて柔軟で細かい設定ができる製品のため、標準的な使用シナリオの設定が困難でした。
これはエンタープライズ向けの製品では「あるある」かもしれません。
SmartDBはお客さんの業務に合わせ、さまざまな機能を組み合わせてノーコードで業務ワークフローを作ることができます。 機能と設定同士の組み合わせという、無数の選択肢の中から運用を踏まえて選択していくため、同じ処理を実現するにも、複数の手段が取れる製品なのです。
使う側にとっては非常にありがたい機能ですが、いざユーザビリティテストをするとなると、
・観察したいタスクまでの誘導ができる自然なシナリオは？
・逆に、ユーザーの動きを制限するシナリオにはなってないか？
・そのシナリオはリアリティがあるのか？？
などなど、非常に頭を抱える事態となりました。
テストを行うまでにやったこと
さまざまな問題を列挙しましたが、ここからはそれに向けてとった解決策を記載します。
✏️まずは知る✏️
今でこそ「難しかったポイント」として上記を記載していますが、実際に始めた当初は「右も左もわからない！」という状態だったため、まずは「知識の補充」から始めました。
✏️知識の獲得・共有を継続的に行なえる場のセッティング
幸いなことに、ドリーム・アーツでは「社内勉強会」が非常に活発な会社だったため、プロダクトデザイナーチーム内での勉強会を開催することにしました。 これが、継続的なインプットとナレッジの共有をしやすい仕組みになりました。
✏️情報収集
主に書籍、次いでセミナー、イベントなどに参加をし、情報収集を行いました。
✏️社内での情報収集
社内でシナリオ設計前のユーザー把握ができる資料を探し出し、メンバーと協力しつつ以下を行いました。
・提案資料の読み込み
・顧客要望データベースで関連情報の把握
・使用シナリオの一般化が難しそうな機能に関しては、アンケートを実施
🙆♂️できる範囲（社内）でのユーザビリティテストの実施🙆♂️
学習と並行して「ユーザビリティテストが行える環境」を探っていきました。
簡単にいうと、BtoBのエンタープライズSaaSの場合は社内でのユーザビリティテストをおすすめします。
機密情報の取り扱いへの配慮が少なめで済む📃
ある程度「製品について知っている」ちょうど良いユーザーが多い👦
というメリットがあるからです。さらなるメリットとしては、
すぐに実施できるので開発負担も少ない💰
「実際のお客さんの使い方」を知っているメンバーからは、そのフィードバックも受けられる✍️
といった点も大きいです。
もし社内メンバーが実際の利用ユーザーとは異なるという場合は、社内の中でも利用ユーザーと近い経験があるメンバーにお願いをするなどの必要がありそうです。
後編では実践編として、製品特有のシナリオ設計時の考慮についてと、実践してみてわかった課題とその対応を記載しています。
後編はコチラ👉