과업과 관찰 계획

테스트는 화면 설명회가 아닙니다

동아리 신청자가 접수 화면을 보고 참가가 확정되었다고 생각하면 예쁜 화면이라도 업무 목적을 달성하지 못합니다. 사용성 테스트는 정해진 조건에서 사용자가 스스로 과업을 수행하는지 관찰하는 활동입니다. 제품 담당은 기능을 소개하고 만족한다는 답을 얻기보다 어디에서 멈추고 어떤 상태를 잘못 해석하는지 찾습니다. 이번 목표는 신청 내역을 찾고 승인 대기가 참가 미확정이라는 의미를 설명하는 행동을 확인하는 것입니다.

이번 모듈의 기록 공간

미션 starter를 별도 연습 폴더에 풉니다. Python 3 표준 라이브러리만 사용합니다. m06 solution에서 가져온 이전 JSON은 보존하고 usability.json에 새 기록을 작성합니다. screens-v1.md와 screens-v2.md는 진행자가 카드 전환을 대신하는 텍스트 초안이며 실제 앱이 아닙니다. provided-sessions.json은 가상 관찰 사례입니다. 문서 작성 단계의 output은 비우며 실행 결과가 있는 명령만 출력으로 기록합니다.

범위를 앞 결정에 맞춥니다

backlog.json에서 I01 본인 상태 조회는 채택, I02 승인 알림과 I03 엑셀 내보내기는 보류입니다. 이 테스트에서 알림이 안 온다는 문제를 신규 실패로 세면 제공 범위 밖 기능을 평가하게 됩니다. D01 정원 집계 변경도 제안 상태이므로 승인 대기가 자리를 확보했다는 뜻이라고 안내하지 않습니다. 미결 정책은 scope.policyDecision에 남기고 이번 검증으로 확정할 수 없는 조건을 행사·개발 담당에게 질문합니다.

과업에는 목적을 주고 경로는 숨깁니다

T01 과업은 “EV01에 신청을 제출한 뒤 자리를 떠났다가 다시 왔습니다. 현재 본인 신청 상태와 참가가 확정되었는지 확인해 주세요”로 씁니다. “신청 내역 확인 버튼을 누르세요”라고 쓰면 찾는 경로를 미리 알려 줍니다. 목적을 이해하지 못하면 상황을 다시 읽어 줄 수 있지만 버튼 위치나 문구의 의미는 알려 주지 않습니다. 정답 경로가 아니라 사용자가 알아내야 하는 업무 결과를 문장에 넣습니다.

출발 조건을 고정합니다

U01이 EV01을 선택했고 A001 저장 성공이 확인된 접수 카드를 출발점으로 정합니다. 실제 개인정보는 쓰지 않고 가명과 연습 신청 ID를 사용합니다. 카드를 누르면 본인 내역 카드로 전환한다는 연결 규칙은 진행자만 알고 있습니다. 참여자마다 다른 출발 화면을 보여 주면 탐색 실패의 원인이 화면 차이인지 사람 차이인지 구분하기 어렵습니다. setup에 계정 역할·초안 버전·응답 조건을 함께 적습니다.

과업 완료와 버튼 클릭을 구별합니다

이번 완료 조건은 90초 안에 도움 없이 A001 내역을 찾고 승인 대기는 참가 미확정이라고 설명하는 것입니다. 90초는 연습에서 정한 제한이며 보편적 기준이 아닙니다. 버튼만 눌렀거나 내역을 읽고도 확정이라고 설명하면 완료로 세지 않습니다. 두 행동을 나누어 관찰하면 경로 탐색 문제와 상태 이해 문제를 따로 개선할 수 있습니다. 화면에 적힌 문장을 읽은 사실과 의미를 이해한 사실도 구분합니다.

완료 판정 규칙을 미리 공유합니다

success는 도움 없이 조건을 충족한 경우, assisted는 방향이나 의미 도움 뒤 충족한 경우입니다. failure는 종료 조건까지 목적을 충족하지 못한 경우이고 unknown은 완료 기록이 없어 판정할 수 없는 경우입니다. 과업 문장 반복은 repeat로, 위치 안내는 direction으로 기록합니다. 참여자의 도움 요청만 있고 제공한 도움은 없다면 assisted로 단정하지 않습니다. 실제로 무엇을 알려 주었는지가 판정의 근거입니다.

중단은 실패와 이유를 나눕니다

