menu

12.02.11

category

comments

1

trackbacks

0

permalink

Time spans of UX

最近いろいろなところで UX の重要性について語られることが多いのだけど、UX の意味ってすごく広い。
UX をどう捉えるかによってデザインされたアウトプットも変わってくるはずだと思うので、定義を正しく捉えることってとっても大切。そこで、自分がUX について考えてきた過程を少し書いてみることにしました。

◆UX の定義

自分は UI デザイナーという立場から UX というものに出会いました。
最初の自分の UX の定義は「UI の使い心地、ユーザビリティ」や「インタラクション・ビジュアルデザイン」を通じたユーザ体験という感じだったんです。UI Oriented という感じです。

ところが2011年から参加している AIIT の Human Centered Design の履修プログラムで出会った Web サービス系のデザイナーさんや SIer さん達と話をするうちに UX の定義が自分のものと何か根底から違っていることに気がついたのです。
いや、正確にいうと定義というよりも「UX で最も重要視していること」なのかな。
サービス系の人たちは UX =「サービスを使う過程のユーザ体験、サービスを利用することで成し得た体験」、UXD(UX Design)≒「サービスデザイン」といった割と大きな視点で UXを捉えているのです。この捉え方を Service Oriented と勝手に命名。
こちらのほうが世間一般に言われている UX に近い気もします。

両方ともたしかに UX だと考えられるんだけど... というわけで自分のなかに異なる UX の定義が同居することになりました。
この2つの関係性はどうなってるのか、はたまたこれ以外の定義が存在するのか。
自分のなかに疑問が生まれたのです。

◆UX白書(User Experience White Paper)に出会う

ユーザビリティや HCD に関する勉強会「新横浜ユーザビリティ研究会」というのがあります。自分は第3回あたりからずっと参加しているのだけど、その第6回に HCD Value(HCDの実践をコンセプトとしたコミュニティ)の方々が行ったセッションでこの疑問を解決する糸口を得ることになります。

セッションの内容は UX白書(User Experience White Paper)という 2010年に Dagstul セミナーで議論された「ユーザエクスペリエンスの概念」についてまとめた宣言文を HCD Value が翻訳し、その概要について報告をするというものでした。

その UX 白書のなかに「TIME SPANS OF USER EXPERIENCE」というのがあって、そこに解説とともにこんな図があったのです。

timespans-of-UX.png

自分の理解しているレベルで説明すると

Anticipated UX : 
プロダクトを使う前のUX。プロダクトを使うことでできることを"ユーザが想像する"体験。
>ブランドイメージや販売促進戦略などをデザインすることでよりよいUXを提供できると思う。

Momentary UX:
プロダクトを使っている最中のUX。使い心地や効率性の体験。
>ユーザビリティやインタラクションをよりよくデザインすることが重要。自分の最初に考えていたUXの定義はこれだったのか...

Episodic UX:
使用後のUX。プロダクトを使って成し遂げたことを振り返って感じる体験。
>サービスやアプリケーション設計をきちんとデザインすることでユーザの要求を満たすことができる。要求以上のことを提供できれば、それはすばらしい体験につながる。Service Oriented はこのあたりと次の Cumlative を合わせた感じなのかな...

Cumulative UX:
上記3つの体験をあわせた全体から感じる体験。
>よいUXを提供することがユーザの満足感やエンゲージメント(愛着)につながるのではないか。

このように "UX は Time Span ごとに捉えることができるのだ" と考えると、自分のなかの UX の定義に対する疑問がすうっと消化されました。ただ、UX 白書に出会ったのが8月で AIIT に通い出したのが 10月からですから、ピーンとくるのに大分時間がかかってますけどね。さらに自分が認識していた2つの UX に加えて Anticipated と Cumulative というもう2つの UX があることがわかりました。

◆全ての Time Span で UX をデザインする

自分が UI Oriented や Service Oriented と思っていた UX は実は Cumulative UX という全体の体験の一部に過ぎなかったわけです。
それまでに自分がデザインしたプロダクトを振り返ると、理解できていなかった UX へのケアが不足しているのがわかって、己の未熟さにしょんぼりしたりしましたが、同時に UX を Time Span でセグメントすることでよりよい UX を提供するにはどのような方策を取ればいいか、という改善点を容易に見つけることができたのは、この概念を知ることができたからこそだと思っています。

