Piece of Service Design Sprints

Service Design Sprints のフレームワークを使って、試験的にワークショップを実施しました。

Service Design Sprints とは、リーン・スタートアップとサービスデザインを組み合わせたようなもので、4 日間で MVS (Minimum Viable Service) を得る手法です。Google Ventures の Design Sprint とは異なるものです。そのほか半日や 2 日間で行う Google Design Sprint もあります。

  • Service Design Sprints / 4日間 / 最小限のサービス (MVS) を得る
  • GV Design Sprint / 5日間 / 最小限のプロダクト (MVP) を得る

最終的に落とし込むのが、サービスかプロダクトかという点で違いがありますが、どちらもリーンスタートアップをベースにした短期間集中プログラムです。ちなみに、書籍は『サービス・スタートアップ』と『Sprint』が参考になります。

ワークショップ

今回のワークショップは、短い時間の中で Service Design Sprints を知ってもらうこと、体験を通してアイデア創出のヒントをつかんでもらうことを目的に取り組みました。

2時間だけだったこともあり、ワークの中から「Time Machine / Invoke your heroes / SWAP」の3つだけを取り出し、それぞれを約 20 分くらいで取りかかるというクレイジーなスケジュールで取り組みました。

  • Time Machine: 過去・現在・未来を調査する
  • Invoke your heroes: ヒーローにインタビュー
  • SWAP: たくさんアイデアを出す

Time Machine – 過去・現在・未来を調査する

ワークショップ風景

まず、グループごとに対象サービスを決めてもらいます。以下4つの中から選んでもらい、それぞれの過去・現在・未来を調査していきました。サービスの選定基準は参加者が利用したことのあるサービスとしてボクのほうであらかじめ用意しました。

  • コンビニ
  • 地下鉄
  • コーヒーショップ
  • スーパー

ワークブックでは「Yesterday / Today / Tomorrow」と書かれていましたが、いつの時代かで迷う人もいたので「起源 / 今 / SF」くらいの振れ幅で考えてもらうようにしました。過去を見つめ直してもらうことで、新しい未来を考えるキッカケにつながります。

そのあとに、それぞれの時間軸で「Learn / Use / Remember」を深掘りしてもらいました。これも「認知方法 / 利用方法 / リピート方法」という具合に、独自の解釈を加えて進めてもらいました。

Invoke your heroes – ヒーローにインタビュー

Invoke your heroes

実際のユーザーにインタビューをしてもらいます。この場合「Hero」とは「エクストリーム・ユーザー」を指します。今回は時間もなかったので以下 4 タイプから選んでもらうようにしました。

  • ヘビーユーザー(熱中しやすい人)
  • ギーク/テッキー(一日中スマホ触っているような人)
  • 臆病/慎重すぎる(何でも臆病になる人)
  • シニア(高齢者)

このタイプが1で決めたサービスにおいて、どう振る舞うのか(どんな人で、どんな行動をするのか)を付箋に書いてもらい「The Hero Profile」のワークシートに貼り付けてもらいました。

だいたいイメージが固まってきたあとに、実在する人にインタビューをしてもらいます。聞き手と書き手のペアで取り組んでもらうようにして、オフィス内で直接聞いてみたり、チャットやメッセで聞いたりしてもらいました。

インタビュー項目は、主にペルソナで使われる構成要素をベースに考えてもらいました。

  • プロフィール(性別・年齢・居住地・職業・家族構成など)
  • サービス利用(1で決めたサービスとの関わり方)
  • 価値観(性格やタイプ、なにを大事にしているかなど)
  • 課題や要望(どういう課題を持っているかなど)

SWAP – たくさんアイデアを出す

SWAP

インタビューで得たニーズや課題からアイデアを描いていきます。インタビューした中から、特徴的だったことや重要そうな課題やニーズを付箋に書き出してもらいます。その中からコアな課題を見つけ出し、解決案(アイデア)を考えるベースをつくります。

