本当に実践的なデザインドキュメントの書き方 第2回:受託側と発注側のミゾを埋めるUXデザインドキュメント | アドビUX道場 #UXDojo

連載

本当に実践的なデザインドキュメントの書き方

この連載は、現在のWeb制作における分業体制を前提に、情報設計に関わる『デザインドキュメント』をきちんと制作することで、受託側と発注側のミゾを埋める手段を探ります。

[図]デザイナーも参加してみるべき|「このウェブサイトでは、どんな人に、どうなってほしいのか」デザイナーがまとめに参加すれば一気通貫できる

前回は、ユーザーニーズの取りまとめにデザイナーが取り組むことで、分業のあり方を見直し、UX デザインを理解してもらうファーストステップになるというお話をしました。簡単に言えば「この Web サイトではどんな人にどうなってほしいのか?」をまとめる工程にデザイナーも参加してみるということです。

今回は、3種類のデザインドキュメントが、受託側と発注側のミゾを埋めるためにどのように役立つのかをご紹介します。

発注側と受注側の意識のズレ

[図]要件定義と、サイトマップやワイヤーフレームの間にはブラックボックスがある

よく耳にする問題の中に「前段の検討が終わっていないと感じられるワイヤーフレームを渡され、要件定義の段階から再整理しなければならなくなった」というものがあります。
ディレクターとしては、間違った伝言ゲームを行ったら、余計なコストがかかるし非効率です。スケジュールやコストの管理はプロジェクトマネージャーとして一番大事な部分ですから、わざわざそんなことをするわけがありません。

もちろん「あいだに人が挟まっているから」という理由もあるでしょう。しかし、根本的な原因は、受注者と発注者の視点のズレが原因です。伝えるべき情報の認識がズレているため、デザインの段階までに降りてきた時に情報が足りなくなるのです。

[図]発注側と受注側のあいだに生じる意識のズレ(セグメントとユーザー、マクロとミクロ、オペレーションとプロジェクト)を埋めるUXドキュメント

ウェブサイトを日々運用している発注側と、新規制作やリニューアルを担当する受注側では大きく3点ほど視点の違いがあると考えられます。

これらがズレているので、合意しておくべき粒度がズレてしまい、あとから確認しなおすという事態が起きるのです。デザイナーがまとめに参加する際にこのことを理解しておけば、きちんと軸を持ったデザインを進めることができるようになるはずです。そして、その溝を埋めるのに役に立つのがデザインドキュメントです。それでは、それぞれの点をどのようにデザインドキュメントが解決するのか、ひとつずつ具体的にみていきましょう。

視点のズレ1. ユーザーの捉え方

[図]セグメントとユーザー|発注側はセグメントで捉える、受注側は個人の背景・目的・動機・行動を知りたい

1つ目は、ユーザーの捉え方の違いです。発注側はユーザーをセグメントとして捉えていることが多いでしょう。ある製品やサービスを提供する場合、まずセグメントの特定から着手することは一般的です。 一般消費者に向けたものであれば年代・性別・住所・家族構成・収入など、ビジネス向け商材であれば業種・業態・会社の規模・担当部署・担当者の決裁範囲などでターゲットユーザーを面(上図左)として捉えながら絞り込んでいきます。

しかし、デザインする上では、こういったセグメントの情報だけでは足りません。例えば「都内在住・30代・男性・会社員・既婚・子供あり」が対象のセグメントだとして、私が所属しているfreee株式会社だけでもこの属性の人が何十人もいます。そうした人達全員に向かってデザインをするというアプローチにはちょっと無理があります。いかに属性を絞り込んだとしても、ターゲットはあくまで提供者側の考えとして、どの範囲になら受け入れられそうか、どの範囲に届けたいかを示すものです。ここにユーザー側、すなわち個人の視点は存在しません。

ウェブサイトは、数名で一緒に見て相談しながら使うものではありません。ユーザーはサイトと1対1のコミュニケーションを行いつつ利用します。必然的に、受注側は、訪れた個人が独力で目的を達成できるようにデザインすることになります。

そのためには、訪れたユーザーがどういう前提を持ってこの企業と関わっているのか?その人の目的や動機は何なのか?それゆえにどういった行動を行うのか?といったあたりを明らかにする(言い方を変えれば、決め打ちする)必要があるのです。

[図]UX=期待や感想=主観|受注側が知りたい背景・目的・動機・行動は、一言で言えば「主観」

UX、すなわちユーザー体験は個人の心の中に発生するものであり、ユーザーの主観によって左右されます。企業や団体のユーザーである個人にとって好ましい行動を実現することで、満足という感想を持ってもらうことが企業側の利益にもなると考え、その満足につながるプロセスを再現可能にしようというのが UXデザインの目的です。そのためには、セグメント内のユーザーの目的や動機を知ることが必要になります。

