ユーザビリティメモ

usabilityMemo.txt

ユーザビリティメモ
===============================


------------------------
[1]ユーザビリティ設計
------------------------

ユーザビリティ、UI設計に関するポイント

[1-1]UIの難しさ

UI作成が大変である理由

対話的設計 
　実装/評価が何度も繰り返されることが望ましい 
グラフィック設計 
　使い易い配置の決定には試行錯誤が必要 
非同期入出力のサポート 
　常にユーザ入力を受け付ける 
　複数入出力のサポート 
制御構造 
　アプリケーション部とインタフェース部の交錯 
　プログラムの状態遷移が複雑 
並列処理 
　インタフェース部品の独立動作 
　アプリケーション部とインタフェース部の分離 
実行効率 
　高速描画/検索/etc. 
エラーへの対応 
　ユーザに責任を転嫁しないための工夫が必要 
　　× 「エラー: ファイルを保存できません」 
　　○ ファイル名を変えてみる/要らないファイルを消す
　　　　/理由を解析する/... 
例外処理 
　時間切れ、資源不足、etc. に対応しなければならない 
Undo 
特殊な要素技術 
　音声認識 
　ジェスチャー認識 


[1-2]ダメなUI設計

プロジェクト開始当初は、設計チームは時間もエネルギーも十分に持っています。
より優れたユーザ体験を提供するために、メンバーは新しい機能や
インターフェイスの改善案について様々なアイデアを出し合います。
ところが、どんなに素晴らしいアイデアが出されても、設計チームの誰かが、
たった１人の「反対する」ユーザ像を思い付いてしまうと、そのアイデアはお蔵入りです。
時が経つとともに、創造的な情熱は感情的な泥仕合の様相を呈してきます。

このような不毛な議論を続けているうちに、設計チームには危機が訪れます。
「納期」が迫ってくるのです。そうすると、今度は"声の大きい"メンバーが主導して、
今のインターフェイスでも"なんとか"使ってくれそうなユーザ像を作り上げます。
崖っぷちに立たされ、また不毛な議論に辟易していた他のメンバーには、もはや反論の気力はありません。
それまで自分が主張してきたユーザの形を少し変えて、その案に賛成します。
このようにして、使用不可能なインターフェイスは生み出されるのです


[1-3]メニューの“広さ”と“深さ”

○メニューの“広さ”と“深さ”

「広くて浅いメニュー」とは１画面当たりの選択肢の数が多く、
その代わり階層は少ないメニュー構造のことです。
一方、「狭くて深いメニュー」とは、１画面当たりの選択肢の数が少なく、
その代わり階層が多いメニュー構造のことです。

同じ数のコンテンツを分類する場合、
この“広さ”と“深さ”はトレードオフの関係にあるので、
ウェブサイトやＯＡ機器のメニュー画面を設計するデザイナは頭を悩ませることになります。

人間の短期記憶の制約である「マジックナンバー７±２」を根拠として、
１画面当たりのメニュー数は５つから９つが適切だと主張する人もいます。
しかし、ユーザはメニューを記憶する訳ではないので、これは妥当なガイドラインとは言えません。

多くの研究者がこの問題に関する実験を行っており、
その結果、情報探索型ウェブサイトに関してはいちおう答えが出ています。
狭くて深いメニューよりも広くて浅いメニューの方が優れているのです。
ただし、それは単純なメニューの数の問題ではありませんでした。

少し古い研究（1998年）ですが、マイクロソフトリサーチの２人の研究者が、
とても優れた論文を発表していますので、その要旨をご紹介したいと思います。

◆Web Page Design: Implications of Memory, Structure and Scent for Information Retrieval
http://research.microsoft.com/users/marycz/chi981.htm

○実験の概要
  被験者数は19名。 
  コンテンツはエンカルタ（百科事典）から引用した。 
  512個のコンテンツを3種類のメニュー構造（8*8*8｜16*32｜32*16）
   に分類したテストサイトを作成した。 
  テストに先立ち、視覚探索力と記憶力を測定するプリテストを実施した。 
  その後、各被験者は3種類のサイトでそれぞれ8回の情報探索を行った。（一人当たり合計24回） 
  各被験者のページ遷移とタスク達成時間を測定し、
   テスト終了後、主観的評価質問（順位付けと５段階評価）を行った。 

○主な結果
  タスク達成時間は16*32が最も速かった。 
   8*8*8:58秒｜32*16:46秒｜16*32:36秒 
  ユーザの混乱度合い（Lostness Score）は16*32が最も低かった。 
   8*8*8:0.63｜32*16:0.49｜16*32:0.38 
  主観的評価（順位付け）では、32*16が一番好まれた。（下記参照） 

  ＜主観的評価＞
          8*8*8 32*16 16*32 
  Best        6      11       2 
  2nd         2        3     14 
  Worst     11       5       3 

結果を総合すると、２階層のメニュー（32*16と16*32）は
３階層のメニュー（8*8*8）よりも優れていたと言えます。
つまり、広くて浅いメニューの方が優れていると言えます。
そして、２階層のメニュー構造の中では、
32*16よりも16*32の方が優れていました。（ただし、主観的評価では32*16が一番。）

○なぜ、広くて浅いメニューの方が優れているのか？
この実験では、テスト本番前に視覚探索力と記憶力を測定するプリテストを実施しています。
研究者たちは、このプリテストと上記テスト結果を組み合わせることで、興味深い考察を行っています。

研究者たちは「相関関係」に注目しています。
普通に考えれば、視覚探索力や記憶力が高い被験者の方が、
タスク達成時間は短い“はず”です。相関係数を算出すれば“マイナス”になるはずなのです。

確かに、32*16と16*32のメニュー構造の場合は、
視覚探索力と記憶力の相関係数はどちらもマイナスでした。
つまり、視覚探索力や記憶力の高い被験者の方が、早くタスクを完了したのです。

ところが、8*8*8のメニュー構造の場合は、記憶力の相関係数はほとんどゼロ（r=0.02）、
つまり記憶力はタスク達成時間に影響を与えていないという結果だったのです。
さらに、視覚探索力の相関係数は“プラス”でした。
視覚探索力が高い被験者の方が、タスク達成に時間がかかっているという、
ちょっと常識外れとも言える結果です。

研究者たちは、１画面当たりのメニューが８個程度ならば、記憶の負荷は小さいので、
記憶力に関わらず同じようなタスク達成時間になったのではないかと考察しています。

また、多くのコンテンツを少ないメニューに分類しようとすると、
“直接的”なカテゴリ名ではなく、“一般的”なカテゴリ名を使うことになってしまいます。
そのような分かりづらいカテゴリ名から内容を想起するという作業は、
ユーザの認知的負担が大きいのです。
頭をひねるよりも、少しくらい数が多くても、斜め読みして選択する方が効率的です。

そのため、8*8*8では、たとえ視覚探索力が高くても、カテゴリの内容を考え込んでしまうと、
タスク達成に時間がかかるのではないかと推測されます。
32*16や16*32ならば、メニューを流し読みするだけなので、視覚探索力が高ければタスク達成も早いのです。

このように、8*8*8のような狭くて深いメニューでは、
視覚探索力や記憶力といったユーザの能力を十分に生かし切れていないのです。

さらに情報探索には、メニューや階層の“数”だけでなく、
カテゴリ名から内容を想起するための“情報の匂い”が大きな影響を与えています。
広くて浅いメニューでは、内容を直接的に表すカテゴリ名ラベルを付けやすいので、
総合的には早く情報に到達できるのです。

○私たちが学ぶべきこと
この論文のタイトルは
『ウェブページ設計：情報検索のための、記憶と構造と匂いの関わり合い』というものです。

研究者たちは、ウェブサイト構築におけるガイドラインとなるような
メニューと階層の数を明らかにしようと実験を行いましたが、
導き出された結論は「最適なメニュー数はn個である」という単純なものではありませんでした。
論文のタイトルが示すように、最適な情報構造の背後には、ユーザの認知的能力、
メニュー数と階層、そして“情報の匂い”といった要素が複雑に絡み合っていたのです。

このように、ユーザインターフェイス設計では、１つ１つの要素の最適化ではなく、
全体的な最適化が重要です。そして、私たちが考慮すべき要素には、
ガイドラインや基準値を設定できる簡単なものだけでなく、
“情報の匂い”といった評価の難しいものも含まれているのです。




[1-4]ユーザレベル

ユーザレベルと機能　：　ヒューマンコンピュータインタラクションより

ユーザレベル  使用形態   要求      必要機能
----------------------------------------------------
初級者           選択         教育      オンラインチュートリアル
中級者           限定機能   支援      オンラインヘルプ
上級者           多機能性   高速性   ショートカット

○初心者
システムに対する知識も行うべきタスクに関する知識も無い
システムに対する教育が重要
ユーザの慣れ親しんだ言葉で説明する必要
ユーザには対話における積極性を期待しない
エラーが発生したことだけでなく対処法も表示

○中級者
概念は理解しているが、具体的な操作方法を忘れていることもある
まだ使用していない機能もある
機能を思い出させることや機能の詳細を示す
効率的に使うには操作手順や用語が覚えやすく、一貫性があり
ほかの機能についても類推できるような仕組みがいる
システムを使いこなすようにするにはエラー処理に
ユーザがいろいろいじっても大丈夫なように耐久性が必要となる

○上級者
上級者はシステムを熟知している
機能に対する高速なアクセス手段とすばやいシステムからの応答が必要
入力は最小限でメッセージも簡素にしてユーザがタスクに集中できるようにする


ユーザーレベルで大事なことは同じ人間でもレベルが変化すること
多くのユーザは中級者であり、そこに重点を置いたデザイン
ただし誰もが最初は初心者であり、初心者向けの機能はセットされているが
容易にはずせることが望ましい


[1-5]GUIの課題

GUIの問題点

メタファやメニューを多用することによってユーザの操作が煩雑になる

GUIはコンピュータのすべての情報を可視にして、操作の結果も直ちに視覚的にフィードバックするのが理念である
しかしこれではすべての情報を視覚化しようとしたために、かえって自分のやりたい機能がいったいどこにあるのか、
どこのメニューの階層をどこまでたどればよいのか非常にわかりにくくなってしまった

コマンドラインの場合はスペルを覚えていれば確実に命令を実行することができたがGUIの場合は
メニューをたどる順番やボタンを押す順番を覚えておかなければならない
このような手順は複雑になった場合、正確に暗記することはスペルよりも難しい

この問題を緩和する策としてショートカットキーの利用などユーザの記憶を活用する方法がある
しかしショートカットキーの組み合わせは限られているため、
キー操作とそれによる処理の連想性が低くなりがちでユーザがおぼえて利用するのは難しい



