WWDC Quick Look 💓 By SwiftGGTeam
中文 EN 日本語
The process of inclusive design

The process of inclusive design

AccessibilityInclusionDesign
元の動画を見る

ハイライト

Apple は、インクルーシブ デザインを、チーム、研究、設計、開発、テスト、リリース、反復を通じて実行されるワークフローとして定義し、開発者がさまざまな人々の本当のニーズを早い段階で発見できるようにし、リリース後のエクスペリエンス ギャップを修正するコストを削減します。

主要内容

チームがアプリケーションを構築するときは、よく知っているユーザーから始めるのが最も簡単です。チーム メンバーは同じ都市に住んでおり、同じネットワークを使用し、同じ言語を読み、同様の身体能力と文化的経験を持っています。要件のレビュー中に、誰もが製品が主要なシナリオをカバーしていると感じるでしょう。

リリース後まで問題が判明しないこともよくあります。誰かが遅いネットワーク上で重要なプロセスを完了できません。 VoiceOver (スクリーン リーダー) を使用している人にはカスタム コントロールの音が聞こえません。写真や思い出の中に元パートナーや亡くなった親族の姿が映り、本来は温かいものであったものがストレスの原因になる人もいます。

Appleは今回のプレゼンテーションで新しいフレームワークをひとつも発表しなかった。まず多様性の軸を使用して視野を広げ、次にアイデア出し、設計、開発、テスト、立ち上げ、および立ち上げ後の反復に包含チェックを組み込むプロセスをレイアウトします。

この方法により、タイミングの問題が解決されます。オンライン化する前に包括性のみをチェックする場合、多くのデザインを変更するのは困難になります。リリース日、リソース、アーキテクチャはすべて制約になります。各段階に配置することで、チームは誰のフィードバックを聞きたいか、どのくらいの期間保持するか、うまく機能しない機能を削除するかをより早く決定できます。

チームから始めましょう

Apple は、多様なチームを持つだけでは十分ではないと強調しています。チームメンバーにさまざまな視点を表明してもらう必要があり、これらの視点を意思決定に織り込む必要があります。小規模なチームは、早期に雇用して文化と製品の前提を確立するため、これを特に早期に行う必要があります。

簡単なアプローチは、「文化の適合」を「文化の追加」に変更することです。採用やコラボレーションを行う際には、どの視点が欠けているかを問い、既存のチームに最もよく似た人材だけを探すことは避けてください。

プロセスから始めましょう

セキュリティやプライバシーなどの包括プロセスには、時間を確保する必要があります。アイデアの段階で、その製品が人類にどのような利益をもたらすかを考えてください。設計段階で極端な使用シナリオを検討します。開発段階でアクセシビリティと国際化を事前に計画します。テスト段階には、支援技術を使用するさまざまな背景を持つ人々が参加しました。リリース フェーズでは、トレードオフを特定し、未解決の問題に対する計画を立てます。

実際のフィードバックから反復を続ける

Photos Memories の例は、起動後も反復を続ける必要があることを示しています。このシステムがより多くの興味や休日のテーマを生み出すことを望む人がいたため、チームはスポーツ、趣味、国際的な休日のカタログを拡張しました。誰かが誰かのことを思い出したくない場合、チームは「機能を減らす」および「機能を再度使用しない」のコントロールを追加します。

これらの変更は特定のフィードバックから生まれています。チームはまず話を聞き、次に計画を立て、その後再びインタビュー対象者に確認していきます。

詳細

多様性の側面: まず、デフォルトの視点が非常に狭いことを認めます。

(00:53) Apple は、チームが多様性の側面を中心にユーザーについて考えることを推奨しています。スピーチに記載されている要素には、階級、文化、民族性、言語、教育、信条、人種、性別、性的指向、年齢、能力、障害、利き手、身長のほか、場所、ネットワーク接続、デバイスのアクセス条件が含まれます。

let diversityAxes = [
    "class",
    "culture",
    "ethnicity",
    "language",
    "education",
    "beliefs",
    "race",
    "gender",
    "sexualOrientation",
    "age",
    "abilitiesAndDisabilities",
    "handedness",
    "bodyMeasurements",
    "location",
    "internetConnectivity",
    "deviceAccess"
]

func reviewQuestion(for axis: String) -> String {
    "What will the experience be for people across \(axis)?"
}

for axis in diversityAxes {
    print(reviewQuestion(for: axis))
}