解決案は「SWAP」のワークシートをもとに1人2案以上を作ってもらいました。簡単なスケッチと説明文を書いてもらいグループ内で共有し、お互いにプレゼンしてもらってグループでの1案を決めてもらいました。

この解決案(アイデア)の説明も独自に考えて、「意図 / Intention」と「要素 / Avatar」とで分けて考えてもらうようにしました。そうすると、アイデアの概要をすぐに共有しやすくなると思ったので。

  • 意図 /Intention: そのサービスの意図、ユーザーの目的について書く
  • 要素 /Avatar: そのサービスを構成する要素、インターフェースや環境を書く

最後に、グループごとに施策案を発表してもらいます。各グループでいろいろ施策を出してもらいグルーピングなどをし、グループ内で投票して1案を決めてもらう方式で進めました。グループごとに発表してもらい、無事に終えることができました。

まとめ

非常に短い時間でしたが、比較的スムーズに進めることができました。今回のワークショップで一番伝えたかったのは「インタビューして考えたアイデアは、インタビューした人だけの解決案ではないということ」です。

デザインスプリントという言葉を知らない人でも、こうした進め方に慣れてくれば、どういうインプットでどういうアウトプットができそうかが分かり、早い段階で問題解決のアイデアをつくる術が学べるという点もよかったと思います。

また、これまでにユーザーリサーチやインタビューをしたことがない人でも、実際にインタビューをしてもらったりしてユーザー視点を体験するので、デスクワークだけでは気づきにくい新たな気づきを得るなどの効用もあったかと思います。

参加者からも好評でしたので、今回のを糧にしてまた違う機会でも取り組んでみたいと思います。

日本のコミュニティ発足

今回のワークショップで利用した Service Design Sprints ですが、マスター認定をもらっている日本人どうしでコミュニティを発足しました。インフォバーンの井登さんハコスコの奥さんと一緒にこの活動を盛り上げていければと思います。

近いうちにイベント開催や勉強会兼ねたミートアップを予定しているので、このあたり興味・関心をお持ちの方は Facebook メッセでもかまわないのでご連絡ください。

sds-JP-masters


OpenUM + 千葉市 + Code for Chiba

グループワーク

2015年8月5日、OpenUMプロジェクトによるワークショップイベント「千葉市サイトのペーパープロトを作成する実践ワークショップ」を開催しました。

前回、横浜市と開催したイベントの第二弾になり、今回は千葉市にご協力をお願いしました。会場運営は、前回と同じロフトワークさんにご協力いただき、地元関係者というカタチで Code for Chiba の方々にご協力いただきました。

今回のワークショップでは、グループ毎にペルソナやジャーニーマップから自治体サイトにおける課題を抽出し、ペーパープロトタイピングで最適な画面設計を提案するというものです。前回に引き続き、20名程度の参加者と千葉市広報広聴課の皆さんとで行いました。

はじめに、アスコエ代表の安井さんから、わたしたちの自治体に対する意識の低さについて言及され、メニューのわかりづらさを取っ掛かりに行政関係者にはまだまだ「UX」視点が不足している点、そのうえで今回のイベントの意義についてご説明いただきました。

千葉市の現状課題

千葉市広報広聴課の高橋さんからは、現状の千葉市サイトのリニューアル経緯と今後の課題についてお話いただきました。2万ページにもなるボリュームや縦割り組織においてできた情報の壁など、結果として本来市民が望むようなものになっていない部分も多々あるというお話でした。その中で、横浜市と同じように住民票関連での手続きが約53万件あり課題が多いということで、今回のワークショップで取り上げることになりました。

ペルソナとジャーニーマップの理解

今回は、あらかじめペルソナとジャーニーマップを用意したうえで、全員で読み解きながら対象画面の施策を検討して進めました。

ジャーニーマップ

ペルソナA: 関山さん「電子証明書の更新」
ジャーニーマップA: 更新手続きが目的だが更新手続きの情報がない課題
ペルソナB: 篠原さん「結婚のため戸籍謄本の取得」
ジャーニーマップB: 検索結果ページに近くの手続き場所が出てこない課題