[1-6]設計原則


[1-6-1]GUI 10ヶ条

０１　：　単純で自然なダイアログ 
０２　：　ユーザの立場の言葉を使う 
０３　：　覚えなければならないことを最小に 
０４　：　首尾一貫 
０５　：　実時間フィードバック 
０６　：　簡単に抜けられるように 
０７　：　ショートカット 
０８　：　わかりやすいエラーメッセージ 
０９　：　エラーが発生しにくいように 
１０　：　ヘルプ/ドキュメント 



[1-6-2]デザインの一般原則

デザインの一般原則　：　ドナルド・ノーマン

○可視性
    目で見えるようにすることにより、システムの現在の状態や行うことができる操作を示すことができる

○よい概念モデル
    操作と操作結果がうまく対応付けられるような概念モデルを提供する

○自然な対応付け
    目で見えることとシステムの状態に自然な対応付けができる

○フィードバック
    操作結果として何がおきたかを完全に理解することができる


[1-6-3]対話型システムの設計原則

シュナイダーマンの対話設計における8つの黄金律

１：一貫性
    一貫した操作手段、同一用語の使用、コマンド形式の統一など類似した状況に対して常に同じ対応が取れるようにする

２：ショートカットの用意
    上級者のための省略形、特殊キー、マクロ機能などのショートカットを用意し対話の回数や入力の数を少なくし、
    メッセージをスキップすることで応答時間の短縮や表示速度を向上させる

３：フィードバックの提供
    すべての操作結果に対して状況変化を提示する必要があるが、実行頻度と実行の影響度により応答の情報量を変化させることが望ましい

４：達成感を与える対話の実現
    操作をやり遂げた満足感、安心感を与えることは新たな行動への推進力となる

５：簡単なエラーの処理
    システムによる早期のエラー検出を行い、単純でわかりやすいエラー回復方法を提供する
    そして回復が不可能となるような致命的なエラーは起きないようにする

６：逆操作
    可能な限り操作を可逆にすることにより、エラー回復が容易になると同時に安心感が提供され、ユーザの試行錯誤が容易となる

７：主体的な制御権の提供
    ユーザを応答者としてではなく主体的な操作者として取り扱う
    ユーザを不安や不機嫌にするような応答や要求をしてはならない

８：短期記憶の負担の減少
    短期記憶には限りがあるので、その容量に見合うように表示法を工夫する

[1-6-4]ISO対話型システム設計原則

ISOの規定した対話型システムの設計原則　ISO13407

１：業務への適合
    業務を効果的、効率的に行えるようにユーザを支援する

２：状態の通知
    ユーザが常にシステムの状態を理解できるように、システムからのフィードバックやユーザの要求に基づいた情報提示を対話の各段階で行う

３：主体的な制御性
    ユーザが主体となって対話を進められるようにする

４：期待通りの操作
    ユーザの持つ業務に関する知識や経験、受けた教育、一般慣習に従って動作する

５：エラーの許容
    エラーに対して最小限の修正で意図した結果が得られる

６：個人への適合性
    タスクに対する個別の要求や個人のスキルは異なるので、それに柔軟に対応できるようにシステムを構成する

７：学習の支援
    オンラインチュートリアルやヘルプなどを提供することにより、学習段階のユーザを支援する


[1-6-5]ISO9241-11

国際規格のISO 9241-11では、ユーザビリティを
「特定の利用状況において、特定の利用者によって、
ある製品が、指定された目標を達成するために用いられる際の、
有効さ、効率、利用者の満足度の度合い」
と定義している

[1-7]情報の匂い

情報採餌理論のいちばん有名な概念は情報嗅覚である。
ユーザは狙った獲物の成功率を匂いで予想するのだ。
欲しい結果に関係する手がかりが、その道筋にあるかどうかを判断するのである。
情報消費者（informavore）は、（メタファーを組み合わせていうなら）匂いが「新しく」なっているうちは、
クリックし続ける。匂いはどんどん強くならなくてはいけない。
そうでないと、みんなあきらめてしまうだろう。
目的に達するまでに必要な労力の予測に見合う程度に進展は速くなければならない。 

情報嗅覚から得られるデザインの教訓のうち、もっとも明らかなことは、
リンクとカテゴリーの記述を明確にして、行った先にあるものが何か確実にわかるようにしておくことである。
ナビゲーションの選択肢がいくつかある場合、獲物への道筋がはっきりわかるようにし、
その他の道には食べ物がないことが見て取れるようにしておくのがベストである。 

造語は使わないこと。また、自社のスローガンをナビゲーションの選択肢にすることも避けよう。
いずれも狙ったアイテムの匂いがしないからである。
第二に、ユーザがサイト内を深堀りするにしたがって、各ページにそれが食物への道程であることをはっきりと示しておこう。
言い換えると、現在位置およびそれがユーザのタスクにどう関係するものなのかをフィードバックすることである。 

[1-8]ユーザ体験の点と線

ユーザインターフェイスを改善するときに、
従来のマーケティング的アプローチを使おうとする人が少なくありません。
アンケートやインタビューを実施して、ユーザに
「あなたがインターフェイスを使っていて、最も不満だと思った点をお知らせください。」
と質問するのです。

もちろん、このアプローチでも問題点は見つかります。
リサーチャの意図した通り“重大な障害”が発見できます。
十分な人数を調査すれば、インターフェイス上の重大な障害を、
ほとんど全部見つけ出すこともできるかもしれません。

しかし、それらの重大な障害を取り除いたとしても、
ユーザの不満はあまり改善しません。
なぜなら、まだ「重要な経路」に中程度の障害がたくさん残っているからです。


○ユーザテストのススメ
ユーザインターフェイスの役割は、ユーザをゴールに導くことです。
ユーザの目的は様々なので、ウェブサイトや製品には多様な経路が組み込まれています。
ただ、その経路は必ず１本の線になります。
分岐したりループしたりすることはあっても、途中が途切れているということはあり得ません。

もし、経路上に１カ所でも通過出来ない箇所や、通過しづらい箇所があれば、
ユーザはゴールに到達できなかったり、不愉快な思いをすることになります。
全体的な問題点を取り除いたとしても、ユーザが通る経路上に問題が残っている限り、
ユーザ体験はあまり改善されません。

つまり、ユーザインターフェイス設計では重大な障害を取り除くよりも、
重要な経路上の問題を全て取り除くようなアプローチが必要なのです。

その最も有効な手法はユーザテストです。
ユーザテストでは、ユーザに重要な経路を通過するようなタスクを提示して、
ユーザがゴールに到達するまでの全ての行動や発話を観察して、
その経路上の問題点を詳細に把握できます。
わずか5人のテストでも、経路上の問題点の大半を見つけることができます。

ところで、リサーチ経験のある人ならば、もっと質問を工夫すれば、
アンケートやインタビューでも重要な経路上の問題点を発見できるのではないか
と考えるかもしれません。
例えば「あなたが重要だと思う経路上で経験した全ての問題点をお知らせください。」と質問するのです。

残念ながら、この調査は上手く行きません。
ユーザは専門家ではないので、自分が“どの”箇所で、
“なぜ”失敗したのかを正確には分析できないからです。
どんなにひどいインターフェイスであっても、
ユーザは「何となく腹立たしい」という思いを持っているだけです。

そもそもユーザはインターフェイスに、あまり興味を持っていません。
インターフェイスは目的ではなく手段に過ぎません。
極論すれば、煩わしい思いをせずにゴールに到達できる限り、
どんなインターフェイスでも構わないのです。
ですから、操作ステップを１つずつ記憶しているような暇なユーザは滅多にいません。


[1-9]機能とワクワクと色気

ワクワクに投資する
http://mamico.way-nifty.com/note/2004/06/post_18.html

パソコン始めたいんですけど。
と、いらっしゃる。

「目的は？」と聞く。（本当はもっとやさしく聞いていますよ）
「え、何ができるかわからないのに、目的も何もわからないわよ」と答える人がいる。
「インターネットがしたいの」　
よくよくきくと「いんたーねっと」がしたいだけで、何ができるかわかっていない。

最近パソコンを買ったのよ、と聞くと、かなり良い機種。

「いい機種ですねぇ」
「だって、あとであれもできない、これもできないじゃ嫌じゃない。本当は使わないとは思うんだけど。」

何ができるかなんて、よく解っていない。
でも、皆が使っているんだから、何かできるんだろうし、インターネットはできるだろう。
インターネットをするために、パソコンを買う。
お店に行ったらテレビも見られると聞いた。
ならば、インターネットのために25万円の商品を買うのではなく、
テレビも見れるかもしれないと言う可能性にお金を払う。
何かできるかもしれない、ワクワクのための投資。

デジタルカメラを買ってくる人が多い。
「簡単なのでいいのよ」「使いこなせないと思うし」「撮るだけだし」

といって、本当に簡単なのを買ってきた人を見たことがない。
（まぁ、デジタルカメラはどれも難しいけど）

「安物買いの銭失いじゃ困るでしょ」

「○○だけでいいのよ」を信じちゃいけない。
なぜって？
色々機能がついていないと「安物を買ってしまった」ように思われるから。
というのも一理有。
でも、「今までとは違う生活」というワクワク感にお金を払う。

毎年デジタルカメラを買い換えている人がいる。
別に、本人も使いこなせているわけではない。と、認識している。
でも、新しいものを使ってみたいのだ。ワクワク、なのだ。

単機能の「安心だフォン」にはワクワクがなかった。
私たちは、それを色気と呼ぶのだが、色気がない。
色気なんですよ。キーワードは。


[1-10]ユーザビリティの３大要素

ユーザビリティの３大要素
「良い薬」とユーザビリティには共通点があります。

まず、「良い薬」は良く効きます。
熱を下げたり、腹痛を抑えたり、症状を大きく改善してくれます。

また、少ない量で効きます。
１日何度も大量に服用しなければならない薬よりも、１日１回１錠で効くほうが「良い薬」です。

さらに、同じ効き目ならばなるべく服用しやすいほうが「良い薬」です。
注射薬よりも経口薬の方が、苦いよりは甘い方が、粉末よりは錠剤の方が「良い薬」です。

ユーザブルなインターフェイスは「良い薬」と同じように、ユーザの目標達成を、
確実に、なるべくスムーズに、なるべく嫌な思いをしないようサポートしてくれます。


ユーザビリティ３要素
ISO9241という国際規格の中では、ユーザビリティが“定義”されています。

