デフエンジニアの会アドベントカレンダー19日目に参加しています。
はじめに：音前提の通知(UX)への違和感
多くのアプリ・システムが「アラート音」「通知音」を前提としているが、音が使えない環境は案外多い。
例を挙げると
- 聴覚障害の人はこれが使えない。
→全部が、ではない。私の場合は、仕事用PCではGoogleチャットとSlackチャット通知、Excelの作業完了通知などがくるのだが、それぞれ音のパターンが違うのでそれで聞き分けている。
ただ、全く聞こえない場合＆補聴器を使ってない場合は無理。 - 電話会議中やリモート会議中（特にプレゼン中に通知音がなるのは致命的。。。）
- 夜間のスマホ（これはもう真夜中みんなが寝てる間に鳴るスマホの音を想像していただければわかるだろう。迷惑。）
- 工事音・雑音がひどい環境（全然聞こえない場合あり）
- 図書館やオフィス、電車の中（音が出せへん文化…今もあるのだろうか、いやある）
ちなみに上記は最初の項以外、きこえる人と働いたり、きこえる家族と一緒に生活しているうちに気付いたことばかり。
音なし環境というのは聴覚障がいを持つ人だけの問題ではなく、誰もが日常的に直面する問題なのだ。
それを解決するために、きこえるとか聞こえないとかは関係なく、音に依存しない通知設計、をユニバーサルデザインの視点で考えてみたい。
そもそも通知とは何ぞや
- 気づかせる（いわゆる注意喚起。地震速報とか）
- 状態を伝える（エラーなのか正常終了したのかを知らせる）
- 行動を促す（通知したうえで、行動を促すメッセージを入れる）
- 履歴を残す（今までの通知を残して通知が来ていることに気づかせる）
があるが、音による通知が使えないと、1.は完全に弱くなってしまう。
結果として通知に気づかない、変化を見逃す
といった問題が起こる。
重要なのは、
音が使えない前提でも、これら4つの役割をどう補完するか
を設計として考えることだと思う。
音に頼らない通知設計パターン
ここからは、音を使わずに通知の役割を果たすための
設計パターンを整理する。
パターンA：視覚アテンション型
最も基本的な方法、で、今利用されているのが、視覚的にユーザーの注意を引く設計。
- 画面の目立つ位置にバナーを表示
- 色の変化で重要度を示す
- 軽いアニメーションで目を引く
- ヘッダーやフッターなど、常に視界に入る位置に配置
音がない場合、「どこに表示されるか」は非常に重要で、
画面外やスクロールの下に表示される通知は、
音がなければほぼ確実に見逃されるため避けたいところ。
また、色だけに意味を持たせるのではなく、
アイコンや配置と組み合わせることで、認識しやすくなる。
ちなみに、私は仕事上の通知設計で、成功の場合はチェックアイコン、
失敗の場合は赤ランプ（救急車をイメージするもの）を
つけて、ぱっと理解できるようにしている。
日本が発明した絵文字って最高だよね。絵文字ってギャルが発明したと
されているけど、ほんますごいわ。
パターンB：状態遷移型
音なし環境では、
「状態が変わったことが分かるUI」 が重要。
例えば、
- 「保存中…」から「保存しました」への変化
- ローディング表示から完了表示への切り替え
- エラー時に明確なメッセージと視覚的強調を出す
何も変化しない画面では、
ユーザーは処理が進んでいるのか止まっているのか判断できんので、
状態の変化を視覚的に表現すること自体が通知の役割を果たす。
パターンC：永続型通知
一瞬表示されて消える通知は、
音がないと特に見逃されやすくなる。
iphoneなんかは特にそうだ。
そこで有効なのが、永続的に残る通知。
- 未読数を示すバッジ（メールやLINEのアプリとかでよくあるよね）
- ステータス表示（ドロボとかファイル共有システムでよく見るね）
- ログや履歴として残るメッセージ（通知センターのログ）
これらは、
「その瞬間に気づけなくても、後から確認できる」
という安心感をユーザーに与える。
現に私も通知センターのログはよく利用する。
音に頼らない設計では、
この「後追いできる仕組み」が重要になるだろう。
パターンD：コンテキスト型
通知を「別枠で出す」のではなく、
ユーザーが今見ている文脈の中で完結させるパターン。
例えば、
- フォーム入力エラーを入力欄の横に表示する
- ボタン操作後に、ボタンの表示が「完了」に変わる
- ファイルアップロード後に、対象アイコンがチェックマークに変わる
この方法の強みは、
ユーザーの視線移動を最小限にできる点。
音が使えない環境では、
「通知がどこに出たか分からない」こと自体がストレスになる。
コンテキスト型の通知は、 その問題を根本的に回避可能なのが強み。
特に業務システムや入力画面では、
派手な通知よりも、この設計が有効な場面が多い。
パターンE：触覚フィードバック
触覚フィードバック、いわゆるバイブレーションは、
音の代替手段として有効な場合がある。
私が一番、音の代用として注目しているのがこれだ。
- 操作に対する即時フィードバック
- 重要なアクションの強調
その時その時によって正常終了したらピコン、エラーだったらブーーーーーっ
とバイプレーションを使い分ければ、明らかにステータスなどの通知が可能だ。
ちなみに上の擬音はきこえない私のイメージなのであしからず。
要するにバイプレーションのパターンを使い分けたら通知可能だという話。
そしてこれ、私がPS5の体験ブースで体験したのだが、ゲームの内容によって
パイブレーションが使い分けられてて、それが触感的にわかりやすかった。
これをスマホで応用、つまりアプリでバイプレーションを使いこなせれば
実用的なものに代わるはずだと思っている。
ただし、現状、触覚フィードバックには明確な制約がある。
- 端末やOSに強く依存する
- Webでは利用できる環境が限られてしまう（PCじゃ無理なんだ。。。無理なんだよ。。。）
- 過度に使うと不快感を与えることがあるのが残念
そしてもう一つある大きな制約というより問題であるのは、
これだけでは通知としての性能は低いこと。
バイプがあっても、結局通知の内容がわからなければ意味がないからね。
そのため、視覚による通知の補助手段として使うのが適切。
とはいえ、触覚フィードバックの「気づかせる」力は大きなものだと思う。
ただ、今はWebやスマホでは無理（ではないが、シンプルなのが多い）でも、
おそらくいつかは実現するのではないかと思っている。
バイプレーションの技術をオープンソースにして、
アプリでパイプの機能を使ったものが開発されてほしいなと思うし、
他にもたとえばバイプレーション機能をもたせたマウスを開発するとか。
PS５でもできるのだから、不可能ではないはずだ。
私は残念ながらプログラミング専門でエンジニアではないので他力本願になってしまうが
そういうマウスが発明されるのを楽しみにしている。
エンジニアの皆さん、これ見たらぜひ開発してください（他力本願）
設計時に陥りな落とし穴と必要なチェックリスト
音なし環境での通知設計では、
次のような問題が起こりがちだ。
- 画面外やスクロール下に通知が出る
- 色の違いだけで重要度を表現
- 通知がすぐ消えてしまい、後から確認不可
- 通知の表示位置が分かりにくい
- 状態変化がなく、処理が進んでいるか判断不可
これらは、
音がある前提では気づきにくい問題だが、
音が使えないと一気にUXの破綻につながる。
そのため、下記のようなチェックリストが必要だと思う。
- 視覚だけで重要な通知が判別できるか
- 画面外で通知が発生していないか
- 状態の変化が分かるUIになっているか
- 見逃しても後から確認できる仕組みがあるか
- 色・形・位置など複数の手段で伝えているか
- 触覚フィードバックに依存しすぎていないか
まとめ
音が使えない環境での通知設計は、
聴覚障害のある人だけのためのものではなく、
静かなオフィス、騒がしい現場、夜間のスマートフォン利用など、
誰もが音に頼れない状況でアプリを使っているのだ。
音に依存しない通知設計は、
「気づける」「迷わない」体験を作るための重要な要素なので、
本記事で整理した考え方が、
通知設計を見直すきっかけになれば幸いだ。
そして願わくば、触覚フィードバックの分野の技術が進展することを願って
筆を置く。
わしも負けずにプログラミングがんばらにゃいかん。