ユーザビリティの威力

私が以前とある申請審査業務に関わった際のエピソードを。

その業務は、企業や個人から申請された内容を審査マニュアルに沿って審査し、不備がなければ承認(より上位の審査に回す)、不備があれば申請者に不備内容をお知らせするというものでした。

運営体制は以下。

  • OP(オペレーター):審査担当
  • SV(スーパーバイザー):進行管理兼審査サポート
  • FW(フロアウォーカー):審査要件やシステム設計に関する相談役

大勢いるOPが並行して審査、不明点があればOPはSVに相談し、SVでも迷う場合はFWに判断を仰ぎ、FWでも判断がつかない法解釈などの懸案は外部の専門家に伺いを立てるという運用がなされていました。推測するに、どの申請審査業務も似た感じかと思います。

オペレータたち
同じ条件で集まったオペレータ達であっても個人差があるのだから…

ただし、いざ業務が始まってみるとOPがSVをひっきりなしに呼ぶことになりました。引き当てた申請の内容と審査マニュアルを突き合わせても可否の判断がつかないケースが多発したからです。SVは数人で何十人ものOPを担当するため、個々のSVにはかなりの負荷がかかっていました。

その様子を客観的に見て私が思ったのは「どうにも初動に失敗しているな」です。具体的にはプロジェクトの初期に以下のメンバーも加入させるべきだったと。

  • UXデザイナ
  • テクニカルライター

まず、企業や個人から内容が微妙な申請がなされることが多いのは、申請手引き書の記載や申請受付けWebサイトに起因するところが多かったはずです。申請者はITに慣れた人ばかりではないし、文章読解力もまちまちなのだから、できるだけ迷う要因を減らしてやらないと。

同様に、OPが参照する審査マニュアルも、できるだけ別解釈の余地がなく容易に把握できる内容にすべきです。例えば主語を明確にするだけでも読み手の印象はずいぶん変わります。そして、マニュアルは順次アップデートすると。口頭での周知ではなかなか定着しないし、オペレータ間の個人差も出てしまうので。

そうして、申請システムがユーザフレンドリーではなかったがために申請者を余計に迷わせ、審査マニュアルが平易ではなかったためにOPとSV、そしてFWの負荷が膨れ上がってしまっていました。

逆に言うと、有能なUXデザイナがシステム設計から参加し、同じく有能なテクニカルライターがすべての説明文を監修していれば、エンドユーザー(申請者)もOPも迷うことが少ないため、全体の工数やミスが無駄に膨らむことを防げたはずです。

折しも今は新型コロナ禍の正念場。関連の各種補助金・給付金制度は続いていたり、また新規に始まるかもしれないし、ワクチン接種の受付けや、その他の目的で公的なシステムがこれから作られるかもしれないので、できるだけうまくやってほしいものです。ITコンサル企業がUXデザイナやテクニカルライターを抱えるのもいいだろうし、フリーランスの人材を活用する手もあります。

「どこも変えてない」が優れているわけ

私が制作者だった3年前、クライアントへの校正提出の際は、「今回の修正で変更した箇所」を示す注釈をつけたPDFを添付していました。

でも現役の制作者によると、今クライアントが求めるのはそれではなく、「修正を依頼した箇所以外どこも余計に変えてない」という資料とのこと。なるほど。

「どこを変えたか」と「どこも余計に変えてない」は裏表の関係なので、前者でも同じ目的を果たせそうなものですが、そうではありません。というのも「どこを変えたか」が指し示すのは制作者が把握している変更箇所なので、無意識に変えてしまってたり、レイアウトの都合上、要素を一時的に移動させて修正した後に戻し忘れた場合などは漏れているかもしれないから。

例えばこちらのPDFのペアがあったとします(クリックで拡大表示)。左が修正前、右が修正後のページです。

比較するPDFページのペア

変更箇所は二つ。

  • ページ右上の「エスカ(Esca)」という文字
  • ページ下半分のテキストの分量

でも、もし制作者が「エスカ(Esca)」の部分を見落としたら、「どこを変えたか」のPDFはこうなります。

変更箇所を示した例

四角形がついてないため、クライアントに提出した際に「エスカ(Esca)」の変更は存在しなかったことになってしまいます。その変更が不適切なものであれば重大な申請漏れです。

対して、XORで修正前と後のPDFを読み込んで「透かし表示の書き出し」で書き出せばこの通り。

透かし表示のPDF