『特定のコンテキストにおいて、特定のユーザによって、
ある製品が、特定の目標を達成するために用いられる際の、効果、効率、ユーザの満足度の度合い』
＜ISO9041 Part11より引用・翻訳＞
「効果」とは、ユーザが正確に目標を達成できるかどうかです。
例えば、あるオンライン書店でヤコブ・ニールセンの「ウェブユーザビリティ」という書籍を購入できることです。
ユーザが本を見つけられなかったり、購入プロセスを完了できなかったり、
類似の商品を間違えて購入してしまった場合、そのサイトには効果問題があることになります。
これは深刻な問題です。“効かない薬”など、誰が飲むでしょうか？

「効率」とは、ユーザが無駄な手順を踏まず、なるべく最短経路で目標を達成できるかどうかです。
オンライン書店でショッピングカートの操作に手間取って、何度もやり直してやっと購入できたとすれば、
そのサイトには効率問題があることになります。
効率問題には、ユーザをちょっと戸惑わせる程度のものから、頭を抱えさせてしまうものまであります。
なお、深刻な効率問題は、事実上の効果問題になります。
ユーザがタスク完了を諦めてしまうからです。

「満足度」とは、ユーザに不愉快な思いをさせていないかどうかです。
例えば、会員登録時にプライベートな情報を無闇に要求したり、
一方的な内容の使用規約の許諾を求めたりすると、ユーザは不満を表明します。
デザインの好き嫌いなどの“主観的評価”も含まれます。
満足度問題も程度によっては深刻な結果を招きます。
あまりユーザを怒らせると、二度と使ってくれません。

ISO9241の定義に従えば、これらユーザビリティ３要素を全て満たして、
初めてそのインターフェイスはユーザブルであると言えることになります。
しかし、それは容易なことではありません。
もし、全てのユーザを主観的に満足させることを目的とするならば、プロジェクトは永遠に終わらないかもしれません。

そこで、実際にはまず効果問題を優先して解決するようにします。
つまり“効き目”を保証するのです。
後は時間やコストの制限の中で、問題の深刻さを考慮しながら、
なるべく多くの効率問題や満足度問題を解決するというのが現実的なアプローチです。



[1-11]配置関係

人間が図形を認知するときには、個々の要素の総和以上の意味のある、まとまった構造を捉えようとする。
これをゲシュタルトの法則といい、近接要因、類同要因、閉合要因などの
図形をまとめるいくつかのゲシュタルト要因が考えられている。
これに関係して2つ以上の図園は位置関係から人間は次のような意味を読み取る

一列並び：順序、流れ
対象配置：対比
枝分れ型：分岐、系統
包含型：従属
円環型：巡回
階層型：階層
交差接触：何らかの関係

等々

[1-12]ユーザインターフェイスの目利き

ユーザインターフェイスの目利き
「開運！ なんでも鑑定団」というテレビ東京の人気番組があります。
骨董品や古美術品などの専門家（鑑定士）が登場して、
視聴者が持ち込んだ“お宝”の価値を評価します。
鑑定士は、その豊富な経験と知識を駆使して、素人にはさっぱり見分けが付かない、
年代や作者の違いなどを見事に見分けて評価額を決定していきます。

骨董品だけでなく、ユーザインターフェイスもそれなりの“鑑定士”の手に掛かれば、
その善し悪しを明らかにできるのでしょうか？

○分析的手法とは
以前のエントリーで、ユーザビリティ評価について「総括的評価と形成的評価」
という区分があることをご紹介しましたが、実は、もう１つ区分方法があります。
それは「実験的手法（empirical method）」と「分析的手法（analytic method）」です。

実験的手法とは、文字通り、ユーザを使って“実験”を行います。
代表的な手法は「ユーザテスト」です。その他、アンケート調査なども実験的手法に含まれます。

分析的手法は、別名「専門家による評価（expert review）」とも呼ばれており、
ユーザビリティエンジニアやユーザインターフェイスデザイナが自らの知識や経験に基づいて評価します。
つまり、インターフェイスを“目利き”が“鑑定”するのです。
ニールセン博士が提唱する「ヒューリスティック評価法」は、分析的手法の代表です。（※参考１）

○分析的手法の長所・短所
総括的評価と形成的評価を比較した場合、形成的評価の方が重要度が高いと言えます。
しかし、分析的手法と実験的手法の場合は、どちらかに軍配を上げることは適切ではありません。

例えば、仕様書や画面遷移図しか用意できていないような設計プロセスの初期には、
そもそも実験的手法を適用することは不可能です。
ユーザに仕様書を見せても評価結果を得ることはできないので、
ユーザビリティエンジニアなどの専門家による評価しか選択肢はありません。

また、ユーザテストを設計する際には、まず分析的な評価を行って、
テストで検証すべき問題点や、重点的に観察するポイントを事前に把握するのが普通です。
拙速に設計されたテストからは、十分な成果は得られません。

さらに、一般的に言って、分析的手法は費用や時間が少なくて済むという利点があります。
ユーザに会場に来てもらって１～２時間テストに協力してもらうとすれば、当然、交通費や謝礼などが必要になります。
それに「明日来てください」という訳にはいきませんから、テストの準備から終了までには、
それなりの日数（通常２週間以上）がかかります。
一方、分析的手法ならば、評価者の時間と体力が許すのであれば“今日中”にでも評価結果を出せるかもしれません。

このように、分析的手法は、様々な制約の下でプロジェクトを推進している
設計チームにとって非常に重要なツールであると言えます。
そのため、ヒューリスティック評価法以外にも、認知的ウォークスルーやクレーム分析などの
体系的な評価手法や、様々なユーザビリティ・ガイドラインなどが開発されてきました。

しかし、分析的手法には大きな“弱点”があります。
それは、分析的手法による評価結果は、その評価者個人による仮説や議論に過ぎないということです。
評価者が異なると、指摘する問題箇所やその論拠も異なることは少なくありません。

そのため、ユーザビリティエンジニアが出した評価結果にデザイナは反論しがちです。
そんな時、分析的手法はデータに基づいた評価ではないので“証拠”を示すことができず、
意見が分かれたままになってしまうことがあります。
問題点を具体的に特定できなければ、解決策を検討することができません。

もちろん、複数の評価者で評価を行えば、精度と説得力を多少向上させることはできますが、
それでも設計チーム全員を納得させるのは難しいでしょう。
“不毛な議論”に終止符を打つためには、やはりユーザテストなどの実験的手法の導入が不可欠です。

○２つで１つ
ユーザインターフェイスの設計において、実験的手法と分析的手法は補完関係にあります。
全てを実験で検証しようとすれば、そのプロジェクトは予算と納期を大幅に超過して失敗に終わるでしょう。
一方、分析的手法だけに依存していると、設計チームは延々と議論を続けてしまい、
最後にはイデオロギー的な対立を引き起こす危険さえあります。

分析的手法による評価結果は、議論のスタート地点だと考えるべきです。
設計チームは評価結果を受け入れなくても構いません。
ただし、デザイナは自分の設計意図や根拠を改めて明らかにして、論理的に議論すべきです。
そういった議論を重ねれば、見解の相違の多くは解消できます。
そして、実際のユーザで検証しなければいけない論点を絞り込めます。
そのうえでユーザテストを実施すれば、設計チームはテストで明らかになった問題点の解決に集中できます。

このように、優れたユーザインターフェイス設計とは、決して“鑑定士”頼みでもなければ、テスト一辺倒でもないのです。

【参考情報】
（１）U-site: ユーザビリティ評価手法
http://www.usability.gr.jp/whatis/evaluation_method.html
ヒューリスティック評価法の概要が解説されています。

[1-13]『ユーザテストは5人で十分』の真偽

『ユーザテストは5人で十分』の真偽

ヤコブ・ニールセン博士は1993年に『5人のユーザでテストすれば、
ユーザビリティ問題の85%が発見できる』という公式を発表しました。
それまでの大規模な実験を前提としたアカデミックなユーザビリティに対して、
費用対効果に優れた実践的なユーザビリティが普及するきっかけとなりました。（※参考１）

私が被験者10名のユーザテストのデータを使ってこの公式を検証したところ、
理論値と実績値はほぼ一致しました。
また、ユーザテストでは1人目から3人目くらいまでは新たな問題点の発見が続きますが、
4人目以降では新たな発見は少なくなってくるという経験は、
ユーザビリティエンジニアならば日常的にしていることでしょう。

ニールセン博士の説に対する反論（※参考２）もありますが、
現実的には5人か6人のユーザでテストすることは業界標準になっています。

○ニールセンの公式の盲点
では、5人のユーザでテストして、発見された問題点を全て解決すれば、
そのインターフェイスは「85点」であると言えるのでしょうか？

ニールセン博士の公式は以下のとおりです。

n人のユーザをテストしてわかるユーザビリティ問題の数　=　N(1-(1-L)^n) 
N:デザイン上のユーザビリティ問題の数（潜在的なものも含むので架空の値） 
L:一人のユーザをテストして発見できるユーザビリティ問題が全体に占める割合
　（ニールセン博士は経験値として0.31を提示） 
n:テストするユーザ数 

この公式にL=0.31、n=5を代入すると右辺は「0.8436N」となります。
仮に100個のユーザビリティ問題が潜在的に含まれているデザインならば、
5人でテストして「84.36個=約85個」の問題点が発見できると期待されます。

既にお気付きと思いますが、この公式は「問題点の数」を算出しています。
85個の問題点の中には、ユーザのタスク達成を困難にしてしまうような“深刻な問題”もあれば、
ユーザに多少の不満を感じさせるだけの“軽微な問題”もあるはずですが、
この公式は「問題点の質」については何ら言及していないのです。

ところで、20問で100点満点のテストがあったとして、
「85点」を取るためには何問正解すればよいでしょうか？　
20問の配点がすべて同じ（5点ずつ）ならば、17問正解すれば85点になります。
しかし各問の配点が異なれば、何問正解すれば85点になるとは一概に言えなくなります。
最後の1問に50点配点するという極端な例もありえるのです。

さらに、公式の「1-(1-L)^n」の部分は絶対に1（=100%）にはなりません。
どんなにテストを繰り返しても、全てのユーザビリティ問題を発見することはできないのです。
そして、発見できなかった問題点が「ショーストッパー（深刻な問題）」である可能性は否定できません。

つまり、5人のユーザでテストして、発見した問題点を全て解決したとしても、
そのインターフェイスは残念ながら「0点」かもしれないのです。

○ユーザテストは無意味なのか？
ソフトウェアの開発において、バグは決して無くならないことが知られています。
そこで開発者はテスト工程におけるバグ摘出数のグラフ（バグ曲線）を作成して、
累積数が収束してくれば、そのソフトウェアの品質が安定してきたと判断します。

