フィークルで体験設計をする際に意識したこととその方法

この記事は、2018年12月22日に作成された記事です。
記事内に出てくるサービス「フィークル」は現在終了しています。

こちらは「Service Designer's Advent Calendar 2018」の、22日目の記事です。

こんにちは、UXデザイナーの八尾です。

クリスマスも間近となり、アドベントカレンダーも終盤ですね！

私の2018年UXデザイナーとしてのスキルを生かし、さらに拡張させるため、フィークルという新規事業のプロダクトオーナーを兼務しています。今日はフィークルで体験設計をした際に意識したことを記事にしてみます。

フィークルとは

はじめに、軽くフィークルがどういうサービスなのか触れておきます。

フィークルは、「クライアントが本当に報酬を払ってくれるか不安」「報酬がいつ振り込まれるかわからず不安」などといった、フリーランスの報酬にまつわる不安を解決するサービスです。具体的には、仕事をした際に発生する債権（報酬を請求する権利）をフィークルが買い取ることで、ユーザーに仕事の報酬を先払いするという仕組みとなっています。

フィークルは、新規事業ということもあり、債権の審査や、報酬の振込は人力のオペレーションで成り立っている部分があります。体験を設計する上では、オペレーションなど、サービスの裏側の仕組みも踏まえて設計する必要があります。体験設計は、ユーザーメンタルモデルとシステムの実際の動きをすり合わせる作業であり、システム側の実際の動きに大きな影響を与えているからです。

体験設計はユーザーとのメンタルモデルをすり合わせる作業

メンタルモデルとは

メンタルモデルとは、「AはBのように振る舞うだろう」という頭の中のイメージです。

UX TIMESの記事の例がわかりやすかったので引用すると、

以下の図の２人のうち、１人は過去に犬に噛まれたことがあり「犬は噛むから危ない」というメンタルモデルを持ち、もう１人は家で犬を飼っており「犬は可愛く触れ合える」というメンタルモデルを持っている。この２人のアクションは異なり、それぞれのメンタルモデルがアクションに影響を与えているということになる。

と、書かれています。

上記の例のように、メンタルモデルは過去の経験やこれまでの当たり前から生成される頭の中のイメージです。

ユーザー体験を考えることは、ユーザーのもつメンタルモデルと、サービスの実際の動きをすり合わせることと捉えることができます。

UIによってユーザーが形成するメンタルモデルが変化する

ユーザーのメンタルモデルは、サービス自身がどのような振る舞いやコミュニケーションをとるかで変わります。

例えば、フィークルには、申請内容を審査するというオペレーションがあります。審査中、ユーザーは結果を待つことになるのですが、ユーザーの「審査」に対するメンタルモデルによって感じ方が変わります。審査期間が1日だった場合でも、

「やっと終わったのか、遅い！」

「もう終わったのか、意外と早かったな」

両方の感情的な体験がありえます。

この体験はUIでユーザーとどのようにインタラクションしているかで決まります。

同じ「審査」というものが発生するサービスでも、CASHというサービスのユーザーの審査に対するメンタルモデルは、フィークルと全く異なります。

CASHは、モノを担保にお金を得るというサービスですが、「目の前のアイテムが一瞬でキャッシュに変わる」という訴求をしています。このような訴求審査はすぐに終わるんだろうなというメンタルモデルをユーザーは「審査」に対してもつでしょう。

その理解に応える（あるいはいい意味で裏切る）ことができたサービスだと考えられます。

フィークルでは、ユーザーに適切なメンタルモデルを持ってもらうために、サービスブループリントを用いて体験の検討をおこないました。

サービスブループリントを利用した体験設計

サービスブループリントとは 

サービス側の実際の動きとユーザーのメンタルモデル両方を明らかにするため、サービスブループリントを作成しました。

サービスブループリントは、ユーザーの行動と、ユーザーには見えないオペレーションのフローを両方同時に可視化できるようにする方法です。

ホテルサービスなど、webサービス以外でもよく使われる手法ですが、webサービスでも、ユーザーには見えない部分で手動オペレーションが発生したりするサービス（新規事業などだと多いかもしれませんね）にはオススメのツールです。

U-Siteの記事に定義と例があったので詳しくは以下の記事をご覧ください

サービスブループリント：定義

サービスブループリントを使ったメンタルモデルの可視化

サービスブループリントは、ユーザーの行動の洗い出しとマッピングをおこない、その後、ユーザーには見えない部分でどのようなオペレーションがおこなわれているかを洗い出し、マッピングして作成しました。

サービスブループリントの作成に注意したことは、デザイナーやPOだけでなく、必ず開発メンバーもオペレーション担当やカスタマーサポート担当のメンバーにも参加してもらい、抜け漏れがないようにすることです。

そして、一通り現状の体験や裏側の仕組みをマッピングした後、ユーザーはサービスの各フェーズでどういったことを期待していて、サービスはそこに応えられているかを確認していきました。

せっかくサービスブループリントを作ったので、サービスブループリントの得意なことと苦手なことをまとめておきます。

サービスブループリントが得意なこと

・裏側を含めたサービスのすベてを可視化すること
・ユーザーとサービスのメンタルモデルを明らかにすること
・チームメンバー全員に参加する機会を提供すること（カスタマージャーニーマップはデザイナーが中心になりがちですが、サービスブループリントだとシステムやオペレーションも含まれるので必然的に全メンバーの参加が促進されます）

サービスブループリントが苦手なこと

・サービスには関わらないユーザーのコンテキストを反映させること
・ユーザーの感情を反映させること
・回遊性の高いサービスの反映（難しそう、、）

サービスブループリントをベースに解決策を立案

メンタルモデルの齟齬が明らかになると、それを解決する案を考えます。齟齬への対応は大きく２通りです。

・システムの実際の動きを変える（裏側のオペレーションの変更やサービスのフローの変更）
・ユーザーのメンタルモデルを変える（ユーザーとのコミュニケーションの変更など）

齟齬が起きているポイントそれぞれで、どちらの対応をとるかを検討していきました。検討する際の観点は、重要性と緊急性とコストで議論しました。

例えば、

「申請の審査フローの自動化をおこなって審査の時間を短くするべき（システムを変える）だけど、そこにはある程度の時間を要する。短期的には申請時のコミュニケーションを変えてある程度時間がかかることがユーザーに理解してもらえるようにしよう。（ユーザーのメンタルモデルを変える）」

というような議論をおこないました。

この議論を全員でおこなうことで、デザイナーはサービスの裏側についての理解が深まり、サービスの裏側を支えているオペレーションの担当者はユーザーのメンタルモデルを理解することができます。

サービス改善に関わる全員が同じ認識を持っておくことで、管理画面の自動化とユーザビリティ改善のどちらを優先するかなどといった優先度のつけづらい議論がしやすくなります。

最後に

体験設計はUIだけでなくあらゆる要素を複合的に捉えてこそできることなんだなという学びを書いてみました。

サービスの実態と、ユーザーの期待がずれることがしばしばおきます。特に広告を見て期待値が上がったものの、実際にサービスでは期待に応えきれない場合もあります。そうなると、ユーザーはサービスに価値を感じなくなり、利用をやめるでしょう。

このような悲劇を防ぐために、体験を作る上で、メンタルモデルは一つのキーワードになると思います。そのメンタルモデルを整理する一つの手法として、サービスブループリントの利用例を紹介しました。

ぜひサービス全体の体験について考える機会があれば、ユーザーのメンタルモデルとサービスの実際の動きそれぞれの関係を整理して考えてみるのはいかがでしょうか？