今回用意したペルソナは、ペルソナAの電子証明手続きとペルソナBの戸籍謄本に関する手続きについてです。どちらも、それぞれのコンテクスト(経緯)をジャーニーマップにした際に、本来の目的が達成できていない課題があり、対象となる画面をどのように改善すればそれらがスムーズに流れたのか、というお題です。

ペーパープロトタイピング

今回は、参加者のほとんどがペーパープロトタイピングをしたことがない方が多かったため、まずは既存サイトの画面を題材に練習しました。その場で説明をしましたが、順番に細部を積み上げていくのではなく、全体構成から徐々に細部を仕上げていく方法です。グループは4つあり、それぞれのグループごとに対象を決めて進めました。

ペーパープロトタイピング

まず個人ワークをしてからグループで議論したため、各グループともに実施内容を細かく議論できた印象でした。途中で参加者から質問があったように、対象画面だけで解決する部分と、ジャーニーマップにしたことで対象画面以外で解決する部分とがあることに改めて気づくことができたと思います。今回の例でいうと、ペルソナAでいえば電子証明用のICカードリーダライタでの接点、ペルソナBでいう検索エンジン対策(はじめに目的のページがヒットすること)などは、今回の対象以外で解決しなければいけない部分として考えることができます。

まとめ

今回のように、ジャーニーマップにすることで全体を俯瞰し、本来対象ではない(ウェブサイトではない)部分の課題にも気づくことができます。また、どちらのペルソナにとっても、ランディングしたページですべての道標がわかるようにナビゲーションの設計が肝になります。「手続き」という一連の流れを持つサービスではとくにこの部分が重要だと思います。

最後に、今回ご協力いただいた Code for Chiba の活動についても触れ、同じような日本各地にあるコミュニティと連携して今回のような取り組みを継続していければと思います。

発表・講評


Citizen Journey Mapping Workshop #OpenUM

2014年8月7日 (木)、渋谷のloftwork Labで「OpenCU 自治体サイトのサービスを考える - Citizen Journey Map ワークショップ」を開催しました。おかげさまで30人分のチケットを完売することができ、参加者も積極的だったため活気あふれるイベントになりました。

OpenUMワークショップ集合写真

参加者の中には、couldヤスヒサさんや「ユーザビリティエンジニアリング」著者の樽本さんStandard Inc鈴木さんなど、とても豪華な顔ぶれでした。

ワークショップ

ワークショップは、普段よく使う「Customer Journey Map」という言葉に対して、今回は一般市民という意味で「Citizen Journey Map」としましたが、文字通り行政サービス(自治体サイトなど)と一般市民とのやりとりを一連の流れで可視化することで、ペルソナの課題を見つめなおし、新しいソリューションを考えるという内容でした。

また、今回は横浜市広報課の方々にもご協力いただき、横浜市のサイトをワークショップの題材にさせていただくことに加え、顕在化している既存の課題(住民票や戸籍に関する問い合わせが多い点)をご紹介いただきました。

ペルソナとシナリオ

あらかじめペルソナとシナリオを用意していたため、各チームは個別で検討しコアな課題とそのソリューションに集中できる構成で進めることができました。講評には横浜市の方々にもお願いし、実際に取り組んでいる内容と現実とのギャップについてもお話いただきました。

ペルソナ

用意していたのは以下5体のペルソナで、住民票取得に関するシナリオを用意しました。

  • 山下さん (61歳・女) 体が不自由な旦那のかわりに住民票を取得し年金請求を行う
  • 高梨さん (32歳・女) 平日日中に住民票を取得しバイト先に提出する
  • 羽生さん (23歳・女) 引越しの手続きのため住民票を会社に提出する
  • 湯澤さん (32歳・男) パスポート取得のため戸籍謄本を取得する
  • リささん (26歳・女) 日本語で住民票を取得し教習所に提出する

ソリューション