現代のインタラクティブなシステムのユーザインターフェイス設計は、
ソフトウェア開発に負けないくらい複雑です。
ユーザビリティ問題（バグ）を完全に無くすことが不可能であっても、
テストは必要であり、十分に価値があるのです。
テストの結果、ユーザビリティ問題の“数”が収束した段階で出荷するというのが現実的な対応策です。

それから、ニールセン博士の真意は「5人のテストを“1回”行えば十分」ということではありません。
ニールセン博士が主張しているのは、小規模なテストでも
十分に成果（そういう意味で“5人で十分”）が得られるのだから、
予算や時間を言い訳にしないで、もっと積極的にテストを実施すべきだということです。
さらに、大規模なテストを1回行うよりも、小規模なテストを繰り返すことを推奨しています。

設計チームが1回もテストを行ったことがないのであれば、5人で構わないからテストを行えば、
大規模なテストに匹敵する結果（大規模テストの85%の問題点が発見可能）が得られるのです。
もし、20人のテストを行う予算が確保できるのならば、
その予算を使って設計プロセスの途中に3回から4回のテストを実施すべきなのです。

ユーザビリティエンジニアはニールセン博士の公式を誤用・乱用していはいけません。
ユーザテストには限界があるのです。
「5ユーザテストを実施すれば、インターフェイスが合格点に達する」という説明は全くの間違いです。

そして、どんなにテストを繰り返してもリスクは“ゼロ”にはならないのですから、
設計チームはテスト結果に慢心しないで、
出荷後もユーザからのフィードバックに謙虚に耳を傾け続けるべきなのです。


【参考情報】
（１）U-site:5ユーザでテストすれば十分な理由
http://www.usability.gr.jp/alertbox/20000319.html
論文そのものではありませんが、ニールセン博士自身が論文に基づいて書いたコラムです。

（２） Testing Web Sites: Five Users Is Nowhere Near Enough（※PDFファイル／英文）
http://www.winwriters.com/download/chi01_spool.pdf
5ユーザテストに反論したジャレッド・スプール氏の論文です。
5人では少なすぎることを実証していますが、残念ながら適切な被験者数は明らかにしていません。

（３）What’s in a Number?（英文）
http://www.stcsig.org/usability/newsletter/0301-number.html
ユーザテストの被験者数に関する議論を総括しています。
ウェブサイト全体を評価する場合や、ターゲットユーザが多様な場合は、当然ながら多くの被験者が必要です。
また、5ユーザテストの本来の目的は設計途中にユーザフィードバックを得ることであり、完成品の評価ではありません。




[1-14]ユーザベネフィット抽出

「製品に求められるユーザビリティとユーザベネフィットを抽出する手法の開発」
仲川薫、三留修平　株式会社イード

○一言
ユーザビリティはノンネガティブの性質を持ち、製品義務としては捕らえられているが、
ユーザにアピールする魅力条件とはなりづらいと考えられている

ユーザビリティが満たされる結果生じるUser-Benefitを解明することにより、
よりユーザにとって重要であると考えられるユーザビリティの特定と、
そのアピールの仕方を発見することができるのではないか

発想の基本は「使いにくさ」である
ネガティブなイメージは人間の印象や記憶に残りやすく、
想起しやすいため「使いにくい」をキーワードとしている

○質問の仕方
「まず、□□のときに、○○製品を使用する際に、
使いにくいと思うことを挙げてください。」
「それはどういう状況で、誰がどのように、使いにくいのですか」

○ラダーリング
・上位概念を引き出す場合（ラダーアップ）
「○○だと使いにくいということですが、○○が改善されると、
ユーザにとっては、どんな良い点があるのですか
その理由をいくつでも、1つずつ順番に教えてください」

・具体的要求を引き出す場合（ラダーダウン）
「○○だと使いにくいということですが、○○が改善されるためには
具体的には何がどうなっていることが必要だとお考えですか
○○であるための条件をいくつでも、1つずつ順番に教えてください」



[1-15]思考発話の理想と現実

人机交互論
http://allnight.cocolog-nifty.com/usability/

○思考発話の理想と現実

思考発話法（発話思考法とも言う）はユーザに“話しながら操作”してもらうという
ユーザテストの１つの手法ですが、これは「言うは易し、行うは難し」の典型で、
実はユーザビリティエンジニアを少なからず悩ませているのです。

思考発話法のテストを始める前には
「今日は、考えていることを話しながら操作してください」とユーザに依頼するのですが、
その際に戸惑いを見せるユーザが少なくありません。
皆さんは「自分の思考過程を全て発話する」という経験はあるでしょうか？

普通の人は、そんな経験がないので、指示を受けてもどう振る舞えばいいのか想像がつかないのです。
もちろん、中には思考発話が上手なユーザもいますが、
大半のユーザは上手く発話できないと想定しておいた方が無難です。

計算問題や簡単なパズルを使って思考発話の練習を行ってからテストに入るという方法もあります。
しかし、５分～１０分くらい練習したところでユーザの習慣は変わりません。
練習の時は“話すこと”に注意が行っているので発話できても、
実際にタスクに取り組み始めて操作に集中すると発話が滞ってしまいます。

それに、発話してくれたとしても、女性のユーザなどで声が小さいと聞き取れません。
そうすると、「もっと大きな声で」という依頼もすることになります。
ユーザは、奇妙な鏡張りの小部屋（ユーザビリティラボ）で、初対面のインタビューアと２人きりで、
考えていることを全て、普段よりもかなり大きな声で発話しながら、
初めて見るインターフェイスを使って、指示されたタスクを実行しなければなりません。
これはユーザにとって非常に不自然で、負担が大きい状態と言わざるを得ません。
これでは、ユーザはインターフェイス以外の要因で混乱しかねません。



○理想と現実

理想的な思考発話とは“独り言”です。
誰かに対して話すのではなく、自分自身に対して話すのです。
例えば、私たちはランチのメニューを決めるときにも
「（昨日の夕食のメニューも）中華だったし・・・」などと内省します。

このように、本来、思考発話とは自然な状態で行うもので、
無理矢理に発話するものではありません。
また発話内容は思考過程の実況生中継という詳細なものではなくて、
断片的で不完全なもの（つぶやき）になります。

それから、ユーザの発話に対してインタビューアは応答しないのが原則です。
思考発話とは“独り言”なのですから。

ところが、実際にはインタビューアが応答しないとユーザの発話はどんどんフェードアウトしてしまいます。
日常生活では「反応がない＝相手は興味がない」ということが多いので、
ユーザはだんだん居心地が悪くなって黙ってしまうのです。

このように、思考発話の理想と現実にはかなりのギャップがあります。
もし、テストの目的が“研究”ならば理想に近づけるべきです。
ユーザがラボの環境や思考発話に十分に慣れるまで時間をかけて訓練したり、
どうしても上手く発話できないユーザは被験者から除外してもいいでしょう。
そして、何度もビデオテープを見直して、
断片的で不明瞭な発話内容からメンタルモデルを推定するのは研究の真骨頂です。

しかし、企業のユーザビリティラボは大学の研究室ではありません。
思考発話の練習に１人あたり３０分を費したり、
思考発話が下手なユーザを対象者から除外していては、
予算とスケジュールの範囲内で評価結果を出せなくなってしまいます。

また、分析者が解明したメンタルモデルよりも、テスト中にユーザが発した一言の方が、
設計チームのメンバーにとってはインパクトが大きいこともあります。

そこで、実際にはインタビューアが“介入”します。
「どうしようと思っているのですか？」といった発話を促す質問だけでなく、
「なぜ、さきほど左（OKボンタ）ではなく右（クリアボタン）を押したのですか？」と理由を尋ねたり、
「今の気分は？」と主観的評価を尋ねることもあります。

また、ユーザが立ち往生してしまったら“助成”する
（ヒントを提供したり、場合によっては次のステップに誘導する）こともあります。
さらに、タスクが終了してから回顧法で質問する場合もあります。

いずれにせよ、このようにインタビューアとユーザが対話する中で得られた発話はもはや独り言ではありません。
実際、ユーザは介入を受けると、操作の手を止めたり、視線をインタビューアに向けたりして話すことがあります。
ユーザは明らかにインタビューアに向けて発話しています。



○ユーザは嘘つき？
独り言でないからといって、ユーザの発話内容が全て“偽物”という訳ではありません。
ただ、ユーザは無意識のうちに内容を歪めて発話することがあります。
この歪みは時間が経てば経つほど大きくなる可能性があります。
例えば回顧法のように、タスクが終了してから質問に答える場合、
タスク実行途中に考えていたこと、感じていたことは、
時間経過とともにユーザの頭の中で再処理されてしまうので、
元の状態を再現することは非常に困難になります。

そこで、私は次のように考えてデータを分析するようにしています。
もし介入に対して、すぐさま発話が得られた場合は、
その内容はユーザの頭の中に存在した（信頼できる）と考えて差し支えないでしょう。
一方、しばらく考え込んでから得られた発話は、理由を後付けしている危険性があります。

なお、半分くらいの発話は自然に得られることが多いです。
また、テストの前半部分で介入することで、ユーザの口が滑らかになって、
後半は割と自然に発話できるようになることもあります。
介入はユーザにバイアスを与えるというリスクを伴いますが、
ユーザが意味不明の行動をして、その理由を推測できる発話を行わなかった場合は、
何らかの介入を行うというのが私の方針です。
テストの目的はユーザの行動を理解することだからです。


○精度と有用性
このようにインターフェイス設計の現場で用いる思考発話法は、
心理学の研究で用いるものとは精度が異なります。
そして調査データの精度を議論し始めると、なかなか結論が出ません。
正統派の人たちは「信頼性の低いデータを収集して、何の役に立つのか」と主張しますし、
現実派の人たちは「現場では十分役に立つ」と反論します。

ある調査レポートの中で、インターネット視聴率調査の最大手である
ネットレイティングス（株）の萩原雅之氏が、こういった議論に対する１つの見解を述べています。
これは、ユーザテストに言及したものではありませんが、
私たちの議論でも参考になると思うので、最後に引用しておきます。

「『正確な調査』と『役立てる調査』には違いがある。
世論調査は、調査結果そのものがアウトプットとなるので、その手続きでしか正当性が保てない。
一方、マーケティング・リサーチは、企業が意思決定をするために調査するのであって、
調査が『正しい』必要はなく『役立つ』ものであればよい。」

＜独立行政法人　労働政策研究・研修機構
　『インターネット調査は社会調査に利用できるか― 実験調査による検証結果―』P46より引用＞

