前回は、ユーザー調査の結果をワークモデル分析、KJ法を使った分析を経て、ターゲットユーザーのモデルとなるペルソナを作成するところまで作業をしてもらいました。
宿題として各自に、自分たちがつくったペルソナにぴったりだと思われる写真を探してきてもらうことを宿題としました。
今週の作業はその写真のなかから一番ぴったりと思われる写真を選んでもらうことからスタート。その後、ペルソナの期待を満たしつつ、ペルソナがゴールと考える状態まで導くためのWebサイトの要件、プロトタイプを、シナリオとペーパープロトタイピングの手法を使ってデザインしてもらいました。
以下のステップです。
- シナリオ
- 要件抽出、フロー図作成
- ペーパープロトタイプ
- アクティングアウトによる発表
それでは、また作業の内容を紹介しつつ、プロセスの説明を。
シナリオ
ペルソナを使ったシナリオ法によるデザインは、ペルソナがあるゴール（今回の場合は、旅行先での過ごし方のプランを決めるために情報収集を行い、同行者に相談したりしながら、最終的にプランを決定する）に到達するために行う行動、デザインの対象となるモノ（今回なら旅行情報サイト）をどう使うのかを、物語風に記述することで、デザインするモノに求められる要件（今回なら旅行情報サイトのサービス要件）を抽出するために行うものです。僕がいつもワークショップで使っているシナリオ用のテンプレートは、シナリオで対象となるシーンにおけるペルソナの「目的」と「ゴール」を書く欄が上にあり、その下に、ペルソナが行う行動を段階的に記述していく「プロセス」の欄、それに対応する形で「ユーザーの要求」「必要な機能、コンテンツ」の欄が設けられた表があるものです。
シナリオを書く際は、最初にそのシーンでペルソナが何を目的として行動し、具体的にどんなものを手に入れたらゴールとなるか（行動が終了するか）を明らかにします。
そのうえで、ペルソナがゴールに到達するまでに行う行動、Webサイトでどんな手順で情報を入手し、情報をどう扱うのか、自分以外の誰かとWebサイトを使って情報の共有を行うのか、その際はどんな方法を使って行うのか、などの行動のプロセスを考え記述していきます。
作成するシナリオは、新しくつくるWebサイトのデザインコンセプトとなるものです。ですから、シナリオに描かれたペルソナの行動は、ユーザー調査などでみられた現実そのものではなく、現実の問題を解決する方法をペルソナに提供する理想の状況を提供すべく描かれている必要があります。
今回の参加者には、写真を探してきてもらう宿題とともに、各自がシナリオの案を書いてきてもらうことにしていました。
実際の作業は各メンバーが考えてきた案を元に、チームでひとつのシナリオを書く形で進めてもらいました。
事前の説明で、あたらめてユーザー中心のデザインは、チームでの共同作業が基本で、たがいに他の誰かの意見を聞いて自分の意見を膨らませたりというチームでの作業の利点を最大限に生かすようにしましょうとアドバイスしておいたおかげもあってか、今回の作業は前回以上にチーム内でのコミュニケーション・議論が活発になって、どちらのチームも、これまでのワークショップのどの参加者以上に作業がスムーズに進んでいた気がします。
要件抽出、フロー図作成
シナリオを書くときのコツは最初に、ペルソナがゴールに辿りつくまでに行う行動を描いた「プロセス」を埋めるようにすることです。「ユーザー要求」や「必要な機能・コンテンツ」の欄は、プロセスすべてが決まったあとで考えるようにすることです。何度かワークショップをやっていますが、大体失敗するのは、すぐにペルソナが行う行動よりも具体的な機能やコンテンツの話になってしまうことです。参加者はWebサイトの企画や設計・デザインに関わる方なので、そっちのほうを考える方が楽なんですね。いつもやってるから。
でも、そうすると、ペルソナのことは忘れて自分たち自身が欲しい機能とか、不特定なユーザーのことを想定して機能が盛りだくさんになってしまう。それでは、せっかくターゲットユーザーのモデルとしてペルソナをつくった意味がないんですね。デザインがボケたものになってしまうんです。
そうではなくペルソナの期待することに焦点を絞って、あくまでペルソナの行動、ペルソナが行うWebサイトやまわりの人たちとのコミュニケーションを流れに沿って考えることが大事なんです。そうすれば、いつWebサイト側がペルソナに対して、どんなメニューを提示すればよいか、どういう提供の仕方をすればよいかということがみえてくる。それを元にユーザーがプロセスの各段階で求める情報は何か、それに応えるためにはどんなコンテンツや機能が必要かということがペルソナの期待に対応した形で考えられるようになる。それが結局、ペルソナにあわせたWebサイトのサービス要件の抽出なんですね。
そうやって要件が抽出できたら、今度はそれをすこしWebサイトの形として考えるために、画面のフロー図を作成します。これはできればペルソナが実際に辿る順番で画面の流れを描いたほうがいいんですけど、サイトの構成を把握するためのサイトマップを書きながら考えてもいいと思います。
ここでは次の作業として行うペーパープロトタイプで作成する画面数を把握する意味合いもあります。何枚ペーパープロトタイプを作成しないといけないか。どのくらいの作業量か、と。
ペーパープロトタイプ
ペーパープロトタイプは、シナリオを使って考えたサービスのコンセプトを具現化する作業の最終のステップです。シナリオから抽出された要件をフロー図に落とし込みましたが、今度はそのフロー図に描いた各画面のイメージを具体的に落とし込んでいきます。もちろん、この時点で各画面にどんな情報の要素、機能の要素が必要かが特定されていないと各画面の構成を考えることはできません。昨日のワークショップでは時間がないので、シナリオのなかの「ユーザー要求」や「必要な機能・コンテンツ」の欄で記述した情報だけを元にペーパープロトタイプを作成してもらいましたが、本来ならこのステップに入る前に、そこで上がった要件を具体的にWebサイトのUI上に表現する要素としてラベリングを考えることも含めて整理しておくとよいと思います。
ペーパープロトタイプで確認すべき内容は、情報構造、表現、振る舞いの3つだと僕は思っています。画面上、情報がどのように構造化されているか、個々の情報はどのように表現されている必要があるか、また、ユーザーが行うアクションに対してWebサイトはどのように振舞うべきか。
特に、最後の振る舞いの部分がペーパープロトタイピングを行う最大のメリットかなと思っています。
最近のWebサイトはAjaxなどをつかって画面遷移を行うなく、ユーザーとのコミュニケーションを行うインタラクションの形が多くなってきています。これをよくWebサイトの設計者が行うように、パワーポイントなどをつかった平面的で静的な表現だけで考えるのはちょっとむずかしい。その点、ペーパープロトタイプなら、こんな風にパーツをポストイットなどを使ってつくることで、動きの表現も簡単に確認できるようになります。
このパーツを別々につくるというのがペーパープロトタイピングのコツで、ユーザーのアクションによって動的に変化する部分は、別のパーツとして作成したほうがいいんですね。
ほかにもこんな風にサイト内で変化しないグローバルメニューなどは、台紙のほうに書きこんでしまっておくといいと思います。
そうやってつくるとこんな風なペーパープロトタイプができます。旅のプランをスケジュール表に落とし込む画面のイメージですね。
ポストイットの部分はユーザーがドラッグして編集が可能な箇所として表現されています。こういう風につくると、ユーザーの利用イメージが思い浮かびやすくなりますし、使う際の問題点もみえてきます。
こちらはグーグルマップ風に、ポイントをクリックするとバルーン表現で情報が表示される画面のイメージ。これもバルーンをポストイットで表現しています。
ペーパープロトタイピングは、このように描きながら、ユーザーが実際に使う画面の見た目の印象だけでなく、動きから感じる印象も確認できるという点で、優れた方法だと思います。
メンバー内で分担しながら作業を行うと、おたがいに意見をいいあい、デザインをブラッシュアップできてよいと思います。
アクティングアウト
こうして作成したプロトタイプを元に、アクティングアウトという方法を使って発表してもらいました。アクティングアウトは実際にサービスを利用するユーザーの利用状況を再現しながらサービスそのものの説明をする方法で、ひとりがペルソナ役、別の誰かがシステム役になってペーパープロトタイプの画面を変更しながらサービス内容の説明を行います。
ペーパープロトタイプは分担して作成してもらいましたので、全体の流れのなかでの整合性も確認するために、チームごとに発表のリハーサルをしてもらいます。
そうすると、またペーパープロトタイプをつくってる際には気づかない問題点に結構気づくんですね。実際のユーザーの利用シーンをシミュレーションするので、ユーザー視点でデザインの問題点が見えてくるわけです。これもペーパープロトタイピングを行う利点のひとつです。
発表はこんな風に、ペルソナの写真を前にしながら各チーム行ってもらいました。
アクティングアウトはちょっとした寸劇みたいなもので、ちょっと演じるのが恥ずかしいところもありますが、2チームともアドリブなども加えながら楽しく発表してくれました。
最後にリフレクションとして2日間の感想や今後の仕事にどう活かすかというコメントをいただきました。そのコメントが的をついてるものが多かったと感じるのは、いつにも増して2チームの出来がよかったからなんだろうなと思いました。やっぱり感じることっていうのはやったことに比例するんでしょうね。
今回の2チームは失敗することをいとわず積極的に作業を行い、かつチーム内での互いのコミュニケーションを積極的に行ったことが成功の大きな要因だったんでしょうね。
よいワークショップになってよかったなと思いました。
先週の1日目の講義の模様：第3回ユーザー中心のWebサイト設計・ワークショップ1日目
- 第1回目（2008年10月18日、25日開催）
- 第2回目（2009年2月21日、28日開催）
この記事へのコメント