◆まとめ

正直自分は勉強嫌いだし、理論よりも実践してなんぼと思っているタイプなのだけど、こういうことがあると勉強も大事だよねえ、と思わざるをえないです。クライアントワークでこの4つの UX にフルコミットできるのってなかなかないケースだとは思うけど、こんど自分でアプリを出すときにはこれを意識しながらプランをつくっていこうと思うのでありました。

関連リンク:
新横浜ユーザビリティ研究会:http://asanoken.jugem.jp/?cid=23
HCD Value:http://site.hcdvalue.org/
User Experience White Paper:http://www.allaboutux.org/uxwhitepaper




11.11.10

category

comments

0

trackbacks

0

permalink

[AIIT]インターフェイス設計の8原則

認知科学はときに難解で数回に分けて行われている授業でもたびたび睡魔に襲われつつようやくあと1回を残すとこまできた。昨日は特に UI デザイナーにとってはとても重要な講義だった。

講義ではノーマンのメンタルモデルの話やよいデザインの4原則などが紹介されたのだけど、なかでも「インタフェース設計の8原則(Shneiderman, 1996)」は自分がデザインや設計を行うときに常に肝に銘じているもの。

shneiderman.png

UI の使い心地をダイレクトにユーザが感じてしまう今日のタッチデバイスのアプリケーションにおけるデザインでは非常に強力な原則だと実感しているものなので、この機会にもう一度おさらいをしておきたいと思ったのでエントリ書いてみました。
(でも、いっぺんにはできないのでちょっとずつw)


1. 一貫性を持たせる

「一貫性」とひとつかみにすると難しいのだけど、なぜ一貫性を持たせるべきなのか?という問いに対する自分の理解としては、

・「システム」と「ユーザ」のメンタルモデルの乖離を最小限にするため
・ユーザのメンタルモデル形成時において、ルールを設けることでユーザがデザイナーの意図したモデルを正しく学習できるようにするため

という感じ。

一貫性と言われて、手短かなところで例をあげると iOS のナビゲーション。

画面のリストをタップすると、画面が右から左にスライドしてより詳細な情報の画面へ遷移する。上のバーの左にある横向きベース形状のボタンをタップすると遷移元の画面へ戻れる。
詳細画面が左からスライドして現れることから「左から右に向かって情報が階層的になっている」というルールをあることを理解する。
遷移した画面の上部のバーの左側の横向きベース形状のボタンをタップするとどうなるか?(遷移元の画面に戻る)は、物理的な側面から類推することができる。

navigation_controller.png

しかし、利用するうちに「左上にあるボタンは戻るボタンである」という感じに位置的記憶が強くなりすぎでMusic Appの「Store」ボタンを間違ってタップしてしまう、というようなエラーを招くこともある(あ、これ蛇足だ)ので注意。

情報構造のテンプレートを用意したり、アニメーションをつかって物理的なイメージを与えたり、ビジュアル的な記憶を使ったりして、一度使えばシステムのメンタルモデルを理解できるのはそういう手法によって生み出された一貫性によるもんなのだよね。

で、一貫性を持たせるためにはどんなことをするかというと、

(Model)
・情報の構造化(noun)
・コンテキストにおけるユーザのアクションの予測(verb)
・モードの利用

(Visual)
・空間的な記憶の利用
・正しいマッピング
・体制化の利用(ゲシュタルトの法則)

などを利用する。
デザイナーはとかく見た目の一貫性だけに固執してしまいがちだけど、そうではなくて全体として「一貫性」というものをとらえないといけないすね。自戒も含め。

てなわけで、今日はここまで。
時間ができたらまた続きをエントリします。

11.11.04

category

comments

0

trackbacks

0

permalink

[AIIT]評価グリッド法による価値分析

今日の演習は評価グリッド法を用いた価値分析だった。
フローモデル図のときと同じく、また理解がしきれずもやもやが残ってしまったので少し整理をしてみた。
講義で教えていただいたことと復習のために web などで調べたことを自分的な基準で統合して書いているので、もし理解が間違っている部分があればぜひ指摘してもらいたいです。


評価グリッド法

どのようなことができるか
・サービスやプロダクトに対してのユーザの評価を
 「抽象的価値」「感覚的理解」「客観的・具体的」と階層的に把握できる
