WebSigのIA分科会
料理ネタばかりエントリーしてましたが、たまにはそれ以外も・・。
土曜日にWebSigのIA分科会「明日から実践できるIA vol.3 ユーザー目的からユーザーフローを導き出す」に行ってきました。IA分科会の開催は3回目の今回で終了とのことなので、私が行くのは、最初で最後。
2部構成になっていて、第一部では、ネットイヤーの坂本さんによるライブIAという初の試み。第二部では、第一部の内容をグループワークショップで体験。
ライブIAと言っているのは、坂本さんが情報設計時に頭で考えていることを口に出して言い、実際見ている画面なども見せていくことで、思考プロセスをオーディエンスが追えるようにしたものです。
具体的には、東京都のサイトを例に挙げ、自治体サイトの良いナビゲーションを考えるプロセスを見せていただきました。
坂本さんのプロセスでは、
1. 価値基準を作る
その業界(この場合は自治体サイト)で、どんなサイトが一般的に優秀とされているかを知る。さらにその中で、自分が作りたい(好きだなと思う)のはどんなサイトなのか、モデルになるサイトを選んで、自分の方向性を決める。
●利用できるもの
各種サイトランキング調査
●具体的手法:
ランキング上位のサイトをみて傾向、特徴を掴む。
また、過去数年のランキングも参考に、デザインや評価の変遷を知る
●注意:
価値基準を作る時に、(制作)対象サイトを見すぎてしまわないようにする。そのサイトのルールが刷り込まれてしまい、ニュートラルな判断ができなくなるから。
2. 行動を想定する(自分が利用者になる)
区役所にどんな時に行くのか、実際に行く時にはどんな行動を取るのか、・・・。自分を1ターゲットとして捉え、自分が実際に使う時のことを考える。
●利用できるもの
実際に撮影した写真、Google画像検索した区役所や、フロアマップなどの画像など
●具体的手法:
できれば、実際に場所に行って写真を取りつつ、どういう行動を取っているかプロセスをたどってみる。できるだけ具体的に行動を洗い出すため、例えば「引っ越し手続き」などテーマを持って行う。
3. ユーザーのニーズを知る
想像できる一般的な行動プロセスだけでなく、ユーザーが区役所や自治体に対して想起するような事柄を知る。
●利用できるもの
各種コミュニティ(アスコエ、kizashi、mixiのコミュニティなど)
4. 行動プロセスの分析
プロセス、行動、要件を洗い出す。
●利用できるもの
AIDMA、AISASなどフレームワーク
5. 要件のマッピング
フローと情報構造は同じではないため、構造的な情報分類と、ユーザーが想起しやすい切り口の動線作りが必要。
●具体的手法:
グローバルレベルのメニュー名(カテゴリ)を抽出し、これ以上分解できないというところまで分解し、情報構造を理解し、再整理する。
想定した行動においてプライオリティが高いもの(例:引っ越しタスクではアクセスマップのプライオリティは高い)については相応の掲載方法をとる
といった感じでした。(うろ覚え・・)
情報設計ってリニアな思考プロセスってわけではないと思うので、短時間内でライブで見せることができるものなのか、すごく疑問だったのですが、なかなか興味深いトライだったのではないかと思います。(ライブIAに限らず、他の人がどう物事を考え、捉えているのかを知るのは興味深いです!)
全く予備知識のない業界のサイトを、どんな風に見ていったら良いか、といった時に参考にできる点がたくさんあると思いました。
ただ、「これが、情報アーキテクチャの設計です」というには、若干違和感を感じます。どちらかといえば、ディレクターや、もしかすると企業の担当者が、情報設計前に行うウォーミングアップみたいな位置づけに近いような・・・。
本来IAが行うべきは良いナビゲーションを作ることではなくて「問題解決」です。課題が何なのかを明確にするのが一番最初で、次に、解決するための方策を考え実施し、結果的にナビゲーション(なり、ラベルなり、構造なり)が、ターゲットユーザーにとって「良い」ものになるのかなと思っています。
一人ブレストするだけの時や、小規模でターゲットが明示的な場合は、自分を1ターゲットとして行動プロセスを考えてみるのは良いかと思いますが、実際の自治体サイトなど大規模なサイトの場合、多種多様なユーザーがいると思われ、また同じユーザーであっても、状況に応じて必要とされる機能や動線も全く変わってくると考えられるので、MECEに検討することと、優先順位の付け方とその根拠がキモだと思います。
HCD-Netの「地方自治体ホームページのユーザビリティ評価〜引っ越しタスク編〜」で評価を行った時も似たようなことを思った記憶があります。サイト内のページ単体の使い勝手の評価という意味では、ヒューリスティックによる、それこそ○×評価や、ベンチマークとの比較とかで良いかもしれません。
でも、本当の意味でユーザーにとって使いやすいか、分かりやすいかどうか、というのは、ペルソナを作ったからといって明確になるわけではなくて、また「引っ越しタスク」といった漠っとした目的に対して分かるものではなくて、ユーザーの一連の行動の中で、ユーザー自身も気づいていない「課題が何か」を知り、それが解決できているか、ということが指標になるのではないかしら。課題が不明なままだと、評価も設計もできないんじゃないのかなーと。
今回のライブIAという試みは、パフォーマンス的な面もあるし、サイト外施策は考えず、前提も緩く、というのが参加者全員の共通認識としてあったので、検討範囲がかなり限定的でも問題ないのかもと思いましたが、第二部のグループワークでのテーマ設定で悩んだ点や、そのHCD-Netのユーザビリティ評価の際に評価しきれないと思った理由に「課題が何か」の観点が欠落しているという共通項があるような気がして、後々の参考のために、超長いエントリーだけどポストしときます。
あ、ちなみに宣伝(?)ですが、WebSigのIA分科会は、IAAJ(Information Architecture Association Japan)の活動に引き継がれます。IAAJでは、毎月1回程度、できるだけ定期的にIA Cocktail Hourという懇親会や、その他勉強会/報告会などを開催しています。この会には、インフォメーションアーキテクトだけでなく、業務としてIA的なことを行っている人、IAに関心がある人など幅広く参加いただいていますので、ぜひ、参加してみてください。開催予告は、IAAJのサイト、メーリングリストのほか、コンセントブログでも行いますー!
はじめてコメントさせていただきます。
> ユーザーの一連の行動の中で、ユーザー自身も気づいていない「課題が何か」を知り、それが解決できているか、ということが指標になるのではないかしら。
おっしゃる通りで同意します。
そもそもの問題ユーザーは何がしたいのか、「課題は何か」という点については、方法論がなかなか見いだせないでいます。
今後は次のステップとして、自分自身も気づいていない心の中にある課題を探ることにテーマを絞ることも必要ではないかと考えています。
>tazukeさん
こんにちは!コメントありがとうございます!!
そうなんですよね。テストやインタビューを行うことで「これが課題だ!」と明確になれば良いですが、そもそもそうやってテストやインタビューを行うにも、仮説が必要なので、見当違いにならない仮説をたてられるかどうかが、私もテーマです。仮説が立てられるかどうかは、センスだけじゃないですよね!?!?
課題や問題解決といったシナリオを自分(たち)の知見や経験、そして感性を集約して立てるというのが基本だと思うんですが、しかしそれの裏づけ行動としてこのライブIAのような思考をたどるということならありえると思いますが、いきなりこのプロセスだとすると、それは短期間で提案しなきゃならないコンペ用のイチ作業とか、そういう印象がありますね。まあ参加してないので真相わかりませんけど、読んだ限りで。
>本来IAが行うべきは良いナビゲーションを作ることではなくて「問題解決」です。
これは、コミュニケーションデザインに携わるすべての人が行なうべきことでしょう。だってそれがデザインというものだから。
まあそういう意味で書いてんのかもだけど、IAって、僕はロールだと思っているけど、読み手によっては職種とか、もっと固定的なふうに受け止めてしまいがちだと思うので。
[…] WebSigのIA分科会 – chibirashka journal […]
>yuuさん
おー、コメントありがとうございます。
そうそう、それです!実際にサイトのストラクチャとかナビゲーションを定義した後、その妥当性の検証のために、それより前に作ったシナリオやユーザー経験フローを使うっていうのが自然かなと感じました。
あと、エントリー内では言葉足らずでしたけど、問題解決を誰がすべきか、ということについては、私も同じように思っています。「広義のデザイン=問題解決」と捉えているので、Webのプロジェクトの中で、情報構造の設計とかを行う人だけがそこを担保するわけじゃなく(IAが情報構造の設計だけをやってるわけでもないし、情報構造の設計をIAがやっていないケースもあるわけだけど)、関わる全ての人に、その認識が必要だろうなーと思ってますー。
[…] ーニーズによりサイト要件を整理する(WorkSheet IV)というワークがあり、ずーっと前に参加したWebSig(IA分科会)でもこんなアプローチのワークがあったんだけど、ユーザーニーズやシチ […]