2008年10月31日 01:25Fujii

プロトコル分析(かるたでわかる用語集)

20081039.jpg

プロトコル分析は、ユーザーテストの発話などを録画したデータなどを見ながら記録し分析するものですが、自分として取り入れたのは、ユーザーテスト中のメモとしてです。メモをする際にフォーマットがあれば書きやすいと思ったからです。

録画データなど取れれば良いのかもしれませんが、簡易的にその場で要点を書いてしまおうという形です。項目は以下です。()内は何のための項目かの説明です。

  • 番号(あとで状況がわかるように)
  • 画面(その場面、どの状況下で)
  • 様子(その場面でしゃべったことを知るため)
  • 問題(問題ポイントをメモ)
  • アイデア(解決アイデアを思いついたら)

「書くことで、観察に集中して、よりよく理解する」ということが一番の目的と感じています。

このサイト内の関連記事:

関連書籍:

プロトコル分析入門―発話データから何を読むか
プロトコル分析入門―発話データから何を読むか

ユーザーエクスペリエンス ユーザーリサーチ実践ガイド

20081038.jpg

『ユーザーエクスペリエンス ユーザーリサーチ実践ガイド』という本分厚いですが、様々なリサーチが紹介されています。 ユーザーをオーディエンスと呼ぶところがおもしろいです。

  • リサーチ・プラン
  • リクルーティングとインタビュー
  • ユーザ・プロファイル(ペルソナに近いです)
  • 文脈調査、タスク分析、カード・ソーティング
  • フォーカス・グループ
  • ユーザビリティ・テスト
  • サーベイ
  • 継続的なリレーションシップ
  • ログ・ファイルおよびカスタマーサポート
  • 競合リサーチ

などなど、メリット、デメリットそれぞれ書かれています。 基本的には、「問題の発見」までをユーザリサーチで行うということになると思います。 詳細はまた別の機会に。

このサイト内の関連記事:

書籍情報:

