About Face 3 読書ノートの16。
ユーザーの質的調査の結果をペルソナにまとめて、一体何を把握するかって、いろいろありますが一番大事なのはユーザーのゴールですね。なんといっても、ゴールダイレクテッドデザインっていうくらいですから。
About Face 3 いわく、ユーザーのゴールには次の3種類があるんですね。ごくごくシンプルにまとめますと、こんなかんじです。
その1。エクスペリエンスゴール。
ユーザはそれを使うときにどんな感じを求めているのか？
その2。エンドゴール。
ユーザーはそれを使って何をしたいのか？
その3。ライフゴール。
ユーザーはそれを使ってどんな人になりたいと思っているのか？
ペルソナを作って、それから、ペルソナと「それ」の関わり方をシナリオとして描いていく上では、これら3つのゴールのうち、エンドゴールに注意を払うことが多いと思います。
どんなコンテキストでどんなエンドゴールのために「それ」は使われるのか？ってことをはっきりさせるためのものがシナリオですからね。
ライフゴールも、シナリオとは無縁ではない、っていうか、ペルソナのコンテキストがそもそもライフゴールに大きく影響されているはずですよね。ひょっとしたら挫折形態かも知れないけれども。
でも、エクスペリエンスゴールは、おそらく、あんまりシナリオに絡んできません。いや、書いてもいいと思うんですけどね。
「おびただしい数の大小さまざまなコントロールが整然と居並ぶ例の編集画面が PC のモニターに映し出された。ビビアンはゆっくりと呼吸を整える。そして夜のしじまに独り佇んでいるかのような、一種独特な静謐さ --- これがいわゆる静かな闘志ってやつ？ ---- が心に広がるのを感じた。」
なんて。でも、ここからは、機能要件もデータ要件も出てこないですね。
ただし、ビジュアルデザイン、ルック（見た目） & フィール（使い心地）にはダイレクトに響いてきますよね。
About Face 3 は、ビジュアルデザインの一番最初のところでは、これから作ろうと思うインタラクションデザインから離れて、ペルソナのエクスペリエンスゴールだけを見据えて、そこに直接刺さるルック&フィールを探れ、っていってます。
それが、ビジュアル言語スタディ。言語ですよ。言語。ビジュアルにも語彙とかシンタックスがあるんだという考えですね。（この考えは、デザインニング・インターフェースなんかにも通じますよね。）
たとえば、全体の色調とか、質感とか、サイズ感とか。
あるいは、フォント、ケイ、リストや表組みやグラフの表現、ボタンやセレクトボックスなどフォームのコントロールのスタイルのあり方とか。
そういうのが、どういうタイプの「ビジュアル言語」で描かれるべきか、インタラクションデザインから離れて、スタディ（研究、あるいは、習作？）してみよう、と、こういうわけです。
たしかにね。
インタラクションデザインとビジュアルデザインを一体のものとして見て検討していると、インタラクションの細かい設計に気をとられて、いやあ、そんなのわかりづらいよー！とか言ってるうちに、いつの間にかルック&フィールがおざなりになってしまう傾向はあるかも知れないですね。
つまり、3つのゴールのうちのエクスペリエンスゴールが可哀相なことになっている状態。
ほかにも、ビジュアル言語スタディが前提にしなければならないこととしては、
・ユーザーの特性 (高齢者向けには文字を大きく、とか)
・利用状況、利用環境（長時間集中して利用するのでコントラストを抑えた配色に、とか）
・先行して定められているブランドガイドラインなど
なんてのがあります。
About Face 3 は、そういうところをけっして見逃しませんね。そういうのをいちいち告発しては、ごっちゃにしないでいったん分けて考えてみろと、ビシっと言ってくれます。
そうして、ビジュアル言語、すなわち、ビジュアルデザインのガイドラインを別に作っちゃうんですね。で、キーパスシナリオが出来たら、そのガイドラインに従って、実際の画面を構成していくと。
あと、このアプローチがいいのは、インタラクションデザインとビジュアルデザインは、プロセスとしてリニアにつながっている必要は必ずしもないってところですね。
エクスペリエンスゴールの見極めが出来ていれば、ということは、プロジェクト全体の非常に早い段階から、ビジュアルデザインのプロセスは動かせるってこと。
実はこれ、ぼく、やったことあるんですよね。たんに、くそスケジュールを乗り切るための工夫としてだったんですけどね。それがビジュアル言語スタディだなんて、ご利益のある仕業だなんてちっとも知らずに。
これからは胸を張って、ビジュアル言語スタディをやろう、と言おう。
2009年7月2日
ギャレットの5段階とインタラクションデザイン
About Face 3 読書ノートの15。
ひとつ前のノートまでで、シナリオに関する部分を一通り"読み終えた"格好です。
だいぶ、こう、自分の現場に強引にひきつけて、断りもなく勝手な解釈を混ぜ込んであるんですが、まあ、自分のためのノートなので、それはそれでいいでしょう。
おれはそう読んだ、ってことです。
自分の現場といえば、数年前から、制作プロセスの指針としていつも参照しているのが、これなんですね。
ウェブ戦略としての「ユーザーエクスペリエンス」
Webサイトの企画から実装までを5段階のフェーズに分けて進めていこうという本です。著者は、Ajax の名づけ親としても有名な、ジェシー・ジェームス・ギャレットです。
About Face 3 を読んでなんとなくイメージできたインタラクションデザインの作業プロセス感をですね、牽強付会ついでにギャレットの5段階に当てはめてみるとこんなかんじになるかな、と。
戦略段階とは、ビジネスゴールなんかも明らかにしつつ、何を何のために作るのか、戦略記述書とかビジョン記述書をまとめる段階です。
いったんまとめた戦略にしたがって、ほかに質問はあるかね？ないね？OK！ムーブ、ムーブ、ムーブ！ってケツを叩かれて作業を始めるとして、まず最初に手をつけるのがユーザーの質的調査、それをペルソナにまとめて把握するってことになりますね。
これ、要件定義のはじまりとも言えるんですけど、しかし、把握されたペルソナの姿から、たぶん、戦略自体に強力なフィードバックがかかると思うんですよね。なんで、これはむしろ戦略段階の作業と考えたほうがいいでしょう。
で、ペルソナの振る舞いをコンテキストシナリオとして描き出し、ここからユースケースを抽出して機能要件を、概念モデルを抽出してデータ要件をまとめる。ここんところがまさに要件段階です。
そうして取り出された要件を、今度は、開発計画を立てるためということもあって、小さな複数の開発ドメインに分けて把握しようとしますね。これで、これから作るべきものの姿、輪郭と構造がはっきりする。これを、構造段階と呼んでいいでしょう。
このあたりからいよいよ開発チームが本格的に参入してきて（もちろん要件定義から立ち会ってもらいますけどね）、開発ドメインごとに反復的に開発プロセスを回していくわけですが、インタラクションデザイン側としては、反復プロセスの冒頭でいわゆるキーパスシナリオとしてのワイヤーフレームや、それを補完するチェックシナリオを拵えます。これが骨格段階です。
そして、ビジュアルデザインとシステム実装が、実際にユーザーが手にするものを実現する作業ということで、表層段階。
ま、実際にはですね、案件の性質や規模によっては、いきなり骨格段階からはじめちゃうことだってあると思います。
でも、そんな場合でも、そんなことができるのは、幸運にもそれ以前の段階の成果がなんらかの形であらかじめ与えられているからであって、もし、与えられているはずのものが見当たらなければ、勇気を出してちゃんと前の段階に戻ろう、と、そういう心積もりをいつも持っていたいものです。
ひとつ前のノートまでで、シナリオに関する部分を一通り"読み終えた"格好です。
だいぶ、こう、自分の現場に強引にひきつけて、断りもなく勝手な解釈を混ぜ込んであるんですが、まあ、自分のためのノートなので、それはそれでいいでしょう。
おれはそう読んだ、ってことです。
自分の現場といえば、数年前から、制作プロセスの指針としていつも参照しているのが、これなんですね。
ウェブ戦略としての「ユーザーエクスペリエンス」
Webサイトの企画から実装までを5段階のフェーズに分けて進めていこうという本です。著者は、Ajax の名づけ親としても有名な、ジェシー・ジェームス・ギャレットです。
About Face 3 を読んでなんとなくイメージできたインタラクションデザインの作業プロセス感をですね、牽強付会ついでにギャレットの5段階に当てはめてみるとこんなかんじになるかな、と。
Interaction Design With Garrett
View more documents from Hideki Takahashi.
戦略段階とは、ビジネスゴールなんかも明らかにしつつ、何を何のために作るのか、戦略記述書とかビジョン記述書をまとめる段階です。
いったんまとめた戦略にしたがって、ほかに質問はあるかね？ないね？OK！ムーブ、ムーブ、ムーブ！ってケツを叩かれて作業を始めるとして、まず最初に手をつけるのがユーザーの質的調査、それをペルソナにまとめて把握するってことになりますね。
これ、要件定義のはじまりとも言えるんですけど、しかし、把握されたペルソナの姿から、たぶん、戦略自体に強力なフィードバックがかかると思うんですよね。なんで、これはむしろ戦略段階の作業と考えたほうがいいでしょう。
で、ペルソナの振る舞いをコンテキストシナリオとして描き出し、ここからユースケースを抽出して機能要件を、概念モデルを抽出してデータ要件をまとめる。ここんところがまさに要件段階です。
そうして取り出された要件を、今度は、開発計画を立てるためということもあって、小さな複数の開発ドメインに分けて把握しようとしますね。これで、これから作るべきものの姿、輪郭と構造がはっきりする。これを、構造段階と呼んでいいでしょう。
このあたりからいよいよ開発チームが本格的に参入してきて（もちろん要件定義から立ち会ってもらいますけどね）、開発ドメインごとに反復的に開発プロセスを回していくわけですが、インタラクションデザイン側としては、反復プロセスの冒頭でいわゆるキーパスシナリオとしてのワイヤーフレームや、それを補完するチェックシナリオを拵えます。これが骨格段階です。
そして、ビジュアルデザインとシステム実装が、実際にユーザーが手にするものを実現する作業ということで、表層段階。
ま、実際にはですね、案件の性質や規模によっては、いきなり骨格段階からはじめちゃうことだってあると思います。
でも、そんな場合でも、そんなことができるのは、幸運にもそれ以前の段階の成果がなんらかの形であらかじめ与えられているからであって、もし、与えられているはずのものが見当たらなければ、勇気を出してちゃんと前の段階に戻ろう、と、そういう心積もりをいつも持っていたいものです。
2009年6月15日
3つのチェックシナリオ
About Face 3 読書ノートの14。
ノートの11～13でコンテキストシナリオ、キーパスシナリオを紹介しました。
About Face 3 のペルソナ/シナリオ法で使うシナリオには3種類ありまして、最後がチェックシナリオってことになります。
チェックシナリオは、前の2つみたいに凝って書くことはないんですね。
こういう場合はどうするの？ こんなときはこうなるよ、みたいに端的な表現で箇条書きにしておく。
システムやアプリケーションには、けっしてメインストリームじゃないんけど、でも、絶対できなくちゃいけないことってのがあって。そういうのも忘れずにちゃんと考慮されたデザインになっているか、ワイヤーフレームを描き、インタラクションの細部を精緻化していくプロセスの中で、適宜、チェックシナリオを参照しながら確認していこうって、まあ、そういうことなんですね。
もし、コンテキストシナリオから機能要件を取り出してまとめるためにユースケース図を書いたとしたら、全部のユースケースをふたつに分けることになるでしょうね。
一方は、システムやアプリケーションの価値を形成する中心的なユースケース群。これらはワイヤーフレームを使って詳細化され、キーパスシナリオとして把握されていく。
他方は、あえてそれ以上は詳細化せずに、いわばチェックシナリオとして使っていく一群。
そう考えると、チェックシナリオっていうのは、書くのも、取り扱うのも、前の2つに比べてずいぶん気軽なような気がしてきますけれども、About Face 3 に挙げられている典型的なチェックシナリオの種類ってのをみると、それが早合点だったってことにすぐに気がつかされます。
いわく、チェックシナリオは、だいたい、次の3種類のどれかになると。
1. キーパスバリアントシナリオ
なんらかの条件の下で、あるいは付随的な要求に応じて、キーパスシナリオにつけ加えられたり、そこから分岐したりする操作に関するシナリオですね。
ブログだったら、書いてすぐ公開じゃなく、日時を指定して公開を予約するとか、かな。
ユースケース図で extend でつないで拡張ユースケースを書いたり、ユースケース記述で、代替シーケンスを明記したり、というのと同じことだと思います。
2. 必須パスシナリオ
システムやアプリケーションにユーザーが期待しているゴールの達成には直接関係ないけど、そのゴールを達成するためには必要となる動作設定とかコンフィグレーションとかですかね。
About Face 3的にいえば、「間接税的な操作」ってやつです。間接なんだけど、それは税。不本意でも必ず支払わなくてはならない。
3. エッジケースシナリオ
これこそ、まさに、"こういう場合どうすんの？"です。想定される異常事態とその対応方法のことですね。
アドレス帳で、新規作成ってことだったのに、既存のレコードと名前も電話番号もメールアドレスも一致してるのが登録された（前に入れたのを忘れちゃったのかな）場合、ほっといていいの？それとも黙って上書きしちゃう？それも乱暴だから、何かアラートでも出しとく？なんて。
で、ですね。
キーパスバリアントは、ユーザーの質的調査 → ペルソナまとめ → コンテキストシナリオ展開、ってな作業の中で見えてきているはずなんですよ。
ペルソナのいくつかあるゴールのうちでも優先順位の低いほうのものとか、脇役ペルソナのゴールとして。
でも、必須パス（間接税的な操作）ってのは、実装側からの要請という面が強いんじゃないかと思います。
インタラクションデザイン的には、できることなら省略したいくらいのものですからね。キーパスバリアントのように、インタラクションデザインのプロセスの中から自然に浮かび上がってくるということは、まずありえないでしょう。
それから、エッジケース。これ、経験上、思いつくのが得意な人と不得意な人がはっきり分れますよね。
いや、個人の資質もあるのかも知れないけど、職業的に訓練された思考パターンにも強く影響を受けそう。はっきり言うと、このへんの気づきは、プログラマーの人のほうが得意。でしょ？
というわけで、キーパスバリアントはともかく、後の2つは、プログラマーの人と一緒に考えたほうがいいと、ぼくは強く思います。
そうすると、これまでのエントリーでも触れてまいりましたとおり、インタラクションデザインと、プログラミングをウォーターフロー的につなげるのではなくてですね、やはり両方を含めて、小さく反復的に作業を進めていくべきなんじゃないかと、ここでも思います。
実装設計から、必須パスやエッジケースに関するフィードバックがかかって、インタラクションデザインも再考されていく、みたいなプロセス感。それによって、キーパスシナリオすら書き換えたほうがよくなるかも知れなくて。
ま、実際、現場ではそういうことをやっているような気もしますよ。
ただ、せっかくかかった実装側からのフィードバックに対して、その場でごにょごにょやって、解決した気になって盛り上がって、あっさり忘れちゃうのではなくて、それらをちゃんと「チェックシナリオ」として全体のプロセスや設計の中に位置づけて定着させていこうとすること、それが重要ですよね。
それはれっきとしたデザイン作業場の（中間）成果物なんであって。
それ以降に発生するインタラクションに関する仕様変更が、視野狭窄に陥って思ってもみないところで矛盾を生み出していたり、インタラクション全体のバランスを崩すことになっていたりしないか、とか、そういう危機を早期に発見するためのツールとしてもっと大事にしていく。
キーパスシナリオのところでも、その位置づけをちゃんと考えるっていうことで、なんか同じようなことを書きましたが、About Face 3 を読んで感銘を覚えることのひとつは、このへんですね。これまでなんとなく、ぼーっとやってきてしまっていた実践に、はっきりとした輪郭が与えられていくかんじ。
そんなわけで「チェックシナリオ」っていう言葉と考え方、これから積極的に使っていこうかなと、そう思った次第です。
ノートの11～13でコンテキストシナリオ、キーパスシナリオを紹介しました。
About Face 3 のペルソナ/シナリオ法で使うシナリオには3種類ありまして、最後がチェックシナリオってことになります。
チェックシナリオは、前の2つみたいに凝って書くことはないんですね。
こういう場合はどうするの？ こんなときはこうなるよ、みたいに端的な表現で箇条書きにしておく。
システムやアプリケーションには、けっしてメインストリームじゃないんけど、でも、絶対できなくちゃいけないことってのがあって。そういうのも忘れずにちゃんと考慮されたデザインになっているか、ワイヤーフレームを描き、インタラクションの細部を精緻化していくプロセスの中で、適宜、チェックシナリオを参照しながら確認していこうって、まあ、そういうことなんですね。
もし、コンテキストシナリオから機能要件を取り出してまとめるためにユースケース図を書いたとしたら、全部のユースケースをふたつに分けることになるでしょうね。
一方は、システムやアプリケーションの価値を形成する中心的なユースケース群。これらはワイヤーフレームを使って詳細化され、キーパスシナリオとして把握されていく。
他方は、あえてそれ以上は詳細化せずに、いわばチェックシナリオとして使っていく一群。
そう考えると、チェックシナリオっていうのは、書くのも、取り扱うのも、前の2つに比べてずいぶん気軽なような気がしてきますけれども、About Face 3 に挙げられている典型的なチェックシナリオの種類ってのをみると、それが早合点だったってことにすぐに気がつかされます。
いわく、チェックシナリオは、だいたい、次の3種類のどれかになると。
1. キーパスバリアントシナリオ
なんらかの条件の下で、あるいは付随的な要求に応じて、キーパスシナリオにつけ加えられたり、そこから分岐したりする操作に関するシナリオですね。
ブログだったら、書いてすぐ公開じゃなく、日時を指定して公開を予約するとか、かな。
ユースケース図で extend でつないで拡張ユースケースを書いたり、ユースケース記述で、代替シーケンスを明記したり、というのと同じことだと思います。
2. 必須パスシナリオ
システムやアプリケーションにユーザーが期待しているゴールの達成には直接関係ないけど、そのゴールを達成するためには必要となる動作設定とかコンフィグレーションとかですかね。
About Face 3的にいえば、「間接税的な操作」ってやつです。間接なんだけど、それは税。不本意でも必ず支払わなくてはならない。
3. エッジケースシナリオ
これこそ、まさに、"こういう場合どうすんの？"です。想定される異常事態とその対応方法のことですね。
アドレス帳で、新規作成ってことだったのに、既存のレコードと名前も電話番号もメールアドレスも一致してるのが登録された（前に入れたのを忘れちゃったのかな）場合、ほっといていいの？それとも黙って上書きしちゃう？それも乱暴だから、何かアラートでも出しとく？なんて。
で、ですね。
キーパスバリアントは、ユーザーの質的調査 → ペルソナまとめ → コンテキストシナリオ展開、ってな作業の中で見えてきているはずなんですよ。
ペルソナのいくつかあるゴールのうちでも優先順位の低いほうのものとか、脇役ペルソナのゴールとして。
でも、必須パス（間接税的な操作）ってのは、実装側からの要請という面が強いんじゃないかと思います。
インタラクションデザイン的には、できることなら省略したいくらいのものですからね。キーパスバリアントのように、インタラクションデザインのプロセスの中から自然に浮かび上がってくるということは、まずありえないでしょう。
それから、エッジケース。これ、経験上、思いつくのが得意な人と不得意な人がはっきり分れますよね。
いや、個人の資質もあるのかも知れないけど、職業的に訓練された思考パターンにも強く影響を受けそう。はっきり言うと、このへんの気づきは、プログラマーの人のほうが得意。でしょ？
というわけで、キーパスバリアントはともかく、後の2つは、プログラマーの人と一緒に考えたほうがいいと、ぼくは強く思います。
そうすると、これまでのエントリーでも触れてまいりましたとおり、インタラクションデザインと、プログラミングをウォーターフロー的につなげるのではなくてですね、やはり両方を含めて、小さく反復的に作業を進めていくべきなんじゃないかと、ここでも思います。
実装設計から、必須パスやエッジケースに関するフィードバックがかかって、インタラクションデザインも再考されていく、みたいなプロセス感。それによって、キーパスシナリオすら書き換えたほうがよくなるかも知れなくて。
ま、実際、現場ではそういうことをやっているような気もしますよ。
ただ、せっかくかかった実装側からのフィードバックに対して、その場でごにょごにょやって、解決した気になって盛り上がって、あっさり忘れちゃうのではなくて、それらをちゃんと「チェックシナリオ」として全体のプロセスや設計の中に位置づけて定着させていこうとすること、それが重要ですよね。
それはれっきとしたデザイン作業場の（中間）成果物なんであって。
それ以降に発生するインタラクションに関する仕様変更が、視野狭窄に陥って思ってもみないところで矛盾を生み出していたり、インタラクション全体のバランスを崩すことになっていたりしないか、とか、そういう危機を早期に発見するためのツールとしてもっと大事にしていく。
キーパスシナリオのところでも、その位置づけをちゃんと考えるっていうことで、なんか同じようなことを書きましたが、About Face 3 を読んで感銘を覚えることのひとつは、このへんですね。これまでなんとなく、ぼーっとやってきてしまっていた実践に、はっきりとした輪郭が与えられていくかんじ。
そんなわけで「チェックシナリオ」っていう言葉と考え方、これから積極的に使っていこうかなと、そう思った次第です。
2009年6月1日
キーパスシナリオの正体
About Face 3 読書ノートの13。
前のエントリーで見たとおり、コンテキストシナリオができたら、次にシナリオからデータ要件と機能要件を抽出します。
About Face 3 がそういっているわけではないけど、それはつまり、概念モデルとユースケースを書くってこと。まあ、そういうことにしておこう。
そしたら、アジャイルな開発プロセスをはじめられる。これも、About Face 3 がそういっているわけではないけどね。
毎回のイテレーションの冒頭では、今回のターゲットとなる開発範囲に含まれるユースケースについて詳細化を行うことになるでしょう。
ユースケースの詳細化っていうと、細かくユースケース記述を書くってのもあるけど、たいがいは、ワイヤーフレームを作成してみることになりますね。少なくともぼくがいる現場ではそうすることが多いです。
ここのところを、About Face 3 的に言い換えれば、つまり、フォームファクタ、ポスチュア、入力メソッドなんかをどんどん決めて、実際のインタラクションを描いていく、すなわち、キーパスシナリオを書く、ということになるみたいです。
About Face 3では、キーパスシナリオのことを次のように説明しています。
なるほど。でも、そうすると、コンテキストシナリオとユースケースは明らかに違うもんだっていうのはわかったんだけど、キーパスシナリオっていうのはなんだか、それこそユースケース記述みたいだな、なんて思っちゃったり。
でも、よく考えてみると、やっぱり違うもんだと捉えたほうがよさそうです。
ある目的にそった「行為」とは、目的を達成するために組み立てられたな複数の「作業」からなっていて、各「作業」はまた、一連の「操作」によって構成されている、としますね。
たとえば、
こんなかんじ。
これでいうと、作業レベルの記述がユースケース。で、操作レベルの記述がキーパスシナリオってことになるんですよね。キーパスシナリオの内容は、インターフェースの実装に依存した書き方になる。
ユースケースとは機能要件の網羅であって、そのひとつひとつを実現できたかどうかが、開発の進捗を測る上での中心的な指標になるんですよね。
だから、プロジェクトの最後まで、常に最新の設計が反映された状態を維持しておきたいんです。
ユースケース記述で操作の詳細にまで書く踏み込んで書くと、その後のデザイン/実装での変更を逐一反映させていかなければならないハメになっちゃう。でも、そんなこと実際にはやってられないわけで。
だから、ユースケースは作業レベルの記述に止めておくのが吉。
でも、これだけじゃ、具体的にどんなインタラクションを作っていいのかわからない。
ユースケースに機能要件の網羅という役割を期待するんなら、インタラクショデザインの道しるべとしての役割のほうは期待できない。
ってわけで、そっちは、キーパスシナリオに任せる。
キーパスシナリオはインタラクションデザインの試行錯誤の中で何度も書き直されるし、作業プロセスの過程で十分にデザインと実装が進めば、途中で捨てちゃっても構わない。いってみればいつも書き捨てるつもりで軽く書く。
このへんの話、思い切ってまとめると、こんなかんじでしょうか。
→ コンテキストシナリオは、ユーザーのニーズとゴールを見失わないために常に参照されるドキュメント。
→ ユースケースは、システムの全体像と整合性を見失わないために常に参照されるドキュメント。
→ キーパスシナリオは、具体的なシステムの姿を描き出すためのツール。
じゃあ、そのキーパスシナリオ、具体的にはどう書くの？って話になるんですが、About Face 3 によれば、コンテキストシナリオは（データと機能の要件を抜き出すためのヒントが書き込まれやすい）テキストで書くべし、とはっきり書かれていて、前に紹介したようにサンプルまでついて、手取り足取りってかんじなんですが、キーパスシナリオの書き方についてはそこまで詳しく書いてなくて。
ただ、映画におけるストーリーボードテクニックが参考になる、なんてことは書いてあります。
ストーリーボードって、インタラクションデザインの場合でいえば、つまりインタラクションを説明する一連のワイヤーフレームってことになりますね。
引き出し線をひっぱって操作を説明するテキストを添えて、それを順番に読んでもらえれば、それこそ、キーパスシナリオそのものってわけで。
というわけで、思わせぶりなタイトルをつけちゃいましたが、まあ、言いたいことは、キーパスシナリオ = とりあえずワイヤーフレームでOK？ってことです。
ただ、肝心なのは、形式はどうあれ、当の作業を次のようなプロセスの中にちゃんと位置づけて、これは "キーパスシナリオ" なんだと意識して行うってことですよね。
ユーザーの質的調査
↓
ペルソナ + コンテキストシナリオ
↓
ユースケース + 概念モデル
↓
キーパスシナリオ / ワイヤーフレーム
↓
(チェックシナリオ等、その他のシナリオ)
↓
インタラクションデザイン + システム実装
こういうプロセス観の下で作業しないと、何の当てもないのにいきなりワイヤーフレームから書き始めるとか、まるでエスパーの仕事になってしまう。
あるいは、本来の役割を弁えていないもんだから、妙に表層的なビジュアルデザインに踏み込んじゃったり、コンテキストに関する説明のために膨大なコメントを書き込んじゃったりして、それ自体を分析することが一仕事になっちゃったりして。
そう、だから、何を隠そう「ワイヤーフレームの正体」こそ、実はキーパスシナリオだったのです。
あ、タイトル逆だったかな。
前のエントリーで見たとおり、コンテキストシナリオができたら、次にシナリオからデータ要件と機能要件を抽出します。
About Face 3 がそういっているわけではないけど、それはつまり、概念モデルとユースケースを書くってこと。まあ、そういうことにしておこう。
そしたら、アジャイルな開発プロセスをはじめられる。これも、About Face 3 がそういっているわけではないけどね。
毎回のイテレーションの冒頭では、今回のターゲットとなる開発範囲に含まれるユースケースについて詳細化を行うことになるでしょう。
ユースケースの詳細化っていうと、細かくユースケース記述を書くってのもあるけど、たいがいは、ワイヤーフレームを作成してみることになりますね。少なくともぼくがいる現場ではそうすることが多いです。
ここのところを、About Face 3 的に言い換えれば、つまり、フォームファクタ、ポスチュア、入力メソッドなんかをどんどん決めて、実際のインタラクションを描いていく、すなわち、キーパスシナリオを書く、ということになるみたいです。
About Face 3では、キーパスシナリオのことを次のように説明しています。
キーパスシナリオは、インタラクションフレームワークの語彙を使って、ペルソナが製品とどのようにインタラクションするかを記述する。このシナリオは、ペルソナがもっともひんぱんに通過する（毎日という場合も多い）インターフェースの主要経路を説明する。
（中略）
コンテキストシナリオはゴールオリエントだが、これと比べ、キーパスシナリオは作業寄りであり、コンテキストシナリオでは広くヒント程度に描かれていた作業のディテールに重点を置く。
（中略）
キーパスシナリオは、主要なインタラクションの正確な振る舞いを詳しく記述し、ス要な操作経路を最初から最後までたどってみなければならない。
なるほど。でも、そうすると、コンテキストシナリオとユースケースは明らかに違うもんだっていうのはわかったんだけど、キーパスシナリオっていうのはなんだか、それこそユースケース記述みたいだな、なんて思っちゃったり。
でも、よく考えてみると、やっぱり違うもんだと捉えたほうがよさそうです。
ある目的にそった「行為」とは、目的を達成するために組み立てられたな複数の「作業」からなっていて、各「作業」はまた、一連の「操作」によって構成されている、としますね。
たとえば、
| 行為 | 作業 | 操作 |
|---|---|---|
| 自動販売機で缶ジュースを買う | ||
| 自動販売機にお金を入れる | 硬貨投入口に10、50、100、500円を一枚ずつ差し込む | |
| 缶ジュースを選ぶ | ディスプレイされた缶ジュースの中から、飲みたいものを選び、当該の缶ジュースに対応するボタンを押す | |
| 缶ジュースを受け取る | ジュースの取り出し口に放出された缶ジュースを取り出す | |
| おつりを受け取る | おつり返却レバーを回転させ、おつり返却口に放出された硬貨を取り出す |
こんなかんじ。
これでいうと、作業レベルの記述がユースケース。で、操作レベルの記述がキーパスシナリオってことになるんですよね。キーパスシナリオの内容は、インターフェースの実装に依存した書き方になる。
ユースケースとは機能要件の網羅であって、そのひとつひとつを実現できたかどうかが、開発の進捗を測る上での中心的な指標になるんですよね。
だから、プロジェクトの最後まで、常に最新の設計が反映された状態を維持しておきたいんです。
ユースケース記述で操作の詳細にまで書く踏み込んで書くと、その後のデザイン/実装での変更を逐一反映させていかなければならないハメになっちゃう。でも、そんなこと実際にはやってられないわけで。
だから、ユースケースは作業レベルの記述に止めておくのが吉。
でも、これだけじゃ、具体的にどんなインタラクションを作っていいのかわからない。
ユースケースに機能要件の網羅という役割を期待するんなら、インタラクショデザインの道しるべとしての役割のほうは期待できない。
ってわけで、そっちは、キーパスシナリオに任せる。
キーパスシナリオはインタラクションデザインの試行錯誤の中で何度も書き直されるし、作業プロセスの過程で十分にデザインと実装が進めば、途中で捨てちゃっても構わない。いってみればいつも書き捨てるつもりで軽く書く。
このへんの話、思い切ってまとめると、こんなかんじでしょうか。
→ コンテキストシナリオは、ユーザーのニーズとゴールを見失わないために常に参照されるドキュメント。
→ ユースケースは、システムの全体像と整合性を見失わないために常に参照されるドキュメント。
→ キーパスシナリオは、具体的なシステムの姿を描き出すためのツール。
じゃあ、そのキーパスシナリオ、具体的にはどう書くの？って話になるんですが、About Face 3 によれば、コンテキストシナリオは（データと機能の要件を抜き出すためのヒントが書き込まれやすい）テキストで書くべし、とはっきり書かれていて、前に紹介したようにサンプルまでついて、手取り足取りってかんじなんですが、キーパスシナリオの書き方についてはそこまで詳しく書いてなくて。
ただ、映画におけるストーリーボードテクニックが参考になる、なんてことは書いてあります。
ストーリーボードって、インタラクションデザインの場合でいえば、つまりインタラクションを説明する一連のワイヤーフレームってことになりますね。
引き出し線をひっぱって操作を説明するテキストを添えて、それを順番に読んでもらえれば、それこそ、キーパスシナリオそのものってわけで。
というわけで、思わせぶりなタイトルをつけちゃいましたが、まあ、言いたいことは、キーパスシナリオ = とりあえずワイヤーフレームでOK？ってことです。
ただ、肝心なのは、形式はどうあれ、当の作業を次のようなプロセスの中にちゃんと位置づけて、これは "キーパスシナリオ" なんだと意識して行うってことですよね。
ユーザーの質的調査
↓
ペルソナ + コンテキストシナリオ
↓
ユースケース + 概念モデル
↓
キーパスシナリオ / ワイヤーフレーム
↓
(チェックシナリオ等、その他のシナリオ)
↓
インタラクションデザイン + システム実装
こういうプロセス観の下で作業しないと、何の当てもないのにいきなりワイヤーフレームから書き始めるとか、まるでエスパーの仕事になってしまう。
あるいは、本来の役割を弁えていないもんだから、妙に表層的なビジュアルデザインに踏み込んじゃったり、コンテキストに関する説明のために膨大なコメントを書き込んじゃったりして、それ自体を分析することが一仕事になっちゃったりして。
そう、だから、何を隠そう「ワイヤーフレームの正体」こそ、実はキーパスシナリオだったのです。
あ、タイトル逆だったかな。
2009年5月28日
コンテキストシナリオを書いたら
About Face 3 読書ノートの12。
コンテキストシナリオがどうやら書けたら次にどうするか。
これからデザインするモノが何であるか明確にするために、シナリオの中の目的語（オブジェクト）、行為、コンテキストに注目して、まずはデータ要件と機能要件を抽出するんですね。
こんな例が書かれています。
オブジェクトがデータ要件の、行為が機能要件の、それぞれ雛形になるんですね。コンテキストはデータや機能のグルーピングの単位やある種の制約条件になるでしょうね。
これって、システム設計の話で、ユースケースを書いて、ユースケースから概念モデル(クラス)図を書くのとまったく同じ手口ですね。
ま、いってみればユースケースとは機能要件の定義、概念モデルとはデータ要件の定義なわけで、だからコンテキストシナリオを書いたら、シナリオに基づいてユースケースと概念モデルを書く、って言っちゃってもいいんじゃないでしょうか。
ユースケースの入門書なんかでは、はじめっからいきなりユースケースを書くみたいなかんじなんですけど（いや、実際の仕事でも、ヒアリングもそこそこにほとんど思いつきだけでユースケースを書いてきたような！）、言われてみれば、いきなり書き始められるわけがないんですよね。神の啓示を受けて何かにとり憑かれたようにいっきに書き上げる、自動書記じゃないんだから、そんなのないわけです。
そう。ユーザーの質的な調査に基づいてゴールとニーズの典型をつかむためにペルソナを作り、シナリオを書く。しかるのちに、そのゴールとニーズに応えるツールやシステムの輪郭を明確にするためにユースケースと概念モデルを書く。そうこなくっちゃいけない。
ちなみにユースケースについては、About Face 3 の中で次のように言及されています。ちょっといいことが書いてあるんで長くなりますが引用します。
まさに、ですね。しかし、この文章、ユースケースはシナリオの代わりにはならないよ、シナリオのほうがいいよって文脈で出てくるんですけど、コンテキストシナリオから機能要件を抽出したら、それを書き留める方法としてユースケース図が使えるってニュアンスで捉えたいところですね。
で、機能要件をユースケース図にまとめて、データ要件を概念モデル図にでもまとめたら、それらをうまくハンドリングするためのインターフェースの設計に入っていくわけです。
でも、ここで、「ちょっと待った」ってかんじがするんです。
当然ながら、プロジェクトはインタラクションデザインだけで出来上がっているわけではなくて。ここまできたら、システムを構成するドメイン(=相互に関連の深い概念モデルやユースケースの集まり)を見極め、反復的な開発プロセスを回し始めたっていいでしょう。はじめからそれなりに動作するシステムをすこしずつ拡張していって完成形に近づけていくってやり方で。
実は、About Face 3って、デザインのプロセスの内部は反復的なんだけど、開発との関係においては、結構、ウォーターフローモデルを前提にしてるところがあるんですよね。後でいろいろ考え直したりはしてるみたいなんですけど。
あとがきにこんなことが書いてあります。
これは、でも、たんに複数チームを並列的にワークさせて合理的に時間を使うってな話で、アジャイル開発の発想ではないですね。
やっぱり、インタラクションデザインも含めて開発イテレーションを回して、実際に動くモノを目の当たりにしながら、それこそ、イテレーションごとにユーザーのフィードバックなんかも得ながら少しずつ拡張するようにして作り上げていくほうが、インタラクションデザインにとってもいいような気がするんですけどね。どうなんでしょう。
コンテキストシナリオがどうやら書けたら次にどうするか。
これからデザインするモノが何であるか明確にするために、シナリオの中の目的語（オブジェクト）、行為、コンテキストに注目して、まずはデータ要件と機能要件を抽出するんですね。
こんな例が書かれています。
アポ（コンテキスト）から人間（オブジェクト）に電話をかける（行為）。
オブジェクトがデータ要件の、行為が機能要件の、それぞれ雛形になるんですね。コンテキストはデータや機能のグルーピングの単位やある種の制約条件になるでしょうね。
これって、システム設計の話で、ユースケースを書いて、ユースケースから概念モデル(クラス)図を書くのとまったく同じ手口ですね。
ま、いってみればユースケースとは機能要件の定義、概念モデルとはデータ要件の定義なわけで、だからコンテキストシナリオを書いたら、シナリオに基づいてユースケースと概念モデルを書く、って言っちゃってもいいんじゃないでしょうか。
ユースケースの入門書なんかでは、はじめっからいきなりユースケースを書くみたいなかんじなんですけど（いや、実際の仕事でも、ヒアリングもそこそこにほとんど思いつきだけでユースケースを書いてきたような！）、言われてみれば、いきなり書き始められるわけがないんですよね。神の啓示を受けて何かにとり憑かれたようにいっきに書き上げる、自動書記じゃないんだから、そんなのないわけです。
そう。ユーザーの質的な調査に基づいてゴールとニーズの典型をつかむためにペルソナを作り、シナリオを書く。しかるのちに、そのゴールとニーズに応えるツールやシステムの輪郭を明確にするためにユースケースと概念モデルを書く。そうこなくっちゃいけない。
ちなみにユースケースについては、About Face 3 の中で次のように言及されています。ちょっといいことが書いてあるんで長くなりますが引用します。
シナリオとユースケースは、ともにユーザーとシステムのインタラクションを記述するための方法である。しかし、この2つが果たす機能は大きく異なっている。ゴールダイレクテッドシナリオは、特定のユーザー（ペルソナ）の視点から製品の振る舞いを反復的に定義する手段として使われる。振る舞いには、システムの機能だけではなく、機能の優先順位や、ユーザーからは何が見えるのか、システムとどのようなインタラクションをするのかという意味での機能の表現形態も含まれる。
それに対し、ユースケースは、低水準でのユーザーの操作とそれに対するシステムの応答に重点を置いた、入出力のレベルでのシステムの機能要件を網羅的に記述するテクニックである。
まさに、ですね。しかし、この文章、ユースケースはシナリオの代わりにはならないよ、シナリオのほうがいいよって文脈で出てくるんですけど、コンテキストシナリオから機能要件を抽出したら、それを書き留める方法としてユースケース図が使えるってニュアンスで捉えたいところですね。
で、機能要件をユースケース図にまとめて、データ要件を概念モデル図にでもまとめたら、それらをうまくハンドリングするためのインターフェースの設計に入っていくわけです。
でも、ここで、「ちょっと待った」ってかんじがするんです。
当然ながら、プロジェクトはインタラクションデザインだけで出来上がっているわけではなくて。ここまできたら、システムを構成するドメイン(=相互に関連の深い概念モデルやユースケースの集まり)を見極め、反復的な開発プロセスを回し始めたっていいでしょう。はじめからそれなりに動作するシステムをすこしずつ拡張していって完成形に近づけていくってやり方で。
実は、About Face 3って、デザインのプロセスの内部は反復的なんだけど、開発との関係においては、結構、ウォーターフローモデルを前提にしてるところがあるんですよね。後でいろいろ考え直したりはしてるみたいなんですけど。
あとがきにこんなことが書いてあります。
かつての私たちは、コーディングが始まる前にデザインの作業をすべて終わらせるべきだと考えていた。しかし、開発日程の厳しさや、提案したデザインの現実可能性を証明する必要性（こちらの方が大切）などを考えると、これは現実的ではないということを学んだ。
（中略）
しかし、製品のある側面について構築を始めても、他の側面についてはまだデザインしているという形にすれば、実質的な形で仕事の順序を守ることは可能だということだ。
これは、でも、たんに複数チームを並列的にワークさせて合理的に時間を使うってな話で、アジャイル開発の発想ではないですね。
やっぱり、インタラクションデザインも含めて開発イテレーションを回して、実際に動くモノを目の当たりにしながら、それこそ、イテレーションごとにユーザーのフィードバックなんかも得ながら少しずつ拡張するようにして作り上げていくほうが、インタラクションデザインにとってもいいような気がするんですけどね。どうなんでしょう。
2009年5月8日
ビビアンのコンテキストシナリオ
About Face 3 読書ノートの11。
さて、About Face 3 によれば、コンテキストシナリオこそ、「デザインの開始位置」なのです。
以下引用。
コンテキストシナリオの範囲は、広くて比較的浅いものにする。製品やインタラクションのディティールを書き込んではならない。それよりも、ユーザーの視点から見て、高い水準の動きに重点を置く。最初に大きな図を描き、ユーザーの用件を系統的に突き止めていけるようにすることが大切だ。適切なインタラクションやインターフェイスをデザインできるのは、それらがはっきりしてからである。
引用終わり。
いやあ、びしびし語りかけてきますね。
つまり、まずコンテキストとゴールを明らかにして、そのゴールを実現するために、これからデザインしようとするシステム/デバイスがいったいどんなふうに使われるのか、そこらあたりを大ざっぱに書いてみるってかんじでしょうか。
137ページに例が載ってます。120～240字でまとめられた8つのパラグラフからなる、全部で約1200字ほどの文章。題して「ビビアンのコンテキストシナリオ」。
これを見れば、具体的にどんなスタイルで、どれくらいの粒度で書けばいいのか、だいたいつかめます。
それから、文章を構成している要素を分解してみると、
・コンテキスト
・ゴール
・ゴールを実現する上での課題
・課題を解決するために果たすシステム/デバイスの役割
だいたい以上の4つのポイントを押さえるようにして書かれているみたいです。
ちょっと紹介してみたいと思います。
シナリオに入る前に、まずペルソナの定義から。シナリオの主人公の名前はビビアンです。
不動産屋に勤めているビビアンには、夫がいて、学校に通う娘がいる。
ビビアンのライフゴールは、妻として母として家庭生活をけっして疎かにすることなく、その一方で、ばりばりと契約をまとめる敏腕エージェントとして活躍すること。
不動産屋の勝負は、数多くのクライアントを、いかに効率よく、それぞれの希望に添う物件に案内できるか。しかも、”え、ひょっとして専任でついてくれてるの？”と思わせるほどのクイックかつ的確なレスポンスで。
そんなビビアンを少しでも楽にしてあげられるシステム/デバイスとは？ってことでコンテキストシナリオが書かれます。
まず、システム/デバイスにまったく触れずにシナリオの要点をまとめてみるとこんなかんじになります。
（１）朝、娘を学校に送り出すまでの世話を焼きながら、クライアントの突然の求めに応じてその日の午後にアポを入れる。
（２）オフィスにはその日の外回りに必要な書類をとるためだけに顔を出す。（面倒な活動報告などもなし。）
（３）これから案内する物件に向かう途中、クライアントに関連する情報に目を通しておく。一方で目的地までの正確な経路もちゃんと確認。正確な到着時間を知らせるためにクライアントに電話を入れる。
（４）クライアントに物件を案内している最中、娘から緊急連絡が入る。（接客中に緊急連絡を入れられるのは家族だけ。）どうやらバスに乗り損ねて帰るに帰れないらしい。自分は今手が離せないないので、夫に連絡した。夫が迎えに行けることがわかってほっと一安心。
こうやってかいつまんでみると、以上はそのまま、システム/デバイスが使用されるシーン、コンテクストの描写になってますよね。なおかつ、これ、全部そうだといいな、ってことなんで、システム/デバイスがビビアンにもたらすエンドゴールのイメージにもなっていると思います。
エンドゴールのイメージってことは、（１）～（４）ともに、実は、そうであるために解決したい課題があるわけです。で、それを、これからデザインするシステム/デバイスがどうさばいてくれたらいいのか、そのあたりのことをさらに書き加えてみると、例示されているとおりの文章になっていくでしょう。
ちなみに彼女を彼女のゴールに導くお手伝いをしてくれるシステム/デバイスとは、「PDAタイプの電話」、いわゆるスマートフォンです。
たとえば、上記の（３）にあたる部分は、例では 第５,第６パラグラフとして次のように書かれています。
以下引用です。
５．時間が過ぎるのは早く、彼女は少し遅れている。フランクに見せる物件のもとに向かっていると、電話が約束の時間まであと15分だということを警告してくる。彼女が電話を開けると、アポだけではなく、電子メール、メモ、電話メッセージ、フランクの番号への発信記録など、フランク関連のあらゆるドキュメントのリストが表示される。ビビアンが発信ボタンを押すと、電話はフランクとのアポが間もなくであることを知っているので、自動的にフランクに電話をかける。彼女は、20分で着くと連絡する。
６．ビビアンは物件の住所こそ知っているが、正確にどこなのかについては少し自信がないので、アポに記入したアドレスを引っ張り出して軽くたたく。すると、電話は現在位置と目的地の関係を示す小さな地図と彼女に対する指示をダウンロードしてくる。
引用終わり。
これで、ゴールに立ちはだかる課題と、課題を解決するためにシステム/デバイスがどう役立ってくれるかのイメージがはっきりしてきますよね。
ところで、課題をどう解決するかっていうのは、システム/デバイスをどう実装して実現するかというのとは違います。あくまでも、こんなこといいな、できたらいいな、の、のび太レベル。About Face 3 ではこれを「魔法のふりをする」あるいは「魔法のインターフェースがあるふりをする」といっています。
たとえば、このコンテキストシナリオで描かれる魔法の「PDAタイプの電話」はこんなかんじです。
(いや、実際、こんなのありそうですけれども。)
・手軽にメールチェックができて、メールからシームレスに電話もかけられる
・相手と電話(スピーカーフォン)で話ながら、スケジュールを確認できて新しいアポを登録できる
・登録されたアポはオフィスで共有できる
・アポの時間が近づくとリマインダー通知が行われ、PDA内部では当該のアポ関連の情報が"活性化"する
・現在位置を目的地をプロットした地図が表示できる
・留守電モードであっても、"秘密のコード"を知っている人からは通話モードで連絡が入る
・インタントメッセージの送受信ができる
しかし、こういう一連の機能をどう実装するのかなんてこの時点ではまったく心配していないし、具体的にどんなインタラクションで操作するのかについても非常に無責任にすらすらっと書いちゃう。「アポに記入したアドレスを引っ張り出して軽くたたく」なんて。
コンテキストシナリオの眼目は、どう作るか、ではなく、何を作るのか、をはっきりさせること。"実現方法"は、コンテキストシナリオを固めた後に、コンテキストシナリオに基づいて考えていけばいいことじゃん、と。だから、ここが「デザインの開始位置」になるわけです。
そう考えてみると、この本に書かれているわけではないですが、上でやってみたように、コンテキストシナリオで明らかにしたい4つのポイントを意識しつつ、まずは、システム/デバイスにまったく触れずに、コンテキストとゴールを明らかにするためだけにシナリオを書いてみるのがいいんじゃないかと思うんですよね。ここまではユーザー調査の結果をペルソナにまとめる作業の成果から、わりと論理的に導けるはずです。仮にペルソナが想像上の「暫定ペルソナ」だったとしてもね。
で、その後に、ゴールの前に横たわるいくつかの課題と、それを解決していくシステム/デバイスのイメージを書き込んでいってみると。ここは、ちょっとクリエイティブに、思いっきり「魔法のふり」をしてみながら。
その「魔法」は、デザイン/設計の工程が進むにつれてボコボコにされる運命をきっと辿りますが、それでも最後まで参照される成果物として生き延びていきます。
そこに描かれた「魔法」たちが要請されたニーズを、別のかたち(実現方法)ではあれ、きちんと満たしているかどうか？ それが、その後作られることになるワイヤーフレームや画面モックの評価の基準になるわけですから。
ワイヤーフレームや画面モックを目の当たりにして、あれ、はたしてこれでよかったんだっけ？なんて不安になったら、それらが魔法の代わりとしてコンテキストシナリオにずっぽりハマるかどうか検証してみるとよろしい。
そう、これがないからさ、前のエントリーに書いたような話になるんじゃないかなーなんて、思うんですよね。どうでしょうね。
さて、About Face 3 によれば、コンテキストシナリオこそ、「デザインの開始位置」なのです。
以下引用。
コンテキストシナリオの範囲は、広くて比較的浅いものにする。製品やインタラクションのディティールを書き込んではならない。それよりも、ユーザーの視点から見て、高い水準の動きに重点を置く。最初に大きな図を描き、ユーザーの用件を系統的に突き止めていけるようにすることが大切だ。適切なインタラクションやインターフェイスをデザインできるのは、それらがはっきりしてからである。
引用終わり。
いやあ、びしびし語りかけてきますね。
つまり、まずコンテキストとゴールを明らかにして、そのゴールを実現するために、これからデザインしようとするシステム/デバイスがいったいどんなふうに使われるのか、そこらあたりを大ざっぱに書いてみるってかんじでしょうか。
137ページに例が載ってます。120～240字でまとめられた8つのパラグラフからなる、全部で約1200字ほどの文章。題して「ビビアンのコンテキストシナリオ」。
これを見れば、具体的にどんなスタイルで、どれくらいの粒度で書けばいいのか、だいたいつかめます。
それから、文章を構成している要素を分解してみると、
・コンテキスト
・ゴール
・ゴールを実現する上での課題
・課題を解決するために果たすシステム/デバイスの役割
だいたい以上の4つのポイントを押さえるようにして書かれているみたいです。
ちょっと紹介してみたいと思います。
シナリオに入る前に、まずペルソナの定義から。シナリオの主人公の名前はビビアンです。
不動産屋に勤めているビビアンには、夫がいて、学校に通う娘がいる。
ビビアンのライフゴールは、妻として母として家庭生活をけっして疎かにすることなく、その一方で、ばりばりと契約をまとめる敏腕エージェントとして活躍すること。
不動産屋の勝負は、数多くのクライアントを、いかに効率よく、それぞれの希望に添う物件に案内できるか。しかも、”え、ひょっとして専任でついてくれてるの？”と思わせるほどのクイックかつ的確なレスポンスで。
そんなビビアンを少しでも楽にしてあげられるシステム/デバイスとは？ってことでコンテキストシナリオが書かれます。
まず、システム/デバイスにまったく触れずにシナリオの要点をまとめてみるとこんなかんじになります。
（１）朝、娘を学校に送り出すまでの世話を焼きながら、クライアントの突然の求めに応じてその日の午後にアポを入れる。
（２）オフィスにはその日の外回りに必要な書類をとるためだけに顔を出す。（面倒な活動報告などもなし。）
（３）これから案内する物件に向かう途中、クライアントに関連する情報に目を通しておく。一方で目的地までの正確な経路もちゃんと確認。正確な到着時間を知らせるためにクライアントに電話を入れる。
（４）クライアントに物件を案内している最中、娘から緊急連絡が入る。（接客中に緊急連絡を入れられるのは家族だけ。）どうやらバスに乗り損ねて帰るに帰れないらしい。自分は今手が離せないないので、夫に連絡した。夫が迎えに行けることがわかってほっと一安心。
こうやってかいつまんでみると、以上はそのまま、システム/デバイスが使用されるシーン、コンテクストの描写になってますよね。なおかつ、これ、全部そうだといいな、ってことなんで、システム/デバイスがビビアンにもたらすエンドゴールのイメージにもなっていると思います。
エンドゴールのイメージってことは、（１）～（４）ともに、実は、そうであるために解決したい課題があるわけです。で、それを、これからデザインするシステム/デバイスがどうさばいてくれたらいいのか、そのあたりのことをさらに書き加えてみると、例示されているとおりの文章になっていくでしょう。
ちなみに彼女を彼女のゴールに導くお手伝いをしてくれるシステム/デバイスとは、「PDAタイプの電話」、いわゆるスマートフォンです。
たとえば、上記の（３）にあたる部分は、例では 第５,第６パラグラフとして次のように書かれています。
以下引用です。
５．時間が過ぎるのは早く、彼女は少し遅れている。フランクに見せる物件のもとに向かっていると、電話が約束の時間まであと15分だということを警告してくる。彼女が電話を開けると、アポだけではなく、電子メール、メモ、電話メッセージ、フランクの番号への発信記録など、フランク関連のあらゆるドキュメントのリストが表示される。ビビアンが発信ボタンを押すと、電話はフランクとのアポが間もなくであることを知っているので、自動的にフランクに電話をかける。彼女は、20分で着くと連絡する。
６．ビビアンは物件の住所こそ知っているが、正確にどこなのかについては少し自信がないので、アポに記入したアドレスを引っ張り出して軽くたたく。すると、電話は現在位置と目的地の関係を示す小さな地図と彼女に対する指示をダウンロードしてくる。
引用終わり。
これで、ゴールに立ちはだかる課題と、課題を解決するためにシステム/デバイスがどう役立ってくれるかのイメージがはっきりしてきますよね。
ところで、課題をどう解決するかっていうのは、システム/デバイスをどう実装して実現するかというのとは違います。あくまでも、こんなこといいな、できたらいいな、の、のび太レベル。About Face 3 ではこれを「魔法のふりをする」あるいは「魔法のインターフェースがあるふりをする」といっています。
たとえば、このコンテキストシナリオで描かれる魔法の「PDAタイプの電話」はこんなかんじです。
(いや、実際、こんなのありそうですけれども。)
・手軽にメールチェックができて、メールからシームレスに電話もかけられる
・相手と電話(スピーカーフォン)で話ながら、スケジュールを確認できて新しいアポを登録できる
・登録されたアポはオフィスで共有できる
・アポの時間が近づくとリマインダー通知が行われ、PDA内部では当該のアポ関連の情報が"活性化"する
・現在位置を目的地をプロットした地図が表示できる
・留守電モードであっても、"秘密のコード"を知っている人からは通話モードで連絡が入る
・インタントメッセージの送受信ができる
しかし、こういう一連の機能をどう実装するのかなんてこの時点ではまったく心配していないし、具体的にどんなインタラクションで操作するのかについても非常に無責任にすらすらっと書いちゃう。「アポに記入したアドレスを引っ張り出して軽くたたく」なんて。
コンテキストシナリオの眼目は、どう作るか、ではなく、何を作るのか、をはっきりさせること。"実現方法"は、コンテキストシナリオを固めた後に、コンテキストシナリオに基づいて考えていけばいいことじゃん、と。だから、ここが「デザインの開始位置」になるわけです。
そう考えてみると、この本に書かれているわけではないですが、上でやってみたように、コンテキストシナリオで明らかにしたい4つのポイントを意識しつつ、まずは、システム/デバイスにまったく触れずに、コンテキストとゴールを明らかにするためだけにシナリオを書いてみるのがいいんじゃないかと思うんですよね。ここまではユーザー調査の結果をペルソナにまとめる作業の成果から、わりと論理的に導けるはずです。仮にペルソナが想像上の「暫定ペルソナ」だったとしてもね。
で、その後に、ゴールの前に横たわるいくつかの課題と、それを解決していくシステム/デバイスのイメージを書き込んでいってみると。ここは、ちょっとクリエイティブに、思いっきり「魔法のふり」をしてみながら。
その「魔法」は、デザイン/設計の工程が進むにつれてボコボコにされる運命をきっと辿りますが、それでも最後まで参照される成果物として生き延びていきます。
そこに描かれた「魔法」たちが要請されたニーズを、別のかたち(実現方法)ではあれ、きちんと満たしているかどうか？ それが、その後作られることになるワイヤーフレームや画面モックの評価の基準になるわけですから。
ワイヤーフレームや画面モックを目の当たりにして、あれ、はたしてこれでよかったんだっけ？なんて不安になったら、それらが魔法の代わりとしてコンテキストシナリオにずっぽりハマるかどうか検証してみるとよろしい。
そう、これがないからさ、前のエントリーに書いたような話になるんじゃないかなーなんて、思うんですよね。どうでしょうね。
2009年4月24日
シナリオ重要。
About Face 3 読書ノートの 10。
Web アプリケーションを開発するプロジェクトで、ワイヤーフレームとか、あるいは、モックアップやプロトタイプなんかを作ってクライアントにレビューしてもらっていると、クライアントがじーっと何かを考えはじめて動かなくなることってありませんか。ここをこうさわるとこうなって、なんて一連のインタラクションを説明して、これまでの打ち合わせで確認してきた要求はこれで満たせますでしょうか、いかがでしょうか、って段になると、じー。
これでいいですか？って判断を求められたクライアントが何に思いを馳せて固まっているのかというと、たいていは、実際の利用シーンを総まくり総点検中ってかんじじゃないかと思うんですよね。じー、の後は、じゃ、こういう場合はどうなるの？ いや、実はこんな人がいてね、それで、こんな事情があってね、なんて話になることが多い。
こちらは、はい、その場合はですね、画面の操作はこうなってこうなります、これは、ユースケースでいえばここの部分にあたりまして、概念モデルのこれに関する操作です。で、その流れを詳しく記述したのが、こちらのシーケンス図になるんですけど、それは以前ご説明させていただいたとおりです。なんてやっちゃう。
しかし、これって、ナントカ図、ナントカ図っていろいろ書いてみるんだけど、結局、あるべきシステムのイメージのおおもとをちゃんと見える化できてないってことなのかも知れないなあ、なんて最近よく思うんですよね。
ユースケースにしたって、概念モデルにしたって、それらは要求を分析して実装の要件を把握するためのツール、ある観点、水準でのシステムイメージのビューのひとつにすぎないわけで。みんなそれぞれに有用ではあるんだけど、これでいけるかなって最後の判断を下すときに参照したくなるような、なんというか、おおもと感がない。全部を総合したとしても、たぶんそれは出てこないでしょうね。
そう考えてみると、おおもと感のあるシステムイメージそのものはクライアントにしろ、われわれにしろ、各自がめいめいに勝手に思い浮かべてるだけなんですよね。それなのに、その派生物のほうはなぜか目に見えて共有されてもいるっていうこの状況、ちょっと倒錯してるようななかんじがしますね。
もう、面倒だから、今、クライアントがじーっと考えていたイメージのほうを先に書いとこうぜ、って言いたくなってきます。ユースケースがそれにもっとも近いんだろうけど、もっと生々しいかんじでしょう。
たとえば、あー、これだと総務の鈴木さんみたいな人が使うにしては、操作がちょっとややこしいかもなあ、なんかボタンも小さくて目立たないしなー、なんかこのままじゃ、ぶーぶー言われそうだなーなんて、漠然とにしろ、その鈴木さんという人の日々の仕事ぶりを思い出しながら、オフィスで彼がこの画面に向かっている場面を心のうちに思い描いてるんじゃないかと思うんですよね。
なら、素直にまず鈴木さんの利用シーンの想定をみんなで共有して、それから鈴木さんに喜ばれるにはどうしたらいいかってことで設計を進めたほうがいいんじゃないか。
そうすれば、じーっとする代わりに、鈴木さんの利用シーンが描かれたシナリオを追いながら、ワイヤーフレームやモックアップ、プロトタイプで示されたインタラクションが、本当にこれでいいのかって点検していけるわけですから。
って、それが、つまり、ペルソナ/シナリオ法なわけですよね。
わりと、ペルソナって言葉がバズっぽく一人歩きしている感がありますが、むしろ強調されるべきは、シナリオを書くってこと、シナリオドリブンでプロジェクトを動かしていくことなんじゃないかと思います。
質的なユーザー調査の結果を何人かのペルソナというかたちでまとめたら、各ペルソナが一体どんな状況の下でどんなゴールに向かって活動するのか、そこにこれからデザインするものがどう関わっていくのかを端的で短い物語にしてみる。
インタビューからペルソナを作るまでの一連の作業においては、実はこれからデザインするもののことを考えないこと、それをいったん魔法のツールＸとして措いておいて、その周囲、Ｘがすっぽりハマるコンテクストを探ることに専念する、そうした禁欲的な態度でのぞむところにコツがあったわけですけれども、シナリオを書く段階にはいって、やっと、これからデザインするもののことを考えられるようになるわけですね。
そして、
●シナリオを分析することでニーズ=要件が定義されます。
●シナリオからユースケースや概念モデルが抽象され、実装設計に対するインプットとなります。
（この点は About Face 3 では触れられていないんですが。）
●シナリオに適合するようにしてシステム全体のインタラクションがデザインされます。
●そうして出来上がったものは、シナリオによって品質がチェックされます。
というわけですから、まさにシナリオ重要。です。
About Face 3 流ペルソナ/シナリオ法では、目的別に大小さまざまなタイプのシナリオを書きます。コンテクストシナリオ、キーパスシナリオ、チェックシナリオとあって、チェックシナリオが、キーパスバリアント、必須パス、エッジケースの各シナリオに分かれて。
それぞれ、実際、どうやって書くけばいいものなのか興味のあるところなんで、ここのところは細かく刻んで、ちょっと丁寧にノートにしていこうかな、と思ってます。あと、シナリオとユースケースの違いとかもちゃんと考えてみようかな、なんて。
しかし、このペースでは、About Face 3 一冊フォローするのに、一年くらいかかっちゃいそうな気がしてきた。
まあ、いいか。
-----------------
sent from W-ZERO3
登録:
投稿 (Atom)