キーポイント:

  • diversityAxesプレゼンテーションの冒頭に挙げた多様性の側面から。
  • languageチームにコピーライティング、ローカリゼーション、入力フォーマットを確認するよう伝えます。
  • abilitiesAndDisabilitiesアクセシブルな設計と支援技術のテストに対応します。
  • internetConnectivity低速ネットワーク、オフライン、トラフィックが制限されたシナリオに対応します。
  • reviewQuestion(for:)抽象的な次元を復習の質問に変えます。
  • for axis in diversityAxes製品レビューにあらゆる側面を取り入れ、チームが最もよく知っている人だけをチェックすることは避けてください。

このコードは、デザイン レビュー スクリプトまたは PR テンプレート ジェネレーターに組み込むのに適しています。その機能は、チームに思い出させることです。新しいコアプロセスが追加されるたびに、どの次元がチェックされ、どの次元がまだ証拠が欠けているかを明確にする必要があります。

コンセプト段階: まず、なぜそれを行うのか、誰のためのものなのかを答えます。

(09:32) Apple はアイデアの段階で 2 つの質問をします。なぜこのアプリやゲームを作るのか、そして誰のためのものなのかです。チームは、それが誰に役立つのか、そしてそれが人々の行動、成り、感じ方に何を助けるのかを説明する必要があります。

struct ProductIdeaReview {
    let purpose: String
    let humanGood: String
    let targetPerspectives: [String]

    var isReadyForDesign: Bool {
        !purpose.isEmpty && !humanGood.isEmpty && !targetPerspectives.isEmpty
    }
}

let review = ProductIdeaReview(
    purpose: "Help people revisit meaningful photos and videos.",
    humanGood: "Enable people to relive moments they care about.",
    targetPerspectives: [
        "people with different hobbies",
        "people celebrating regional holidays",
        "people with difficult memories around specific people"
    ]
)

print(review.isReadyForDesign)

キーポイント:

  • purpose「なぜこれを作るのですか？」に相当します。
  • humanGood「あなたは人間のどのような利益に奉仕しようとしていますか?」に相当します。スピーチの中で。
  • targetPerspectives特定のグループの人々や状況について書く場合、単に「すべてのユーザー」と書くことはできません。
  • isReadyForDesignチームが空の目標を持って設計に入るのを防ぐため、3 つのフィールドすべてにコンテンツが含まれている必要があります。
  • 例の写真記憶のシーンは、講義後半の写真記憶の事例から来ています。

このモデルは製品要件文書で使用できます。新しい機能を開始する前に、担当者にこれら 3 つのフィールドに入力するよう依頼してください。記入できない場合は、面接を続けるか範囲を絞る必要があります。

開発フェーズ: アクセシビリティと国際化を事前に計画する

(12:23) Apple は開発者に対し、開発の開始時にアクセシビリティと国際化を計画するよう促しています。標準の UIKit、AppKit、および SwiftUI コントロールは、デフォルトで UIAccessibility メソッドを実装します。カスタム コントロールとビューには追加の時間が必要です。

import SwiftUI

struct ReminderSettingsView: View {
    @State private var isEnabled = true

    var body: some View {
        Form {
            Toggle("Show Memories", isOn: $isEnabled)
            Text("Use standard SwiftUI controls before building custom controls.")
        }
    }
}

キーポイント:

  • import SwiftUISwiftUI フレームワークの紹介。
  • ReminderSettingsViewは、共通設定ページの例です。
  • Toggleこれは標準の SwiftUI コントロールであり、講演では標準の SwiftUI コントロールがデフォルトでアクセシビリティをサポートしていると指摘しています。
  • Textシステム テキスト コントロールを使用して、システムのテキストおよびアクセシビリティ システムにアクセスします。
  • Formプラットフォームの標準フォーム構造を使用して、カスタム レイアウトのアクセシビリティ コストを削減します。
  • 音声リマインダーのカスタム コントロールには追加の計画とテストが必要なため、このコードはカスタム コントロールを作成しません。

開発時には、各インターフェイスの複雑な適応を減らすためにシステム コントロールの使用を優先してください。本当にコントロールをカスタマイズする必要がある場合にのみ、VoiceOver ラベル、フォーカス順序、動的フォント、およびキーボード ナビゲーションを開発タスクに追加します。

機械学習機能: 画像の説明は相互同一性を処理する必要がある