事前にインタビューまでしてできたペルソナと仮説でいくつか作成したペルソナとがあり、情報の粒度がバラバラだった点は反省点ですが、これらのペルソナの課題を抽出して各チームからは次のようなソリューションを考えだしていただきました。

グループワーク

  • 委任状が必要なことに気付けない→バス停サイネージで注意喚起するサービス
  • 一度に全ての情報を取得したい→モバイル自動ガイダンスやFAQサービス
  • 手続き全体がわからない→手続きがまとめてわかり、次の手配を示すサービス
  • 目的の場所で受け取りたい→Web申請でパスポートセンターで受け取れるしくみ
  • 専門用語が多く翻訳がおかしい→運営者側の翻訳ガイドと統一化

そのなかで印象に残ったのは、行政サービスへの不満もそうですが、そもそもWebに対する不安や不信感がある方はサイトには訪れずに電話で済ませてしまっているという点です。そういう点でも Citizen Journey Map にしたことで、事前と事後における課題と感情を見つけることができました。

まとめ

個人的にまとめると、行政サービスに関して利用者の課題となる点は以下の3つ。いずれも行政以外のサービスでも同じようなことが言えるかと思います。

  • 専門用語が多い、漢字が多い、きちんと翻訳されていない
  • 手続きが断片的で、全体の流れ(ステップ)がわかりにくい、無駄に多い
  • 自治体サイトに訪れる以前にも問題がある(ネットへの不信感など)

また、Webサイトに情報量が多い点について横浜市広報課の方々からは、正確さを追求するあまり網羅性を求めてしまう傾向があるというお話をいただきました。必然的に、情報過多に陥ってしまう問題があるとのこと。これに対し、ペルソナ視点で見直した結果、ペルソナの行動からは全体最適よりも個別最適が求められます
つまり、シナリオに沿った流れを俯瞰して見ていくことで、行政手続きが最終目的ではなく、本来の目的は別にあるということがわかります。当たり前ですが、この前提をふまえて設計していくことがなによりも大切だといえます。

発表

最後に、Webサイト構築の視点では、サイト構造などはUMなどを使用して定型化し、目的に合わせたLP(ランディングページ)およびハブとなるページを見直すことで、それぞれの目的をスムーズに達成できる動線を計画することができます。また、次に向かうべき手続きや場所を指し示すことで、回遊施策を盛り込むことができます。

今後は、こうした課題解決の手段としてカタチをアウトプットしていくとともに、今回とは違う行政の方にもご参加いただきまた違った課題とテーマで開催ができればと思います。関係者の皆さん、お疲れさまでした。そしてありがとうございました。


TOHOKU seminars and volunteer #6

東北セミボラ南相馬ボランティアセンター

先週、4/4 (金) に仙台(せんだいメディアテーク)で開催されたWeb広告研究会主催の第六回東北セミボラに参加してきました。

トライバルメディアハウス池田さん電通レイザーフィッシュ得丸さんという豪華なスピーカーとともに、ボクが担当するIAセッションでは、ツルカメ森田さんグリー村越さんインテリジェントネット和田さん専修大学上平さんとで登壇しました。

今回は、森田さんから事前に声をかけてもらい、IAセッションを担当することになったわけですが、ただの講義スタイルではなく、その場で要件を詰めていく過程をワークショップのようなカタチにできないか、という話からはじまりました。

ワークショップ

IA/UXデザインワークショップ

今回のワークショップでは、ボクが司会を担当することになったので、お三方に意見をいただきながら森田さんがリアルタイムドキュメンテーションするという格好になりました。なのでスライドはその場で話を進めるための頭出しにしかなっていないので、中身はありません。閲覧パスワードは「webken」です。

ただ、課題となるRFPづくりを上平さん・和田さんとで作成いただいたため、議論がブレないようにすることができました。今回の課題の題材は「東北物語」のモバイルサイトのリニューアルです。

セッション時間が70分というかなり少ない時間の中で、IAのエッセンスを注入したワークショップを構成するため、なかなか難しい作業でしたが「コンテクストを整理する」という部分にフォーカスして話ができるようにしました。ここで言うコンテクストとは「目的・ユーザー・コンテンツ」を指しています。

