개발 인계와 디자인 QA
문제 근거부터 명세·화면·에셋까지 연결하고 구현 결과를 함께 검수하기
10주 결과물: 개발자가 이어받을 수 있는 설계
문제 정의·리서치·정보 구조·명세·컴포넌트·검증 결과를 연결하여 개발 인계를 완성합니다. 파일을 많이 전달하는 것이 아니라 구현에 필요한 결정을 찾을 수 있어야 합니다. 9주의 사용성 테스트에서 남은 핵심 실패도 먼저 확인합니다.
인계 묶음의 첫 페이지
Figma Readme 또는 팀 문서 한 곳에 다음 링크를 정리합니다. 동일 내용을 여러 곳에 복사하기보다 기준 문서로 연결합니다.
| 항목 | 반드시 확인할 내용 |
|---|---|
| 제품 브리프 | 사용자·문제·근거·첫 버전 범위 |
| 리서치·검증 | 익명화한 관찰, 해석, 남은 가정 |
| 정보 구조·플로우 | 시작·완료·실패·되돌아가기 |
| 기능 명세 | 기능 ID·정책·권한·수용 기준 |
| 화면 | 검토할 최신 버전과 상태별 프레임 |
| 컴포넌트 | 이름·속성·사용 규칙·접근성 |
| 에셋 | 파일 형식·이름·용도·대체 텍스트 |
| 변경 기록 | 결정 날짜·이유·영향·미확정 사항 |
초안과 구현 기준 화면을 명확히 구별합니다. 개발 중 화면을 임의로 바꾸지 않습니다. 영향을 주는 변경은 기록해 담당자와 공유합니다. 실제 사용 중인 에셋의 라이선스와 폰트 사용 범위도 확인합니다.
화면 하나를 설명하는 예시
다음은 세션 상세 화면의 가상 인계 메모입니다. 실제 프로젝트 수치와 계약으로 바꾸어 사용합니다.
화면 DETAIL-01 · 기능 APPLY-01과 연결. 제목·일정·마감·준비물을 신청 버튼보다 먼저 읽는다. 좁은 화면은 한 열, 넓은 화면은 본문과 신청 영역을 나눈다. 제목은 줄바꿈하며 잘라 숨기지 않는다. 신청 가능·제출 중·완료·마감·권한 없음 상태를 별도 프레임으로 제공한다. 요청 실패 후 상세 정보와 현재 위치를 유지한다.
프레임 너비만 숫자로 적지 말고 어느 요소가 늘어나며 어디서 줄바꿈되거나 이동하는지 설명합니다. 정확한 브레이크포인트(breakpoint)는 콘텐츠가 깨지는 지점을 확인한 뒤 개발자와 합의할 수 있습니다.
에셋과 상태 전달
아이콘처럼 벡터가 적합한 에셋은 SVG, 사진은 적절한 래스터 형식을 검토합니다. 텍스트 전체를 이미지로 내보내면 검색·번역·확대가 어렵고 접근성도 떨어지므로 실제 텍스트로 구현합니다. 장식 이미지와 정보 이미지의 대체 텍스트 요구도 구분합니다.
Figma prototype의 동작은 실제 인증·저장·네트워크 동작을 증명하지 않습니다. 제출 중 중복 방지, 응답 실패, 키보드 포커스 이동은 개발 결과에서 다시 검사합니다. 애니메이션이 있다면 목적·종료 상태와 모션 감소 설정을 켰을 때 동작을 설명합니다.
디자인 QA를 기록하는 방식
| 항목 | 기록 예시 |
|---|---|
| 위치 | 상세 화면 / 신청 폼 / 360px 폭 |
| 재현 | 이름을 40자로 입력한 뒤 오류 제출 |
| 기대 | 오류가 입력과 연결되고 버튼이 화면 안에 남음 |
| 실제 | 오류 문장이 다음 요소와 겹침 |
| 영향 | 사용자가 수정 방법을 읽기 어려움 |
| 우선순위 | 과업 방해, 다음 수정에 포함 |
| 근거 | 화면 캡처와 기능 ID |
위 표는 기록 형식의 가상 예시입니다. 실제로 관찰하지 않은 오류를 발견한 것처럼 제출하지 않습니다. “느낌이 다르다” 대신 재현 조건·기대·실제를 적습니다. 반대로 제품 목표와 관계없는 1px 차이를 핵심 과업 실패보다 먼저 처리하지 않습니다.
함께 검사할 흐름
- 비로그인 사용자가 상세를 열고 로그인 후 원래 과업으로 돌아옵니다.
- 신청 가능한 상태에서 제출하고 완료 여부를 확인합니다.
- 마감·중복·네트워크 실패에서 다음 행동을 찾습니다.
- 360px와 1280px, 긴 제목·빈 데이터에서 내용을 읽습니다.
- 키보드만으로 이동하며 포커스가 보이고 오류가 색상 외의 문장으로 설명되는지 확인합니다.
접근성 검사는 자동 도구 결과와 실제 키보드·보조기술 검토를 함께 고려합니다. 화면 캡처가 일치해도 동작과 접근성까지 통과한 것은 아닙니다.
세션 진행과 완료 기준
권장 120분: 자료 연결 25분, 개발자 인계 25분, 구현 또는 프로토타입 QA 35분, 수정 20분, 발표 15분입니다. 아직 구현이 없다면 프로토타입 검사와 “구현 후 확인할 항목”을 분리해 제출합니다.
발표는 문제 근거→핵심 흐름→가장 큰 실패와 수정→컴포넌트 규칙→남은 위험 순서로 진행합니다. 완료 기준은 처음 보는 개발자가 기능 명세와 화면을 찾아 추가로 추측하지 않고 정상·실패 흐름을 설명할 수 있는 것입니다. 미확정 항목마다 담당자와 다음 행동도 정해져 있어야 합니다.
최종 제출물은 인계 첫 페이지, 최신 화면·프로토타입, 기능 명세, QA 실제 결과, 남은 작업 목록입니다. 포트폴리오에는 팀의 실제 기여와 검증 범위를 구분하여 기록합니다.
더 읽어보기
연결된 PBL 미션과 VOD
| 주차·미션 | 참고 VOD 범위 |
|---|---|
| 10주 · 개발 인계 | PM 10·11장 / Figma 4·5장 |
PM은 ‘PM업무, 강의 하나로 정리하기’, Figma는 ‘Figma로 앱 디자인부터 포트폴리오까지’를 뜻합니다.
강좌 안내: 참고 강좌 1 · 참고 강좌 2. 이 문서는 영상 전체를 옮긴 전사 자료가 아닙니다. 세부 내용은 위 공식 문서에서 확인합니다.