UCDを行う場合、仮説検証プロセスを回すことになりますが、事前にペルソナの作成やプロトタイプへのユーザビリティテストを行うこと、つまり事前の仮説・検証にコストをかけることに対し、
「そんなことをやってどれくらい効果が出るのか。効果を説明できるのか。」
と言われるということを良く聞きます。
（お客様からだったり、上司からだったり、メンバーからだったり。）
でも、その一方で、何の疑問も持たずにシステム性能については事前に仮説・検証を行ってたりします。
例えば、
システムの検証がしっかり行われていなかったためにレスポンスが遅くなり、ユーザーの使い勝手が悪くなる
ということに対しては、敏感なのに対し、
ユーザーの検証がしっかり行われていなかったために機能の提供方法を誤り、ユーザーの使い勝手が悪くなる
ということに対しては、非常に鈍感です。
どちらもユーザーの満足感を下げる要因であるのに。
LiveValidationは、入力フォームの入力内容をリアルタイムでチェックし、問題があるとメッセージを表示してくれるJavaScriptライブラリです。スタンドアローンバージョンと、prototype.jsを使うバージョンの２つが公開されています。
具体的な動作はデモでご確認ください。
ボタンを押した時点でチェックをするというのが従来の方法でしたが、問題があった場合にその場で気づかせることにより、ユーザービリティの向上につながります。
入力制限はシステム側の都合による制限であることがほとんどなので、このような細かい気配りでユーザーにストレスを与えないことが大切です。
少し前に、マックで夜を明かした時のこと。
時間は沢山あったので、本をじっくり読んでたのですが、ふと壁に貼ってあったポスターが目に入りました。
期間限定。２時からスナックタイム１５０円。
どうやら100円マックのドリンクとフードがセットで１５０円になるらしいのです。
ですがそこで考えました･･･。
今は深夜３時。これは時間内？時間外？
■よくある（？）例
システム開発を行っているとこんなことがよく起こらないでしょうか？
などなど
このような事が起こる原因の一つに、「多くの場合、自分も顧客もユーザーではない」ということが挙げられます。
頭では「ユーザーが使いやすいように」とか「ユーザーにとって便利なように」と分かってはいても、いざ考えるときには、「ユーザー」が「自分」に置き換わってしまっていませんか？
しかし、それは仕方ないことなのです。なぜなら、いくら頑張ったところで（悲しいですけど）結局自分はユーザーではないからです。
ではどうすればよいかと言うと「ユーザーに登場してもらう」のが一番です。
そう、その登場してもらい方こそが「ペルソナ」なのです。
先月発売したばかりの、「Webサイト設計のためのペルソナ手法の教科書
「Webサイト設計のための」と書かれている通り、ペルソナ作成や分析の元となるデータがアクセス解析だったりという部分はありますが、手法としてはWeb以外にも適用できる部分が大きいと思います。
ペルソナについては少し勉強したことがあるけど実際使ったことが無い人や、作ってみたけどこのペルソナで正しいのかという疑問を持っている人にお勧めです。
以下メモ。
more…
「「新規ウインドウで開くことの是非」は正しいか」で書いたように「同一ウインドウで開くか新規ウインドウで開くかはユーザーの判断に委ね、サイト側は両方の手段を提供する」という方針に至ったわけですが、実際問題全てのリンクに手動で両方のタイプを用意するのは面倒です。
そこで、Fsikiさんの「新しいウインドウを開くべき？」という記事内で公開されている、newwin.jsのような、「既存のリンクに自動的に新しいウインドウで開くアイコンを追加してくれるスクリプト」のようなものを使うという方法があります。
このスクリプトは新規ウインドウで開くためのアイコンリンクを自動で付加してくれます。
ポイントとしては、
という手軽さとカスタマイズしやすさが挙げられます。
以前、「新規ウインドウで開くことの是非」という記事の中で、「なるべく新規ウインドウで開かないほうが良いが、境界をはっきりさせるため別サイトへのリンクは新規ウインドウで良い」ということを書きました。
しかし、<a>要素のtarget属性は、HTML4 Transitionalで非推奨となっており、HTML4 Strict、XHTML1.0 StrictおよびXHTML 1.1では削除されています。つまり、target属性は廃止される方向に向かっているということですね。また、ユーザビリティの観点からも、最近では新規ウインドウで開くかどうかはユーザーの判断に委ねるべきであるという考えが広まってきているようです。
そもそも、ブラウザに「新しいウインドウ/タブで開く」機能が備わっているのですから、それが使い勝手がよければ問題にならないのではないかと思うのですが、現状の機能だとユーザーがストレス無く同一ウインドウか別ウインドウかを使い分けるのは難しいと思います。
2008/03/14(金) 13:30-19:30の日程で人間中心設計推進機構(HCD-Net)による講演会兼意見交換会「ビジネスに役立つHCD」が開催されました。
HCDについて概念や具体的な手法だけでなく、実際ビジネスに適用する際の色々な情報を得たいと思い参加させていただきました。
内容としては、ビジネスでHCDを利用する際の情報についての講演
と、参加者の社内でのHCDの状況や問題点に関する意見交換を行いました。
「ガイドラインアプローチ（ユーザビリティの守）とは？」では、あらかじめ定めたガイドラインを遵守することによって、最低限のユーザビリティを確保するというアプローチ方法について説明しました。
例えば、「リンクにはアンダーラインをつける」のような細かい部分に関しては、あらかじめ決めておいたガイドラインに則ることが非常に大切ですが、大きな部分になればなるほどあらかじめ決めておけないような事柄が増えてきます。
また、ガイドライン方式であらかじめスパッと決めてしまうと、良い意味でも悪い意味でも一般的なものになってしまいます。
この一般的ということがいい方向に働けばいいのですが、ユーザビリティはユーザーやその利用状況、目的などによって変わるものですから、逆にそれがユーザビリティの低下を招いてしまう可能性もあります。
ガイドラインアプローチでは、本当に最適なのか？ということについて何も裏づけが無いというところが弱みです。
そこで必要になってくるのが、検証や評価というアプローチです。これを当サイトではユーザビリティの破と呼んでいます。
jQuery TextAreaResizerはjQueryのプラグインとして提供されているスクリプトです。jQuery TextAreaResizerを使うと、ユーザーが自由にテキストエリアのサイズを変えられるようになります。規約の「テキストエリアのサイズは可変にしておく」で書いたように、テキストエリアが小さくて使いづらいというような点を解決し、ユーザビリティを高めるのに効果的です。
?
動作サンプルを見る限り、textareaだけでなく、iframeのサイズを変更できるようになるみたいですが、iframeのほうは処理が重くて高速に動かした場合にあまりきちんとは動きませんでした。でもtextareaのほうは大丈夫みたいですね。リサイズ中は微妙に白くなるなどのエフェクトもあり、分かりやすいと思います。