ディスカッション

途中で、いくつかボクのほうから質問を投げさせていただきました。

  • RFP受領時にどういう点を気にするか?
  • サイトの印象はどうか?
  • どういう目的のサイトだと思うか?
  • どういう人が利用するか?
  • いつ利用されるものか?
  • 目的に戻ると、コンセプトはどういうものが考えられるか?
  • コアコンテンツはなにか? コンセプトを考えると足りているか?

やりとりの内容は、森田さんがタイピングしていただいているので、後日整理したものを村越さんのほうでまとめてもらう予定です。

当初は、ホワイトボードを使うことや付箋に書いてマッピングするなども考えていたのですが、進め方の詳細まで事前のすり合わせがしきれなかったことと、思ってたよりも時間が足りないことがわかったため、結果としてはそこまではしない判断をし、パネルディスカッション風なものにしました。

したがって、いくつか反省点はあるものの、コンテクストを決めることの大切さやその際気をつけなければならない客観性コンセプトの重要性などを、参加いただいた皆さんといっしょに共有することができたと思います。

懇親会

懇親会では、「IAシンキング」を持参いただいた大学生もいたり、得丸さんとオムニチャネルについてのお話をしたり、東京でもお会いしたことのある方々ともお話ができたので、とても有意義な時間を過ごすことができました。

また、IAセッションの登壇者どうしでは反省点をふまえて、グレードアップしたものを、和田さんが主催をされている Websig 24/7 とかで再演できればと話をしましたので、以降でまた計画したいと思います。

ボランティア活動

翌日は、南相馬でボランティア活動に参加しました。

ボランティアの概要は、花王本間さんのブログをご覧いただくとわかりますが、はじめてのボランティア参加ということで、だいぶ身構えてしまっていました。

というのも、東北セミボラの募集ページのほうにも書かれていますが、事前に十分な装備が必要な点。まずはボランティア保険への加入。厚手の軍手に、踏抜き防止のワークブーツ。粉塵防止のマスクにゴーグルなどなど。前日に東急ハンズに買出しに行きました。多分こういうことでもないと買わないだろうな、と思う防災グッズの数々。ただ一度揃えてしまえば、東京で震災が起きても安心です。

ボランティアセンター略して「ボラセン」という言葉を聞くのもはじめてでしたが、南相馬ボランティアセンターで事前にオリエン。現地へはバスで向かったのですが、途中に津波被害に遭った箇所をくぐり抜けて到着。細い路地をなんなくすり抜けるバスの運転手に拍手喝采。

一軒家を丸ごと撤収する具合で、付近の雑草や木の伐採からはじまり家屋の荷出し。昼の休憩時には、いったんボラセンに戻りカップヌードルをいただくなどのおもてなしには感動しました。休憩後、最後の荷出しを精一杯やりきって完了。皆で記念写真も撮り、一軒家のオーナーにもご挨拶し帰路。文章にすると数行ではありますが、非常に中身の濃い一日になりました。

今回はじめてボランティア活動に参加したわけですが、なかなかこういう機会でもないと団体活動には参加しない方なので貴重な経験ができました。一度参加しただけではありますが、今後こうしたボランティア活動に対して見る目が変わったと思います。参加してよかったです。そういえば、当日の服装は経験者たちは皆ツナギを着ていたのが印象的だったので、今度参加するときにはツナギを着て参加したいと思いました。

牛タンと仙台

仙台に行くのははじめてだったのですが、到着してからすぐに利久牛タンを食べ(その頃、村越上平ペアは「真助」で牛タン)、ボランティア終了後に喜助牛タンを食べたので、まさに「牛タンではじまり、牛タンで終わる」という経験をすることができました。お土産も「伊達の牛たん」にしたし。

ただ、伊達政宗像に会えず終いだったのが心残りですので、またぜひ行きたいと思います――杜の都仙台へ。ボクの中ではずっと青葉城恋唄が流れていたというのは内緒です。


