POSTD PRODUCED BY NIJIBOX

POSTD PRODUCED BY NIJIBOX

ニジボックスが運営する
エンジニアに向けた
キュレーションメディア

POSTD PRODUCED BY NIJIBOX

POSTD PRODUCED BY NIJIBOX

ニジボックスが運営する
エンジニアに向けた
キュレーションメディア

FeedlyRSSTwitterFacebook
Piet Hadermann

本記事は、原著者の許諾のもとに翻訳・掲載しております。

bad_vending_ui

前のブログ記事 を書いた時、「訓練された目ならば、不親切なソフトウェアを結構な頻度で簡単に見抜けるようになる」ということに気づきました。

それは初対面の人に第一印象を抱くのに似ています。私たちは初めて会った人の印象を判断するのに コンマ1秒もかからないそうです

人を判断するのとは違い、ユーザインターフェースの良しあしを判断することは、私たちが(今はまだ)本能的に行っていることではありません。しかし、たった数分で、もしくはもっと早く、ユーザインターフェースがじっくり考えられて作られたものか、ちょっとした思い付きで作られたものかどうかを判断することは可能です。

どうして判断がついたのかや、どんな警告サインが出ていたのかについては確証がなかったため、私は注意を払い、メモを取ることにしました。

以下は私が気付いたことです。

用語/ラベルの使い方があまりに総称的/一貫性していない

これはユーザの言葉ではなく、むしろプログラマが考えつく言葉です。

私は先日、イベントオーガナイズ用のソフトウェアをトライアルしてみました。ビジターや参加者は時に”ユーザ”と呼ばれていて、私をひどく混乱させました(ビジターではないユーザやログインを、後から付け加えることもできました)。

私の勤める企業では、かつて新しいウィザードのようなプロセスのプロトタイプを作りました。同じ人物を表現する3つの異なる言葉を使用したいくつかのスクリーンから成り立っていました。 トラッカー、カードホルダー、スターター です(言うまでもなく、これは商品化される前に修正されました。この話をすると『続・夕陽のガンマン』という映画のことを思い出してしまうのですが、何故なんでしょう? )。

プロセスがどのように機能するか分かっている時は、まったく気づかないでしょう。しかし、初めてこのソフトウェアに直面した時、この3つの言葉が同じ人物か、別々の役割を持った異なる人物について話しているかどうか、疑問に思うかもしれません。誰が知るところでしょうか?

自分のユーザを混乱させたくはありません。そこでホールウェイテストが役立ちます。

Excelと開発用IDE − ユーザインターフェースとして

もし、経験の少ない非技術畑の人にユーザインターフェースのデザインを頼むとしたら、大抵の場合、Excelでデザインされたようなものが出来上がるでしょう。Excelはほとんどの人が知っている制約のないアプリケーションです。”実際の”ソフトウェアとして使えるようになる前に、ソフトウェアの多くはExcelシートから取りかかっています。

一方で、開発者は全てを自分たちのなじみのあるユーザインターフェースとして見なすコツを知っています。すなわち開発用IDEです。

eclipse-ide_sm

意味の分かりにくい、イメージだけのアイコン/ボタンの使用

すでに意味するところが分かっているのであれば、既存のアイコンイメージは理にかなっているように見えます。しかし、初めてアイコンを見たときは、何を意味するのか手がかりを持っていません。どうしても必要でない限り、アイコンの代わりに言葉を使ってください。たとえアイコンの方がよく見えるとしてもです。

undefined icons UI

あいまいで分かりにくいエラーメッセージ

(プログラマが書いたものです)

Pointless error dialog
訳注:不正な値です。許容値のみ入力してください。

入力欄に不正な値を入れるか、入力必須項目を空欄にして、エラーメッセージを確認してみましょう。

(エラーメッセージを読まずに)どこにエラーがあるのか、すぐに分かりますか? それとも、「全ての必須項目を入力してください」、「入力内容が正しくありません」といった包括的なメッセージが表示されてしまいますか?

更にひどいのは、データベースのエラーメッセージが表示されるケースでしょう。または、エラーは何も表示されずに、知らぬ間にデータが失われていた、なんてこともあるかもしれません。

過剰なテキストや説明

「もしXであれば、YとZを入力してください。もしXでないなら、Zだけを入力し、Zが1でない場合はYも入力してください」

他の国の事は分かりませんが、このような説明を見ると、ベルギーで所得税の申告書を記入している気分になります。

これは、ステップやコードの追加を控えることで”利口”ぶるプログラマの特徴を、実によく表していますね。このようなものが品質監査を通ってはいけません。顧客にとって負担になるだけでなく、サービスデスクに不要な問い合わせが殺到する原因にもなります。

はるか昔(実際には20世紀)、私はこの種の説明を含む”メッセージ実装ガイド”(MIG)に基づいて、EDIソフトウェアを開発していました。当時は、たくさんの入力項目と、ケースごとの入力必須項目を示すMIGの説明を表示するだけで、ユーザにとって分かりやすく改善しようとは考えていませんでした。そんな調子で再検討をしないのが、私たちのやり方だったのです。失敗から学ぶ能力はあって良かったと今は思います。

Message Implementation Guide
訳注:
通常Bring Parcels(BPNとBPI)において、重量と容積の両方、またはいずれか一方は不要である。
輸送時は、総重量と総容量の両方、またはいずれか一方のみが有効である。
特殊素材への義務付けがある場合に限り、危険物に対して純重量を使用する。