【参考情報】
（１）道具眼：プロトコル分析にまつわる誤解
http://www.do-gugan.com/column/column_003.html



[1-16]情報の整理

Passion For The Future: それは「情報」ではない
http://www.ringolab.com/note/daiya/archives/000510.html


ワーマンは情報を構造化する方法は５つしかないと定義している。
５つは頭文字をとってLATCHと呼ぶ。
位置、アルファベット、時間、カテゴリ、階層。
あらゆる情報はこの５つとその派生形の構造化手法で説明、分類できるという。

LATCH   
Location 位置 地図として表現 
Alphabet アルファベット 順番、順序で表現 
Time 時間 時間軸で表現 
Category 分野 カテゴリで表現 
Hierarchy 階層 程度で表現 

確かにこの5つで表現できない情報は探すのが難しい。

------------------------
[2]UI一言
------------------------

UIに関する一言メモ、名言などなど

[2-1]UIの一言ポイント

ユーザは自分の失敗に気付いていないことが少なくない

歴史があるから正しいわけではない
未来のほうが過去よりずっと長い

Simpleとeasyは違う

「Killing Time is the Killer App for Mobile
（モバイルでは、時間浪費こそがキラーアプリである。）」

情報の匂い

インタラクティブ性が必要なのか、意思決定が必要なのか

作業が求められているのではなく成果物が求められている

整理整頓
誰にでもすぐに使える、戻せる
分かる
  どこに  定位（場所表示）
  何が    定品（品目表示）
  いくつ  定量（量表示）
取れる
戻せる

既存のWindowsやMacのデスクトップは２次元です。
机の上（デスクトップ）に書類（ウィンドウ）を並べて作業するという
メタファ（比喩）を用いています。
ただ、現実の机の上の書類ならば、ユーザは持ち上げたり、積み上げたり、
裏返したりできますが、デスクトップ上のドキュメントは画面に貼り付いていて、
なかなかユーザの思い通りには操作できません。
もし、現実の机が完全な２次元空間であったとすれば、
今と同じ仕事をこなすには随分広いスペースが必要となることでしょう。

３Dだからバーチャルにしちゃうと
せっかく電子化されてるのに、わざわざ遠くにある情報を手を伸ばして
よいしょって取りに行くのは無駄
意識することなく、わざわざ手を伸ばさなくても
必要な情報が目の前or便利な場所にあればいい
優先度の低い情報は視界内のどこかにあって、
いつでも簡単に参照｜比較｜抽出等できればいい


ユーザ中心設計とは
「ユーザを満足させる」という作り手の立場に立った顧客本位ではなく、
「ユーザが満足する」という真の顧客本位のシステム創出が目的

メトカーフの法則とは、Ethernetを開発したボブ・メトカーフ氏が1995年に提唱した法則で、
「ネットワークの価値はノード数の2乗に比例する」というもので、
平たく言えば、そのネットワークに接続されている機器が増えれば増えるほど、
そのネットワークの重要性が加速的に高まっていくというものだ。
Metcalfe氏は同時に「コストはノード数に比例して(直線的に)上昇する」とも述べており、
ネットワークは投入したコストに比較して価値が急激に高まっていくことを示唆している。



音声は使いものにならないというわけではない。
ただ、他のメディアが利用できる場合に、二次的なインタラクション・モードになることが多いというだけだ。
リストを読み上げてもらうよりは、モニターに表示してもらった方が、
望むアイテムを選び出すのはずっと簡単だ。
音声は一次元メディアで、持続性はゼロである。
モニターは、二次元メディアであり、持続性（好きなだけ見ていられる）と
部分的更新性（画面内のどのフィールドに入力しようと、他の部分は変化しない）をあわせ持っている。 




[2-2]GUI

松下シンポ論文概要

タイトル

デジタル家電向け
　UD指向
　グラフィックス技術を用いた
　○○に基づく

GUIの開発


著者：○大槻，折本，仙田，樋尻，望月

概要

デジタル家電の高機能化、操作の複雑化に伴いGUIの重要性が増しており、
初心者でも容易に理解できる、誰にでも使いやすいUD指向GUIの実現が求められている。

そこで我々は、UD指向GUIの設計に必要な条件を
視認性、操作性、快適感に着目して抽出し、
家電機器の操作系や表示画面に応じたGUIを開発している。

本GUIは、グラフィックス技術により
「現実世界のメタファを用いた理解しやすい表現」、
「操作デバイスに応じたGUIの配置」、
「ユーザの操作に即応する高速なアニメーション」
などを実現し、視認性、操作性、快適感を向上させる。

本発表では、UD指向GUIを実現するための条件や表現方法について説明し、
携帯電話及びDTV向けに開発したGUIのプロトタイプを示す。

またUD指向GUIの条件に基づいて、ユーザによる主観評価を行い、
開発したGUIプロトタイプの妥当性を評価する。


----------------------------------------------------

成果物→GUI
GUIを作るために、条件を抽出した


デジタル家電の高機能化、操作の複雑化に伴いGUIの重要性が増しており、
初心者でも容易に理解できる、誰にでも使いやすいUD指向GUIの実現が求められている。

そこで我々は、UD指向GUIの設計に必要な条件を
視認性、操作性、快適感に着目して抽出し、
家電機器の操作系や表示画面に応じたGUIを開発している。

本GUIは、グラフィックス技術により
「現実世界のメタファを用いた理解しやすい表現」、
「操作デバイスに応じた表現」、

「アニメーションによる操作のフィードバック」、
「滑らかな画面遷移」

などを実現し、視認性、操作性、快適感を向上させる。

本発表では、UD指向GUIを実現するための条件や表現方法について説明し、
携帯電話及びDTV向けに開発したGUIのプロトタイプを示す。

またUD指向GUIの条件に基づいて、ユーザによる主観評価を行い、
開発したGUIプロトタイプの妥当性を評価する。

----------------------------------------------------





快適感←→快適じゃないGUI
	反応が遅い
	見た目と操作方法がよくわからない（アフォーダンス）
	匂いがしない（ゴールが見えない）

楽しさ、快適さ、面白さ、軽快さ	
快適なGUI？

操作性
	様々な機能になるべく簡単な操作でアクセスできる
	操作結果のフィードバック
	ストレス、入力の負担がない

「操作デバイスに応じた表現」
	スマートホイールだから１次元配置とか螺旋
	十字キーだから縦横に配置


HTMLとCSSの様に、データ構造と見た目の分離

統一的な操作性と先進性を備えたUD指向GUIは
商品優位性の確保を可能にし、また商品の顔としてブランドイメージの向上にもつながる。

デジタル家電のGUIを設計するための指針となる条件を

UD指向GUIを設計するための指針となる設計原則を提案する

2D、2D形状による現実世界のメタファを用いた理解のしやすさや
フィードバック、
アニメーションによる画面遷移の表現といった
グラフィックス技術の効果をふまえて

このGUIフレームワークを用いることにより、統一的な操作性と先進性を備えたUD指向GUIが効率的に開発可能となる。

統一的な操作性と先進性を備えたUD指向GUIは
商品優位性の確保を可能にし、また商品の顔としてブランドイメージの向上にもつながる。

また商品買い替え時に継続して同じGUIの製品を購入するようになると考えられる。


UD指向GUIに必要な条件を追加、修正を行ってUD指向GUIの指標をまとめた。

----------------------------------------------------

ポイントをどこに置くか
UD？見栄え？GUIの評価手法を確立する？GUIの指針を提案する？

１：背景：UDを押す？→UD→個人適合とか
２：背景：新しいGUIであることを押す？→PSX等最新のGUIの商品優位性→見た目がいい
→UDだけでなく、見た目も大事→３D

背景に沿って優位点：我々のGUIのどこが優れている→
評価
何を満たせばいい？何が必要？

UD→
初心者に優しい→
使いやすい
見やすい
分かりやすい



GUIの条件を出して
GUIのプロト作成→評価→条件にあっていました
→GUIに必要な条件をさらに発見して、追加
→ユーザビリティ推進室に承認を得ました

---------------------------------------------------
例

携帯電話の高機能化に伴い、ＧＵＩの操作性や視認性の向上が求められている。３ＤＣＧを使用したＧＵＩは、それらを解決する為の重要なアプリケーションの１つとして注目されており、３ＤＧＵＩの構築は商品優位性の確保を可能にする。

そこで、我々は、
３ＤＧＵＩの特長を生かした上で、
開発の容易性と効率化が図れる、
携帯電話向け３ＤＧＵＩ描画用ミドルウェアを開発している。

本ミドルウェアは、
「独自高速描画ライブラリ上に構築」、
「３Ｄの専門的な知識を持たない開発者でも利用可能なＡＰＩ設計」、
「アイコンの立体配置、集団動作、強調動作、背景のアニメーション、
ＣＧキャラクタとの同時表示などの機能による、操作性と視認性の向上、
及びユニークな視覚表現効果を実現」
という技術的な特徴を有する。

本発表では、
ミドルウェアの構成、特長的な機能について説明し、
ミドルウェア上で作成したアプリケーションの例を示す。 



[2-3]EPGと可視化による視認性画面内検索性

山田祥平のRe:config.sys
http://pc.watch.impress.co.jp/docs/2005/0415/config047.htm

●見たら消すというスタイル
　デジタル家電としてのHDDレコーダーや、パソコンでのTV録画機能の浸透によって、
VHSカセットに予約録画をしていたころに比べ、TVを見るスタイルは大きく変わった。
何よりも、録画予約がカンタンだ。
多くの場合はEPGによる番組表から、見たい番組を指示するだけでいい。
以前は、時刻を指定したり、Gコードを指定して録画を予約していたのだから、驚くほどカンタンになった。

　ぼくは、VHSのビデオカセットデッキを引退させ、DVデッキにしたころから、
テープの交換や、録画済み番組の頭出しなどが億劫になり、
録画してまでTVを見なくなってしまっていた。
長時間テープを入れっぱなしにするという手もあるのだろうが、見終わったら、
消してもいいところまでテープを送り、次に備えて録画待機させるというような作業が
面倒でしかたなく思えるようになり、だんだん、録画には縁がなくなっていったのだ

　けれども、パソコンの録画機能やHDD/DVDレコーダーを使うようになってから、
また、TVを見始めた。ライブで放送を見る機会はあいかわらず少ないけれど、多くのTV番組を録画して見ている。