(14:56) Apple は、iOS 15 のマークアップ説明機能を導入しました。これにより、ユーザーは写真に独自の説明を書くことができます。 VoiceOver Recognition は、機械学習を使用して画像の自然言語説明を生成することもできます。研究チームは後に、写真を見ただけで人の性別を見分けるのは不可能であるため、モデルが人の性別を説明する際には注意が必要であることを発見した。

struct ImageDescriptionInput {
    let hair: String
    let clothing: String
    let setting: String
}

func genderNeutralDescription(for input: ImageDescriptionInput) -> String {
    "A person with \(input.hair) wearing \(input.clothing) and standing \(input.setting)."
}

let input = ImageDescriptionInput(
    hair: "curly black hair",
    clothing: "a red and white striped shirt",
    setting: "in front of a building"
)

print(genderNeutralDescription(for: input))

キーポイント:

  • ImageDescriptionInput写真から説明できる外観情報のみが保存されます。
  • hair音声例の「黒髪の巻き毛」に相当します。
  • clothing音声例の「赤白ストライプシャツ」に相当します。
  • setting音声例の「建物の前」に相当します。
  • genderNeutralDescription(for:)使用A person、チームが最終的に採用したジェンダー中立的な記述の方向性と一致しています。
  • コードは推測されませんmale、female、non-binaryまたはtransgenderというのも、演説では写真からは人の性別を知ることはできないと明言されているからだ。

この例は、機械学習関数の出力の後処理に適しています。モデルは服装、髪型、シーンを識別できますが、製品のコピーライティングでは、不確かなアイデンティティを事実に書き込むことは避けるべきです。

テスト フェーズ: 支援テクノロジーをテスト計画に書き込む

(21:34) テスト段階では、さまざまな背景を持つ人々が製品を使用できるようになり、支援技術やさまざまな機能が追加されます。この講演では、VoiceOver の基本を学ぶ、テキストを最大化する、キーボードを使用してアプリやゲームを操作するという 3 つの簡単なチェックインについて説明します。

let inclusiveTestPlan = [
    "Navigate every primary flow with VoiceOver",
    "Increase text size to the maximum level",
    "Navigate the app or game with the keyboard",
    "Collect feedback from testers with diverse backgrounds",
    "Review and prioritize feedback before release"
]

for item in inclusiveTestPlan {
    print("[ ] \(item)")
}

キーポイント:

  • VoiceOverトークからのテストのアドバイス。
  • maximum levelそれに応じて、テキストのサイズを最大に調整します。
  • keyboardアプリ キーボードを使用してアプリやゲームを操作します。
  • diverse backgrounds対応により、さまざまな背景を持つテスターがエッジ シーンを発見できるようになります。
  • Review and prioritize feedbackスピーチにおける「フィードバックを聞いて見直し、優先順位を付ける」に相当します。
  • print("[ ] ...")起動前チェックリストを生成できます。

このタイプのリストはテスト計画に含める必要があり、本番稼働前に個人的な記憶に残すべきではありません。 Apple は、インクルージョン テストの目標を KPI (主要業績評価指標) として追跡することも推奨しています。

発売後: Photos Memories はフィードバックを使用して製品管理を変革します

(24:31) Photos Memories チームは 2 種類のフィードバックを受け取りました。ユーザーのカテゴリーの 1 つは、より多くの趣味や休日のテーマを見たいと考えており、チームは武道、スケートボード、サッカー、さらにはディワリ、旧正月、イード アル フィトル、ハヌカなどのフェスティバルにまで拡大しました。別のタイプのユーザーは特定の人物のことを思い出したくないため、チームはキャラクターの出現頻度を制御する機能を追加しました。

enum MemoryPersonPreference {
    case featureLess
    case neverFeatureAgain
}

struct MemoryFeedbackResponse {
    let personName: String
    let preference: MemoryPersonPreference
}

let response = MemoryFeedbackResponse(
    personName: "Alex",
    preference: .neverFeatureAgain
)

print(response.preference)

キーポイント:

  • MemoryPersonPreference2 つの反復結果を状態として音声に書き込みます。
  • .featureLess人をあまり見せないでください。
  • .neverFeatureAgain該当する人物は表示されなくなりました。
  • MemoryFeedbackResponseユーザーのフィードバックから生まれた製品の設定を表します。
  • personName実際の製品では、ユーザー独自の写真文字ライブラリから取得する必要があります。
  • スピーチでは、人によって想起内容に対する許容範囲が異なると述べたため、この例では 2 レベルの制御が維持されています。

