ガイアックス技術開発部 QAマネージャーの境野(@sakaimo)です。前回に引続き、ガイアックスで試した「デザインスプリント」の取り組みを紹介します。

Day3: DECIDE (決める)

最終段階である「プロトタイプを作成し、ユーザーテストを行う」までの記録となります。下記の写真のような雰囲気で進んでおりました。

この日のゴール

もっとも優れたアイディアを選び、全員で同意する。(どのプロトタイプを作るのかを決めるということです)

Day2の復習

下記写真がDay2の成果物です。

• • 緑が「何ができるサイトなのかを理解してもらう」に対するストーリーボード
  • 黄色が「旅を探しやすくする」に対するストーリーボード

意見のコンフリクトを探す

というステップがあるのですが、今回の我々には該当しないなと思いました。ですので具体的にここでどんなことが起こるのか体験出来ませんでした。想像したのは「TOP画面にあるのは動画だよ」vs「静止画のスライドショーだよ」とかかなと思いました。この時点で解決したい課題が2つ以上ある場合(取り組みたいストーリーボードが2つ以上ある場合、、、2つが限界と思う)、下記のどちらかを選択します。

• BestShot：どちらかを選ぶ
• BattleRoyale：どちらも作る

今回はなかったのでBestShotでいきます。上記に「黄色と緑、2つあるのでは？」と思いますが、「一つ作ることでどっちも解決できる」と判断したため、1つですｗ

画像引用元 http://www.fastcodesign.com/1672929/how-to-decide-what-ideas-to-prototype

「検証したい仮説」と「検証方法」を出す、らしいです。TABICAのこの時点での「検証したい仮説」は「何ができるサイトなのかを理解してもらう」と「旅を探しやすくする」であり、検証方法は(この図で言えば)UserStudyしかないのではと思いました。

少なくてもここまではDay5のユーザーテストで検証するものだと思って取り組んでいるので、それ以外で検証したい仮説および検証方法って、、、？と考えてしまいました。

みたいなことを考えながら、どうやって検証するか、をこんな感じで書き出してみました。(この間、議論が発生していますが、それをうまいことまとめていくことが必要。議論しっぱなしだと収集つかなくなります)

詳細なユーザーストーリーを描く

上の画像では、サイトTOPから入って、ユーザーに何をしてもらいたいか(今回は理解と検索)を考えました。議論のポイントは

• サイトの理解、って何だろう
• 検索する(今回の場合、検索と呼んでますが「検索フォームをつける」ことではなく、旅詳細画面まで行けること)にはどうしたらいいか

そこからユーザーストーリーが出来ました。

上の画像では、TOP画面で伝えたいこと、を考えました。

• コンセプトが伝わること(動画がいい)
• 「日帰りの旅」が予約できるサイトだとわかること
• 自分に合った旅がありそうって思ってもらえること

Day3感想

• ファシリテーター視点
  • この日のプロセスがイマイチよくわからなかった
    • 「何をプロトタイプするのかを決めなければならない」ことは理解できたが、そこに至る段階がイマイチ不明瞭
    • Day2のSuper Voteで絞り込まれている、かつ、プロトタイプを作ることが前提なので自ずと選ばれるアイディアは決まるでしょ、ってこと？
  • 「ユーザーから何を学びたいか？」と「その指標」を議論できたのはよかった
    • 本家では「前提とテストの方法を決める」というざっくり説明
    • たぶん、この日にやっておかないとDay5がグダグダになったはずなので、決めておいてよかった

• メンバー視点
  • ユーザーストーリーというと、ユーザーがどういう画面遷移をしてどこにたどり着くか、っていうのを真っ先に考えてしまっていたのですが、「画面遷移」ではなく「ユーザーがこのシステムを操作することで体験してもらいたいこと)を考えるんだなーと。←これが目的
  • そのために最適な画面遷移とか、表示要素やレイアウトてなんだろうなと。←これ手段

Day4: PROTOTYPE (試作する)

この日のゴール

明日のユーザーテストで見せられるものを作る