　最近は、TV録画も、保存のために録画をするのではなく、
録って見たらすぐに消すというユーザーが増えてきているらしい。
レコーダーを明確にタイムシフトのために使うユーザーが増えてきているということなのだろう。
自分の都合でドラマを見ていても、電話がかかってくるかもしれないし、鍋は容赦なく沸騰し、
風呂は風呂でお湯があふれる。ライブにつきあっていては、TVの時間に自分を合わせざるをえないが、
録画してタイムシフトすれば、そんなことをする必要はない。

　つまり、録画したTV番組は、捨てられやすくなっている。それは、保存の方法にも関係しているように思う。
保存したファイルは、ファイル名やフォルダ名とそのタイムスタンプ、
あるいは、DVD-Rなどのメディアの整理などによって管理するしかないのだが、
ぼくの知る限り、録画時にはあれほど親切だったEPGの情報を、
録画済みデータといっしょに保存してくれる環境がまったくない。

　たとえば、録画済み番組500本があったとして、そこから、
特定の出演者の出ている番組を探し出すことができるだろうか。
未来の番組は録画予約に備えてそれができるのに、過去の番組ではそれができない。
TV番組情報サイトでは、昨日の番組の情報でさえ、見ることはできない。
そういう意味では、デジタルデータでの番組保存も、カセットテープへのシーケンシャル録画の域を超えてはいない。
録画時にこうしたメタデータがいっしょに保存されていれば、どれだけ重宝するだろう。

●視覚で情報のプロパティを見切る
　その一方で、録画予約をするという行為が、見たい番組を見るという行為である以上、
まずは、見たい番組を探さなければならない。以前は、その手段は、新聞のTV欄が独擅場的に担っていた。
新聞のTV欄はザッと見れば、どの番組が重要なのかが一目でわかったし、
特におすすめの番組は、あらすじなども紹介されている。
今夜はどうすればいいのかが、すぐに理解できたのだ。

　ところが、EPGの番組表は、どのサイトを見ても、今ひとつ、これは見ておこうという番組を直感的に探し出しにくい。
同じことは、新聞社のニュースサイトを見ても感じていたことだ。
紙の新聞では記事のスペースや見出し、写真の大きさなどで、
個々の記事の重要性がザッと見ただけで理解できるが、ウェブサイトのニュース一覧ではそれがわかりにくい。

　ぼく自身にとっては、どうも、英語を読んでいるときと似たような感覚である。
日本語の情報は、表意文字である漢字が散在するため、
パッと見ただけでも視覚的に意味を理解することができる。
ところが、英語の場合は、読まなければわからない。英語の速読は、文字の集合としての単語を、
一種の表意文字のように扱うことで、読むスピードを加速するのだそうだが、
日本人は意識しないうちに、それと同じことをやっているというわけだ。

　今、せっせと、iPodに、手持ちのCDを片っ端から保存している。
実は、最近になってiPod Photoを買ったのだが、今まで入手しようとしなかったのは、
このデバイスを単なるPhotoビューワ的なものだと思いこんでいたからだ。
ところが、iTunesで、CDのジャケット情報を添付してやると、再生時にそれが表示されると知って欲しいと思った。
その点だけで、小ささがとりえのシリコンオーディオプレーヤーよりもずっと魅力的に感じる。

　LPレコードの時代には、その30cm四方というダイナミックなサイズのせいもあり、
アルバムジャケットの印象は強かったのだが、CDになってからはそれが薄れていた。
アルバムは背表紙もそれなりの色で判別できるので、棚の何百枚のレコードの中からも、
目的のアルバムをサッと見つけ出すことができた。
でも、CDは文字を読まなくちゃならないことが多い。欧文の場合は、首を横にしてアルファベットを読む。
これがまたつらい。だから、よほどきちんと整理していない限り、棚から目的のCDを探し出すのはたいへんだ。

　視覚とデータの関係は、いろいろな部分に影響を与える。
CDのジャケットを、かつてのレコードジャケットのように、きちんと認識できるようになったら、
以前に買ったのを忘れていて、2枚購入してしまうタイトルも少なくなるにちがいない。
こういうことが起こるのは、単なる老化現象のせいだけとは思えないのだ。
デジタルにはまだまだできることがあるのに、それが放置されている。


(2005年4月15日)
[Reported by 山田祥平]



------------------------
[3]評価
------------------------


[3-1]総括的評価と形成的評価

○使いやすさの評価
道具の使いやすさを「評価する」ことが問題になる場合があります。
道具の使いやすさをきちんと評価することが望まれる場面はいろいろですが、評価の目的は違います。
道具を適切に評価するためには、評価の目的にあった使いやすさを問題にしていかなければなりません。

○総括的評価(Summative Evaluation)と形成的評価(Formative Evaluation)
使いやすさの評価をその目的によって、大きく二つに分けることができます。
一つは、総括的評価と呼ばれるもので、道具全体としての使いやすさが問題になります。
これは、典型的には、二つの道具があったとき、
どちらの道具が使いやすいのかを判定したいというようなときに問題になる評価です。
道具を購入するときに、いくつかの候補の中からその使いやすさで決めようというような場合、
それぞれの道具について、どれぐらい使いやすいのか「数」で示されていれば、
一番大きな数を持つ道具を選べばよいということになります。

一方、形成的評価(Formative Evaluation)と呼ばれるものがあります。
これは、ユーザーインターフェイスの設計の過程で、
どのようなデザインにすればよいかという情報を得るための評価です。
このような評価が必要なのは、道具の使いにくさは道具を設計する人や、
ユーザー自身にとっても自明なものではないというからです。
道具を系統的に検討し、調べないとどのような点で使いにくさが生じているのか分からないことがむしろ普通です。
これを調べるための手法が必要になります。

総括的な評価(Summativeな評価)の方法
総括的な評価は一つの数に集約される評価です。
主観的な印象としての使いやすさを問題にしている場合は、総括的な評価をしやすい面があります。
一つの道具に対して、ユーザーが持つ印象を調べることで総括的な数が得られるからです。
ユーザーが持つ印象を調べる直接的な方法は実際にユーザーに対して質問紙やインタビューなどによる調査を行うことです。
普通は特定のユーザーだけの印象を求めるのではなく、特定のユーザー集団について問題にしますから、
調査の結果を効果的に利用するには、得られたデータから有用な情報を引き出すための統計的な手法が必要になります。

ユーザーの印象を調査するのは費用もばかにならないことが多いので、
ユーザーがどんな印象を持つかを専門家が推定するということで代わりをすることも可能な場合があるでしょう。

機能としての使いやすさの総括的な評価をする場合、どのような使いやすさの機能を問題にするのか、
またそれをどのように総合して、一つの数にするのかが問題になります。
学習のしやすさとエラーの起こしやすさが問題になったとしたら、それをどのように「重み」づけして、
一つの使いやすさの指標にまとめるかが問題になります。
このような重みを決めるための適切な根拠を見つけることは必ずしも容易ではないでしょう。
しかし、そのような重みを厳密に決めなくても、二つの道具を使いやすさで選択しようとする場合などでは、
見つかった使いやすさの問題点の数を指標とすることで、十分であることも少なくありません。
評価の精度をどこまで求めるかは、絶対的に決まるものではなく、その評価が必要とする精度が出れば十分だからです。

参考書

Nielsen, J. and Mack, R. l. (ed) "Usability Inspection Method" Jhon WIley and Sons, New York. 1994 
Rosson, M. B. and Carroll, J. M. "Usability Engineering" Academc Press. 2002 

[3-2]主観的使いやすさの測定方法

主観的使いやすさの測定方法
印象としての使い易さを問題にする以上、それを正確に「測定する」ことが必要になります。

いろいろな主観量をしたり、測定したり、尺度化したりする技術は、
心理学の中の主観量の「測定法」や「尺度構成法」という分野で研究されてきました。
使い易さを主観量として扱おうというときには一つの基礎になる分野です。
主観量を扱うための方法論や技法が心理学の測定法の分野にあることを知っていれば、
そこでの成果を使うことで、自分で一から再構成しなくても済む場合があります。

主観量の扱いをここでは、それほど詳しく紹介はしませんが、
ただ、要点をいくつか取り上げておこうと思います。

主観量のデータ収集方法
ここで扱うのは人がどう感じたかという主観量なので、
人に「判断」や、「評定」してもらうところから始めるのが普通です。
評定には、「評定尺度」を用います。
例えば、次のような7項目からなる尺度を提示し、一番あてはまると思う項目を選んでもらいます。
道具の使いやすさを全体として評定してもらうならば、
「使い易さ」を評定してもらうのならば、次のような5段階の尺度が使えるでしょう。

非常に使いやすい。 
使いやすい。 
普通。 
使いにくい。 
非常に使いにくい。 

また次のように、7段階の尺度で尋ねることもできます。

大変学びやすい。 
かなり学びやすい。 
学びやすい。 
どちらでもない。 
学びにくい。 
かなり学びにくい。 
大変学びにくい。 

5段階の尺度がよいか、7段階の尺度がよいかは一概には決まりません。
評定者が自然に評定できるように段階の数を選ぶべきでしょう。
段階を多くしすぎても、ユーザーの負担がますばかりで、精度が上がるわけではありません。
また、両端は選ばれないという傾向があります。

また、次のことに賛成するかどうかを尋ねるという形で評定を取ることもできます。 

以下のことにどこまで賛成できるか、その程度を以下の反対、賛成の5段階の中から一つ選んで示してください。

このシステムは学びやすい。

非常に反対である。 
かなり反対である。 
反対でも賛成でもない。 
かなり賛成である。 
非常に賛成である。 

（このような、どれほど賛成か、反対かの尺度をLikert尺度と呼びます。）

評定尺度を使う他にも、主観量を測定する手法はいろいろ開発されてきました。
どの方法がよいかは、目的に応じて、コストとの兼ね合いで決めていかなければなりません。
とりあえず主観量を取りたいのなら、データも集めやすく分析も比較的容易な評定法がよいでしょう。

データの吟味と図表化
データが手元に集まったら、次はそのデータを吟味して、こから意味のある情報を引き出す段階に入ります。
生のデータは数の集まりですから、それをまとめて意味を引き出しやすくする必要があります。
平均値のような数（統計量）にまとめていくのが一つの方向です。
ただ、統計量だけでなく、生の「分布」を見ることで得られるものも少なくありません。
7段階の評定データも平均値にしてしまうと一つの数になってしまいますが、背後の分布に多くの情報があります。
例えば、極端に使いにくいという人がどれほどの割合を占めるのかなどを見ることができます。
エクセルなどのソフトウエアで分布を図示することは簡単にできるようになりましたから、これらを活用すべきです。

