「体験」の価値検証: 新卒のわたしにとって、初の経験。学びや気づきを書いてみました。
「届けたい『体験』に、そもそも価値はあるのか。」それを検証した経験を、この記事ではお伝えします。
「ユーザビリティテストのこと？」など、少しでも気になった方は、チラッと覗いてくださると嬉しいです。
🍅 はじめまして！
2023年に新卒入社したデザイナーのrikoです。7月からfreee会計に関わっています。
現在は、「会計初心者が勘定科目を迷いなく選べるようにするには？」というお題に対し、企画（リサーチや体験設計）や画面デザインなどをPMと一緒に進めています。
そのなかで、「設計したユーザー体験（以下、体験と表記）が本当にユーザーさんにとって嬉しいものなのか？」を検証しました。この記事では、その経験をお話しさせてください。
📘 この記事における「体験」って？
ところで「体験」って、何を指すのでしょうか。きっと、人や場合によって答えは違うと思います。
そこで、まず本記事で使う「体験」という言葉を以下の意味で統一させてください。
見た目の良し悪しなどに依存しない部分。本機能を通してユーザーさんが実現できる、主な操作。
画面デザインの良さも体験に影響を与えるものの1つであるとは思います。
けど、そもそも「ユーザーさんができる主な操作（例：勘定科目を検索することができる）には、そもそも価値があるのか」を知りたいという想いで、価値検証を行っていました。
そのため、ここでは便宜的に「視覚的な情報によらない部分の体験」を「体験」と呼ばせてください。
💭なぜ、「体験」の価値検証をしたかったか
検証の大切さを知った新卒研修のしくじり
4~6月の新卒研修のとき、体験の価値検証をしなかったことが理由で痛い目を見ていて…笑
「私たちが考えてる体験、きっと、ユーザーさんにとって嬉しいよね！」というチーム内の思い込みで、画面のデザイン完成&実装まで突き進んでしまいました。
その時点でようやくユーザーさんに案をぶつけた結果、「アレ…なんか体験ビミョい…？」と気付かされまして…。
「作り手が良いと思っているものは、ユーザーさんにとって必ずしも嬉しいわけじゃない」「思い込みはユーザーさんに確かめないといけない」と痛感しました…。
チーム外の人やユーザーさんに意見を求めることを忘れ、チームに閉じた議論を重ねてしまったと、個人的に思っています。
また、1つの仮説を信じて突き進んでいたからか、後戻りできなさそう…とも徐々に感じていました。正直、自分の仮説を信じていたかったのかな…とも思ったり。
たとえば、考えた機能が「なくてはならない」ことが明らかだったり、施策の性質によっては「そのまま進んじゃえ！」な場合もあるのかもと想像します。
ですが、考えた機能が「なくてはならない」ではなく、「あったらイイな」な場合。
たとえ案がラフな状態であっても、早い段階で体験の方向性が良さそうかを確かめるのって、大切だなと個人的に考えています。
今回私が取り組んでいたお題は、「あったらイイな」な機能です。だからこそ、「体験の価値検証をしたい」という想いがより強くあった、というのが個人的な背景です。
🧪 検証方法と結果の概要
方法
freee会計を使っている、5人のfreeers（=freeeに勤める人）に協力してもらいました。
用いたものは、figmaで作った画面デザイン同士を線で繋いで作ったプロトタイプです。
（このプロトタイプは紙芝居のようなもの。画面デザインのある要素を押したりすると、次の画面デザインが映し出されます。）
このプロトタイプを押したりしてもらいながら、印象などをインタビューしました。
そして、協力してくれたfreeersのなかには、視覚障害を持つ方も。その方は普段、webサービスを使う場合、キーボードによって画面を操作しています。
ただ、私が知っている限り、figmaで作ったプロトタイプは、キーボードで操作することができません。そこで、プロトタイプの視覚的な情報を私が読み上げ、操作をその方に口頭で伝えてもらうという方法を取りました。
結果
検証を終えて、「体験の方向性は良さそうだけど、体験の価値を届け切れてはいないかも」という所感を得ました。
そこで「体験の方向性はそのままで、体験の価値を届け切るための課題を解消する」ことに。
🗣意識したのは 「言葉の表現」
検証中、特に「言葉の表現」に関して意識した、2つのことをお伝えします。
1. 体験の価値検証を「ユーザビリティテスト（UT）」と呼ばない
「『体験』の価値検証をするんだ！」という認識を、チーム内できちんと合わせるために意識しました。
私は、figma上で手を動かしながら体験を考えていました。つまり、検証時点で、figmaで作った仮の画面デザインが存在していました。
そこで、その画面をつないで作ったプロトタイプをそのまま使って検証を実施。
ただ、一般的なユーザビリティテスト（UT）においても、figmaで作ったプロトタイプや実装されたものを使うことがあるんですよね。
つまり、一般的なユーザビリティテスト（UT）と、今回の体験の価値検証で使う手段が同じでした。
手段が同じことに惑わされず、目的に沿った検証や議論を行うために、用いる言葉から変えてみたのが背景です。
結果、検証後の議論において、「体験の価値があるのか」に焦点を当てて、メンバーたちで振り返ることができました 🎉
2. 結果の考察で、「価値がある」と言い切らない
今回の検証では、機能を実際のプロダクトに実装後、ユーザーさんの反応を見て確かめたわけではありません。あくまで、5人のfreeersにfigmaで作ったプロトタイプを触ってもらっただけ。
また、体験の価値に影響を与える要因はUIだったり、操作のサクッと感だったり、色々ですよね。
その機能自体の価値を感じてもらえるかは、リリースしてユーザーさんの声を聞かない限り、結局わからないはずです。
それを肝に銘じ、冷静に今回の検証を受け止めたく、「価値がないとは言えなさそう」という言葉を使うようにしていました。
✍️ 初めての検証で学んだこと・気づき
私は今回、初めて体験の価値検証の計画から実施まで行いました。
そこで得た学びや気づきを、ここでは3つお伝えします。
1. デザイナー以外のメンバーも巻き込んで検証する
検証結果を言葉で伝えるよりも、ユーザーさんの反応や言葉を直接見聞きすることで、肌感を伝えやすくなり、施策を前に進めやすくなりそうと感じました。
検証前は「ここには手を加えない」とスコープ外とされていた内容が、検証結果を踏まえて「ここも改善した方が良さそう」という仮説に変わりました。
2. 手段を変えて、新たな気づきをゲットする
口頭で検証を行うことで、画面を眺めているだけでは得られなそうな気づきがありました。画面の情報を声に出して読み上げたとき、その情報量がいかに多いのかにハッとさせられる場面があったり…
検証という場面にかかわらず、手段を変えてコミュニケーションを取ったりするのも面白そうだ！と感じることができる貴重な経験になりました。
3.場の雰囲気を、イイ感じにつくる
インタビューでは、回答者の答えに応じて、質問者は使う言葉や質問内容を変化させる必要があると思っています。台本を事前準備していたとしても、完全にその通りには進まない…
わたしはカジュアルな会話のなかでさえ、顔が真っ赤になっちゃうくらい、話すのに緊張します。
そのため、インタビュー前の心臓はバクバクでした😱😱😱
その通りには進まずとも、なんとか方向性だけはズレないようにしようと、何度も密かに台本を音読していました笑
とは言え、インタビュー中に予想外の答えが返ってきたときには、混乱し、無闇矢鱈と同じような質問をぶつけてしまったりもしました。
それでもなんとか乗り切れたのは、インタビュー全体の雰囲気が穏やかだったからかなと思います。
私からの拙い質問に対して丁寧に答えてくださった回答者や、周りで見守ってくれていたメンバーに感謝しています。
思い返すと、私が雰囲気に寄与できたのは「ニコニコしていた😊」くらいだと考えています。笑
質問者も回答者も話しやすい雰囲気を作りながら、いろんな話を引き出せる質問者になりたいです。
💌 最後に
検証後知ったことですが、今までfreeeでは、「なくてはならない」ことが明らかな機能を作ることが多く、体験の価値検証をしないこともあったそうです。
なので、今回の検証がfreeeにとっても何か嬉しいことが少しでもあったらいいな〜とか、勝手ながら思っていたりします。
そして、今回の機能はもうすぐリリースされ、ユーザーさんの手に届くはず…！
機能がユーザーさんにとって嬉しいものでありますように…と願って、今自分にできることをしていきます。
読んでいただいてありがとうございました💌
この記事が気に入ったらサポートをしてみませんか？