・被験者(interviewee)の本音が聞ける

どんなときに使えるか
・(サービスやプロダクトの)スペックの判断材料
・改善の糸口の発見、改善後のベネフィットの把握

gridmethod111103.png

これだけ聞くとマーケティング的な側面しか見えずらいのだけど、調べていくとこれがメンタルモデル・アプローチ(この言葉すごくしっくりきた!)におけるユーザ側のモデルの一種だと考えると、以前演習したペルソナ/シナリオ法の3つのモデル(フロー、文化、シーケンス)と並ぶペルソナづくりの素材にもなると感じた。
KA 法は価値項目の抽出が効果的にできる反面ユーザ像が若干希薄になる感じがするのだけど、評価グリッドはその人自身の価値観のモデルが浮き出てくる感じ。

mentalmodel111103.png

どういうふうにやる?
・半構造化インタビュー(用語難し杉)
 事前に大まかな質問事項を決めておき、
 回答者の答えによってさらに詳細にたずねて行く簡易な質的調査法
・比較対象物を用意してそれらを被験者に比較評価してもらい、その評価理由を聞き出す
・ラダリング技法
 上位概念(how、どのように好ましいか?)・下位概念(what、好ましくあるための条件とは?)の抽出


演習

・この手法を理解しよう
・プログラム上の共通課題「旅支度」
というところから(だと思う)、既に調査済みの4人分の旅支度に関するコンテキストインタビューメモの項目を比較対象物として、3人1組で「interviewer」「interviewee」「recorder」役をそれぞれ実習。調査した結果は9人組になって1つの構造図にした。

インタビュー実施
1つ1つの行動についてのラダリングはまあなんとかできて、横方向の構造化?はできた。
inteviewer と recorder が別なので「あ、いまラダーアップしたつもり」なんだけどラダーダウン方向に記録されたりすることはあったけど、あとでみんなでレビューしたときにそれぞれの意見を出し合って修正できたから問題なし。
あと、これは復習しているときに見つけた blog に書かれていて「うん、たしかに」と思ったことなのだけど、その場で3人が記録されたグリッドを見ながらやるとラダーの方向が整地されるのと interviewee に内観的なことが起って答えも整地されるので「グリッドを共有しながらインタビューする」というのはいいですな。

難しかったのは比較素材がサービスやプロダクトといった具体的なものではなくて、インタビューのメモだったということ。そこから「比較対象を決定する」ことがつまずきどころ。

Q:No1さんとNo2さんの「持っていくアイテム」について、どちらが好ましく思いますか?(一対比較になるのかな?)

みたいに始められると、ラダリングっぽさ?がでてよかったのかもしれない。
(けど、両方の人に書いてあって比較できる共通項目を探すのが大変)
interviewee 自身の考えと No1さんの考えを比較するだと(単独評価になる?)、どうしても「比較してどう思う」というより「私はこう思う」にながれがなってしまってラダリングからはみでる感じがした。

どこかのサイトでインタビューの始めに比較する商品について好ましい順に並べてもらうという手法が紹介されていたが、全体のヒエラルキーを作ってもらうことで interviewee 自身で複数あるであろう価値の視点をある程度見切ってヒエラルキー化するので、それも構造化してあげればそこからもその人の価値のプライオリティが分かっていいと思ったけど、見切るのにそれなりに内観する必要があるだろうし、見切りが適切に行われるかどうかは微妙な気もするから、このあたりは気にして取り入れるべきだと思った。

統合
横構造のみにフォーカスしていたのが功を奏して2項目については統合することができた。が、それ以外はラダリングの開始地点がばらばらすぎて統合できず。ちなみに統合すると班になった9人から抽出された価値観をもったペルソナができる?と考えていいのだろうか。

全体的には
自分が演習の時点で評価グリッド法の優位点を見いだせなかったのは手法の理解不足につきる。それと最終的な目標がやってるうちに手法の習得になってしまって、なんのためにやっているのかとか、最終的にはなにが出来上がるのかを理解できていなかったところにあるのかな。
演習の最後の講評会で質問とか意見が、このあたりのもやもやはどうやらみんな同じだったぽい...?


統合についてのさらなる疑問