EDIメッセージ実装ガイドより引用

この不合理さが更に当たり前になっていくのを感じたのは、一式のフォームで、類似性のある2種類のメッセージ(データ構造)を”実装”するのが賢明だろうという意見が出た時です。

このように手間を省いている時点で開発者は、混乱してサポートに電話をかけるユーザのことなど全く考慮していません。

風変わりで無意味、そして複雑な日時フォーマット

例として「 2015-06-29 15:44:21 EST 」を挙げましょう。おそらくこれは、ソフトウェアに使われている言語やフレームワークの種類によらず、ほぼデフォルトに設定されている未フォーマットの出力です。

この表記は15:44やJun-29 15:44(ヨーロッパとアメリカのユーザには分かります)とすれば十分かもしれません。

場合によっては、より人間味のある「1時間以内」、「昨日」、「来週」といった相対表記にすると、もっと良くなるでしょう。

マウス操作に頼りすぎる

Tabキーでの移動順序が論理的でなく、キーボードによるショートカットが設定されていないと、全ての操作をマウスで行わなければいけません。

これは、マウスが発明された頃からユーザを悩ませてきました。

要領を得ないメッセージボックスが多すぎる

「本当に文書を印刷しますか?」

上記のメッセージボックスが表示され、続けて印刷ダイアログが開くユーザインターフェースがありますが、印刷ダイアログでも操作をキャンセルすることは可能です。

誤って印刷するということは、最初の段階で許可が必要なほど悪い事なのでしょうか?

一貫性のない警告ダイアログ

少し前にCRMのようなアプリケーションを使う機会がありました。

連絡先のフォームを保存せずに閉じようとすると、 「本当に保存せずに終了しますか?」 というダイアログが表示されました。

また、勤務先のフォームを保存せずに閉じようとすると、 「終了前に変更を保存しますか?」 というダイアログが表示されました。

「はい」をクリックすると、その結果が2つのダイアログで異なることは明らかです。

使用開始時にユーザインターフェースが何も設定されていない

初期状態の”きれい”なインストレーションやアカウントには、使い始めるための説明がありません。

ユーザが最初に何をしなければいけないのかを示すべきです。

「まだ連絡先が登録されていないので、”連絡先を追加”をクリックして1つ目の連絡先を追加してください」
「初めてのご利用ですね。チュートリアルをご希望の場合は こちらをクリックしてください

このようにすれば、まず何をしたらいいのかが分かります。

見た目が散らかっている

不必要な分割線やグループ分けのボックスが使われている場合、これらが減れば、もっと見やすくなるはずです。同じボックスに格納してグループ分けするよりも、位置でグループ分けする方が便利でしょう。

ひどいユーザインターフェースを扱っていることを、もっと簡単に知る方法をご存知ですか?
コメント欄に投稿して教えてください!

ソフトウェアの仕様だけに留まらないユーザフレンドリー

私が以前、勤めていた企業では、とても長いメールをユーザに送っていました。そのため、「メールを貰ったんだけど、内容を説明してくれる?」と、電話でユーザが問い合わせをしてくることがよくありました。

メールに書かれていない内容について問い合わせがあると、その答えを追加してメールのテンプレートを変更することもありました。正しく、論理的な対処法のようですが、実際にはどうでしょう?

メールが長くなりすぎて読むのが大変だと思う人がいなければ、素晴らしい対処法でしょう。

また、顧客が電話をしてきた時、サポートチームはソフトウェア内で使用されている用語で説明していました。「申し訳ありません。まだバリデーションが”アンバリファイド”の状態です」といった具合です。残念ですがほとんどの場合、顧客にとってこの説明は無意味です。顧客は、何が”バリデーション”で、なぜ”アンバリファイド”なのかが分かりません。そしてサポートチームのメンバーはイライラしてきます。なぜなら、”愚かなユーザ”に繰り返し同じことを説明しなければならないからです。

ユーザインターフェースをフレンドリーにすることは、繰り返しを伴うプロセスです。頻発する問題を修正または解明できるよう、サポートリクエストの確認を常時行うべきです。

皆さんは賛成ですか? 反対ですか? ひどいユーザインターフェースかどうか、もっと簡単に分かる方法をご存知ですか?
コメント欄に投稿して教えてください!

こちら で私のメーリングリストに登録して、更に面白く、洞察に満ち、有益な(役に立たない場合も)投稿をお楽しみください!

トップの 写真rdolishny 氏が撮影した作品で、クリエイティブ・コモンズ・ライセンスのCC BY-NC 2.0と定められています。

監修者
監修者_古川陽介
古川陽介
株式会社リクルート プロダクト統括本部 プロダクト開発統括室 グループマネジャー 株式会社ニジボックス デベロップメント室 室長 Node.js 日本ユーザーグループ代表
複合機メーカー、ゲーム会社を経て、2016年に株式会社リクルートテクノロジーズ(現リクルート)入社。 現在はAPソリューショングループのマネジャーとしてアプリ基盤の改善や運用、各種開発支援ツールの開発、またテックリードとしてエンジニアチームの支援や育成までを担う。 2019年より株式会社ニジボックスを兼務し、室長としてエンジニア育成基盤の設計、技術指南も遂行。 Node.js 日本ユーザーグループの代表を務め、Node学園祭などを主宰。