[図]ペルソナシートの例|生鮮食品ECサイトにおける、育児に忙しい主婦のペルソナ。1日の時間割、買い物に割ける時間、料理に対する考え方、生協を使う理由などが記されている

そこで登場するのがペルソナです。ペルソナは、代表的なユーザーのパターンを形にしたもので、その個人にどんな背景があり、どういった生活をしていて、どのような動機があって、何がゴールなのか、といったことをまとめたデザインドキュメントです。

ユーザーと1対1で対峙するウェブサイトだからこそ、個人の主観を満足させるということを念頭に置くUXデザインという手法が馴染みやすく、そのためにペルソナ手法が取り沙汰されるようになったのだと考えています。

視点のズレ2. サイトの位置づけの捉え方

[図]マクロとミクロ|発注側は全体施策の一部としてウェブサイトを捉えている。受注側はウェブサイトを中心として周辺施策があると捉えている

2つ目はウェブサイトの位置づけの捉え方の違いです。企業活動や製品を知ってもらう手段には、ウェブサイト以外にも媒体広告、テレビCM、ダイレクトメール、イベント開催、口コミなど多数あり、発注側はそれらを組み合わせてユーザーの認知や理解を得ようとしています。また、実際の購入やサポートの手段も、実店舗があったり、申込書による購入ができたり、電話でサポートするなど多数あります。発注側にとって、ウェブサイトをはあくまで全体の施策の一部です。

しかし受注側は、特定のウェブサイトの構築やリニューアルを頼まれているため、そのウェブサイトを企業活動の中心のように錯覚してしまいがちです。イメージできるとしても、ウェブサイトの流入経路となっている広告は何か、そのウェブサイトの内容がSNSでどのように話されているか、といった周辺領域にとどまるでしょう。ユーザーの生活全体の中での企業との接点、目的を満たすためのチャネルなど、施策の全体像を理解しないままプロジェクトが進行しているケースは多いはずです。

もう一つ重要なポイントは、体験というのは時系列に進み、積み重なっていくものであるということです。複数ある施策の関係性にも体験は影響されます。良い体験をデザインするには、体験の流れも理解する必要があるのです。

[図]UXの時系列。利用前は予期的UX、体験を想像する。利用中は一時的UX、体験する。利用後はエピソード的UX、ある体験を内省する。利用時間全体が累積的UX、多種多様な利用期間を回想する

出典:UX白書

上の図はUX白書に記載されているものです。私たちはウェブサイトやアプリケーションを使っている瞬間の体験をUXと考えてしまいがちです。しかし実際はそのウェブサイトを訪れる前にサイトを知った方法や、知った時に想像した体験、さらに使った後に持った感想も、ユーザーにとっては体験の一部です。そして、体験は時系列に進み、積み重なります。過去の体験を踏まえて、次の体験を迎えるわけです。

[図]Airbnbを利用するユーザーのカスタマージャーニーマップの例。列見出しとして宿泊候補を探す、宿泊先を決める、宿泊地に行く、宿泊地を評価がある。行見出しとしてタッチポイント(行動)、思考、感情、インサイトがある

カスタマージャーニーマップを正しく活用するには「おもてなし」と「カスタマーエクスペリエンス」の理解から | 顧客の行動パターンを理解するためのカスタマージャーニーマップ入門 | Web担当者Forum

UXデザインにおいて、体験の流れと全体像を記述する代表的なアウトプットに、カスタマージャーニーマップがあります。ユーザーの行動フェーズ、ユーザーと企業のタッチポイント、その中での今回対象となっているサイトの位置づけを、時系列に沿って積み重なっていく体験として記述するデザインドキュメントです。現状の様々なイベントの関係性が明らかになり、ユーザーの背景・動機・ゴールを的確に掴む助けになります。

受注側は、サイト利用時のユーザーの行動や思考は把握しようとするものの、サイト構築の範疇を超えた全体感を理解していないケースが多いはずです。そして発注側は、プロジェクトのスコープではないから伝えなくてもよいだろうと考えがちです。そうしたギャップを埋め、デザインの対象となるユーザーに対する認識を揃えるために、タッチポイントと体験を直線的に並べた図であるカスタマージャーニーマップは効果を発揮します。

視点のズレ3. ウェブサイト構築に対する視点

[図]オペレーションとプロジェクト|発注者は日々運営し、経営計画から降りてきたKPIを追っている。受注者はゼロベースでプロジェクトとして関わるため、KPIに対する理解が浅い

3つ目は、日々運用するオペレーションなのか、ゼロから完成に向かうプロジェクトなのか、という違いです。発注側は、全体施策の一部として、日々ウェブサイトを運用しています。そこでは、資料請求数、購入数、問い合わせ数、アンケートによる満足度など、おおむね定量的な指標が意識されています。そして、その指標は運用や企画を行う部署の目標に繋がっており、さらにその目標は経営計画に繋がります。
ポイントは、日々運用するオペレーションの中では、こういった指標が当たり前の存在になっているということです。