重複してでてくる着目点については重なった数を記すなどして重みをつけないと統合の意味がない気がした。複数の評価グリッドを統合する際の正しいオペレーションがあれば知りたいところだ。
というわけで復習したつもりが、違うモヤモヤを増やす結果になったのでした... orz


11/10追記:霧が晴れて来た

上のほうにあった図は、複数人のモデルを統合して一人のモデルにするイメージで作ったのだけれども、エントリ後に山口先生からいただいたコメント----

「基本的に評価グリッド法の使い方は、ユーザ全体の評価構造を抽出して俯瞰し分析するためのものです」

「(統合では)定量的に扱う意味でも、重なった評価ワードの人数や、関係線の人数、価値観の系統のネーミングなどを行います」

「数十人分の評価グリッドを統合することで一覧しやすくなりますし、抜け漏れの評価項目が少ない構造MAPができあがり、それを手掛かりに設計につなげることができます」

から理解をし直すと、数人分を代表する一人のモデルを作るというよりは、数人分の価値マップとして統計データ的に利用するほうがこの技法の使用方法としてはふさわしいようです。先生ありがとうございます!


参考になった記事

[AIIT]ユーザモデリングワークショップ

「ペルソナ/シナリオ法」の授業でのユーザの行動モデリングのワークショップ。
6人ぐらいのチームに別れて(自分は赤組)、分担を決めてユーザ2人分の行動モデル分析を行いました。

自分も含め要領を得ないので分担の仕方も微妙な感じに、とりあえず最初は Aさんのフローモデルを作成開始。
共同作業者と情報を共有/すりあわせしながら、ひとりが用紙にプロットしていく感じ。
けど、みんな読むスピードや読解力が違うので、自分は全然ペースが掴めず若干置いてけぼりに。>本当にすいません...

そして、分担を変えて今度はBさんのシーケンスモデルを開始。
こちらはパラグラフにわけて分担をしたので、自分の担当部分に関しては集中して理解できてよかった。
その集合知になるシーケンスモデル全体も(たぶん)うまい感じになっていると思う。
反面、自分の担当外のパラグラフの理解についてはほとんど頭に入ってなかった。

そのあと、チーム内でできあがったモデルをみんなで共有/レビュー。
メンバーそれぞれが意見を出しながらになるので、自分の性格的に意見を理解するのに手一杯でモデルそのもののレビューができないと途中で気がついて、自分でざっくりBさんのフローモデルをつくってみたりとかしていたのだけど、見合わせるとこまではいかずにタイムアップ。
みなさん頭の回転よ杉で、ちゃんとチェックしたりしていてちょっとショック。

今度はそのモデルをもとにユーザ要求を抽出していきます。
ここでついやってしまったのが、解決策やアイディアを考えながら抽出を行ってしまったこと。
自分も含めアイディアについてのほうに話題がいってしまって、機械的に抽出作業ができなかったのは反省材料かなと思う。
つか、抽出の途中でアイディアとか頭に浮かんでしまうのはどうしようもない気がするので、
それを心に留めておくとかするほうが心得的にはあっているのかも。

そんなこんなで、モデリング作業ができましたが、自分的にはフローモデルのところがすっごく出来なかった気がしたので、レビュー中に途中まで書いてあったBさんで復習してみることにしました。

授業でやってみて、最終的なモデルにまとめるのにかなりの書き直しが必要だなとわかっていたので、普段業務でワイヤフレームを作るときに使っている OmniGraffle を使いながら進めることにしました。
手書きで書いたものをベースに配置を最適化しながら、どんどんプロットしていきます。

途中まで来て、疑問に思ったのは「どこに行った」とか「どうやって移動した(電車に乗った)」とかをどうプロットするかということでした。
そこまでの作業ではほとんどが「情報のやりとり」に関するフローだったのだけど、旅の実施のセンテンスでは「実際の旅行行動」に関するフローがでてきたのです。
で、判断としては「情報のやりとり」をメインにしてプロットすることにしました。この判断が正しいかどうかはわからないのですが。

flowmodel_b.png
そんなわけで、出来上がったのが上の図になります(PDF版)。
わかりやすさを向上させるための工夫としては、
・「情報の要求」を青、「情報の提供」をオレンジ、「依頼」を緑色に色分け
・やりとりの矢印を「要求」「提供」で1セットになんとなくまとめる
といったところでしょうか。

ここまでやるのに約3.5時間ほど。疲れましたー。