「なんか使いにくい」
そう感じたことのあるツールが、一つや二つはあると思う。ボタンの場所がしっくりこない。操作の順番が直感と合わない。なんとなく毎回迷う場所がある。でも大きな問題でもないし、慣れの問題かもしれないと思って、そのまま使い続ける。
そうやって、小さな違和感はやり過ごされていく。
でも、その「なんか使いにくい」という感覚は、実はツールの問題だけではないことが多い。その違和感は、自分の業務の流れとツールの設計が噛み合っていないというサインであることがある。つまり、UIへの違和感は、業務設計への問いだ。
この記事は、その視点を一つ整理する試みだ。ツールの使いにくさを「慣れの問題」として閉じるのではなく、「業務の構造を問い直すヒント」として読む観察記録として書いている。
UI違和感はどこで生まれるか
UI違和感が生まれる瞬間は、だいたい決まっている。
「ここをクリックするはずなのに、違う場所にある」。頭の中に「次はこれ」という動きのイメージがあって、それとUIの構造が合わないとき、一瞬止まる。止まった瞬間に、小さな摩擦が生まれる。
「この順番がおかしい」。自分の業務の流れでは、AをやってからBをやる。でもツールはBの入力欄をAより先に出してくる。どちらが正しいというわけではないけれど、自分の流れと合わないから、毎回少しだけ考え直さなければならない。
「なんでここで確認画面が出るのか」。特に問題のない操作なのに、確認を求められる。毎回「OK」を押すだけなのに、その一手間が積み重なっていく。
「この項目、自分には関係ない」。使わない機能やフィールドが並んでいて、本当に必要な部分を探すのに一瞬かかる。
これらの違和感に共通しているのは、「ツールが想定している使い方」と「自分の実際の使い方」がずれているという事実だ。ツールは何かを想定して設計されている。その想定と、使う人の現実が合わないとき、UI違和感が生まれる。
そしてこの「合わない」は、多くの場合、ツールの出来の問題ではなく、「誰の・どんな業務の流れを想定して作られているか」という設計の問題だ。
UI違和感の正体は「文脈のズレ」だ
UI違和感の正体は、文脈のズレだと思っている。
ツールには、それを作った人が想定している「業務の文脈」がある。どういう順番で仕事が進むのか、どのタイミングでどんな情報が必要になるのか、誰がどういう状態でこの画面を開くのか——そういう前提が、UIの設計に埋め込まれている。
だから、同じツールでも、想定された文脈と近い業務をしている人にとっては「使いやすい」と感じ、文脈が遠い人にとっては「なんか使いにくい」と感じる。
たとえば、海外のSaaSは欧米の業務慣行を前提に設計されていることが多い。承認フローの考え方、コミュニケーションのスタイル、情報の粒度——これらが日本の現場と合わないとき、日本語化しても「使いにくさ」が残る。言葉を変えても、文脈は変わっていないからだ。
もっと身近な例で言えば、複数人で使っているツールで、特定の人だけが「使いにくい」と言うことがある。同じツールなのに、なぜ違うのか。その人の業務の流れが、ツールが想定している流れと違うからだ。「使いにくい」と言っている人の業務を見ると、ツールとのズレが見える。
UIは、使う人の業務文脈を映す鏡だ。「使いにくい」という感覚は、その人の業務の流れとツールの設計の間に何かがある、というシグナルだ。
違和感を放置すると何が起きるか
小さな違和感は、放置していると積み重なる。
最初は「慣れの問題だろう」と思う。使い続ければなんとかなる、という感覚でやり過ごす。実際、慣れで解決することもある。でも、業務の流れと根本的にずれている違和感は、慣れでは消えない。慣れるのではなく、毎回少しだけ余分な思考を使いながら操作するようになる。
その「毎回少しだけ余分な思考」が積み重なっていくと、ツールを開くことへの小さな抵抗感が生まれる。意識的ではないかもしれないが、「あのツール、なんか面倒くさい」という感覚が体に染みついていく。
使用率が落ちる。チームで使っているツールの場合、違和感を感じている人ほど、そのツールへの入力が雑になったり、後回しになったりする。「入れなければならないのはわかっているけど、後で」が続く。情報が欠けた状態でツールが運用されていく。
そして最終的に、「結局手動でやった方が早い」という判断が生まれる。ツールを使わずにメモや表計算で管理するようになる。ツールと手動の二重管理が始まり、情報がさらに分散していく。ツールを入れる前より、かえって複雑になる。
これは意志の問題ではない。ツールへの違和感が積み重なって、使い続けることのコストが、使うことのメリットを上回った結果だ。
そしてもう一つ、見落とされやすい問題がある。「結局手動」になったとき、多くの場合、その事実が共有されない。担当者は手動でなんとかしているから業務は回っているように見える。でも実際には、ツールと手動の二重管理が静かに続いていて、その人が休んだり辞めたりしたときに初めて「あそこが詰まっていた」という事実が露わになる。違和感の放置は、業務の属人化を静かに進める。
違和感を「設計の問い」に変える
違和感は、不快なものとして処理するだけでなく、設計の問いとして読むことができる。
「なぜここで止まるのか」という問いを立てることが、その入口だ。
毎回迷う場所があるとしたら、なぜそこで迷うのか。ツールが出してくる選択肢と、自分が必要としている選択肢が合っていないのか。情報の順番が、自分の思考の順番と違うのか。そもそも、そこでその判断をすること自体が、業務の設計として正しいのか。
「なぜここが使われないのか」という問いも有効だ。チームで使っているツールで、特定の機能が誰も使っていない、ということがある。それは機能が悪いのか、使い方を知らないのか、それともその機能が担おうとしている業務が、実はそのタイミングでは発生していないのか。
「なぜここで手動に戻るのか」という問いは、特に重要だ。ツールがあるのに手動でやっている部分は、ツールと業務のズレが最も大きい場所だ。そこを問うことで、ツールの問題なのか、業務設計の問題なのかが見えてくる。
違和感は、業務の流れを可視化するデータだ。「なんか使いにくい」という感覚を起点に問いを立てることで、普段は見えにくい業務の構造が浮かび上がってくることがある。
この問いを立てるのに、特別な分析ツールは必要ない。「毎回止まる場所はどこか」を書き出すだけでいい。チームで使っているなら、「みんながよく迷う場所はどこか」を聞いてみるだけでいい。その答えが、業務設計の問い直しの起点になる。
UIを直す前に、業務を問い直す
UI違和感への対処として、多くの場合に最初に考えるのは「UIを直すこと」だ。ボタンの位置を変える。表示の順番を変える。不要な項目を隠す。それは正しい対処かもしれない。でも、もう一段前に問うべきことがある。
業務の流れは、正しいか。
UIが業務文脈を反映しているとしたら、UIへの違和感は業務の流れへの違和感だ。だとすると、UIを直す前に「業務の流れ自体を問い直す」という判断が、より本質的な対処になることがある。
たとえば、成約後の情報入力の順番がツールと合わないと感じているとする。ツールの入力順を変えることもできるが、もしかしたら「成約後にどういう順番で情報を処理するか」という業務フロー自体を見直す機会かもしれない。ツールに合わせながら業務を整理することで、ツールのUIと業務の流れが自然に一致することもある。
あるいは逆に、業務の流れを問い直した結果、「このツールは自分たちの業務に合わない」という結論が出ることもある。それはそれで、重要な発見だ。UIへの違和感を放置して使い続けるより、早い段階でその結論に至る方が、長期的なコストは小さい。
UIを直すことと、業務を直すことは、どちらが先かという問題ではなく、両方を同時に問うことで初めて、「本当に整えるべきもの」が見えてくる。
今使っているツールの中で、「なんか使いにくい」と感じている場所はどこか。
その違和感を、慣れや個人の問題として閉じるのではなく、「なぜそこで止まるのか」という問いとして開いてみる。その問いが、業務の流れの中にある構造的な問題を指し示していることがある。
UI違和感は、設計の解像度を上げるためのヒントだ。