一方、受注側にとって、話はゼロからスタートします。発注側からのブリーフィングでは、先に挙げた定量的な指標も「形の上では」共有されるでしょう。

しかし、指標が決まった背景は何か、ユーザーの振る舞いが変わると指標はどう動くのか、指標同士がどう影響し合うのか、過去どういうチャレンジがあったのか、といった細かい点までは共有されないことが多いでしょう。発注側としてはそれらは当たり前のことになってしまっているからです。

このような状態のまま、サイトマップやワイヤーフレームを書くと、問題が起きます。発注側が持つ指標をどう改善するのかという問いに、答えることができないからです。一見整って見えたとしても、そもそものお題をクリアできる見通しが持てないものに対して投資すべきか、発注者は頭を悩ませるはずです。

[図]価値のシナリオ|生協ECアプリのリニューアルをテーマとし、ユーザーの特徴→ユーザーの本質的な欲求→価値のシナリオ→価値が関わるシーンと繋いでいる

[図]行動のシナリオ|価値のシナリオを引き継ぎ、ユーザーの目標とシーンを元に、具体的な理想のシナリオを文章として記述している。その文章から、理想のシナリオを成立させるために必要なタスクを導出している

UXデザインでは、ユーザーにどう振る舞ってほしいかをシナリオという形で示します。振る舞いの変化が指標の達成につながることが伝われば、発注側は、新しいサイトの効果を具体的にイメージできますし、指標達成のためにはどのような情報を共有すればよいのかも理解できるようになるでしょう。

シナリオにはさまざまなスタイルがあります。テキストで書き記していくものもあれば、イラストを使ったやりかた、実際に体を動かして表現する方法もあります。

どのやり方を選ぶにせよ、守るべき点があります。それは、実現可能性はいったん脇に置いてユーザーにとっての理想の姿を考える点です。
UXデザインでは、個人の主観を満足させるための施策を企業がサポートすることで、双方に良い結果を生もうと考えます。そのため、提供側の都合はさておき、まずはどういう体験をもたらすべきかということから検討します。

理想の姿をシナリオに書き記すことで、現状のジャーニーマップと比較でき、どこを改善すべきなのかが見えてきます。すると、「ユーザーにとって何を良くすると、どういう指標が改善されるか」を議論しはじめたり、どこに重点的にアプローチするべきかを検討できるようになるでしょう。

指標とワイヤーフレームのミゾを埋めるデザインドキュメント

UXデザインの記事や書籍を見ていると、事業を行っている側がユーザーを見ていないという表現が頻繁に出てきます。私はこの表現は半分当たっていて、半分違うと感じています。確かに、ユーザーがどう行動するかの動機を捉えきれていない、そのためにユーザー調査を行うべきという話は理解できます。とはいえ、サービスや商品を提供する事業を行う上で、ユーザーをまったく見ていないということはあり得ません。

ウェブデザインの現場における重要な課題が、調査の有無よりもっと手前の段階にあります。ユーザーの振る舞いが、発注側では指標という形に、受注側ではサイトマップやワイヤーフレームといったモノに変化していて「それが互いに暗黙の了解になっている」という状況です。両者の意識のズレから生まれたミゾがそこでは見逃されています。この問題を、まずは解決しなければなりません。これまで紹介したように、デザインドキュメントがその溝を埋めるのに役立ちます。

[テキスト]AsIs→ToBe|現状のモデル化→新しいシナリオの策定を行ったのち、行動のシナリオとしてサイトマップやフローを作る。そして操作のシナリオとしてワイヤーフレームを作り、それらをプロトタイピングしていく

現状(AsIs)理解という観点からは、ペルソナで「どんな人が」、カスタマージャーニーマップで「どんな行動をしているか」について合意できます。そして、理想(ToBe)の検討という観点からは、「ユーザーはどう振る舞えるべきか」をシナリオで合意できます。その上で、それを実現するサイト構造をサイトマップで、画面構成をワイヤーフレームで考えれば、発注側と受注側での意識のズレが解消され、要件とサイトマップのあいだのミゾは埋まります。
また、合意を積み重ねることでチームとしての目標も明らかになり、デザインに必要な情報も十分に得られるようになるはずです。

私の経験上、このようなプロセスで進めているときは、デザイン案を出したときに過度に説明を求められることはありません。既に合意済みのデザインドキュメントの、どのポイントに対してどういうアプローチをしたかを説明すれば十分だからです。

次回はデザインドキュメントの具体例として、簡易ペルソナの解説と作成方法をご紹介します。