デジタルバンク「みんなの銀行」、デザイン部の中川です。この記事では、デザイン部プロダクトデザイングループが、日常的なUI改善の一環として取り組んでいるユーザビリティテストについてご紹介します。
私がみんなの銀行に入社してからの約1年間だけでも、なんと約80名の方にテストへご協力いただきました。プロダクトデザイングループ全体で見れば、さらに多くの方の声を聞きながら日々プロダクトを磨き上げています。
しかし、実際のテスト現場は教科書通りにはいきません。今回は、私がテストを通じて直面したリアルな課題と、それを乗り越えるために工夫したテスト設計の裏側をお伝えします。これからユーザビリティテストを導入したい方や、UI/UXデザインに関心がある方の参考になれば幸いです。
ユーザーの声に向き合う取り組みに共感して応募
そもそも、なぜ私がみんなの銀行に入社したいと思ったのかというと、『みんなの銀行公式note』で、みんなの声委員会やデザイン原則、ユーザビリティテストの取組みなどの記事を読み、サービス作りの姿勢に惹かれたことがきっかけでした。
私はこれまでベンチャーや制作会社で様々なアプリケーションのUIデザインやWebデザインに携わってきました。
その中で、PV数や離脱率といった定量データに基づいた改善には非常に説得力があり、UIデザインやWebデザインをする上で不可欠なものであると実感しています。
しかし、データを見て改善することの大切さを学ぶ一方で、実際に利用されるお客さまの「生の声」を聞いた時にハッとさせられることも多々ありました。その経験から、数値が示す「何が起きたか」という事実だけでなく、ユーザーの「なぜ」という背景を考慮したデザインをしたいと考えていたとき、目に留まったのがみんなの銀行の取り組みです。
ユーザーの声に向き合う仕組みが構築されている点や、定性と定量の両面を重視している点、さらにはビジュアルデザインにも注力しているところが魅力的で、すぐに求人に応募し、今に至ります。
ユーザー視点で日々磨き上げるプロダクト
入社から1年を通じて実感しているのは、ユーザーインタビューやユーザビリティテストが単なる開発工程の一つではなく、「文化」としてデザイン部に定着していることです。
具体的には、同じデザイン部のサービスデザイングループによる外部ユーザーへの定期インタビューに加え、私たちプロダクトデザイングループも、普段は開発に関わっていない社員に協力してもらい、クイックなユーザビリティテストを実施しています。このように、日常的に客観的なフィードバックを取り入れる体制が整っています。
デザインのプロセスは、こうした定性分析だけで進むわけではありません。サービスデザイングループによる定量的な裏付けや、他部署からの別観点での定性・定量分析、さらにビジネス部門や銀行業務の専門家からの視点も掛け合わせて進行します。
特筆すべきは、デザイン部以外の部署でもユーザー視点を重視した議論が活発に行われている点です。「常にお客さまを起点に考える」という意識が社内全体に浸透していることを、日々肌で感じています。
教科書通りにはいかない？ユーザビリティテストのリアル
こうした社風のもと、私が所属するプロダクトデザイングループでは社内の多様なメンバーと協力してUIデザインに取り組んでいます。
UIの制作過程で行うユーザビリティテストでは、実際のユーザー像に近い方々にUIを試してもらうことで、「学習しやすいか」「効率がいいか」「満足感はどうか」などを客観的に検証します。基本的なテストのプロセスは仕組み化されており、テスト経験がないメンバーでも日々の業務に取り入れやすいよう、ガイドラインが整備されています。
また、AIを導入して作業を効率化するなど、ガイドラインは常にアップデートされ、基本的なテストは容易に実施できるようになっています。しかし、複雑な課題に対しては「標準的な設計」だけでは不十分なこともあり、プロジェクトごとに創意工夫を凝らしています。
ここからは、標準的な設計だけでは不十分だった2つの課題についてご紹介します。
課題1：テストという「非日常」をいかに「日常」に近づけるか
1つ目の課題は、テストという非日常的な環境下では、率直なフィードバックを得づらいという点です。
基本的にテストでは、参加者には操作中に思ったことを可能な限り声に出してもらう「思考発話法」という手法を取り入れています。これにより、「何を手がかりに情報を探しているか」「どのようなキーワードを想像しているか」といった、ユーザーのメンタルモデルを把握する重要なヒントが得られます。
私たち作り手は仕様を熟知しているため、どうしてもバイアスが生じ、欠点を見落としがちです。そのため、ユーザーの生の声から自分たちのバイアスに気づかされるこの手法は、非常に有効だと実感しています。
しかし、この手法を過信しすぎるのは危険です。
「発話しながらの操作」自体が非日常的ですし、第三者に観察される特殊な環境下では「正しく操作しなければ」という緊張感から、無意識に普段とは異なる挙動をとってしまうことも考えられます。得られた発言や行動を鵜呑みにするのではなく、その背景を慎重に解釈する必要があります。
そこで重要になるのが、テスト前の雰囲気づくりです。
アイスブレイクを丁寧に行い、「間違えてもいい」「むしろそれがヒントになる」と伝えることで、話しやすい雰囲気を作ります。加えて、当日の発言だけに頼るのではなく、シナリオ設計の段階から確認ポイントを明確にし、事後インタビューで深掘りするなど、テスト全体を通じた柔軟な調整が不可欠です。
課題2：毎回同じテスト設計では本当の課題を抽出できない
2つ目の課題は、毎回同じ設計では課題を抽出できない場合があるということです。
入社前、私はユーザビリティテストの目的を漠然と「使いやすさを確認すること」だと考えていました。しかし実際には、「目的を達成できるか」「正しく使えるか」といった「使用可能性」や「有効性」を検証するものへと認識を改めました。
アプリを利用する方が上手く機能を使えない場合、そもそもその機能が「学習しやすいか」という観点から改善案を検討する必要があります。テスト中には、色や形、レイアウトが原因で発生する問題もありますが、「メッセージの意味がわからない」「画面で何が起きているか把握できず、次に進めない」といった、認知や理解のフェーズにおける問題も発生します。
こうした問題は、タスクの完了率といった定量データだけでは、改善案が本当に有効かを評価しきれません。そのため、言葉選びやエラーメッセージ、機能のコンセプト自体が意図通りに理解されているかの検証も行います。
シナリオやタスクの設計はもちろん、事後インタビューの設計や、実際の使用感に近いプロトタイプの準備など、ユーザーの思考プロセスを可能な限り可視化する工夫が必要です。ユーザビリティテストは複数回の実施を前提とし、各回でシナリオやタスクを最適化しながら改善案の検証を繰り返していきます。
【具体例】標準設計では捉えきれなかった3つのケース
ここからは補足として、標準的なテスト設計だけでは捉えきれなかった3つの具体的なケースをご紹介します。
ケース1：新機能における「サービス全体の理解度」
新機能や新しいUIデザインへの理解度に焦点をあてたテストでのことです。
普段アプリを操作するとき、多くの方は無意識に「これは自分の知っているあのアプリと同じだろう」と予測を立てて操作しています。しかし、デザインの意図がその予測とズレていると、どれだけボタンを目立たせてもユーザーの手は止まってしまいます。
実際のテストでも、「この画面で何ができるか」は理解できても、「その行動が全体にどう影響するか」が見えないために手が止まるということがありました。
何となく操作はできるが、納得感がないという状態です。
このような場合、ただ操作しているだけでは「なぜ間違えたのか」がわかりづらいため、少し変わったテスト設計を行うことがあります。例えば、具体的な操作を指示せずに一通り画面を触ってもらい、その後の事後インタビューに時間をじっくり使ったり、2回目・3回目のテストでは指示内容や順番を変えたりしながら、何が原因だったのかを探り当てます。
ケース2：エラーメッセージが「解決」に導いているか
機能によっては、エラーメッセージがユーザーの行動を阻害していないかを検証します。
単なる状況説明に留まらず「次に何をすべきか」が明確か、ユーザーが自力でリカバリー（復旧）できる内容になっているか、といった観点です。
あるプロジェクトで、日常的に実施するテストの多くが、スムーズに進行する「正常系」に偏りがちであることに気づきました。
エラーなどが発生する「異常系」のテストを実施する場合、過去の事例があったとしても画面ごとに仕様が異なるため、単にガイドラインを適用するだけでは実際の利用者の行動に即さないことが多々あります。
そこでグループで議論し、あるプロジェクトの手続きタスクにおいて、敢えてエラーを発生させるシナリオを設計しました。
参加者に「誤ったパスワード（ダミーの認証情報）」をお伝えして操作してもらうというものです。当然、参加者は情報が間違っているとは想定していません。 かといって「情報が間違っている可能性があります」と伝えては誘導になります。
いかに誘導を避けつつ、参加者が自力で「情報が違うかもしれない」と気づき、混乱せずに次の行動へ移れるか。この塩梅を探るテスト設計には非常に苦労しましたが、これを繰り返すことで当初の課題を解消する具体的なUIデザイン案を提案することができました。
ケース3：最初にボタンを押すまでの心理的なハードルはないか
最後に「ボタンが見えていること」と「押せる（押したくなる）こと」は別物であると再認識したお話です。
操作方法は理解できていても、「このボタンを押すと後戻りできない変化が起きるのではないか」「面倒な入力が始まるのではないか」といったリスクの予見が、ユーザーの判断を鈍らせることがあります。これは単純な操作性の問題ではなく、期待値と不安のバランスの問題です。
例えば、手続きを開始するボタンの先に「あと何工程あるのか」「何を用意すべきか」が不透明だと、「今はやめておこう」と離脱を招く要因になります。また、文言の意味はわかっても「押した後の具体的なイメージが湧かない」という理由で敬遠されることもあります。
単なる視認性というスペックの問題にとどまらず、ユーザーに「次へ進む安心感」をいかに提供できるか。数値やデータだけでは測れないこの課題に、唯一の正解はないと考えています。しかし、ユーザーが納得して使い続けられるデザインを提供できるよう、事後インタビューを通して「行動の裏にあるインサイト」を深く掘り下げる工夫を、プロダクトデザイングループでは続けています。
納得のUIを生むための、一歩踏み込んだテスト設計
以上、私がこの1年で経験したテスト事例の一部をご紹介しました。
こうした多角的な視点による分析をUIデザインに落とし込む作業は決して簡単ではありませんが、テストを繰り返す中で評価手法も日々アップデートされ、着実に精度が高まっていると感じます。
ご紹介したように、一歩踏み込んだテスト設計には試行錯誤が伴います。それでも、みんなの銀行には経験豊富なメンバーが多く、迷ったときもすぐに相談しながら進めることができました。最終的に全員が納得のいくUIに仕上がったときには、グループでプロダクトを作り上げる醍醐味を強く感じています。
背中を押してくれる環境だから、挑戦できる
当たり前のことではありますが、こうしたユーザビリティテストを実施するためには周囲との連携が不可欠です。テストの際には、みんなの銀行の社内メンバーやグループ会社の方々に協力をお願いすることが多いのですが、いつも助けられているのは皆さんの「熱量の高さ」です。
単なる検証の協力という枠を超えて、前のめりに参加してくださる姿には、私自身大きな刺激を受けています。皆さんが多忙な業務の合間を縫ってテストの場を共有し、課題を「自分ごと」として一緒に考えてくれるのです。
このような心強い協力があるからこそ、職種を越えた活発な議論が生まれ、プロジェクトメンバー全員が納得感を持って改善へと踏み出せているのだと感じます。社内にこうした温かく協力的な土壌があるからこそ、私たちプロダクトデザイングループも迷いなくテストを企画し、ユーザー目線に徹した提案を出し続けることができるのです。
おわりに
みんなの銀行に入社して良かったことはいくつもありますが、なかでもこのユーザビリティテストを仲間とともに設計・実施するプロセスは、私にとって非常に大きな学びの場となっています。
自分一人では気づけなかった観点に触れ、UIが磨き上げられていく過程を実感できることは、日々の大きなやりがいにつながっています。
誰もが当たり前に、そして心地よく使いこなせるサービスを目指して。これからもお客さまの声に真摯に寄り添い、プロダクトの改善を続けていきます。
※この記事は、みんなの銀行公式ブログ「note」からの転載です。
最新情報やサービス詳細は、みんなの銀行公式サイトをご確認ください。
公式サイト：https://www.minna-no-ginko.com/