IA thinking for mobile redesign #DevLOVE

先週末に実施した #DevLOVE のワークショップは、30名程度の参加者といっしょに題材のデスクトップサイトをモバイルサイトの再設計をするというものでした。やっと時間の隙間が作れたので思い出して書いてみます。

まず、前提として「IAシンキング」を定義しました。

IAシンキングとは、人間中心デザインに基づいた、情報アーキテクチャの分野におけるソリューションを提供するための手法。
現状を調査し情報を可視化したうえで目的や課題を明らかにし、新たな情報の提供方法を構築すること。

デザイン思考でもそうですが、「アイデア発想法」だけだとなんだかよくわからないのでちょっと細かくなったかも知れませんが、書いてみました。

ワークショップ

本編のワークショップの流れは以下のような流れで行いました。すでにあるデスクトップサイトの画面構成を分析して、ジャーニーマップ的なストーリーにすることで、新たなモバイルサイトの要求を整理します。最後にその要求に応えるモバイルサイトのUIを検討します。

  1. 現行サイトの情報を把握する
  2. ユーザー行動を設計する
  3. 新たな要求から設計する

題材は、ティップネスのパーソナルトレーニングの画面です。最近ティップネスに通っていることもり、検索して探してみたらモバイル対応できていなかったのでちょうどいい題材になりました。

現行サイトの情報を把握する

まず、画面構成を分析してコンテンツを整理します。そのなかで Stephen Hey 著「Responsive Design Workflow」にある「ライナーデザイン (Linear Design)」を紹介しました。レスポンシブウェブデザイン対応に関連して、モバイルファースト = コンテンツファーストの話もするわけですが、コンテンツをどう整理するかを作業としてイメージしてもらうのには非常にわかりやすい例だと思います。

具体的には、レイアウトされた画面要素を一列に並べ直して優先順位を検討するというものです。構造化という言葉を使う場合もありますが、単に並べて考えてみるというだけでいいでしょう。スクリーンサイズの小さいモバイルを考える際にはもっとも基本的なデザインになると思います。

ユーザー行動を設計する

ユーザー像を決めたうえで、シナリオを考えます。そのシナリオは、ジャーニーマップのフォーマットに埋めてもらうようにして、ワークショップ内での共通言語をつくりました。そのフォーマットは、ステージ・行動/心情/思考・ニーズ/課題・タッチポイントをマッピングし、最終的にはステージごとに要求を整理するというものです。こうしたツールを使う目的は、要求事項をひとつの軸で整理することに尽きます。

新たな要求から設計する

ジャーニーマップにまとめたうえで、要求事項に合う画面設計を進めます。その際に1で分析した既存のアセットを把握したうえで、新たな創造をしてみます。このあたりは、非デザイナーの場合とデザイナーとでとらえるレイヤーが異なりますが、非デザイナー向けには講義でもご説明したデザインパターンの適用が有効です。

まとめ

今回のワークショップでは、こうした論理的なプロセスを経験している方と経験していない方とでどうしてもクオリティに差が出てしまいます。たとえば、画面設計をした際に書かれた要素は、どういう要求に答えているのかが対になっていない場合があります。プロセスは上から順に追っているものの、進めていく中でつい思いつきで要素が増えたり「こういう情報も必要だ」という観点で要素が増え続けていく傾向もあります。

こうしたジャーニーマップを使う場合には、ほかの方法でも見つけられそうな情報を組み入れることやヌケモレを防ぐように働きかけることは原則求めないことを作成前にポリシーとして定めておくほうがいいでしょう。

#DevLOVE ワークショップ

以前、「Lean UX への違和感」を書いたボクのブログを DevLOVE の主催者である市谷さんが読んでくださったらしく、そこから今回のワークショップ実施につながっている背景があります。ギリギリまで資料を共有することもできず、バタバタでしたが、無事こうした感想ブログを書けて今はホッとしています。また呼んでいただけるよう精進して参ります。ありがとうございました。