design-justice

デザイン・ジャスティス：公平性を重視したデジタルデザイン

周縁にいる人々のためにデザインし、中心にいる人々にも恩恵をもたらしましょう。安定した電話を持たず、住居が不安定で、トラウマの経験があり、デジタルリテラシーが低い人にも使えるなら、誰にとってもより使いやすくなります。

理念

デザイン・ジャスティス（Sasha Costanza-Chock）＋トラウマに配慮したデザイン＋デジタル公平性を重視したデザイン

基本原則：デザイン上の決定によって最も大きな影響を受ける人々をデザインプロセスの中心に置き、例外的なケースとして扱わないことです。

使用する場面

✅ 次の用途に使用します：

• 回復支援や社会復帰支援を受ける人々向けのアプリ
• 政府・市民向けテクノロジーアプリケーション
• 社会的に弱い立場にある人々向けの医療ポータル
• 住居・給付金の申請
• 法律扶助や裁判所のセルフヘルプツール
• 非営利団体のサービス提供プラットフォーム
• 共有端末や公共端末で使われるあらゆるアプリ

❌ 次の用途には使用しません：

• 企業向けB2B SaaS（制約が異なります）
• マーケティングファネルの最適化
• ゲーミフィケーションやエンゲージメントの最大化
• ソーシャルメディア機能
• 一般的な「見た目をきれいにしてほしい」というUXの依頼

---

判断ツリー：どのパターンを適用しますか？

User has unstable phone number?
├── YES → See: Authentication Without Stable Phones
└── NO → Standard auth OK

User may lose internet mid-task?
├── YES → See: Offline-First Design
└── NO → Standard web patterns OK

User may be on shared/public device?
├── YES → See: Shared Device Privacy
└── NO → Standard session management OK

Form is complex or emotionally difficult?
├── YES → See: Trauma-Informed Forms
└── NO → Standard form patterns OK

User has history of system trauma?
├── YES → Apply ALL trauma-informed patterns
└── UNKNOWN → Assume YES for civic/legal/benefits apps

---

パターン1：安定した電話がなくても使える認証

アンチパターン：電話番号優先の認証

初心者の考え：「誰もが電話を持っているし、SMSによる2要素認証は安全です」

実際の状況：

• かつて収監されていた人の25％は、安定して電話を利用できません
• 住居が不安定な間は、電話番号が頻繁に変わります
• プリペイド式の電話は、支払いが滞ると利用停止になります
• SMSによる2要素認証のせいで、重要なサービスから締め出されてしまいます

経緯：

• 2020年以前：SMSによる2要素認証はベストプラクティスと見なされていました
• 2020年以降：Code for Americaがアクセス障壁を記録しました
• 2024年以降：市民向けテクノロジーでは、メール優先＋バックアップコードが標準として広まりつつあります

適切なパターン

ニーズ	パターン	実装
メインの認証	メール優先	メールを識別子として使い、電話番号は任意にします
2要素認証	複数の方法	メール、バックアップコード、またはケースワーカーによる確認
アカウント復旧	印刷可能なコード	書き留められる使い捨てコード
認証の代替	信頼できる仲介者	ケースマネージャーが組織のメールアドレスを使って本人確認します
必須のアクセス	アカウント登録不要モード	アカウントなしでコア機能を使えます

実装チェックリスト

□ Email is primary identifier (phone optional)
□ Backup codes can be printed/written
□ Case worker recovery pathway exists
□ Core features work without login
□ Sessions are not device-locked
□ Phone number changes don't lock accounts
□ "Forgot password" has non-SMS option

---

パターン2：オフライン優先／断続的なアクセス

アンチパターン：常時オンラインという前提

初心者の考え：「『接続なし』というエラーを表示すればいいだけです」

実際の状況：

• 公共図書館のコンピューターには利用時間の制限があります
• 月の途中でモバイルデータを使い切ることがあります
• シェルターのWi-Fiは不安定です
• ユーザーがフォームを完成させられる機会は一度きりかもしれません

適切なパターン

