문제 심각도와 수정 검증

수정은 관찰에서 시작합니다

P01은 내역을 눌러도 참가 미확정 의미를 설명하지 못했고 P03은 위치 도움을 받은 뒤에야 내역을 찾았습니다. 두 사건은 같은 화면에서 발생했지만 고칠 대상은 상태 안내와 다음 행동의 연결입니다. “사용자가 좋아하는 디자인”처럼 넓은 결론으로 바꾸지 않습니다. 수정 기록은 관찰 ID, 막힌 과업, 원인 가설, 바꿀 문구, 확인할 기준을 연결합니다. 근거를 찾을 수 없는 수정은 취향 제안으로 별도 분류하고 관찰 결과처럼 말하지 않습니다.

심각도는 빈도와 다른 축입니다

task-blocking은 과업 목적을 달성하지 못하게 막는 문제, recovery-risk는 잘못된 재시도나 오해로 복구를 어렵게 하는 문제, cosmetic은 과업 의미에 영향을 주지 않는 표현 문제로 연습에서 정의합니다. 같은 화면에서 세 번 나온 문제라도 단순 띄어쓰기라면 업무 영향은 다를 수 있습니다. 한 번 나온 상태 오해라도 참가 확정으로 착각하게 하면 우선 확인할 가치가 있습니다. 분류 이름만 적지 않고 어떤 행동이 왜 위험한지 severityReason에 씁니다.

관찰과 원인 가설을 나눕니다

O01에서 승인 대기를 확정으로 질문한 것은 관찰이고 “접수라는 단어를 확정으로 이해했을 가능성”은 해석입니다. 다른 원인은 행사 규칙을 이미 잘못 알고 있었거나 카드 배치가 상태 설명을 가렸기 때문일 수도 있습니다. 한 관찰에서 원인을 확정하지 않습니다. 수정안은 그 가설을 시험하는 수단이며 수정 뒤 같은 과업으로 의미를 확인합니다. 원인을 가정했다는 이유를 숨기면 성공적인 한 번의 재확인을 전체 원인 해결로 과장하기 쉽습니다.

두 수정은 다른 확인 질문을 가집니다

R01은 “신청 접수 · 승인 대기”를 참가 미확정이 드러나는 안내로 바꾸며 상태를 올바르게 설명하는지 확인합니다. R02는 “신청 내역 확인”을 “본인 신청 상태 확인”으로 바꾸며 스스로 경로를 선택하는지 확인합니다. 같은 UI-normal과 AC-normal을 참조하지만 관찰 ID와 목적은 나뉩니다. 두 수정 후의 최종 message와 nextAction은 같은 화면에 적용되므로 충돌하지 않아야 합니다. 개별 수정안만 읽고 서로 다른 최종 화면을 만들지 않습니다.

정책을 문구로 확정하지 않습니다

수정 문구는 “신청이 접수되었습니다. 아직 참가가 확정되지 않았습니다. 승인 결과는 본인 신청 내역에서 확인해 주세요”입니다. 승인 대기가 정원을 확보했다거나 특정 시각에 승인된다는 약속은 하지 않습니다. D01의 승인 인원 집계 제안과 동시 승인 조건은 아직 미결입니다. 상태 의미를 쉽게 설명하는 개선과 업무 규칙 변경을 구별합니다. 문구가 이해하기 쉬워도 확정되지 않은 정책을 약속하면 실제 업무에서 새로운 오류를 만들 수 있습니다.

원본과 수정안을 따로 보존합니다

spec.json은 앞 모듈 원본으로 유지합니다. usability.json의 revisions.before는 원본 화면 문구와 같아야 하고 after에 수정 후보를 씁니다. 원본을 직접 고치면 무엇을 왜 바꾸었는지 검토할 출발점이 사라집니다. 수정마다 screenId와 criteriaId를 붙이고 criterion에 수정 뒤 관찰 가능한 조건을 적습니다. 자동 검사는 이 연결과 원본 보존을 확인하지만 문구가 사용자에게 적절한지는 실제 관찰과 동료 리뷰가 필요합니다.

인수 기준을 행동으로 고칩니다

“승인 상태를 쉽게 보여 줍니다”보다 “저장 성공 뒤 참가 미확정 안내와 본인 신청 상태 확인 행동이 표시되고 선택하면 A001 상태가 있는 본인 내역 카드로 이동합니다”가 확인하기 좋습니다. 상태 의미 이해는 사용자 과업으로, 표시·이동 계약은 구현 검증으로 나누어 확인합니다. 화면에 문구가 존재한다고 사용자가 이해했다고 판정하지 않습니다. 기존 AC-normal의 given과 when을 유지하고 어떤 결과 약속을 보완했는지 이유를 남깁니다.

권한과 실패 상태를 함께 리뷰합니다