データの信頼性と妥当性
データをまとめれば、平均値や分布の形が得られますが、
そこで.得られたものが「信頼」できる値であるかどうかが問題になります。
狭い意味での信頼性は、それが単なる偶然に得られた数ではなく、
安定して得られるものかどうかというものです。
同じような手続きで同じようなデータが得られるのかという一種の再現性です。
ユーザーに一日おいて、同じ道具の使い易さを評定してもらったら、
別の値になってしまうというようなこともあります。
これはデータの「信頼性」が低いということになります。
それから、データがこちらの意図していないものを表しているかもしれません。
例えば、缶切りが使いやすいかどうかを人に尋ねた場合でも、
こちらはその人本人が使いやすいかどうか尋ねたのに、
プロの料理人にとって使いやすいかどうかを答えられてしまうというようなことも起こりえます。
「データ」が意図しているものに対応しているかどうかを「妥当性」という言葉で表すことがあります。

信頼性や妥当性という観点から、データの質を吟味する姿勢は大事です。
データには余計なノイズがたくさんのっており、
対象の本質を表す部分はわずかであることも少なくありません。
データをたくさん取ることで、信頼性や妥当性は一般には高まりますが、
質問を分かりやすくするなど、誤解を少なくしてノイズを減らし出発点のデータの質を高める工夫が大事です。

データの分析法
数量データから役に立つ情報を引き出すさまざまな手法が統計学の中で発展してきました。
その中には役に立つものも少なくありません。
ユーザビリティの評価の中で、数量データを扱う以上、
統計的検定や推定の考え方と分散分析などの手法を使えるようにしておくと便利でしょう。
ただ、必要な情報を取り出すという意味では、実用的には、
分布図を描いて眺めれば十分ということも少なくありません。
例えば、平均値の検定をして差があるかどうかという見当は、分布図を見ればほとんどの場合、分かります。

また、分布図を見ても差が分からないような微妙な差が大量のデータで統計的に「検出」できたとしても、
差の大きさが小さければ、ユーザビリティの現場で問題になるかどうかは疑わしいとところです。
一概に高度な統計分析の手法の有用性を否定するつもりもありませんが、いつも役に立つとは限りません。
むしろ、分布を図示しするように、いろいろな側面を図示し、
それを示吟味することでそこから意味を見出すことができる場合が少なくありません。
平均値だけを吟味するのではなく、平均値のもとにある分布を見ることで分かることは多いものです。


[3-3]２種類の評価手法

○２種類の評価手法
学習成果の評価は「総括的評価（summative evaluation）」と
「形成的評価（formative evaluation）」に大別できます。

○総括的評価とは、学習成果の総合的な達成度合いを測定することを目的とした評価です。
総括的評価は、学校の期末試験のように一定の学習が終了した後に実施して、通常、得点化を行います。
得点化したデータはさらに分析して、得点の分布や平均点を算出します。TOEICは典型的な総括的評価です。

○形成的評価とは、小さい学習単位ごとに、どれくらい理解できているか、
理解するためには何をしなければならないかをフィードバックするための評価です。
英会話スクールの先生が生徒の発音の間違いを正したり、英文メールを添削するのは形成的評価です。
形成的評価は得点を付けることが目的ではなく、改善することが目的です。

総括的評価の結果が悪いということは、もう１度教育をやり直さないといけない（例えば“落第”）ということです。
総括的評価は序列を付けたり、選別するためには効率的ですが、
“能力を伸ばす”という教育の本来の目的にはあまり役に立ちません。
そのため、現代の優れた教育者は、総括的評価よりも形成的評価をより重視しています。


○インターフェイスの“お受験”
総括的なユーザビリティ評価手法の代表は「パフォーマンス測定」です。
数十名のユーザにインターフェイスを使ってもらって、タスク達成率やタスク達成時間、主観的満足度を測定します。
結果は、「平均タスク達成率：５５％」「平均タスク達成時間：５分３０秒」「主観的満足度（平均）：２．８（５段階評価）」などといった“得点”で表されます。

形成的なユーザビリティ評価手法の代表は「思考発話法によるユーザテスト」です。
５～６名のユーザに“考えていることを話しながら”インターフェイスを使ってもらいます。
人数が少ないので達成率や満足度の平均値を算出することは無意味ですし、
ユーザは話しながら操作しているので、タスク達成時間は測定自体が無意味です。
テスト結果は「送信ボタンがページ下部に配置されているので見つけづらい」といった定性的で具体的なものになります。

教育における評価と同じように、総括的な手法は設計プロセスの“前後”で用い、
形成的な手法は設計プロセスの“途中で繰り返し”行います。
残念なことに、この区別がついていないデザイナやマネージャは少なくありません。

何らかの数値が得られないとテストを行った気分になれない“教育ママ”のようなマネージャは、
プロトタイプを使ってパフォーマンス測定を行おうとします。
一方、「テストをやってみたかった」デザイナは、来月公開するウェブサイトについて、
思考発話法のユーザテストを実施したいと問い合わせてきます。

インターフェイスを評価しようと思い立ったら、まず自問してください。
自分たちはプロジェクトを“これから”始めるのか？、“途中”なのか？、事実上“終了”したのか？
この質問に答えれば、評価手法は自ずと決まります。

もう１つ、忘れてはいけない重大な原則があります。
それは、総括的評価しか行わないのならば、それは全く無駄な投資だと言うことです。
パフォーマンス測定でタスク達成率が５０％だとしても、なぜ半数のユーザが失敗したのか原因は分かりません。
主観的評価が悪くても、ユーザがどこに不満を持ったのか判断できません。

形成的評価を行わずに、総括的評価だけを行うのは、英語を勉強しないでTOEICを受験するようなものです。
結果は悪くて当たり前ですし、評価結果から具体的な改善策は何も得られません。
結局、調査会社が作ってくれた報告書以外には、何も成果はなかったことになります。

インターフェイス設計に近道はありません。
「プロトタイプ→評価→改善」を繰り返す「反復デザイン」抜きにプロジェクトの成功はあり得ません。
総括的評価は、そういった正規の活動を十分に行った後に“卒業試験”として実施するものなのです。



[3-4]調査書のガイドライン

人机交互論
http://allnight.cocolog-nifty.com/usability/

補足情報として「調査票デザインの原則」が掲載（P243）されていました。
この原則は文部科学省統計数理研究所の大隅昇氏などによって提唱されているようです。
この原則をインターフェイス設計のガイドライン（ヒューリスティックス）
と照らし合わせて、私なりに検証してみました。


Welcome Screenを設ける 
    「システムと実世界の調和」という原則に当てはまるので妥当。 

第1問は1スクリーン、すべての回答者が容易に理解できるもの 
    インターフェイス原則として第１問だけ難易度を下げる理由はない。
    ただし調査テクニックとしては妥当と思う。 

従来の紙による質問紙に似たフォーマット 
    従来の紙の調査票では、矩形で囲ったり、下線や矢印を使うことが多いので、
    それをウェブのインターフェイスで再現した方がよいとは言えない。 

1行は短く 
    ウェブではユーザは「読まずにスキャンする」ので、文章を短くするというガイドラインは妥当。 

必要な操作の説明 
    「記憶しなくても、見ればわかるように」という原則に当てはまるので妥当。 

操作の説明は質問ごとに（冒頭一括は×） 
    「記憶しなくても、見ればわかるように」という原則に当てはまるので妥当。 

回答の強制はしない（答えなければ次に進めないのは×） 
    「ユーザコントロールと自由度」という原則に当てはまるので妥当。 

分岐が必要なとき以外はスクロールタイプを 
    スライド形式はページの読み込み回数が多くなってしまうが、
    長尺のスクロールタイプも画面のスクロールが煩雑になる。現状では一長一短ではないか。 

1つの設問は1つのスクリーンに収まるように 
    ユーザの環境によって画面の広さは異なる。基準（例えばSVGA）を決める必要がある。 

あとどれくらいで調査が終了するかが分かるように 
    「システム状態の視認性」という原則に当てはまるので妥当。 

「あてはまるものすべて」や自由記述には気をつけること 
    「測定上の問題が知られている」との但し書きがあるので、調査テクニックとして妥当。 




[3-5]ユーザテストの基本理論

ユーザテストの基本理論

人机交互論
http://allnight.cocolog-nifty.com/usability/ ユーザテストの基本理論

○ユーザテストは粗探し？
ユーザテスト（特に思考発話法）を行うとインターフェイスに潜在している多くの問題点が明らかになります。
デザイナはテスト結果に大きな衝撃を受け、発見された問題点の改善にすぐに取りかかります。
ただ、デザイナは心の片隅で一片の疑念を抱いている場合が少なくありません。
それは、「ユーザビリティエンジニアは粗探しばかりしているのではないか？」ということです。
確かにユーザテストのレポートには問題点が多く書かれています。
もちろん、レポートでは有効性が検証できた点（良い点）も取り上げるのですが、
悪い点と良い点の比率は１０対１くらいになってしまうことが多いので、
ユーザテストとは問題点を発見するために実施すると言っても過言ではないでしょう。
そのため、「ユーザテストはネガティブチェックに過ぎない」という批判を受けることがあります。
また、「問題点よりも改善策を知りたい」と要求する設計者も少なくありません。
しかし、これらは全て的外れな批判や要求と言わざるを得ません。
実は、ユーザテストとは『仮説に対する反証』を目的としているのです。



○反証アプローチ
ユーザビリティを"実証"するのはかなり困難な作業です。
いったい何人のユーザで、何種類のタスクを検証すれば、
そのインターフェイスがユーザブルであることを証明できるのでしょうか。
例えば、私が使っている携帯電話には主なメニューだけで１１５項目あります。
その全てを、設計プロセスの途中で検証するのは、コストとスケジュールの制約から事実上不可能でしょう。
そこで、まず「このインターフェイスはユーザブルである」という仮説を立ててしまいます。
もちろん、何も根拠なしに仮説を立てる訳にはいきませんが、
コンテキスト調査やヒューリスティック評価に基づいて設計されたインターフェイスならば、
差し当たり"ユーザブル"であると仮定できます。
ユーザは"効果的"かつ"効率的"かつ"不満を感じず"に、
そのインターフェイスを使ってタスクを達成できる"はず"なのです。
それを確かめるために、実際に何人かの（優先度の高い）ユーザに、
いくつかの（主要な）タスクを実行してもらいます。そして、思考発話法などを使って徹底的に分析します。
もし、効果・効率・満足度を阻害しているような問題点が見つかれば、
それは仮説に対する具体的な"反証"になります。
その時点で「インターフェイスはユーザブルである」という仮説は崩れます。 仮説が崩れたからといって悲観的になる必要はありません。
そもそもユーザテストでは積極的に反証を見つけようとしているので、
問題点が見つかるのは当たり前のことです。
それに、思考発話法によるテストならば問題点の発見だけでなく、
その原因まで明らかになるので、設計チームはすぐに改善策の検討を始めることができます。
そして、問題点を改善すれば、改めて仮説が成り立つのです。 一方、どんなに分析しても問題点が見つからなかったとすれば、評価者は反証を提示できません。
もちろん、もっと多くのユーザでテストしたり、他のタスクを実行すれば問題点が見つかる可能性はありますが、
そのような議論を続けていては永遠に結論に到達しません。
そこで、反証が見つからない場合は仮説を受け入れます。
つまり「インターフェイスはユーザブルである」と結論づけるのです。
ただ、読者の皆さんも感じていると思いますが、
この結論はたった１つの反証が見つかっただけで覆ってしまいます。
ですから、製品を市場にリリースした後もユーザからのフィードバックを積極的に集めて、
もし問題点が見つかれば謙虚に受け止める覚悟が必要です。



○テストの前にすべきこと
ところで、このような"反証"に基づいたユーザテストは仮説がないと成立しません。
ユーザニーズも把握せず、プロトタイプも作らず、
ヒューリスティック評価も行っていないようなインターフェイスでは、
そもそも「ユーザブルである」という仮説が立てられません。
そんなインターフェイスでユーザテストをすれば、当然、問題点がいくつも見つかります。
それも、解決不可能なような"深刻"な問題点が見つかります。
こんな時は、本当は最初から作り直した方がよいのですが、
現実には深刻な問題には手を付けず（手を付けられず）、
表層的な問題点だけ修正して製品をリリースするという結果に終わってしまいがちです。
つまり、テストはほとんど役に立たなかったことになります。
箸にも棒にもかからないようなインターフェイスをテストするのは全く無駄な投資です。
テスト以前にやるべきことがたくさんあります。
ユーザテストを行うのは、反証に値する程度のインターフェイスができてからの話なのです。 


------------------------
[4]松下UD規定
------------------------


[4-1]松下UD基本規定

第7条　UDの基本要素
１：理解しやすい動作への心配り
２：わかりやすい表示と表現への心配り
３：楽な姿勢と動作への心配り
４：移動と空間への心配り
５：安心・安全への心配り
６：使用環境への心配り


------------------------
[5]基礎知識
------------------------

Alertbox: ユーザビリティの基礎知識（2003年8月25日）
http://www.usability.gr.jp/alertbox/20030825.html
ユーザビリティの基礎知識

要約： 
ユーザビリティとは何か？どのように、いつ、どこを改善できるのか？なぜ配慮する必要があるのか？
この概論的な回答は、こうした基本的な疑問に答えるものである。 
この記事は、あなたの上司や、その他の誰であれ、
時間はないが基本的なユーザビリティ知識を得る必要のある人に対して書かれたものである。 


○What
ユーザビリティとは、ユーザ・インターフェイスがいかに使いやすいかを示す質的属性である。
「ユーザビリティ」という言葉はまた、デザイン・プロセスにおいて使いやすさを向上させるための手法をも意味している。 

ユーザビリティには、5 つの質的な構成要素がある： 
・学習容易性：初めてそのデザインに触れたユーザが、どれくらい容易に基本的なタスクを達成できるようになるか？ 
・効率性：いったんそのデザインを学習したユーザが、どれくらい迅速にタスクを達成できるようになるか？ 
・記憶性：しばらく使用しない期間をはさんだ後、再びそのデザインに戻ってきたユーザが、
　　　　　　どれくらい容易に習熟度を取り戻すことができるか？ 
・エラー：ユーザが犯すエラーの数、そのエラーの深刻さ、そして、そのエラーからの回復の容易さはどうか？ 
・満足度：そのデザインを使うのは、どれくらい楽しいか？ 


その他にも重要な質的属性はたくさんある。中でも重要なのはユーティリティ（有用性）である。
これはデザインの機能性を示す言葉である。
つまり、ユーザが必要なことを行えるか、ということだ。
ユーザビリティとユーティリティは、等しく重要である。
どんなに簡単でも、必要のないことならあまり意味はない。
そのシステムでやりたいことができるはずであっても、
ユーザ・インターフェイスが難しすぎて実現不可能なら、やはりうまくない。
デザインのユーティリティを調査するには、
ユーザビリティ改善のためのユーザ調査手法と同じものが利用できる。 



○Why
ウェブでは、ユーザビリティは生き残りになくてはならない条件だ。
ウェブサイトが使いにくければ、みんな去ってしまう。
そのサイトで企業が提供しているもの、ユーザができることを、
ホームページではっきり伝えられなければ、人は去ってしまう。
ウェブサイトで迷子になったユーザは去ってしまう。
サイト上の情報が読みにくかったり、
ユーザの重要な疑問に答えられなかったりすると、人は去ってしまう。
パターンがあることにお気づきだろうか？
ウェブサイトの取扱説明書を読んだり、インターフェイスを理解しようとして試行錯誤するユーザなどいない。
ほかにもウェブサイトは山のようにあるのだ。
ユーザが困難に直面した場合、そこを去るというのが第一の防衛線だ。 

e コマースの第一法則とは、すなわち、
ユーザは見つけることのできない製品を買うことはできない、ということである。 
イントラネットでは、ユーザビリティは従業員の生産性の問題である。
ユーザがイントラネットで迷子になったり、難解な指示を読み解くのに費やした時間は、
成果をあげられない彼らに支払う無駄金に通じる。 
現状でのベスト・プラクティスは、デザイン・プロジェクト予算の 10％をユーザビリティに回すことである。
平均すると、これでウェブサイトの品質指標は 2 倍以上になり、イントラネットの品質指標は 2 倍弱になる。
ソフトウェアや物理的な製品の場合、改善率はこれほどにはならないのが普通だが、
デザイン・プロセスでユーザビリティに力を入れれば、それでもかなりのところまでいける。


内部向けのデザイン・プロジェクトでユーザビリティを 2 倍にすることは、
トレーニング予算の半減と、時間あたりの従業員の処理能力の倍増につながると考えればいいだろう。
外部向けのデザインでは、売上の倍増、登録ユーザないしは顧客誘導の倍増、
その他、デザイン・プロジェクトの努力目標が何であれ、その倍増につながると思えばよい。 



○How
ユーザビリティ調査には数多くの手法がある。
だが、もっとも基本的で有用なのは、ユーザ・テストである。

これは次の 3 つの要素から構成される： 
・代表的なユーザを何人か確保する。
e コマース・サイトなら顧客だし、イントラネットなら従業員だ
（後者の場合、自分の所属する部署以外から人を選ぶべきだ）。 
・そのデザインを使って、ユーザに、代表的なタスクをやってもらう。 
・ユーザの行動を観察する。そのユーザ・インターフェイスで何がうまくでき、何が難しそうかを見る。黙って、ユーザの声を聞こう。 

重要なのは、ユーザをひとりずつテストし、どんな問題もひとりで解決させることだ。
手助けをしたり、画面上の特定の個所に注意を誘導したりすると、テスト結果を台なしにすることになる。 


デザイン上のもっとも重要なユーザビリティ問題を明らかにするには、
通常は 5 人のユーザをテストすれば十分だ。
大規模で徹底した調査を行うよりは、小さなテストを数多くやって、
各テストの間でデザインを見直していった方が無駄がない。
ユーザビリティ上の欠陥を、見つけ次第、修正していくのである。
反復デザインは、ユーザ体験の質を高める上でベストの方法だ。
版を重ね、ユーザ・テストしたインターフェイスのアイデアを増やしていけば、それだけよいものができあがる。 

ユーザ・テストはフォーカス・グループとは違う。
後者は、デザインのユーザビリティを評価する手法としては不十分なものだ。
フォーカス・グループはマーケット・リサーチのための手法で、
インタラクション・デザインを評価するには、ユーザ・インターフェイスを使って
タスクを実行する個々のユーザを、じっくり観察しなくてはならない。
人々の声を聞くというのは、誤解の元である。
彼らが実際にとっている行動に注目しなくてはならない。 



○When
ユーザビリティは、デザイン・プロセスのすべての段階にからんでいる。
調査を複数回行う必要があるので、個々の調査は、迅速に安価に進めるようお勧めする。

主なステップは次のとおり： 
・新しいデザインを開始する前に、古いデザインをテストして、
残したり、強調したりすべきよい点、ユーザのトラブルの種となっている悪い点を明らかにする。
イントラネットに取り組んでいるのでない限り、競合他社のデザインもテストして、
自社に似た機能を持つ幅広い代替インターフェイスに関するデータを得ておく。
（イントラネットに取り組んでいるのなら、イントラネット・デザイン年鑑を読んで、他社のデザインに学ぼう。） 

・フィールド調査を実施して、自然な環境でユーザがどのように振舞うかをみる。 
ひとつ以上の新しいデザイン案にもとづいたペーパー・プロトタイプを作って、テストする。
この段階では、デザイン案にかける時間は少ないほどいい。
テスト結果にもとづいて、すべてをやり直すことになるからだ。 

・テスト結果のもっともよかったデザイン案を、複数回の反復を通じて磨き込んでいく。
荒いプロトタイプから、コンピュータ上で動作する高品質なものへと、徐々に移行する。
反復を重ねるごとに、テストする。 

・定評あるユーザビリティ・ガイドラインにもとづいて、デザインを評価する。
自分が以前に行った調査でも、出版されている調査でも、いずれに依拠してもかまわない。 

・最終デザインを決めて実装したら、もう一度テストする。
実装時には、細かいユーザビリティ問題が必ず入り込むものである。 
デザインの実装が完全に終わるまで、ユーザ・テストを先延ばしするのはよくない。
そんなことをしたら、テストの結果わかった致命的なユーザビリティ問題の大半は、修正不可能になるだろう。
こうした問題のほとんどは構造的なものであることが多く、修正するには大幅な再構築が必要になる。 

高品質なユーザ体験に至る唯一の道は、デザイン・プロセスの初期段階でユーザ・テストを開始し、
途中、ステップを踏むごとにテストを継続することである。 



○Where
週に少なくとも 1 回はユーザ調査を実施するのなら、専用のユーザビリティ・ラボを設置する価値がある。
だが、ほとんどの企業では、会議室やオフィスでテストを行えば十分だろう。
この場合、邪魔が入らないようにドアを締め切れることが条件となる。
重要なのは、本物のユーザをつかまえて、となりの席でデザインを使ってもらうことである。
必要な道具はメモ帳だけだ。