いよいよ見せられるものを作ることになります。ポイントとしては

• Good Enoughなプロトを作る
• 見た目が最低限リアルであること
• テキストはリアルに書く(テストテストテストテスト…とかじゃなく)

プロトタイプ作成ツールは strikingly を使用しました。馬田さんは「プロトタイプツールはPowerPointやKeynoteで十分！」とおっしゃっていますが、ちょっと色気を出しました。。。

Day3の成果物より

• 実現したいこと=検証したいこと
  • コンセプトが伝わること(動画がいい)
  • 「日帰りの旅」が予約できるサイトだとわかること
  • 自分に合った旅がありそうって思ってもらえること

Day3の成果物↓

作業の中で

←例えばこの部分ですが、サイトの「使い方」はTOPに置いて認知してもらいたいよね、という意図でした。「使い方」について改善前のサイト(すでに公開されている)では下記のようになっています。(表示位置は画面の下の方にありました)

試作をしていく中でも「これは、(使い方)とカッコで書いたものの、より伝えたいのはその下に書いた「特徴」とか「強み」の方だよね」という話をしました。結果として検索窓の下に、特徴となるホストの写真と文言で表現しよう、となりました。途中Yさん(別事業部の人)にここまでの成果物をレビューしてもらったりしながら、本日のここまでの作業時間は3.5時間くらいで形になりました。

プレ・ユーザーテスト

この日の夕方に、ユーザーテストの進行の確認も含めてプレテストを実施しました。(ここは、本来のデザインスプリントにはないプロセスです) Sさん(別部署)に協力してもらい、ユーザーテストを行ってもらいました。

目的は段取りとかスクリプトの確認でしたが、明日のユーザーテスト本番に向けて改善したほうがいいと思える意見をいただけました。

• もらえたコメント
  • 「地元」の人と行く旅(普通の旅行紹介ではなく)という印象が残った
  • テキストではなく画像で判断する。(一字一句はテキスト読んでない)
  • 旅が4つの塊に分けて表示されていたが、違いがわからない
  • 地図があるともっといいかな
  • 「ホスト紹介」はTABICA独特だな
  • 日付、場所の検索フォームが反応しないのは残念
  • 人気のスポットにある画像をクリックしたら、旅詳細に飛ぶと思った(実際はその都道府県の旅一覧に遷移)
  • ホスト一覧がオッサンばっかりなので女性がいたらクリックしたかもw

これらを元に、明日のユーザーテスト本番に向けていくつか対応することにしました。

• ユーザーテストの進行に関する課題
  • どこまでやってもらったら終了にすればいいか、の判断が難しい
  • モニタで動作確認する際に、対面じゃなくてL字で座ったほうがいい

改善前に公開しているものはこれ

TABICA のTOPページです。(2015年3月現在)

プロトタイピングでできたものはこれ

よりリアルにしたい、という思いはあったものの、プロトタイプなのでここまででした。今回の改善ポイントとしては

• KVが静止画に見えますが、実際は動画です
• すぐ下に検索窓。(リピーターがすぐ旅を探せるように)
• その下にTABICAの特徴、強み、ウリを載せる。(初見の人の目に入るように)
• その下から「カテゴリ、スポット、旅、ホスト」から旅を探せるようにする
• 女性の写真を入れるw

Day4感想

• ファシリテーター視点
  • プロトタイピングツール選定と習熟は課題
    • ユーザーに実際に操作してもらうのに、PowerPointやKeynoteで本当にOKなんだろうか？
    • strikinglyも悪くないけど、基本的にスマホ向けなのと、レイアウトに仕様的な限界があるのが微妙
    • その点、Prottはデザインという意味では自由。だた、1枚画像のスクリーンショットをいちいち用意するのが面倒そう
    • 何をつかっても、遷移以上のものが実現できないのは仕方ないのかな？
  • ダミーページ
    • テストしたい画面・ストーリー以外は、明らかにダミーと分かるダミーページで十分だった
    • 中途半端に画面を作ったり、別環境にリンクされてたりするとテスト効率が下がる
  • プレユーザーテスト
    • 今回はやってよかった
    • 次からは、Day4にもともと仕込まれている「デザインレビュー」とうまく統合したい

