chibirashka journal

金曜日の午後、代々木公園のオリンピックセンター研修室を借りて、社内研修を行った。元々は、IA/UXチームの研修会として企画が持ち上がったのだけど、PMやディレクターや、コンセントにいるメンバーはできるだけ出た方がよい、ということになったので、ほぼ全員参加の研修に。

研修の前半は座学でのIA、Webプロジェクトのプロセスといった内容で、後半はワークショップ型でいくつかのサイトをヒューリスティック評価するというもの。

昨年の吉田塾以降、社内のマーケ部、ログ部といったクラブ活動（自主参加型勉強会）の中でも、ワークショップを行うことが多い。内容はさまざまなので、ここでは割愛するけど、どのワークショップでも必ず感想として挙がるのは「時間が足りない」ということ。

今回のワークショップでも、正味小一時間で、ブレスト的なポストイット書き出し（個人ワーク）、サイトマップ作成（デカイ紙に）、書き出したポストイットのグルーピングと、課題の抽出、発表準備まで行う必要があり、「あ〜、全然終わらんっ！」っていうのが真っ先に思うところだった。

ユーザビリティ評価として、ヒューリスティック評価のほかにユーザーテストが挙げられることも多いけど、ユーザーテストに対し、エキスパートレビューとも呼ばれるヒューリスティック評価は、専門家の経験、知見、経験則により、比較的短期間で網羅的に評価できるのがメリットでもあるし、実際のプロジェクトで業務として行う時にも、限られた時間内で行う必要があるので、こういう訓練は必要だと思った。

サイトを評価する観点として、ざっくりと

• 構造（サイトストラクチャ）
• UI/デザイン（エリア-ゾーニング、要素、ナビゲーション、ふるまい）
• コンテンツ

があるんだけど、そう分かっていても、時間もない！というプレッシャーが加わると、どこから見ていっていいのか分からなかったり、あちこちクリックして見てるつもりでも、焦るばかりで評価できるほどにはちゃんと見ていないなんてこともある。（課題になりそうな「何か」に気づけなかったらどうしよう・・というような不安とかもあり）

この辺もやはり訓練次第なんだろう。どのサイトも（基本的には）オーダーメイドなのだから、まず、ここから見れば絶対にOKです、なんてことはないだろうし。

というわけで、ヒューリスティックの「いろは」というわけにはいかないけど、各チームの発表やそれに対する長谷川さんの総評などから、今後覚えておきたい（いや、知っていてもなかなかできないことが多いから念頭に置いておきたい）ことをメモ的に挙げておく。

【評価時】

• そもそもユーザビリティ評価をしているにも関わらず、「ユーザビリティが良くない」と判断するのは意味がない。どこがなぜ、が分からないと。
• ECサイトの評価では、実際の購入フローを重点的にチェックする
• 使う人の気持ちでのシミュレーション（認知的ウォークスルー）ができると良い。
• 個々のインターフェースを細かく取り上げて説明するより、それが何の問題であるかを言ってしまうと良い（これこれのリンクルールが違っていたり、各メニューごとにレイアウトが違っていたり・・云々　⇒　デザインガイドラインが定まっていないように見受けられる）
• そのサイト（または企業、事業者）独特の問題があれば、それをポイントに考えてみるのもよい（例：既に広く認知されたブランドの場合は、そのブランドで期待されるエクスペリエンスがサイト提供されているかどうか・・など）
• メニューやコンテンツといったサイト内の要素だけでなく、サイト自体の立ち位置（B2BかB2Cかなど）を俯瞰して見てみる

【発表時】

• 全体のうちのどの部分を話すのかを最初に明らかにする（例：サイトの全体構成はこれこれこういう風になっていますが、今回評価するのはこの部分です。）
• 仮説を置いて説明する
• 有限の時間では最初に結論を言えると有益（例：重複コンテンツが多く見られるのが問題だと思いました。なぜなら・・・）
• 事実なのか評価なのかを分けて話す

私自身の反省と今後につなげたい点としては、時間配分もだけど、チーム内役割分担かな。同じチーム内にリテラシーの極端に低い人がいる場合に、どうやって進めるかをよく考えないと、その人があまり参加できないままになりグループワークであることの意義が埋もれてしまう。

というのも、たとえば、書き出したポストイットをある見出し（文脈）でグルーピングしているそばから、「こっちのグループのポストイットにもあっちのグループのポストイットにも”メニュー”という言葉が書いてあったので、ひとまとめにしてグループにしておきました」と言って、文脈を崩されてしまう場面が多々あったから。「うんとね、言葉で分けているわけではなくてね・・・」みたいな・・（汗）

こうなると思考が思わぬところで止まってしまったり、作業のやり直しが発生したりしてしまう。だからといって、「構造というのは・・・」「UIというのは・・・」「ふるまいというのは・・・」から説明するのも時間的に厳しかったりするし。。。今回は、若干自己嫌悪になりつつも牽制しながら（謎）、それとなくカタチにしたんだけど、グループワークでやる以上は、参加者全員が同じぐらいの力を出して、同じようにアイディアを出したり発表するのが望ましいと思うし、知識や経験の差によって見方が違うからこそ新しい発見もあるかもしれないしね。なんとかその辺の課題をクリアしていきたいと思った。ヒューリスティック評価自体の話じゃないんだけど、どちらかといえばファシリテーション技術なのかね。

なかなか奥が深い。。。むずいな、ワークショップ。