다음 행동 이름을 바꾸어도 본인 데이터만 보여 준다는 접근 조건은 유지되어야 합니다. 수정안 리뷰에서는 AC-permission-denied의 타인 데이터 제거, AC-network-unknown의 접수 여부 확인 경로를 함께 읽습니다. 이번 텍스트 카드에서 서버 소유권 검사가 실행된 것은 아닙니다. 화면 수정이 다른 상태의 안전 조건을 해치지 않는지 문서로 검토하고 구현 뒤 회귀 검사할 목록을 남깁니다. 문서 리뷰 통과와 실제 서버 검증 통과를 섞지 않습니다.

재확인은 같은 목적을 묻습니다

v2 초안을 보여 줄 때 “바뀐 버튼이 더 좋아 보이나요”라고만 묻지 않습니다. T01과 같은 출발 조건·완료 규칙으로 본인 상태와 참가 확정을 확인하게 합니다. 버튼 이름을 알려 주면 재확인에서도 독립 탐색을 측정할 수 없습니다. revisionIds에 R01과 R02를 연결하고 버전은 v2로 적습니다. 어떤 수정안을 적용한 화면을 확인했는지 남겨야 기존 화면을 본 성공을 수정 효과로 보고하는 실수를 막습니다.

같은 참여자와 새 참여자의 한계를 씁니다

이전에 v1을 사용한 참여자는 경로를 기억해 v2에서 빨리 끝낼 수 있습니다. 다시 같은 사람을 관찰했다면 익숙해진 영향이 있다는 점을 남깁니다. 새 참여자를 사용해도 경험과 조건이 달라 직접 비교에 한계가 있습니다. 제공 V01은 새 가상 참여자 P04가 28초에 완료한 사례입니다. v1의 실패가 v2에서 모두 해결되었다고 쓰지 않고 이 사례에서 경로와 상태 의미가 확인되었다고 범위를 좁혀 설명합니다.

재확인 결과가 실패여도 지우지 않습니다

수정안에서도 참가 확정으로 말한다면 그 결과를 남기고 문구·상태 배치·업무 설명 중 무엇을 다시 볼지 질문합니다. 실패한 재확인을 제거하면 수정의 근거가 한쪽으로 치우칩니다. 이번 미션은 모든 재확인이 성공해야만 제출할 수 있는 구조가 아닙니다. 실패나 unknown도 이유와 다음 확인 계획을 설명하면 학습 근거가 됩니다. 구조 검사 통과는 계획·기록·참조가 연결되었다는 뜻이며 실제 문제 해결을 보장하지 않습니다.

수정 완료와 제공 완료를 구별합니다

revisions.status는 proposed입니다. 텍스트 초안을 고쳤다는 사실이 제품 적용이나 운영 배포를 뜻하지 않습니다. 담당자가 확인할 일은 문구 적용, 본인 내역 연결, 키보드 이동, 오류 상태 처리 등으로 나눕니다. 실제 구현이 없으므로 이번 결과를 서버 기능 검증으로 보고하지 않습니다. 학습자는 업무 이해를 검증한 자료와 후속 기술 확인을 함께 전달하여 개발팀이 어떤 약속을 구현해야 하는지 이해하도록 돕습니다.

수정 기록 오류를 읽습니다

FAIL revisions.R01: 수정 전 문구 불일치는 before를 spec.screens의 UI-normal과 대조하라는 뜻입니다. 관찰 ID 참조 오류는 O01처럼 sessions에 실제 존재하는 ID를 확인합니다. 모든 수정의 재확인 필요는 R02가 V01.revisionIds에서 빠졌는지 확인합니다. 숫자가 두 건이라는 이유만으로 같은 수정문을 이름만 바꾸어 제출하지 않습니다. 동료는 각각의 관찰이 서로 다른 확인 질문으로 연결되는지 읽고 자동 검사 밖의 의미를 검토합니다.

남은 문제는 다음 행동으로 인계합니다

빈 내역 UI-empty와 실제 키보드 이동은 이번 T01 가상 기록에서 확인하지 않았습니다. remaining에는 질문·담당·다음 확인을 적고 막연히 “추가 개선”이라고 쓰지 않습니다. 전체 보고에는 출처, v1 분류, 두 수정의 근거, v2 한 사례의 결과, 미검증 범위를 포함합니다. 동료가 관찰 ID에서 수정안까지 따라갈 수 있고 정책 미결과 기술 검증 과제를 찾을 수 있으면 이번 모듈을 마칩니다. 다음 모듈은 이 자료의 대상·기간·비교 조건을 더 정밀하게 정의합니다.

python3 check.py --submission usability.json

검사 실패: 0
PASS 이전 근거·3명 관찰·집계·2수정·재확인; 판단은 동료 검토