• メンバー視点
  • 試作ツールの使い方(初めて使うものだった)に慣れる時間が必要だった。
  • ツールの仕様に左右されて、レイアウト調整(例えば画像を大きくするとか)が出来なかった。
  • プレテストができたのは有益だった。(画面自体もそうですが、ユーザーテストを実施する流れがわかったのも大きい)

Day5: TEST (検証する)

この日のゴール

ユーザーテストをすることで、4日かけて考え、作ったものに対する効果を検証する。

今回はユーザーテストに3人の社内メンバー(3人とも他チームで非エンジニア)に協力してもらいました。

• 1人あたり説明＋操作で10分くらい。その後ヒアリング20分くらい
• 画面操作をキャプチャするのに Bandicam を使用
• 操作している画面は別モニタに映して全員で「観察」できるようにした

以下がユーザーテストの結果です。

【Mさん】
【Mさん(男性。別事業の営業の人)】
■観察結果
・最初は一番下まで見る
・女性画像はささらず
・一つの記事を見たら、すぐに「もっと見る」

■ヒアリング結果
・KVが大きすぎる（その下にコンテンツがあると思わなかった）
・申込み位置がわからない（詳細ページ&トップページ）
・写真に目が行く
・サイトがきれいすぎる
・旅の一覧表示があった方が良い
・テキストのほうが見やすい
・動画が早すぎる(補足：1秒程度でいろんな動画が切り替わる動画だった)
・どれ見ていいかわからない
・何ができるかわからない
・旅行系っていうのしかわからない
・文字情報（日程、金額など）がほしい
・旅に行く場所がわからなかった
・(画像は)地図や味噌など特徴がある物しか残らない
・検索に気付かない

【Fさん(女性。管理部)】
■観察結果
・最初は一番下まで見る（下に行くまでが早かった）
・「もっと見る」を最初に押す傾向

■ヒアリング結果
・旅の申し込みができるっぽい
・地元のが印象は強かった
・旅行代理店のツアーでなはい
・色々知りたいので、全部網羅しているところをみる(「もっと見る」を押すことで旅の一覧画面を期待した)
・おすすめ、人が出てるところをクリック
・自分に合った旅があるかどうかは(TOPだけでは)判断できない（内容をみてから判断）
・内容までは入ってこない
・下までスクロールした後にもう一回見てみようは、仕事だから。(事前情報無しにこのサイトを案内されたらスルーするかもｗ)
・自分の関心のあるターゲットキーワードでないと止まらない（アンコールワット、世界遺産とか）
・写真は景色のものが良い
・タイトル(各画像のテキスト)はみていない
・検索の用途がわからない
・女の子の画像には目に行った
・普通のツアーとは違うので、違いは自然と目につくと思う
・人気シリーズ(カテゴリ、スポット…)は違いが判らない（ホストのみは違いが分かった）
・字が小さすぎる（デバイスフォント）
・画像だけではわからないが、画像上の文字は目につく
・旅が決まってない状態では金額は気にならない
・ホストで旅を決めるのではなく、最後に決める（人柄が入ってるなら別）
・行われる旅が、5,6人程度なんだろうなという印象はあった(実際行われる旅はそれくらい)

【Sさん(女性。別プロダクトのオーナー)】
・週末空いている、という前提条件にしてもらいました

■観察結果
・じっくり一番下まで行った
・最初は日付検索を実施
・もっと見るを押す傾向
・動画をクリックしていた

