パフォーマンス・エラー

パフォーマンス・エラーというのは、手順を踏んで作業を進める際に犯してしまう間違いのこと。

ロジャーはこれをさらに以下の3つに分けます。

モーターコントロール・エラー

操作に関するエラーです。

クリックする場所を間違えてしまったり、スワイプの指の本数を間違えてしまったり。

UI設計者はここにも気を配らなければなりません。

「間違えるユーザーが悪い」といってしまえばそこまでですが、そのようなエラーも想定してこそ、「UI設計をしている」と言えるのです。

京王線の券売機

Suica/Pasmoを1000円分チャージしようと千円札を挿入し、「Pasmo」と書かれたボタンを押すと……

！！！！

こうなってしまったら取り消しボタンを押して、また最初からやり直すしかありません。

このストレスに苛まれた人が日本中にどれだけいることでしょうか！

1000000000歩ゆずってそういう仕様しかつくれなかったとしても、「PASMO購入またはチャージをご希望の場合、お金は後から入れてください」という注意は、実際にお金を入れたあとにしか現れないのです。

この切符販売機のUIとして悪いところは、

• そもそもエラーとはいえない動作をエラーにしたこと。
• エラーを事前に起こさないようにする導線がひとつもないこと。

大まかにこの2つといえるでしょうか。

box-sizing問題

前回記事にもしましたが、CSSには「widthを指定しているのに、paddingやborderを追加するとその分widthを広げてしまう」問題が健在します。

全国の、いや世界中のデザイナーがこの問題について「なぜbox-sizingのデフォルト値がborder-boxではないのか」と怒りを露わにしていることでしょう。

なぜならば、デザイナーがあるクラスに対してwidth: 400px;と指定した瞬間、それは「このクラスの幅は400pxである」という宣言をしているのと同義であり、それ以上にもそれ以下にもなることは例外的であると考えられるからです。

その例外がpaddingやborderなど常日頃から使うプロパティで引き起こされてはたまったもんじゃありません。

このエラーは、「多くの人が想定する結果と実際の結果が折り合わない」という重大な欠陥といえますね。

ユーザーの視点にたつってなに？

クリエーターや開発者はえてしてユーザーの視点にたつことが求められます。

ウェブやアプリについての知識がほとんどない者として、そしてそのサービスを初めて使う者として、自分のつくったものに触れなければならないのです。

それは容易なことではありませんが、ユーザーの視点にたつにあたってまず必要なのは、「普通であること」ではなく「考えぬくこと」です。

何も考えないユーザーである必要はありません、それはユーザーテストで他人にテストしてもらえばいいのです。

UI設計者は逆に、UI設計者にしかできないことをやる必要があります。それはすなわち、あらゆるヒューマンエラーを想定し、そのエラーへの対策を用意周到に講じておくことでしょう。

何も考えずにただ触ることはUIから逃げているのと同じです。

自分のアプリやサービスについて、どういう人がどういう風に考えて触るのかを想定し、考え続けることが、ヒューマンエラーを抑えるにあたって最低限おこなうべき行動なのではないでしょうか。