ニーズ	パターン	実装
データの保持	ローカル優先	データをすぐにlocalStorage/IndexedDBに保存します
フォームの状態	自動保存	送信時だけでなく、フィールドが変更されるたびに保存します
送信	バックグラウンド同期	操作をキューに入れ、接続が戻ったら同期します
UIのフィードバック	楽観的な更新	UIをすぐに更新し、バックグラウンドで同期します
進捗	どこからでも再開	中断した場所から正確に再開できるようにします
状態	同期状態の表示	「ローカルに保存済み」／「同期中...」／「最新の状態」
機能の低下	オフラインでも適切に動作	ネットワークがなくてもコア機能を使えます

実装チェックリスト

□ PWA with service worker caching
□ All form data saves to localStorage on every change
□ Clear sync status indicator visible
□ Offline mode tested (airplane mode)
□ Background sync when connection returns
□ No data loss on connection drop (verified)
□ Multi-step flows don't timeout
□ Minimal asset downloads (text-first views available)

コードパターン：自動保存フック

// Save form state on every change
function useAutoSave(key: string, data: any) {
  useEffect(() => {
    localStorage.setItem(key, JSON.stringify({
      data,
      savedAt: new Date().toISOString(),
      synced: false
    }));
  }, [key, data]);

  // Return saved data on mount
  return useMemo(() => {
    const saved = localStorage.getItem(key);
    return saved ? JSON.parse(saved).data : null;
  }, [key]);
}

---

パターン3：共有端末／公共端末でのプライバシー

アンチパターン：セッションの永続化

初心者の考え：「ログイン状態を記憶するとUXが向上します」

実際の状況：

• 図書館のコンピューターは複数の人が使います
• シェルターのコンピューターは共有されています
• 前のユーザーのデータが見えると、安全上のリスクになります
• ドメスティック・バイオレンスの被害者にはプライバシーが必要です

適切なパターン

ニーズ	パターン	実装
デフォルトの状態	プライバシーモードをオン	機密情報を自動保存しません
ログアウト	目立つボタン	メニューの奥に隠さず、すぐに見つけられるようにします
タイムアウト	警告＋自動ログアウト	「残り5分です。続けますか？」
フォーム	自動入力をデフォルトで無効化	機密性の高いフィールドでは、ブラウザーの自動入力を無効にします
モード切り替え	「公共のコンピューターですか？」	ワンクリックで、プライバシーをさらに強化するモードに切り替えます
Cookie	セッションのみのオプション	ブラウザーを閉じたときに消去します

実装チェックリスト

□ "Remember me" is UNCHECKED by default
□ Logout button visible on every page
□ Session timeout with save-progress warning
□ Sensitive fields have autocomplete="off"
□ Incognito mode suggested in UI for public computers
□ No cached personal data after logout
□ "Working on a shared computer?" toggle available

---

パターン 4：トラウマに配慮したフォームとフロー

アンチパターン：官僚的な尋問

初心者の考え方：「効率化のため、最初にすべての情報を集める」

実際には：

• 長いフォームは圧倒感を引き起こし、途中離脱につながります
• 赤いエラー文字は羞恥心を引き起こします
• 法律用語は不安を生みます
• 突然の要件は罠のように感じられます
• 「あなたの話を聞かせてください」という入力欄は、認知的な負担が大きくなります

適切なパターン

ニーズ	パターン	実装
長さ	分割して進捗を表示	短いセクションに分け、それぞれを保存します
言葉遣い	平易な言葉	小学6年生から中学2年生程度の読解レベルにします
複雑さ	1ページに1つの質問	難しい話題に適用します
進捗	明確なインジケーター	「全5ステップ中2番目」を常に表示します
入力検証	許容度の高い入力	自動で書式を整え、表記の違いを受け入れます
デフォルト	スマートな事前入力	推測できる情報を事前入力します
ヘルプ	隠さずインラインで表示	ヘルプテキストをモーダル内ではなく、常に見えるようにします
フロー	スキップして後で戻る	任意項目で先に進めなくすることは決してありません

トーンのガイドライン

✅ 使用する表現：

• 人を中心にした言葉遣い：「有罪判決を受けた経験のある人」
• 明確な所要期間：「3〜5日以内に審査します」
• 気持ちへの配慮：「この手続きには、もどかしさを感じることがあるかもしれません」
• 励ます表現：「順調に進んでいます」

❌ 避ける表現：

• 恥を感じさせる言葉：「あなたの犯罪歴……」
• 曖昧な所要期間：「折り返しご連絡します」
• 責任を押し付ける表現：「入力が完了していません……」
• 罪悪感を前提とする表現：「あなたの犯した罪……」