■ヒアリング結果
・予約ではなく人気スポットの記事紹介ページの印象(キュレーションサイト)
・自分に合う旅があるかもとは思ったが、印象に残った旅は無い
・エリア(都道府県や地域)で見たい
・人(ホストがウリ)のイメージができなかった
・ジャンルと地域のみ目が行った
・「日帰り旅」の印象はない。(泊まりの旅行のイメージ)
・一覧には、自分の行きたい旅はあると思った(補足：今回、一覧画面は未実装だった)
・動画は受け入れにくのでは？旅を参加した人を見ていてそう思った。(補足：SさんはすでにTABICAで実施している旅に参加してもらった経験がある)
・動画よりタイトルが目立つ(動画の中に書いてあるテキスト)
・検索窓の下にあるホストの写真およびこのサイトの特徴テキストは目に入っていない
・若い人がいっぱいいるイメージ
・文字が少ない
・人気のスポットは先が想像できない（口コミがあれば押す）
・人気の旅はタイトル(テキスト)が長すぎる
・ホストとしてのクオリティに興味がわかない（名前、年齢、メイン地域、何のプロフェッショナルなのか）
・ユーザーの投稿写真一覧があると良いのでは
・集合写真(旅に参加している人達とか、その現場とかの写真)がほしい

…というご意見をいただけました。お、、おう。そうですよね、、、w

ユーザーテスト後のミーティング

ユーザーテストを受けて、どう改善していこうか、を1時間程度話し合いました。これを元に本番反映させていくことになります。

• ファーストビューでKV(静止画)と検索窓と、画面下の方に「続きがあるぞ」と思わせるように「コンセプトゾーン」を作成します。
• その下には旅を「カテゴリ、スポット、ホスト」で探せるようにします。
  • カテゴリ=伝統工芸、農業体験、街歩き、、、のようなもの
  • スポット=地域、都道府県
  • ホスト=旅の案内人。地元の人