참여자가 그만하고 싶다고 말하거나 실제 개인정보가 보이면 즉시 관찰을 멈추고 중단 이유를 적습니다. 이 중단을 화면 사용 실패라고 자동 해석하지 않습니다. 제품 문제로 목적을 달성하지 못한 것인지 기록 누락으로 판정 불가인지 설명해야 합니다. 연습 과업의 시간 초과는 failure로 정했지만 피로·동의 철회 같은 조건은 별도 이유가 필요합니다. 무리해서 끝까지 시키는 것은 다음 설계 판단에 좋은 근거가 되지 않습니다.

기록 항목을 테스트 전에 준비합니다

관찰표에는 세션 ID·가명 참여자 ID·과업 ID·초안 버전·경과 초·행동·발화·진행자 도움·해석을 둡니다. 과업 시작부터의 정수 초를 쓰면 실제 시각과 이름을 남기지 않아도 행동 순서를 비교할 수 있습니다. 빈칸을 채우려 기억을 꾸미지 않습니다. 발화가 없으면 빈 문자열을 두고 행동은 구체적으로 적습니다. 완료 이유를 별도 칸에 두어 관찰 내용과 평가자의 결론이 섞이지 않게 합니다.

참여자는 조건으로 모집합니다

실제 테스트를 진행한다면 결과 경로를 모르고 행사 신청 경험이 있는 사람처럼 문제의 조건에 맞는 대상을 찾습니다. 동료 세 명이 화면 제작 과정을 모두 알고 있다면 탐색 과업을 너무 쉽게 수행할 수 있습니다. 누구를 어떻게 모집했는지 기록하고 해당 조건 밖으로 결론을 넓히지 않습니다. 제공 가상 사례 3명을 활용하는 연습은 모집을 수행한 실제 조사와 다릅니다. 참여자 수가 같아도 근거의 출처는 같지 않습니다.

동의와 수집 범위를 설명합니다

실제 참여자에게 무엇을 관찰하고 어디에 기록할지, 언제든 중단할 수 있다는 점을 먼저 설명합니다. 이 연습은 녹화나 연락처를 요구하지 않습니다. 가상 자료는 source=provided-fiction과 consent=not-applicable-fiction으로 표시합니다. 실제 동의 관찰은 actual-consented와 obtained로 표시하고 실제로 받은 동의의 범위를 확인합니다. 필드 값을 바꾸는 것만으로 동의가 생기지는 않으므로 동료가 기록 과정도 검토해야 합니다.

진행자의 문장을 점검합니다

“대기가 보이니 이제 확정이 아니라고 말씀해 주세요”는 상태 이해의 답을 유도합니다. 대신 “현재 어떤 상태라고 이해했나요”처럼 설명을 요청합니다. 화면 제작자를 칭찬하는 답보다 실제 행동을 보겠다는 목적을 말하고 참여자의 능력을 평가하는 자리가 아니라는 점을 안내합니다. 막힐 때 바로 가르치고 싶어도 정한 제한까지 관찰합니다. 도움을 제공한 뒤에는 제공 시각과 내용을 남겨 독립 수행 결과와 분리합니다.

파일 형식 오류를 먼저 해결합니다

JSON은 큰따옴표로 키와 문자를 감싸며 마지막 항목 뒤에 쉼표를 붙이지 않습니다. FAIL json: line, column이 나오면 해당 위치의 쉼표·따옴표부터 확인합니다. FAIL tasks는 과업의 완료·중단·도움 규칙이나 ID 연결을 확인하라는 뜻입니다. 검사기를 통과시키려고 의미 없는 문자를 채우지 않습니다. 관찰자가 완료 여부를 같은 기준으로 판단할 수 있는지 동료에게 과업과 완료 조건만 읽혀 봅니다.

예비 진행으로 조건을 맞춥니다

본 관찰 전에 동료 한 명과 카드 전환 및 경과 초 기록을 연습합니다. 카드 링크가 빠져 사용자가 이동할 수 없으면 사용성 실패로 보고하기 전에 초안 결함을 수정합니다. 완료 조건이 사람마다 다르게 읽히면 프로토콜을 고치고 버전을 남깁니다. 예비 진행을 본 세션과 섞어 숫자를 늘리지 않습니다. 테스트 시작 전에 과업·출발 화면·판정·중단·도움 규칙을 설명할 수 있으면 다음 레슨에서 관찰을 진행할 준비가 된 것입니다.