色とビジュアルのガイドライン

✅ Calm palette:
- Success: Soft green (#4a9d9e), not aggressive lime
- Warning: Warm amber (#d4a03a), not alarming yellow
- Error: Muted terracotta (#c97a5d), not aggressive red
- Background: Cream/warm neutrals

❌ Avoid:
- Aggressive red for errors
- High-contrast warning colors
- Flashing or pulsing elements
- Visual "alarm" states

実装チェックリスト

□ No form longer than 5 fields per page
□ Progress indicator on all multi-step flows
□ Help text inline, not in tooltips/modals
□ Forgiving validation (formats automatically)
□ No required fields that aren't truly required
□ "Skip for now" on optional sections
□ Calm color palette (no aggressive reds)
□ Person-first language throughout
□ Clear "what happens next" on every screen

---

パターン 5：記録の抹消／記録の整理に特化した対応

アンチパターン：利用者が知識を持っていると決めつける

初心者の考え方：「利用者は事件番号を知っている」

実際には：

• 何年も前の事件番号を覚えていない人もいます
• 法律用語は分かりにくいものです
• 郡や管轄区域の境界は明確ではありません
• 書類を入手できない場合があります

適切なパターン

ニーズ	パターン	実装
対象となるか	まず資格を確認	情報を集める前に、対象となるかを表示します
書類	複数の提出方法	メール、ファクス、郵送、対面、写真
所在地	自動検出	管轄区域を利用者に調べさせないようにします
記録	検索ツール	利用者が自分の事件番号を見つけられるよう支援します
用語	平易な言葉	すべての法律用語を定義します
所要期間	明確な見通し	「ほとんどの案件は60〜90日かかります」
手数料	免除を目立たせる	手数料免除をデフォルトの申請経路にします

実装チェックリスト

□ Eligibility checker before signup/info collection
□ Case number lookup tool or "I don't know" option
□ County auto-detected from address
□ Document upload alternatives (not just scan)
□ Legal terms have inline definitions
□ Expected timeline stated clearly
□ Fee waiver is default, not hidden option
□ "Not eligible" includes explanation WHY

---

Code for America の原則

市民向けテクノロジーのゴールドスタンダード：

1. 自動適用 ＞ 申請ベース - 記録のある人に手続きを求めない
2. 原則無料 - 手数料免除は自動適用とし、申請させない
3. 政府が作業を担う - 個人に負担をかけない
4. 影響を受ける人々と共同設計する - 人々を対象としたユーザー調査だけで終わらせない
5. データの欠落を前提とする - 不完全な記録に対応できるよう設計する
6. バックエンドを自動化する - スタッフの作業時間を最小限にし、手作業によるボトルネックをなくす

---

クイック監査チェックリスト

市民向け／法律関係／給付申請のアプリケーションで、次の項目を確認してください：

AUTHENTICATION
□ Can user sign up with just email?
□ Is there a non-SMS account recovery option?
□ Do core features work without login?

OFFLINE/INTERMITTENT
□ Does form data survive connection loss?
□ Is there visible "saved" indicator?
□ Can user resume exactly where they left off?

SHARED DEVICES
□ Is "remember me" unchecked by default?
□ Is logout button prominent?
□ Does session timeout with warning?

FORMS
□ Is reading level ≤8th grade?
□ Are there ≤5 fields per page?
□ Is help text inline (not hidden)?
□ Are required fields truly required?

TONE
□ Is language person-first?
□ Are timelines explicit?
□ Is error messaging non-blaming?
□ Are colors calm (no aggressive red)?

LEGAL/EXPUNGEMENT SPECIFIC
□ Is eligibility checked first?
□ Are fee waivers prominent?
□ Is "I don't know my case number" handled?

---

参考資料

• /references/authentication-patterns.md - 認証実装の詳細
• /references/offline-first-patterns.md - PWA と同期のパターン
• /references/trauma-informed-language.md - トーンと言葉遣いのガイド
• /references/code-for-america-learnings.md - CfA のケーススタディ

主要な参考文献

• Design Justice Network の原則
• Code for America の設計原則
• C4 Innovations の公平性に関する取り組み（ホームレス支援システム）
• Innovation Unit の路上生活者向けデジタルアクセス
• Sasha Costanza-Chock：『Design Justice』（2020）