ユーザ・エクスペリエンス ユーザ・リサーチ実践ガイド(IT Architects' Archive ソフトウェア開発の課題9)
ユーザ・エクスペリエンス ユーザ・リサーチ実践ガイド(IT Architects' Archive ソフトウェア開発の課題9)

2008年10月29日 01:00Fujii

どの問題を扱ってるんだっけ?

ユーザーテストなどは、こういった視点の発見が出来ますが、 ユーザーテストからより、多くの結果を得るには、

  • サイトとの接点に問題が無いかを知るためなのか
  • サイト内のコンテンツの構成が問題ないか知るためなのか
  • 具体的な機能を使うときに問題が無いか知るためなのか

を、考えて範囲を決めて行ったほうがいいと感じました。

接点などを知りたい場合は、(どこまでをユーザーテストと呼ぶかは置いておくとして)、ユーザー調査のほうが良い場合が出てくると思います。

今のところ、大事かなと考えているのは以下です。

  • デザインリサーチと呼ばれるようなユーザー調査
  • それをもとに実際に形にしたりアイデアを出す

文章にすると当たり前すぎますね。おかしいな。

このサイト内の関連記事:

関連書籍:

2008年10月28日 01:05Fujii

サイトとの接点がうすいユーザー

対象とする人がWebサイトの場合どのあたりの状態を相手にして良いのかが混ざってしまう感覚があります。

  • ネット、雑誌、人の話などは問わず目的がある人
  • ネットを具体的に使う目的がある人
  • いくつかのWebサイトを使う目的のある人
  • 特定のサイトを使う目的のある人
  • 特定のサイトのある機能を使う目的のある人

もちろんソフトウェアでもそうかもしれませんが、

  • 特定のソフトウェアの特定の機能を使う目的のある人

というくくりが、購入目的決定→購入→使用というフローを経ているのでイメージがつかみやすいかなと思いました。

このサイト内の関連記事:

2008年10月27日 00:37Fujii

「コンテンツの不足」と「メンタルモデルとの違い」という2種類の問題点

問題点の種類をわけるとすると

  • コンテンツの不足によるもの
  • メンタルモデルと返ってきた動きの違いによるもの

があると感じました。

コンテンツの不足によるものは、どんなコンテンツを用意するか(要望をそのままか?代わりのコンテンツは無いのか?本当に必要か?)さらに話し込まなければいけません。

メンタルモデルとの違いによる問題点は、期待していた動きを実現することから検討しますので具体的に進むと思いました。

このサイト内の関連記事:

2008年10月26日 11:42Fujii

問題点と解決案はわけておく

ユーザーテストがおわったあとに振り返ると、「これがないからダメだった」という感じになりますが、やはり、以下の2点をきっちりわけておくように注意しようと感じました。

  • 問題の場面
  • 解決案

もしかすると、「問題点はどこでしたか?」という質問は、「問題の起きた場面」と「解決案」を混同しやすい質問なのかもしれないと思いました。

分けておくと、解決案の候補がいくつか出せます。

このサイト内の関連記事:

関連書籍:

2008年10月23日 23:28Fujii

目的をもって観察する

どんな目的があってユーザーテストで観察するのか?を自分が説明不足だったために問題が起こりました。

やってから説明するか、説明してからやるかは実際迷いましたが、どういう目的で観察するのかという基本的な部分がないと、眺めているだけになることが実感できました。

難しいのは、目的を持っていてもなにか画期的な案が必ず出るわけではないことです。 とはいえ、ラベリングの問題や、画面遷移の問題はあとで分析するまでもなく、その場で一瞬で出てくる面があることも実感できました。時として、拍子抜けするくらい問題点はあっさり出てくる。

ヒアリングでもそうなんですが、あっさり事実がでてくると「まあ、そういうもんだと思ってた」と、なんとなくわかっていたように錯覚することがあります。本当にそう思っていたときもあるんですが、事前になにも考えていなかったにもかかわらずそう感じることがあります。

なので自分は、なるべく事前に予想を立てておいて、あとで結果と比較するようにしています。

このサイト内の関連記事:

2008年10月22日 22:24Fujii

メンタルモデル

前回(予想していたものがでてきたか教えてもらう)の方法の解説です。

気になる点は

  • 作業をストップすることで、自然な流れが止まってしまう。
  • 言葉にすることで、強く意識してしまう。

ですが、観察のポイントとしては非常に良いと思います。

やはり、ネットを見ているときの行動ってじっと何かを見ていたかと思うと、急に速くなってあちらこちらクリックしたりします。

アクセス解析でも実際に滞在時間が1秒とか2秒で次へ行っていたりします。かとおもえばその後のあるページでは1分というログが残っていたりします。

ログでもわかりますが、一度近くの人がネットをしているところをじっと見るとびっくりします。自分自身もそうなのだと後で気づきますが、実際みてみると、速いときはものすごく速い。

それに圧倒されてなにも観察できないよりは、不自然であっても前回の観察方法を一度やってみたほうが良いです。

このサイト内の関連記事:

予想していたものがでてきたか教えてもらう

いろいろな本で「観察し分析し問題点を発見し改善や発想をする」という言い方はでてきますが、やってみるとなかなかスムーズにはいきません。

文章だと「なるほど、そのとおり!」ともっともらしく聞こえる(さらに、最初はついつい「それをやれば、なんかエスカレーターのようにスイスイうまくいくんじゃないか?」なんて思い込んでしまったりする)んですが、実際にやろうとすると一筋縄ではいかないことをこのとき感じました。

  • どう観察するのか?
  • どう分析するのか?
  • どう問題点を発見するのか?
  • どう改善案を出すのか?
  • どう発想するのか?

いざやろうとすると、ものすごく地道だったり行動力が必要とされるフェーズだと感じました。

当時参考にしたのはこちらです。

7. 「そこをクリックすると、どうなると思いますか?」と聞こう。

未経験者がユーザーテストを行う際の10のポイント livedoor ディレクター Blog(ブログ)

このサイト内の関連記事:

2008年10月20日 23:03Fujii

間違ってもいいからやってみようと思いやったこと

今までにやったことを振り返って、失敗の連続ですが描いてみたいとおもいます。

自分はなにかもやもやしているときは、とにかくわざと無理にやってしまって、どこがおかしいのかはっきりさせるということをよくするので、失敗と気づきの連続です。

自分がわかってないのにやるということで混乱は必至です。はい。作る料理を決めるとレシピも頭にはいり、材料もやっと区別がついたりするイメージです。

関係ないですが、アフォーダンスとかのほうにはちょっと踏み込んでないんですが、液晶だけではないタンジブルなインターフェイスというのものがあるらしく、まだよくわからないので、自分の勝手なイメージではおもちゃやゲームセンターのものにつながるというくくりをしています。

ゲームは動きをこちらの手元のものから送ることがメインで、なんとなくタンジブルというほうが、コンピュータのデータなどから手元のものへのフィードバックがたくさんある感じが強いですが。(自分の思いつきだとリーチをおしえてくれるマージャンの牌とかにもなるのかなという程度です)

この辺はまったくわからないですので、ちょっと調べてみたいところではあります。

マウスの話とか、カラオケの話とか、タッチパネルばかりだとどうなるんだろうとか、小林さんのこんなコメントにもつながりそうなんですが、全然まとまっていないので別の機会に。

2008年10月18日 11:38Fujii

実在しない人なので、イメージの共有は書類だけではなく一緒に作りながら

「ペルソナ手法」は「そばにいる人中心デザイン」に比べて、実在しない分イメージの共有がしにくい弱点があります。

「そばにいる人」でも、その人の行動パターンなどの共有は何らかの形で整理しなくてはいけませんが、根本的に実在する人を相手にイメージするほうがわかりやすいのは変わりません。

よりよくするために、コツコツいろんな方法をプラスすることが必要です。

「書類やシナリオ」にくわえて、「共同作業によってチームでイメージを共有する(いろいろ手を動かしながら)」点を重視し、ひとつの方向に改良したのが棚橋さんの本の「ペルソナ作って、それからどうするの? 」のポイントの一つだと思います。

イメージによる共有という点では、何かを憶えるときの方法もヒントになります。

「エピソード記憶」と呼ばれるような、体験したり、何かにアウトプットしながら憶える記憶のしかたがあるといわれます。

これをやろうとすると「体験する」「アウトプットする」を「本を読む」「話を聞く」よりも重視することが大事です。

「ペルソナを作る体験」や「書類としてアウトプットする」ことを通して記憶することが、イメージによる共有をしやすくすると思います。

このサイト内の関連記事:

書籍情報:

そばにいる人中心デザイン

以下の4つの手法は、個々の部分や概念に気をとられてペルソナをうまく自分の中に落としこめなかったときに考えていたことです。

  • 衝動で作りたいから作るデザイン
  • 自分が使うことを考えて作る自分中心デザイン
  • そばにいる人中心デザイン
  • ペルソナを使ったデザイン

一見遠回りのようですが、「そばにいる人中心デザイン」を考えるとある程度ペルソナを使ってやるデザイン手法が理解できます。特に「誰かを想ってデザインする」という部分です。

「そばにいる人中心デザイン」を少し変えるとペルソナ手法になります。 「ペルソナ手法」とは本当にそばにいる人ではなく、もう少しいろんな調査をして統合し、あたかも「そばにいる人」としてペルソナを作るからです。

このサイト内の関連記事:

2008年10月16日 00:01Fujii

自分中心デザインから考えて、ペルソナを説明する

客観的に見るというより、主観をいかに少しづつ変えていくか、それもチーム全体でというのがポイントかと思います。ペルソナの手法をそのまま実現し使うかは別として、人によって、マンガで描いてあるようなズレが結構激しいので、基礎的な感覚として広く普及すればいいなと思います。

それを踏まえたうえで、場面ごとに、どんな手法を選ぶか話し合えると結構ちがってきます。

このサイト内の関連記事:

2008年10月15日 00:35Fujii

ペルソナが今いち理解できない人へ

20081018.jpg 20081019.jpg 20081020.jpg 20081021.jpg

ペルソナは全体の一部というのをイメージすると迷わなくて良いのかもしれません。 分厚い本が苦手な人はユーザビリティエンジニアリング―ユーザ調査とユーザビリティ評価実践テクニックが各ペルソナ本と組み合わせて読むのにおすすめです。

Amazonで見ると分厚くて難しそうな表紙なんですが、実際に本屋で見るとうすくて、とてもわかりやすいです。

※関係ないですがこれはおもしろいですね、ビジュアルでの情報取得に慣れている人にも良いのかなと思ってしまいました。仕事柄、PCと携帯の写真のタイミングをついつい見てしまう。うーん、おもしろい。 第3週 観察結果発表 (infodesign2_2008のブログ)

このサイト内の関連記事:

2008年10月12日 22:28Fujii

小さくはじめて大きく育てる

下記のエントリーを見て。

環境は整っているのに、学科間のコミュニケーションがないために何も生まれない。 環境は整っているのに……。(show must go on.)

正直、これは企業でも起きている課題だと思います。

「小さくはじめて大きく育てる」、これは、自分が会社内で実験的なことを行うときにやるやり方です。

Webサイトでもそうですが、気合いれていきなりビッグなものにするよりは、小さくつくって具体的に動き、何度も調整して育てるほうが、リソースの有効活用になる事があります。

このサイト内の関連記事:

ケーススタディ 人のふりみてやってみたくなる

20081011.jpg 20081012.jpg 20081013.jpg

「やってみる」を視野に入れたときに、うまく伝えるためのメモ

  • やりかた、考え方を文章で説明
  • 写真を使う
  • 写真にあわせて解説を使う
  • 写真と解説をたくさん使う
  • 実例の紹介をする
  • 物語(セリフ入り)形式でケーススタディを書く(文章・マンガ・映像など)
  • 実際にやっている様子を動画で見せる
  • ワークショップ(実際にやっている様子)をその場で見せる

その他全体的に考慮できたらすること

  • 見ている人と同じような人がやっていると感情移入しやすいのかもしれません
  • 属性ごとに見せるものを変化させるか、参加者や行う人を数種類の属性を盛り込んでおく
  • 具体的には、同じポジションの人とか、同じ業界の人とか、同じ立場の人、同じ年齢の人
  • 学生に見せるなら学生、男には男、課長には課長、中小企業なら中小企業、web業界ならweb業界、ディレクターならディレクターがやっているところをなるべく用意。

書籍情報:

2008年10月11日 01:06Fujii

文化は人の行動で生まれる

文化は人の行動で生まれる。それは作ることが出来るのか? 作るよりも発生するに近い気がします。文化を持った人がいて、そのライフスタイルや行動が周りに影響を与えることによって広がり、結果的に作られたということになると思います。

文化を持った人というのは強烈に個人の趣味趣向、ライフスタイルがビシビシ出ていることになります。もしくは、そのような状態の集団です。

「文化を創る」ことが簡単ではなく「発生」と表現したくなるのはそういう面からです。 文化を創ろうとしたならば、そのような文化を持った人を作るということと同じことになります。

20081009.jpg 20081010.jpg

サイト内関連記事:

2008年10月07日 21:39Fujii

ペルソナ作って、それからどうするの?ユーザー中心デザインで作るWebサイト

中小企業のサイトを制作する際は、土台となるものが無いと現場にいて感じます。

その結果、競合(というより同じ業界の他社の)サイトを真似たようなサイトになってしまう結果や、あとはSEOでキーワードの検索順位をうんぬんというのみの話が多いです。

大規模なマーケティングデータはおろか、ユーザーという概念すらない場合もある世界ですが、何か土台として取り入れることができるものはないだろうか?と考えていて、ユーザ調査というものを軸にできないか検討しています(大企業の大規模な調査ではなく、小規模で要所要所という感じです)。

連続しがちなエントリーをどうするか悩み中です。

関連記事:

書籍情報:

ペルソナ作って、それからどうするの? ユーザー中心デザインで作るWebサイト
ペルソナ作って、それからどうするの? ユーザー中心デザインで作るWebサイト

エデュテイメント(教育+エンターテイメント)

ユーザーリサーチに関する本を買って読みながら美容院にいったら、美容師さんが「そういう本嫌いです(笑)」といっていました。さらに、「その本は字ばっかりなんですか?」と。

内容の話になり、
「ユーザーにとって使いやすいものだったり、ユーザーを理解し合わせたものを作るための調査についての本なんです」
「マーケティングみたいなものですか?」
「そういう部分も含まれると思います、手法のヒントはないかなと思って。結構良さそうです」
「なるほど、ところで、その本はスゴク重そうですね・・・私は読む気がしません(笑)」
「はい、電車で読むと人の頭の上に落としそうです、6000円位したんですが、まだ6ページくらいしか読んでません」

ユーザビリティについて調べていると少しづつ「使いやすさ」が求められる例として、戦闘機の計器のようなものが多くなってくることがあります。ソフトウェアのUIだったりです。たしかに、それは使いやすくないと困るものです。

しかし、ユーザー調査だったり、ユーザーの文化理解にもとづくシナリオになると、使いやすさだけではなかったりします。このあたりが、もやもやしていますがおもしろいところです。

書籍は果たしてどっちなんでしょうか?

「使いやすい」のか「おもしろい」のか、そのどちらでもないなにかをターゲットにしているのか?誰をターゲットにしているのか?と本を読んでいるとよく考えてしまいます。

先ほどの書籍は、この美容師さんをターゲットにもしていないし、外で読む用にも作られていません。では「誰」中心設計なんだろう?万が一この美容師さん向けにするならもっと写真主体じゃないとダメか?そもそも本じゃダメか?とついつい考えてしまいます。

こういった本の設計という面も、「情報デザイン」のおもしろさに、含まれるんではないかなと感じています。この分厚い本も「話し言葉に近い表現」というコンセプトがあり、これは「情報デザイン」だと感じます。

いろんなところに少しづつ生かせるのも良さだと感じます。

関連記事:

書籍情報:

ユーザ・エクスペリエンス ユーザ・リサーチ実践ガイド(IT Architects' Archive ソフトウェア開発の課題9)
ユーザ・エクスペリエンス ユーザ・リサーチ実践ガイド(IT Architects' Archive ソフトウェア開発の課題9)

2008年10月05日 01:58Fujii

プロジェクト管理のコツ 「目標を突破する 実践プロジェクトマネジメント」

プロジェクト管理のコツの後編です。

目に見える形にすると、共通のものについてようやく話すことができます。 これがすごく大事です。

と同時に、ある程度目に見える形にしなくても話せるチームは動きが速いです。 意思の疎通とはこういうことをさすのかなと思いました。

どんなに意思疎通がはかれているチームでも、現実には、勘違いも起こる可能性はいくらでもあります。 現場レベルでは、伝えたいことを目に見える形にすばやく表現して、それに対して、目に見える形ですばやく返すというやり取りが一番良い状態です。

もちろん、スケジュール管理の場合、ただ単に描けば良いっていうものではなく、それぞれが何について表すのかというルールの設定も重要です。(例:線は重複しない、一区切りできる最低の単位で書く=同時にほかの事はしないという前提を崩さないようにする)

このマンガに描かれているケースの場合は、本当に絵にすることのパワーを感じました。

※マンガはクリックすると拡大(幅720px)されます。

人が重複する場合は、各プロジェクトごとに管理(極端に言うと人の取り合い)ではなく、複数プロジェクトを統合してまとめて管理しなくては結局うまくいかない(仕掛品ばかり増える)ことがわかりました。

マンガ内で出てきた本:

CD‐ROM付 目標を突破する 実践プロジェクトマネジメント
CD‐ROM付 目標を突破する 実践プロジェクトマネジメント

2008年10月04日 01:47Fujii

インフォグラフィックス・ワークショップ1「ワークショップは答えを教えてもらう場ではない」

「インフォグラフィックス・ワークショップ1」に関しての報告はこれでおしまいです。

あらためて、TUBE GRAPHICSの木村さんや講師の皆様、準備に携わった皆様、参加者の皆様 ありがとうございました。

詳しい情報はこちら(TUBE GRAPHICSのワークショップのページ)にまとめてらっしゃるようです。

ご興味ある方はどうぞ。

このマンガの内容はようやくこのあたりのペルソナとかの話に戻ってきたという感じです。

オープンインタビューに関しては『ユーザビリティエンジニアリング―ユーザ調査とユーザビリティ評価実践テクニック』を参考に、そのほかは『ペルソナ作って、それからどうするの? ユーザー中心デザインで作るWebサイト』等を参考にしています。

やっぱり、描こうとするとスルスル本の内容の理解が深まる気がします。

特に、『ぺルソナつくって〜』のほうは、詳細に書いてあるので、単に読むよりも、本を片手にやってみながらのほうが本の目的(と自分が思う使い方)にあっていそうです。

すぐにでもペルソナを使ってみたいというお急ぎの方:【実践編】からお読みください。【概要編】はプロジェクトを進めながら合間にお読みください。 『ペルソナ作って、それからどうするの?』発売開始。TB&コメントはこちらへDESIGN IT! w/LOVE

この本はちょっと普通の本といっていいのかどうかというものです。その気になればネットで著者のBlogも参照が可能ですのであわせ技?が使えます。

それぞれの本の内容については別の機会に。

サイト内のインフォグラフィックス・ワークショップ1についての記事:

関連記事:

書籍情報:

ユーザビリティエンジニアリング―ユーザ調査とユーザビリティ評価実践テクニック
ユーザビリティエンジニアリング―ユーザ調査とユーザビリティ評価実践テクニック

ペルソナ作って、それからどうするの? ユーザー中心デザインで作るWebサイト
ペルソナ作って、それからどうするの? ユーザー中心デザインで作るWebサイト

2008年10月02日 23:59Fujii

インフォグラフィックス・ワークショップ1「制作完了まで」

横浜と渋谷のワークショップを体験し、インフォグラフィックスの種類を自分なりに整理してみました。 (TUBE GRAPHICSのWebサイトで勧められていた本『世界のダイヤグラムコレクション』を参考にしました)

世界のダイヤグラムコレクションの目次はこのようになっています。

  • 過程図、系統図、組織図、機能図
  • 円グラフ、棒グラフ、折線グラフ、比較統計グラフ
  • 地域図、分布図、観光地図、道路地図、案内図、ピクトグラム
  • 科学、医学、工業、建築イラストレーション

これ以外に、本の中では太田徹也さんは6つに分類されてます

  1. 言葉、数字を配列でグラフィックに整理し、資料化する(表組・・Table)
  2. 情報量の変化を比較、座標化し、統計的に見せる(図表・・Graph)
  3. ものごとの関係や流れを図的にまとめ、系統化してみせる(図式・・Chart)
  4. 質的な時間の経過による変化を記号化し、図的に表現する(図譜・・Score)
  5. 絵画的な情感を拝し、知的なイメージ情報を図像化する(図解・・Illustration)
  6. 時間や距離を空間的に視覚図化し、体系的に場所化する(地図・・Map)

リストアップすると少し難しいですが、本は実際の作品がずらりと並んでいます。

見てみると、この6つをさらに組み合わせているものもあります。

渋谷のワークショップでは、自分としては、図解になるか図式になるかちょっとわかりませんが、数字が必要のないものをベースにしました。(そこに、時間や値段、フロアの階数は数字としてプラス)

「建物の魅力を伝える」というテーマと雑誌向けであるということからか、ほかのチームも、建物の構造や使う人との関係性、比較統計というよりも「ネタとしての情報」を表していました。

インフォグラフィックスの表現手法の選択以外にも、上平先生も感想を書かれています。

実験的な試みが一般的な商業誌で有効かとなるとまた話が別で、普通の読者を想定して作るなら、普通に街探索に役立つ情報を優先するというのが通常の感覚だろう。それ以上の凝った表現はヘタをすれば対象不在のスタンドプレーに成りかねない危険がある。
インフォメーショングラフィックス・ワークショップ1 in Shibuyaへの参加後雑感kamihira_log

上記のエントリーでは、葛藤も踏まえてどう落とし込むかという視点でも感想を書かれています。

自分も、横浜や渋谷のワークショップで、個々の手法をどう使って、統合し落とし込むかもいくつか選択肢があり、そこの選択も大事だと感じました。今回は以下の3点です。

  • 雑誌としての落としどころ
  • インフォグラフィックスとしての落としどころ
  • 人間中心設計を使ったとしたらどうなるか?という落としどころ

参加した皆さんがどう捉えていたのか聞いておけばよかったです。自分は最終的には雑誌としての落としどころだったように思います。

サイト内のインフォグラフィックス・ワークショップ1についての記事:

このサイト内の関連記事: