快適性評価
製品デザインは認知性・操作性などを介して快適な使い勝手を実現しているかについて評価します。
ユーザビリティにおける快適性とは
快適とは広辞苑では「具合が良くて気持のよいこと」とあります。
具合とは同じく広辞苑では「 ①物事のしくみやはたらきの状態。調子。また特に、健康の状態。かげん。「機械の―が悪い」「病気の―」「進み―」• ②物事のやり方。方法。また、できあがった様子。「こんな―に作る」「いい―に出来た」 以下略ーー」とあります。
製品が気持ち良いとは
これをまとめると、ユーザビリティ評価（その１）認知性と（その２）操作性を併せ、製品を使った時にユーザが「製品の仕組みと働きの具合が良く、使い方がわかりやすく、使った後に良い製品だと感じた」という製品に対する捉え方が、肯定的になっているかを評価します。
ハードウエアとソフトウエアが生み出すＵＩとシーケンスを用いて、製品をユーザが使った結果、製品をユーザ自身の認知の下で完璧に制御できたと感じてもらうことはとても重要です。製品を完璧に制御できたと感じたとき、ユーザは真に製品を支配したと感じ満足感を得ます。この満足感は製品に対する愛着を生み、やがて製品の母集団であるブランドのファンになってもらえる可能性を高めます。
一般的に使われる製品で難しいユーザビリティの代表はコンピュータではないかと思います。コンピュータは機能やＵＩの設定をプログラミングで行いますから、様々な仕様を任意に設定できます。この仕様が製品の制作サイドとユーザとの間で、共通のイメージ・スキーマで構成されていれば設定の認知は簡単に共有でき、操作は簡単に行なえますが、スキーマが異なる場合は設定が出来ないという事態を招きます。このイメージスキーマは推論のパターンを指し、例えば制作サイドは設定を増減をカーソルキーの文字列順をイメージして左右で操作を行うというスキーマを元に制作したのに対して、ユーザはカーソルキーの増減は物質量の多寡をイメージして高いか低いというスキーマを元に操作した場合、制作サイドとユーザのスキーマが違いますから設定が思うようにできない。ということが起きます。
この問題は産業機器などプロ用製品であれば、ユーティリティ重視ですから、ユーザに製品を使う強い動機がありますから、リテラシを上げる努力をするというユーザ側の課題となりますが、一般の民生品ではこの問題をユーザのリテラシの問題にしてはいけません。
なぜならユーザは自身が持つリテラシに自信を持っている場合は「メーカの仕様設定はおかしい」と考えます。また自身のリテラシに自信のないユーザは、自身のリテラシを卑下してしまい、この製品は私には使いこなせない。と使用を諦めさせる結果となります。どちらにしても製品は売れず、製品のブランドファンになって頂くとは真逆の効果をユーザに与え、ＣＩ・ＢＩを著しく毀損する危険性を持つからです。
このように、ユーザが製品の使い勝手に満足したかを評価するのが快適性の評価です。先述のように適合しているかというポジティブな面の評価に併せて、「バグはないか」というノン・ネガティブな評価も行う必要があります。
デザインをディレクションするための快適性評価のポイント
デザインをディレクションするうえでユーザビリティの快適性を評価するためのポイントは、「認知性と操作性を決定するＵＩと、全体のデザイン要素との優先順位が適切か」ということになります。
この優先順位をデザインディレクタは決めなければいけませんが、その際の評価する判断規準は製品コンセプトとの適合度合いで以下の３点になります。
- ユーザビリティ要素の優先順位は適切か評価する
- ディファクト製品の操作スキームとのズレを評価する
- ユーザビリティがアイデンティティ評価やクオリティ評価上においても肯定的か評価する
ユーザビリティ要素の優先順位は適切か評価する
ユーザは製品に新しい機能が追加（ユーティリティの変化）された際などに、その新たな機能に興味を持ち製品を手にします。そしてその機能の使い勝手はどうかを確認します。この使い勝手についての評価は、日々厳しくなっているのではないかと思います。それはユーザが、ほぼ同じ機能の製品同士がユーザビリティの違いで天と地ほどの差がつくことをスマートホン（以下スマホ）で体感しているからです。ですから操作するインターフェースが今まで使った他の機能と比較して、快適かどうかを細かく比較評価します。
ユーザビリティはより使いやすい方が望ましい望大特性ですが、製品によってはユーザビリティ要素同士がトレードオフの関係に陥ります。
例えばデジタルウオッチ（通念となっている手首に乗る腕時計サイズ）のプロジェクトで、「操作性を良くするためボタンサイズを大きくしたい」としても、配置できるボタンの数もサイズも限られてきます。さらに同じ製品サイズのなかで「表示もできる限り大きくして認知性を上げたい」という希望が当然のように出てきます。この「製品サイズーボタンサイズー画面サイズ」とトリレンマの関係はどれも犠牲にできない大切な要素ですから、いくら大切なＵＩでも望大特性を許すわけには行かず、優先順位を付けて判断することが必要になります。
このように、製品の中でも認知性と操作性はインターフェースの優先順位の付け方で快適性を大きく変えますから、この優先順位が的確かという評価が快適性の評価につながります。また併せてユーザが製品を操作した際にインタラクションが想定外になった場合、「なぜこうなるのか？」と思い。ユーザは「バグ」は感じる問題は発生していないか、という評価も行います。
ディファクト製品の操作スキーマとのズレを評価する
製品の使い勝手をあげるために認知性と操作性を上げていきますが、その際にデザインサイドでユーザビリティの常識と思っているスキーマが、当該製品のユーザへどの程度受容されているかを確認する必要があります。これは同一カテゴリでデファクト製品があれば、その製品と操作の基となるスキーマが異なる場合に、受容性が評価が必要になります。
ビデオゲーム機を例にとると、プレイステーションを使っているユーザは１２個のキーと２つのジョイスティックをうまく操ってゲームを楽しめますが、ファミコンしか使ったことのないユーザは６つのボタンの操作方法しか経験していませんから、プレステは使えない製品となってしまいます。ビデオゲームはユーザがリテラシを上げることを楽しむという側面を持ちますから、ゲームに魅力を感じることでＵＩを受け入れるための練習を頑張ってくれたとしても、リテラシが上がるまでは使えないことは確かです。
また単純な例では、ボタンに「設定」と標記されている場合、シグニファイアである「設定」のシニフィエ（意味すること）は何かといった問題です。「設定を始めるためのボタン」なのか、「変数を入力した後に数値を確定するボタン」なのか、これはカテゴリ毎、メーカ毎にまちまちでユーザを悩ませます。スマホアプリやデジカメなどは特にこの類いの悩み方をすると思います。
このように、ユーザは製品を使う時「この種の製品はこうやって設定する」と自身の経験から持っているスキーマの引き出しを参照して操作方法を推論し操作します。その際、前述のユーザリテラシの項と同様に、リテラシの高いユーザはスキーマが当該製品のスキーマと合わない場合は、持っている経験の何パターンかのスキーマで試行してみてくれます。しかし想定のとおりに製品が動作しない場合、ユーザはその製品を作ったメーカやデザイナは常識がズレていると判断します。 仕方なく当該機能を使うために取扱説明書を読み難しい操作を覚えなければならないとなれば、ユーザはそのメーカ、ブランドの製品に対して強い負の印象を生み出します。
このようなことが起きないように、デファクト製品となっている操作方法との差を確認することは非常に大切です。
このように記していますが、新しいスキーマを持ったユーザビリティを提案してはいけないということではありません。製品のユーティリティの進歩は日進月歩で、プロジェクトで革新的な製品コンセプトの開発を行った場合、革新的なＵＩは必然でもありますから、このような提案であればデザインディレクタとして積極的に推進していくことも大切です。
ユーザビリティがアイデンティティ評価やクオリティ評価上においても肯定的か評価する
ユーザビリティ評価におけるＵＩやシーケンスが、アイデンティティ評価内でポジショニング・ブランディング・製品コンセプトを評価する判断規準と、後述するデザインクオリティ評価内でオリジナリティ・デザインポリシー・洗練度を評価する判断規準のすべてに対して肯定的に捉えられたかを判断します。
肯定的なユーザビリティとは、操作を行い目標を達成するまでにユーザが感覚として受け取り認知した、すべてのフィードフォワードとフィードバックの印象が良いということです。
デザインディレクションをするうえで、ユーザが使用後も肯定的な印象を持ち続けることを評価するには、製品がユーザにどのような感情を想起させたかがポイントですから、ハードウエアをユーザがどのように評価したか、という課題と、シーケンスのわかりやすさを含めたソフトウエアが、ユーザにどのような感情を想起させたかがの２つがポイントです。
例えばスポーツブランドで操作性の高さを製品コンセプトに謳っている製品であれば、ユーザビリティの優先順位は高く、インターフェースはユーザに認知されやすい場所にコントラストの強いカラーで配置され、かつ操作性の良い大きなボタンを持つように配されるべきです。同様にオリジナリティの高さを謳うブランドであれば、コンペチタとは違うオリジナリティのあるユーザビリティを持たせるために、シーケンス上すべてでオリジナリティ溢れるイメージで統一されることを期待されます。
どんなにユーザビティ重視の製品であっても、製品がプレミアムなブランドであればブランドイメージの表現を重視することが必要ですから、ＢＩ確保のためにブランドでは決して使わないカラーや素材などを使わないなど、制約が発生し優先順位が変わります。
ユーザビリティ評価での注意点
ユーザビリティ評価は非常に大切なことは誰でも分かっていることですが、評価は人によって大きく変わってきます。開発者である自分たちは特定業界のエキスパートですから、当該カテゴリのユーザビリティを知り尽くしています。また開発に携わる人達はユーザビリティがどのようなイメージスキーマを経て設定されたかを知っています。ですから自分たちが当たり前と思ったスキーマが世間でも常識だろうと考えてしまいがちです。
ユーザビリティ評価は非常に大切なことは誰でも分かっていることですが、評価は人によって大きく変わってきます。開発者である自分たちは特定業界のエキスパートですから、当該カテゴリのユーザビリティを知り尽くしていますし、開発に携わる人達はユーザビリティがどのようなイメージスキーマを経て設定されたかを知っていますから、自分たちが当たり前と思った使用操作スキーマが世間でも常識だろうと考えてしまいがちです。
また開発者はプロジェクトを通して、日々製品を操作して自身の練度が上がっています。しかしユーザは製品の初見時が製品との関わりのスタート地点です。そしてユーザは初めて使うときから快適に使えること求めます。
デザインディレクタはユーザ視点を常に忘れずに、使いやすさを見極めるために、出来るだけ開発の早い段階で、想定ユーザのリテラシーレベルに揃えた被験者が、初見で操作する様子を観察する機会を持つべきです。更に判断を間違えないために想定されるユーザの世代や体型、四肢や手指の大きさなど、考え得る様々な視点から被験者を集めテストすることが必要です。
その際、子供向けの製品では一般品と違い注意が必要です。使いやすさという視点から良かれと思い、簡単な一般的なワンタッチで開閉が出来るバックルによるインターフェースを提案ししたときの例です。こちらの意思に反して保護者からは「常識的なリテラシ（この場合はワンタッチバックルで止めるのでなく紐で結ぶ）の練習にならないから、一般生活で必要なリテラシの練習になる製品を買い与えたい」と訴求されたことがありました。この例はオリジナル性を訴求したいデザインディレクタとしては迷うところですが、製品コンセプトにフィードバックし、企画の練り直しを求められる事例だと思います。
デザインディレクタは様々なユーザとその背後にあるインサイトに注意して、自身の常識が世間の常識とずれていないか、自分たちのユーザビリティ練度も考慮し、自分たちで盲点を作ってしまわないように、あらゆるな視点から考え抜き、客観的な判断が出来るように注意しましょう。
またプロジェクトにおいて後の開発段階になるほど、様々な条件を仔細に詰めるためデザインを大きく変更することはできなくなります。源流に近い開発段階において根拠のない期待によってユーザビリティ評価を甘く見ていると、開発段階が進むにつれ、アジャイルな開発の進め方をしていても、様々な因子が決定され、そこから生まれた相互作用がデザインの変更を難しくします。これはユーザビリティ評価に限ったことではありませんが、ユーザビリティはユーザの満足度に大きく寄与しますから、できるだけ源流段階から評価を厳しく行うよう、細心の注意が必要です。
プロジェクトでのユーザビリティ評価の重要性
前ログの様にISO9241-11ではユーザビリティを「有効さ」「効率」「満足度」で表すとしています。（くわしくはこちら→）
製品が「効率の良さ」を求めて、ランダムアクセスを優先し、短いシーケンスでの浅い操作階層を目指す製品もあります。例としては音楽スタジオで見るミキサーや航空機の操縦席のように操作されるボタン、スイッチの数は膨大になります。
また逆の例として操作ボタンを増やさずに（増やせずに）、長いシーケンスを用いて操作階層を深くしていったユーザビリティの代表がデジカメやコンピュータの各種設定です。
この「有効さ」「効率」「満足度」もユーザビリティを評価する上で大切な因子ですが、製品のカテゴリによってこれら因子間のバランスで大きく変わり、どちらが正解ということはありませんが、例にしたシーケンスの長さと操作階層の深さはトレードオフの関係から両立できず、どのレベルに設定するかで製品の企画そのものが変わります。
想定しているユーザがユーザビリティに何を求めているか判断することは、企画レベルで決めなければいけない優先順位であり、デザイン段階で決めるべきことではありません。
このようなデザイン開発の段階で大きな齟齬を起こさないためには、プロジェクトの源流時点でユーザが使っているシーン（ユースケース）をアイデアスケッチとして描き、チェックすることが大切です。製品をユーザが操作している姿を描き、企画がまとまったプロジェクトは、前述のような大きなズレは起き得ません。このユースケースをスケッチするという簡単な作業でプロジェクトでのユーザビティの完成度が分かりますから、必ずスケッチにして検討しましょう。決して頭の中の想像だけで行なっていけません。
以上がユーザビリティ評価（使い勝手評価）の判断規準について説明しました。詳述は別途おこなっていきたいと思います。
ではまた！
コメント