大企業でもない限り、肩書きに何を名乗るかは比較的自由で、ある意味、名乗っちゃったもん勝ちなところがあると思う。

でも、同じ肩書きを名乗るとしても、それが指す範囲は名乗る側（組織）によっても違うし、その言葉を聞いた受け手によっても違う。
あ、ここで「肩書き」と言っているのは、課長、部長、主査、といった職位ではなく、職能のことね。

特にWeb業界の場合は、業界自体が比較的新しいし、進歩する技術によって初めて実現される事柄が出てきたり、何かと何かの関係性が新しく生まれたり、ということが多いので、新技術の名前だけでなく、それに対応できる人の能力や職種を表す言葉もどんどん生まれているような気がする。

そんなに新しいってわけでもないけど、「Information Architect」っていうのもそうだろうし、日本特有の「Web Director」というのもそうだろうし。最近だと（私にとっては）、「Interaction Designer」とか。もう１つおまけに「User Experience Designer」とか。

User Experience Designって、直訳で「ユーザー経験をデザインする人」なので、相当意味が広い。じゃー、全部じゃん！魔法使いか！？とか思う。かといって、「物事を、使いやすく、分かりやすく、使い心地よくする人」って言うと、それはそれでシンプルすぎじゃん？って気もするし。

というわけで、そんなことを考えてるのは私だけじゃないようで、こんな記事を発見。

10 Most Common Misconceptions About User Experience Design
〜ユーザーエクスペリエンスデザインに関するよくある10の誤解〜

Whitney Hessという人が書いた記事だけど、彼女はこの記事を書くにあたり、Peter MerholzやDan Saffer、Dan Brown、Louis Rosenfeld、Luke Wroblewskiなどなど、たくさんの人たちにTwitter DMを打って、ヒアリングした上でアイディアをまとめているので、彼女の思い込みだけで創作されたものではなく、UXD周りにいる、多くの人たちのコメントの引用で構成された興味深い記事となっています。

ちなみに、10個の誤解はこれ。

User experience design is NOT：ユーザーエクスペリエンスデザインは・・・

1. user interface design：ユーザーインターフェースではない
UIはUXの構成要素だが、パズルの1ピースでしかない。

2. a step in the process：プロセスの中の1ステップではない
UXDは、ユーザーの振る舞いに対応し進化させていく継続的なプロセスである。

3. about technology：テクノロジーのことでもない
人々の目的の達成を助けるためにテクノロジーは使うものであって、あくまで本来の意図は、すごいテクノロジーを作ることじゃなく、人々を助けること。

4. just about usability：ユーザビリティだけでもない
モノ（コト）を簡単に直感的にするだけじゃ不十分で、人々に態度や反応を変えさせるため、彼らが使いたくなるようなモノ（コト）を作る必要がある。

5. just about the user：ユーザーのことだけ見てればいいってもんでもない
そこには必ずビジネスの目的があるのであって、必ずしもユーザーのみにベストな判断ができるわけではない。ブランドのことも考えつつユーザーニーズとビジネスゴールの間のちょうどいい塩梅を見つけることが大事。

6. expensive：高くない
フルフルのUCDのプロセス、ペルソナやユーザーリサーチといった手法に執着しがちで、そうすると、コストも高くついて、永遠に時間がかかりそうに見えるけど、実際にはプロジェクトごとにそれにあったメソッドを取り入れ、いくつかのUXDテクニックを導入し小さく改善するという方法を取ることで、あらゆる制約の中でもカスタムメイドのアプローチを取ることができる。

7. easy：簡単じゃない
クールで効果的と思われる取り組みの実施方法は知ってても、その全体のプロセスがそんなに簡単でないことも分かってるし、また別の難しさとしてよくありがちなのが、自分たち自身をエンドユーザーだと思い込んでしまうという罠。

8. the role of one person or department：誰か1人とかどこか1つの部門の役割ではない
UXDは連絡窓口な存在であって、特定の主題に特化した専門家でもなければ、医者でもないし、マジカルな存在でもない。聞き方に長けているというスキルを生かして、組織の中で、最も効果的なプロセスについて説くことを助けることはできるけど、ビジネスが成功するかどうかは、結局はそこに関わる全メンバー次第である。

9. a single discipline：1つの専門領域ではない
UXDはまだかなり新しいので、専門領域としてちゃんと確立していない。せいぜい、いいデザインを気にしている異なった専門領域の人々をつないでいる、認識程度のもの。必要な何か全てを遂行するために、UXDの領域にありとあらゆる専門性を期待しちゃだめ。

10. a choice：選択できる問題ではない
ダメダメなデザインを最初からゴールとして設定するわけがないので、自分たちが提供してるものが低品質で不完全だなんてことは信じたくないのが普通。（UXDを意識的に排除したわけじゃなくても、実際にはいいユーザーを体験を与えていないデザインが多い、っていう含蓄かね？）

しかし、やはりユーザー経験をデザインすることは、ありとあらゆる要素が絡むことなので、User Experience Design is not… という排他的な言い方はできても、User Experience Design is…と、宣言的な言い方は難しそうですね。

UXDの皆さんは、これ読んで共感するのかしら、どうなのかしら。ぜひ教えて欲しいとこです。このエントリーへのコメントを見る限りだと、賛同者が多いようだけど、日本でも同じ反応なのかな。

※私の訳は、超ざっくりすぎて、誤解とかありそうなので、原文を読んでください。