(32:39)チームはまた、サムダウンアイコンが誰かを憎んでいるような印象を与える可能性があることも発見しました。愛する人の死などのシナリオでは、この暗示がユーザーを傷つける可能性があります。最終的にチームは、より中立的なグリフに落ち着きました。

let rejectedGlyph = "hand.thumbsdown"
let selectedGlyph = "minus.circle"

func glyphForSensitivePreference() -> String {
    selectedGlyph
}

print(glyphForSensitivePreference())

キーポイント:

  • rejectedGlyphチームがもはや取らない否定的なアイコンの方向性を示します。
  • selectedGlyphよりニュートラルなアイコンの方向を示します。
  • glyphForSensitivePreference()設計と開発による共同レビューのための選択を一元化します。
  • この例は、開発者に思い出させます。アイコン自体もコピーライティングであり、態度を伝えるものです。

このケースの焦点は閉ループです。チームはまずコメントを読み、次にインタビュー、次にデザインを行い、検証のためにスケッチをインタビュー対象者に持ち帰ります。最初のバージョンのフィードバックが十分でない場合は、引き続き反復していきます。

重要ポイント

1. リリース前の包括性チェックページを作成する

  • やるべきこと: 内部ツールでリリースごとに 1 ページのチェックリストを生成し、多様性の側面、VoiceOver、最大フォント サイズ、キーボード ナビゲーション、遅いネットワーク、ローカリゼーションをカバーします。
  • 実行する価値がある理由: スピーチでは、導入前の一時的な修正だけでなく、プロセス全体を通じてインクルージョンを行う必要があることが強調されました。
  • 開始方法: を使用しますdiversityAxes配列から PR テンプレートまたはリリース チェックリストを生成し、各チェックを責任者と期限にバインドします。

2. ユーザー コンテンツに「まれに表示される」および「二度と表示されない」コントロールを追加する

  • 何をすべきか: ユーザーが写真、日記、ソーシャル レビュー、音楽レビュー、その他の機能における特定の人物、場所、またはテーマの頻度を制御できるようにします。
  • 実行する価値がある理由: Photos Memories は、自動呼び出しが困難な経験を引き起こす可能性があると説明しています。コントロールすることで被害が軽減されます。
  • 開始方法: まず次のようなものを定義しますMemoryPersonPreference列挙し、推奨、並べ替え、またはフィルタリング ロジックの設定を使用します。

3. 画像説明エディターを作成する

  • 対処方法: ユーザーがアップロードした画像にテキストの説明を追加し、共有するときに説明を表示できるようにします。
  • 実行する価値がある理由: 講演では、iOS 15 のマークアップ記述により、写真の説明を共有しながら渡すことができるため、視覚障害のあるユーザーが画像を理解できるようになると言及されました。
  • 開始方法: 画像アップロードプロセスに追加descriptionプレビューを提供するフィールドには、識別可能なコンテンツに焦点を当て、身元の推測を避けるための説明が必要です。

4. 機械学習の出力に包括的なレビューのレイヤーを追加する

  • やるべきこと: 画像説明、推奨理由、自動タグなどの機械学習出力に対してルールレビューを実施し、入力からは確認できない同一性判定をフィルタリングします。
  • 価値がある理由: VoiceOver Recognition チームは、性別に依存しない画像の説明が、視覚障害や弱視を持つユーザーにサービスを提供し、さまざまな性自認を尊重できることを発見しました。
  • 開始方法: まずモデルの出力サンプルを収集し、性別、年齢、人種、文化に関連する単語にマークを付けてから、後処理ルールと手動レビュー プロセスを記述します。

5. ユーザーインタビューを反復ポータルに変える

  • やるべきこと: 否定的なフィードバックに応じて 1 対 1 のインタビューを手配し、特定の瞬間、感情、改善のための提案を記録し、プロトタイプを使用してインタビューを返します。
  • 実行する価値がある理由: Photos Memories チームは、インタビューを通じて、Feature Less の最初のバージョンでは十分ではないことを発見し、その後、Never Feature Again を追加しました。
  • 開始方法: フィードバックの背景にタグを追加し、「含まれていないと感じた」、「間違いを思い出した」、「支援技術を使用できなかった」などのケースを除外し、予定を優先します。

関連セッション

コメント

GitHub Issues · utterances