心（とプロダクト）を傷つけるエッジケース
エッジケースはまれなことではない。それこそが現実なのだ。名前の変更、共有アカウント、悪意のあるユーザーのような面倒な状況を最初から織り込んでデザインしよう。
少し居心地の悪い話をしよう。あなた方が策定した、あの美しいユーザーフローのことだ。すべてが完璧に機能するようになっている。そして、たいていの場合、ほとんどのユーザーにはとてもよく機能する、あのフローのことである。
もちろん問題になるのは、それが機能「しない」ユーザーの場合だ。彼らは、離婚した親同士が養育権を分担するスケジュールの調整に追われたり、バルセロナでの携帯電話の盗難後に自分のアカウントへアクセスしようとしたり、モンタナの田舎に住んでいるために数分おきにネット接続が途切れる環境でアプリを使おうとしたりするなど、立ち往生しているのである。
エッジケースは難しい
先ほどの事例はいずれもエッジケースの例である。
エッジケースとは、主要なデザインやテストの段階では予期されていなかった、まれなまたは想定外のシナリオのことである。多くの場合、異常なユーザー入力、極端なデータ値、あるいは一般的ではない利用パターンを伴う。その中でも特にまれなものは、コーナーケースと呼ばれることもある。
ただし、ハッピーパス（訳注：理想的なシナリオ）からの逸脱が、すべてそこまで珍しいわけではない。我々が例外だと思っているものの中には、驚くほどよく起こるものもある。長く使いつづけていれば、ほぼすべてのユーザーが、いずれ以下の問題の少なくとも1つには直面するだろう。
考慮に入れていないケース
エッジケースがデザインの隙間からこぼれ落ちるのは、多くの場合、それはデザイナーができれば考えたくはないシナリオだからである。
名前の変更
シナリオ
誰かが結婚するか、離婚するか、性別移行する。シンプルな話に見える。名前フィールドを変更するだけだからだ。ところが、古い名前はURLに埋め込まれているし、メール通知は古い名前がそのまま使われている。その結果、検索は元の名前でしか機能せず、他のユーザーはその人を見つけられない。
名前の変更は、どんな人にとっても日常的に起こることではないかもしれないが、毎日どこかの誰かには起こっているため、面倒な手続きをせずとも、本人が容易に対処できるようにしておくべきである。
デザインの改善
- 名前を編集可能にし、変更をプロダクト内の（URLを含む）あらゆる場所に反映させる。
- 少なくとも一時的には既定で両方の名前が機能する、段階的なロールアウトを計画する。たとえば、メールアドレスが変わるなら、古いアドレスから新しいアドレスに転送されるようにし、ディレクトリで見つけられる必要があるなら、古い名前から新しい名前にリダイレクトされるようにする。
- 名前の入力規則を厳しくしすぎない。たとえば、誰かが自分を「パット・ニューネーム（以前の姓：オールドネーム）」のように表示したいなら、それを許容すべきだ。このアプローチには、名前にスペースや句読点が含まれる人（世界の多くの地域で非常に一般的だ）を苛立たせずに済む、という利点もある。
- 安全上の理由から、古い名前を完全に消去する必要があるユーザーもいることを考慮する。これは、両方の名前を検索可能にするという、ひとつ前の提案をユーザーが上書きできるようにすることを意味する！ どちらのユースケースも完全に妥当なものであり、他者にどのように表示されるかについてユーザーがコントロールできるようにするのは常に良い選択である。
アカウントのロックアウト
シナリオ
メールアカウントがハッキングされる。携帯電話をトイレに落とす。認証アプリが破損する。3年分の作業が入っている自分のアカウントから完全に締め出されてしまう。しかも「サポートへの問い合わせ」フォームはログインしないとアクセスできない。
デザインの改善
- 単一のデバイスに依存しないアカウント復旧オプションを複数用意する。
- ログインしていないときにも、サポートへの連絡先情報を見つけられるようにし、ユーザブルにする。
複数アカウント
シナリオ
仕事用アカウントと個人用アカウントを持っている、あるいはフリーランサーで、クライアントごとに別のアカウントを使っている。ところが、プロダクト側はこれをごく普通のユースケースとして認識するのではなく、ユーザーがシステムを悪用しようとしているかのように扱ってしまう。
デザインの改善
- アカウントの切り替えは容易であるべきだ。切り替えのたびに、ログアウトしてから再ログインする必要がないようにしなければならない。場合によっては、一度サインインすれば、その後に複数のサブアカウントを作成できるようにしたり、同じログイン情報に複数のアカウントをひもづけたりできるようにしてもよい。たとえば、ユーザーがソーシャルメディアサイトやビデオ会議アプリで、仕事用と個人用のアカウントを持っているなら、そのすべてを別々に管理しないで済むようにすべきだ。
- ユーザーがすべてのアカウント間でグローバル設定を共有できるようにするとさらによい。ユーザーが望まない限り、何度もプロフィール写真をアップロードしたり、設定を指定したりする必要がなくなるからだ。一方で、共有設定を必須にしてはならない。仕事用と個人用のアカウントで設定を変えたくなるもっともな理由はいくらでもある。仕事用のZoomにサインインして、毎週のDungeons and Dragonsのプレイで使っているキャラクター名とアバターを同僚全員に見られたいと思う人はほとんどいないだろう。
共有アカウント
シナリオ
その美しいユーザーモデルはおそらく1人のユーザーに焦点を当てたものと思うが、現実の人々はアカウントを共有する。カップルはストリーミングサービスを共有するし、家族は写真ストレージを共有する。ときには、片方が出張に行くと、2人で別々の場所から同時にプロダクトやサービスを使うこともある。誰もが追加料金を支払うのを避けるためにこうしているわけではない。アカウントを連携させるほうが単に理にかなうこともあるからだ。
多くのファミリープランは、デバイスを使っている人に応じて、映画や音楽の履歴を別々に管理できるようにしている。そうすれば、夜のデート中にディズニー映画を、あるいは子どもと一緒に見ているときにホラー映画をおすすめされずに済むからだ。プロダクトがテレビやiPadのような共有デバイスで使われる可能性が高いなら、プロフィールを用意し、実際に誰が使おうとしているのかをユーザーに選ばせるといいだろう。
デザインの改善
- 共有アカウントが存在することを織り込む。
- 個別のプロフィールや子どもの安全機能のような、アカウントの正当な共有のための機能を構築する。
- 共有がセキュリティ上問題になりうるときには、罰するようなかたちにせず、問題があるとわかるようにする。
- 関係の解消や子どもの大学進学のような、ごく普通に起こりうる理由でプロフィールを切り分け、別々のアカウントを作成できるようにして、ユーザーがすべてのデータを失わずに済むようにする。
考えたくないケース
悪意のあるユーザー
シナリオ
誰かが、怒っている元交際相手からプラットフォーム上で嫌がらせを受けている。ネット荒らしが、コミュニティ機能を悪用して他のユーザーを攻撃している。報告システムのせいで、ユーザーはすべてを詳細に記録しなければならず、トラウマを追体験することになる。しかも、悪意のあるユーザーは、追い出しても、新しいアカウントを作って、あっという間に戻ってくる。こうしたことはどこででも起こりうる。職場のチームだけが使うはずのエンタープライズプロダクトも例外ではない。
我々は、自分たちのプロダクトを使う全員が善良で、他者を敬意と共感をもって扱うだろうと信じたい。しかし、残念ながら、掲示板やインスタントメッセージングシステム、ソーシャルメディアを通じた40年以上の電子コミュニケーション（それに加えて、何千年もの……なんというか……人間観察）によって、これはまったくそうではないことが証明されている！
詐欺師、ペテン師、嫌がらせ目的のユーザーは、システムの脆弱性を常に試し、こちらがぞっとするようなやり方でプロダクトを使う。実のところ、我々はすでにあまりにも長い間、デジタルでつながるプロダクトを作りつづけてきたため、「こんなことが起こるとは思わなかった」などと装うことはできないはずだ。嫌がらせや意図的に有害な悪用を防ぐようデザインしないと、ユーザーは、あなた方が傷つけられている人々のことを気にかけていないと受け取るだろう。
デザインの改善
- 安全機能を問題への対応として後づけするだけではなく、最初から組み込んで構築する。
- ブロックと報告を容易に行える効果的なものにする。
- アカウントの作成に多少手間がかかるようにし、大量のなりすまし用捨てアカウントによる自動化された嫌がらせ行為を難しくする。
- 最悪のシナリオを意識的に想定し、信頼と安全性に関するガイドラインを検証する。
- この種の嫌がらせを経験した人々を対象にした調査も忘れずに行う。さらによいのは、彼らと共同でデザインすることだ。
亡くなったユーザー
シナリオ
死は、誰もデザインしたがらない究極のエッジケースである。ユーザーの配偶者が亡くなり、共有の写真アカウントがパートナーのメールアドレスにひもづいていたため、突然、アクセスできなくなる。あるいはさらに悪いことに、アプリを開くたびに、次のように尋ねる通知を突きつけられる：
「Mikeはどこ？ 共同作業に招待しよう！」
最悪のケースの中には、Facebookのようなサイトで自動生成された「○年前の今日」のような写真の振り返りや投稿の記念日祝いによって、ユーザーが大切な人の死をずっと思い出させられるものもある。
ここでは、ユーザー自身にいずれ訪れる死だけでなく、いかなるかたちであれシステムに関わりのある人の死にも備えて計画しておく必要がある。ユーザーが大切な人や友人、ペットの写真を撮っていても、そうした存在はいつまでもそばにいるとは限らない。亡くなった人を不意に思い出させる出来事は深いトラウマになりうる。ユーザーが楽しもうとしているときに、そうした体験をプラットフォーム上で絶対にさせるべきではない。
デザインの改善
- 既存ユーザー向けに、本人が亡くなった後も何らかの形で残せる追悼モードやレガシーモードを構築する。その際、そのユーザーがすでに亡くなっているということがわかるかたちにする。
- デジタル遺産をオンラインで管理するための信頼できる連絡先を指定できるようにする。
- 妥当な期間が経過した後は、非アクティブなアカウントに共同作業の招待を送らない。
- ホリデーシーズンや販促キャンペーンの前後に送られてくる、配慮が必要になる可能性のあるメール通知を停止できるようにする。
- つらい思い出につながる可能性がある画像や投稿については、「楽しい」振り返りの自動生成に含めない。あるいは、少なくとも、そのような振り返りを容易に停止できるようにするか、特定の写真を対象外として指定できるようにする。
目を背けがちな技術的現実
技術的な観点から見てユースケースが複雑すぎたり厄介すぎたりすると、考えていなかったエッジケースが起こることもある。
共同作業
シナリオ
3人が同じドキュメントを編集しようとしているとする。そのうち2人は遅い回線を使っていて、もう1人はモバイル環境である。すると、リアルタイム共同編集機能は、変更が失われ、混乱が増していくことで、リアルタイムの災害と化す。あるいは、さらに悪いことに、そもそもシステムに共同編集機能が組み込まれていないため、人々はPresentation_final_v3.5.keyのようにどんどん長くなるタイトルのファイルをメールで回し合う羽目になる。
デザインの改善
- 非同期とリアルタイムの両方の共同作業を想定してデザインする。
- 編集内容の競合の解決方法を明確に示す。
- 変更が保存されていない場合、それがわかるようにする。
- 複数の編集内容の統合で競合が発生したときは、ユーザーに判断を求める。
- 変更の追跡機能を用意し、変更を承認または却下できるようにする。
データエクスポート
シナリオ
プラットフォームを離れたいユーザーがいる。持ち出す必要のあるデータが3年分ある。ところが、エクスポート機能が生成するCSVは情報の半分が抜け落ちており、他のツールでまったく使いものにならない。
これは、プロダクトマネージャーがうんざりした反応を示すこともある話題だ。結局のところ、プラットフォームを離れる人のことなど誰が気にするのか。ユーザーでなくなるならもうこちらの問題ではない！というわけだ。しかし、実際には、多くの政府がこの点をかなり重く見ている！ ユーザーがサービスの利用をやめるときに自分のデータを持ち出せるようにすることは、良いプラクティスであるだけでなく、多くの地域では法律で義務づけられている。
それに、プロダクトが特定の人に合わなかったとしても、その人にそのプラットフォームから出ていくのにどれほど苦労したかを周りに言いふらしてほしいわけではないはずだ。プラットフォームを離れるときでも、感じが良かったと言ってもらえるようにしておき、彼らのニーズが変わった将来には、戻ってこようとすぐ思われるようにしておこう。
デザインの改善
- エクスポートは、後づけの思いつきではなく、中核となる機能であるべきだ。
- エクスポートしたデータを他の場所にインポートして、エクスポート機能をテストする。
- データ間の関係とメタデータを保持する形式を検討する。
遅い回線
シナリオ
通信が不安定な地域を旅行したり、そうした地域に住んでいたりする。Wi-Fiの電波が弱い建物で働いている。地下鉄に乗ることがある。接続が切れるたびに、アプリは見た目はきれいだが役に立たない読み込み画面になってしまう。
サンフランシスコへBARTに乗って通勤し、通勤中に自分の携帯電話のアプリの90%がたまにしか動作しないか、まったく動作しない状態で数年間を過ごした者として、インターネット接続が完璧でなくても何とか機能するよう、できる限りのことをしてもらいたいと切に願う。
デザインの改善
- オフラインファーストのデザインは、開発途上国向けとは限らない。
- キャッシュを賢く活用し、可能なときはいつでも、何らかのオフラインモードを提供する。
- 同期状態を示す明確な表示を行う。
- ユーザーがローカルで作業し、後で同期できるようにする。
後づけのアクセシビリティ
アクセシビリティは、単一のエッジケースよりはるかに大きな問題であるにもかかわらず、デジタルデザインにおける慢性的な問題である。そして、エッジケースが見落とされるのと似たような理由で見落とされがちでもある。すなわち、考慮するのが難しかったり気が進まなかったりすることがある、ということだ。
視覚や聴覚に支障がなく、両手を使って正確に操作できる人には、プロダクトは非常にうまく機能する。しかし、それ以外の人々にとっては、そのプロダクトは物事を成し遂げるうえで苛立たしい障壁になりうる。そして、「それ以外の人々」は少数ではない！
CDC（：米国疾病予防管理センター）によれば、米国の成人の4人に1人以上が何らかの障害を抱えている、ということを知っていただろうか。我々の多くは、人生のある時点で、視力、聴力、または可動性の衰えに向き合うことになるのである。
言うまでもなく、さまざまなアクセシビリティ要件それぞれに対応して、どのようにデザインを改善するかに関する有益なリソースは数多くある。この記事で、すべきこととすべきでないことの網羅的なリストを提供することはできないが、忘れないでほしいのは、アクセシビリティは後から追加する機能ではない、ということだ。アクセシビリティは、最初から織り込み、計画すべきデザイン制約である。アクセシブルなプロダクトを構築する方法を学び、実際の支援技術と実ユーザーでそのプロダクトをテストしよう！
完璧な人を前提にデザインするのはやめよう
完璧なインターネット接続と完璧な意図を持ち、完璧な人生を生きる完璧なユーザーなど存在しない。人々が実際にどのように暮らしているかという、雑然として複雑な（ときには胸が痛む）現実に向けてデザインする時期が早ければ早いほど、プロダクトはすべての人によりよく役に立つものになる。
「エッジケース」は、必ずしもエッジケースであるとは限らない。それはかなりの割合のユーザーにとっては日常の出来事だ。
次にユーザーフローを策定したり、新機能について意思決定したりするときは自問しよう。このフローや機能がうまくいかなかったらどうなるのか。生活が複雑になったらどうなるのか。この機能が現実の人間の存在がもたらす混沌に直面したらどうなるのか。
そして、そうした状況にも対応できるようにデザインしよう。
記事で述べられている意見・見解は執筆者等のものであり、株式会社イードの公式な立場・方針を示すものではありません。
