Implementation
受け入れ条件で修正完了を判定する
受け入れ条件はチェックリストではなく、修正が事業・UX・アクセシビリティ上の目的を満たしたかを判断する基準です。
ui.design: handoffui.design: report-quality
まず確認する症状
- 修正したが、どの状態なら完了かチームで判断が分かれる。
- 再スキャンで所見が残ったとき、仕様の問題か誤検出か分からない。
なぜ問題か
- 完了条件が曖昧だと、自動開発でも人間レビューでも手戻りが増えます。
- 証跡画像、所見、テスト、計測を同じ基準で見るとPDCAが回ります。
診断で見る指標
目視確認
キーボード操作
スマホ表示
該当checkId
イベント発火
修正方法
最小修正
確認観点を3つに絞る
画面で見える、操作できる、再スキャンで同じ所見が減る、を基本にします。
推奨修正
証跡を残す
スクリーンショット、テスト結果、再スキャンURL、イベント名を記録します。
さらに改善
例外条件を書く
外部タグや認証後画面など、自動診断の限界を明示します。
受け入れ条件
- 01PCとスマホの両方で目視確認し、主なCTAまたは操作対象が迷わず見つかる。
- 02キーボード操作、読み上げ補助、または自動検査で再発しやすい項目を確認する。
- 03修正後にui.designで再スキャンし、同じ所見が残る場合は原因を分解する。
コーディングエージェント向け修正指示
目的: 各修正タスクに、目視、操作、自動検査、再スキャン、計測の受け入れ条件を付けてください。確認不能な条件は人間確認や対象外として分けてください。
参考資料
よくある失敗
- テストが通ることだけを完了条件にし、実際の画面確認を省く。
- 見た目だけを整え、見出し、リンク、フォームラベルなどの意味構造を直さない。
- 1つの指摘だけを直し、同じ原因から出た別画面の再発を確認しない。