赤い囲みは同じでも、ページ右上に「エスカ(Esca)」という青い文字が見て取れます。制作者が気づけば提出前に直せるし、万が一そのまま提出してしまってもクライアント側で気づいてもらえるでしょう。

そう、「透かし表示の書き出し」なら制作者の先入観や見落としに影響されることがなく、「どこも余計に変えてない」という資料になるわけです。

先日リリースしたXOR for Mac Version 1.5は、わずかな操作だけで「どこも余計に変えてない」というPDFを書き出せます。

どこも余計に変えてない証明に

XOR Version 1.5(Mac版)では透かし表示状態のPDFを書き出せるようになりました。

実はこの「透かし表示の書き出し」はこれまでで最もリクエストが多かった機能です。どうやら某大手印刷会社系列の制作では、校正提出の際に「修正を依頼した箇所以外はどこも変えていない」を証明する資料の添付が求められるらしいので。

もちろん制作では無用な変更は行わないのが鉄則だけど、DTPではちょっとした修正であっても周りの要素を移動したり並べ直すことも多く、意図しない不具合が紛れ込みがちです。そして意図していないために発見もされにくく、それが時には刷り直しなどの大ごとにも発展しかねません。

よって「どこも変わっていない」の証明は非常に重要です。これまで各制作者がどのような手段で応えていたのかは伺っていないものの、なるほどXORの透かし表示をPDF出力できれば簡単だし、それで事足りてしまうわけですね。XORの新機能としてリクエストしてくださったのもごもっともです。

本当はもっと早く実現したかったのだけど、懇意の開発者のスケジュールが開かず、この時期のリリースとなってしまいました。何事も理想通りとはいかないものです。

Macのキーボードが壊れた

MacBook Airに接続して使っていた外付けキーボード(Apple純正のUSB接続タイプ)が壊れました。shiftキーを押すと「W」が入力され、deleteキーを押すとミュージックアプリが起動します。こうなるともう役に立ちません。

Apple純正USBキーボード
先日、湯沸かしポットのお湯をこぼして濡らしてしまったのが悪かったのかも…

まあ、このキーボードは10年以上使ったから買い替え時だろうけど、選択肢は少ないのですよね。Apple純正のMagic Keybord(テンキー付きBluetooth接続タイプ)は12,800円(税抜)もしています。

かといって安価なサードパーティ製は、テンキーに「,」がなかったり、Windows PCで一般的なキーの背が高いタイプが多かったりで食指が動きません。

幸い、かつて購入したiMac付属のBluetoothキーボードが残っているので(iMac本体は9年ほど使って故障した際に廃棄済み)、こちらで凌ごうかと。ただし、テンキーがないので、どこまで耐えられるだろうか。乾電池式だし…。

いちばん効く花粉症対

今年も嫌なスギ花粉症シーズンがやってきました。私の場合、例年2月の下旬から春分の日ぐらいまでの約1ヶ月間悩まされます。

花粉症のイメージ

もちろん最強の対策は海外逃避なのだけど今は無理なので代わりの方法を探さないと。ただし私は病院嫌い。市販薬を試したことはあるものの3日間ぐらいで効かなくなったので信用していません。他の手段が必要です。

そうして見つけたのがファスティング、断食です。ただし朝食を抜くという簡単なものでOKみたい。どういう理屈かは解らないけど私には十分に効果があって、通勤しても午前中の症状がかなり和らぎます。鼻水は少し出るけど、くしゃみはずいぶん減って、目のかゆみもかなり軽減されるといった具合に。

朝食を食べないのは不健康なイメージがあるものの1ヶ月限定だし、何より花粉症のあの不快さや不便さに比べれば無視できるデメリットです。

とはいえ昼まで空腹に耐えるのも嫌なので何かは腹に入れておきたいところ。試した限りではヨーグルトはOKでした。加えて冷凍ラズベリー(業務スーパーで購入)も。フルーツはいいのかも。でも卵は症状が多少出ますね。炭水化物はダメっぽいです。肉類は試してません。検証のために食べて症状が出たら憂鬱な1日になってしまうから。

もちろん昼食や夕食を摂れば後にその影響が出るけど、お昼に屋外に出て花粉を浴びなければ夕方までは大丈夫。夜も帰宅時間を遅くすれば花粉をあまり浴びずに済みます。

まあ、この方法が万人に効くかは解らないけど、花粉症持ちにとっては症状が軽くなるだけでも好ましいだろうから気が向いたら試してみてください。