• その下に旅の詳細をズラっと並べておく。クリックで旅詳細画面に遷移する。
• 遷移先の旅詳細でも、(TOPに戻らなくても)別の旅を探せるようにする(この部分はTOP画面ではなく旅詳細画面の改善にあたります）
• TOP下部にも検索をつける。

…という改善をしていこう、ということに決めました。これがいつ本番に反映されるかはお楽しみに！

ユーザーテストの感想、反省

操作をしてもらう前の導入

• ロールとか事前情報(旅を探してこのサイトに来た、とか)を与えてしまうのがいいのか？それだと「探す」という作業をするのか、という指示になってしまう気もする、、、
• Day5のユーザーテストは「ユーザビリティテストではない」とのことなので、タスクを与えてそれを完遂できたかどうか？というのは違うんだろうな
• ただし、そもそもユーザーテストに協力してもらう、という点において「普段通りに使う」ということはできないのでは？(普段クリックしないところも、クリックしてみたりするだろうし、興味がなかったらすぐ離脱するだろうし)

どこまでやってもらったらテスト終了かに迷った

• 今回はTOPページだけが対象
• 上から下まで、5分もあれば見きれちゃう

意見に流される傾向はある

• 本来ユーザーテストは「意見(ヒアリングで出てくる発言)」じゃなくて「行動」を観察することが大事である、は頭では理解していますが、観察する側のスキルがなかったのか、あるいはTOP画面しか無かった(かつクリックできるところも限られていた)からか、観察のポイントがわからなかった。
• そのため、ヒアリングして出てきた意見に重きをおいてしまう傾向はありました。
• それでも「個々の旅の画像」より「もっと見る」を押されることが多いのか、というのは観察で気づいたところです。

検証はできたのか

結果として「何ができるサイトなのかを理解してもらう」「旅を探しやすくする」が達成できたのか正直わかりません。(ここは本番反映させた後に検証するのでデザインスプリントのスコープ外なのかも）「指標の決め方をもっと工夫したほうが良かった」はわかるのですが、どうだったらよかったのか、は今考えても悩みます。。。だけど改善前よりは確実に良くなっている気がする！(主観ですけど)

Day5感想

• ファシリテーター視点
  • タスク遂行型か、タスクを指示せず任せるか
    • ユーザビリティテストなら、タスクを指示してそれをユーザが達成できるかを見るのが常道
    • ただし、「デザインスプリントにおけるテストはユーザビリティテストではない」と繰り返し強調されているので、タスクを指示するのが前提ではない
    • 個人的には、「旅を探しに来た」と指定しただけでも十分にインタビュイーの思考を縛ってしまった気がするので、難しい
  • 慣れとの戦い
    • インタビューも3人目くらいになると「こんなもんか」と思ってしまう。もしくは、共通点を見つけて安心してしまう
    • 今回はリアルなユーザではなく社内メンバーだったので、それが顕著だったのかも
  • インタビュー後の振り返り
    • 今回は「次のスプリントは未定」だったので、議論して新しい仮説まで立ててしまった
    • 本来は、今回の学習をそのまま加工せずinputとしてもう一回スプリントにかける流れ
    • 個人的には、スプリント2回くらいは当たり前にしたい

5日間を終えて

境野の感想です。

事前情報で得ていた「やりきった感」はありました。「時間を区切って、形にすること」が大事なので、否応なく追い込まれます。一番の収穫は「ユーザーテスト」です。(当たり前か)　ここでは大小はありますが、とにかく「気付き」が多く得られるのですが、それが相反すること(動画がいい、という人もいれば、静止画がいいという人もいる)もあります。それはそういう事実があることをわかった上で我々がどう判断するか、の「判断すべきポイント」が学習できたんだと思います。次のステップとしては、プロトタイピングで得た気づきを使ってDay1とかDay2に戻るのですが、今回はここまでの気づきをもって本番反映していきます。その前にプロトタイピングは作るかも…いや、作ったほうがいいですよね。

今回はDesign Sprint Process / デザインスプリントの実際のプロセスについて を元に進めましたが、全てがこのシナリオ通りに行くわけじゃないので、自分たちで「ここまでやろう」を決めるシーンもありました。(そうじゃないと進まない) 都合で開発者は同席できませんでしたが、もっと「機能寄り」の改善スプリントであれば開発者も参加すべきです。(本来は参加必須です)

参加メンバーの声

• 解決したい課題が何なのか、そのためにはどんなユーザーストーリーを提供すべきか、をチームでしっかり議論して決めた上で、具体的な改善策に落としこむプロセスになっていたので、具体策の検討段階で話がそもそも論にならず良かった。（岡田）
• 小手先のサイト改善にならず、本質的なUX改善につながると感じた。（岡田）
• 検証の結果、ユーザーストーリーを変える必要があると判断した場合など、何度かスプリントのサイクルを回すケースもありそうなので、場合によっては改善リリースまでに時間がかかる。（とはいえ、本番リリース前に問題に気づけたという意味では、無駄に時間がかかるわけではないが。）（岡田）
• 「ユーザーから素早く有益なフィードバックを得る」ために、Day1～Day5のすべてのプロセスがうまく組み立てられているんだな、と感じた。（近藤）
• 意志決定のプロセスが可視化されていて、意志決定者がその場で決めることができるので、スピード感が良かった（田島）
• アウトプットを喋らずに決めるという手法は、冷静に考える時間がもて、他人に引っ張られずに自分の考えを出せるのでユーザー視点になれてよかった（田島）
• ユーザーストーリーを一人の人が考えるのではなく議論した上で、改善策を出していくので、デザインスプリントをやっている時間内でもそうですが、今後も一定のコンセンサスがとれているので、次に改善する際もコミュニケーションコストをカットできそうな気がする。（細川）
• ステイクホルダーの時間を確保し、決められたフレームワークの時間の中で、一気に開発をすすめられるのが良かった。（細川）
• プロトタイプのつくり込みをどこまでするのかが課題で、スピードを求めすぎてプロトタイプの完成度が低いと、欲しかった検証結果が得られない可能性があるので、プロトタイプをつくる方法は短時間で一定のクオリティになる方法を考えた方がよい（細川）

Thanks

社内初の試みでした。ゼロから勉強、準備して5日間まるっとファシリテートしてくれた近藤さんに超感謝！他プロジェクトにも広げていこう！

おわりに

前後編にわたる連載(?)は以上となります。ものすごく手探りで進めてきましたが上記にあるように得られるものは大きいと感じました。デザインスプリントに取り組んでいらっしゃる組織、チームがありましたらぜひ意見交換などしていきたいです！