김희준
좋은 디자인 핸드오프는 개발자가 결정 맥락, 의도한 동작, 작업 범위를 추측하지 않게 합니다. 각 요구 사항을 확인 가능한 결과와 담당자에 연결하세요. 아래 주문 제출 예시는 완성된 화면만으로는 알 수 없는 로딩, 오류, 결과 확인 중 상태까지 어떻게 명세하는지 보여 줍니다.
결정 맥락 기록하기
사용자 문제, 선택한 방향, 검토한 대안, 판단 근거를 적습니다. 팀이 함께 사용하는 제품 기획 공간에 맥락과 명세를 나란히 두면 디자인, 개발, QA가 같은 버전을 보며 논의할 수 있습니다.
이 예시의 목표는 구매 화면에서 주문 한 건을 완료하는 것입니다. 최종 검토, 제출, 주문 확인은 포함하지만 장바구니 변경은 범위에서 제외합니다. 핵심 위험은 결과를 모르는 상태에서 다시 제출하는 것입니다. 응답이 늦어지면 사용자는 첫 주문이 처리됐는지 모른 채 버튼을 다시 누를 수 있습니다. 따라서 주문이 거절된 경우와 결과를 아직 확인하지 못한 경우를 구분해야 합니다.
| 확인 항목 | 전달할 내용 | 완료 기준 |
|---|---|---|
| 범위와 결정 | 사용자 과제, 포함 화면, 제외 사항, 선택한 흐름의 이유. | 이번 변경으로 제공하는 것과 제공하지 않는 것을 설명할 수 있다. |
| 상태와 전환 | 준비 완료, 입력 오류, 제출 중, 결과 확인 중, 거절, 완료. | 각 상태의 발생 조건, 안내 문구, 다음 동작이 정해져 있다. |
| 컴포넌트와 콘텐츠 | 컴포넌트 참조, 확정 문구, 에셋, 버전. | 임시 문구나 출처가 불분명한 파일이 남아 있지 않다. |
| 반응형 동작 | 읽기 순서, 줄바꿈 규칙, 지원 화면 폭의 예시. | 긴 문구나 오류 메시지가 금액 또는 버튼을 가리지 않는다. |
| 접근성 | 키보드 이동 순서, 보이는 포커스, 접근 가능한 이름, 상태 알림. | 마우스 없이 이용할 수 있고 색상만으로 상태를 전달하지 않는다. |
| 인수 테스트 | 시작 조건, 사용자 동작, 관찰 가능한 결과. | QA가 '정상 동작'의 의미를 다시 묻지 않고 재현할 수 있다. |
| 담당과 미결 사항 | 담당자, 남은 질문, 검토자, 검토일. | 모든 차단 항목에 결정 담당자가 있고 합의한 예외가 기록돼 있다. |
상태·에셋·콘텐츠 명세하기
이상적인 화면만 전달하지 말고 실제로 필요한 상태를 열거합니다. 최종 에셋, 콘텐츠 규칙, 토큰이나 컴포넌트의 기준 소스를 함께 연결하세요. 빈 상태나 권한별 상태가 이 흐름과 관계없다면 불필요한 화면을 추가하는 대신 해당하지 않는다고 기록합니다.
| 상태와 발생 조건 | 화면에 보이는 동작 | 다음 동작과 검증 결과 |
|---|---|---|
| 준비 완료: 필수 정보가 입력됨 | 주문 총액과 '주문하기' 버튼을 표시한다. | 검토 항목 다음에 버튼으로 포커스가 이동하고, 실행하면 제출이 한 번 시작된다. |
| 입력 오류: 필수 항목이 누락됨 | 필드 옆의 구체적인 오류와 오류 요약을 표시한다. | 해당 필드로 연결되는 오류 요약에 포커스를 옮긴다. 주문 요청은 보내지 않는다. |
| 제출 중: 요청을 처리하는 중 | 문구를 '주문 처리 중…'으로 바꾸고 중복 실행을 막는다. | 포커스를 조작 요소에 유지하고 상태를 알린다. 연속 클릭이나 키 입력이 추가 주문을 만들지 않는다. |
| 결과 확인 중: 응답이 끊김 | '주문을 확인하고 있어요'라고 표시하며 실패로 단정하지 않는다. | 다시 제출하도록 안내하기 전에 기존 요청을 조회하고 입력 내용을 보존한다. |
| 주문 거절: 서비스가 주문 미생성을 확인함 | 해결할 문제를 설명하고, 가능할 때 '다시 시도'를 제공한다. | 오류를 알리고 올바른 입력을 유지한다. 수정 후 새로 시도할 수 있다. |
| 주문 완료: 주문 번호가 확인됨 | 주문 번호와 요약이 있는 확인 화면을 연다. | 확인 화면 제목으로 포커스를 이동한다. 새로고침해도 주문을 다시 제출하지 않는다. |
이는 이 예시에서 구현하려는 동작입니다. 개발팀은 주문 제출·조회 방식과 반복 요청을 식별하는 규칙을 정해야 합니다. 버튼을 비활성화된 것처럼 보이게 하는 것만으로는 중복 주문을 방지할 수 없습니다.
반응형과 예외 상황 확인하기
지원하는 화면 폭에 따른 변화를 보여 주고 긴 라벨, 현지화, 키보드 포커스, 모션 감소, 네트워크 중단을 확인합니다. 이 구매 화면에서는 총액과 제출 버튼의 관계가 분명해야 합니다. 좁은 화면에서는 요약과 버튼을 읽기 순서에 맞게 배치하고 번역된 문구가 여러 줄이 되어도 가격을 가리지 않게 합니다.
긴 상품명, 여러 줄의 오류 메시지, 확대된 화면을 검토에 포함하세요. 고정 버튼을 사용한다면 포커스가 있는 입력란이나 오류를 가리지 않는 조건을 명시합니다. 로딩 애니메이션이 없어도 텍스트로 처리 상태를 이해할 수 있어야 합니다.
동작과 접근성을 검증 가능하게 만들기
클릭, 제출, 재시도, 뒤로 가기에서 어떤 일이 일어나는지 관찰 가능한 규칙으로 씁니다. 포커스 순서, 대비 기준, 컨트롤의 접근 가능한 이름도 포함하세요. '오류를 적절히 처리한다' 대신 다음과 같이 작성합니다.
- 필수 정보 누락: 주소의 필수 항목이 비어 있을 때 '주문하기'를 실행해도 주문 요청은 전송되지 않는다. 포커스가 오류 요약으로 이동하고 그곳에서 수정할 필드로 갈 수 있다.
- 느린 응답: 유효한 정보로 제출을 시작한 후 버튼을 다시 실행해도 주문이 추가되지 않는다. 키보드와 스크린 리더를 사용해도 처리 중임을 알 수 있다.
- 응답 유실: 결과를 모르는 경우 연결이 복구되면 기존 요청을 조회한다. 이미 주문이 생성됐다면 새 주문 없이 해당 주문의 확인 화면을 보여 준다.
- 거절 확인: 서비스가 주문이 생성되지 않았다고 확인하면 올바른 정보를 다시 입력하지 않고 문제를 수정해 재시도할 수 있다.
- 완료: 주문 번호를 읽고 키보드로 다음 동작에 접근할 수 있다. 확인 화면을 새로고침해도 제출이 반복되지 않는다.
수용 조건과 담당자 정하기
각 항목에 담당자, 수용 조건, 검토일을 붙입니다. 디자이너는 상태별 화면·문구·포커스 명세를, 프런트엔드 담당자는 표시와 상호작용을, 백엔드 담당자는 주문 식별과 반복 요청 처리를, QA는 합의된 테스트 결과를 맡습니다. 실제 작업 문서에서는 역할을 담당자 이름으로 바꾸세요.
Boardmix에서 결정 내용, 체크리스트, 상태 매트릭스를 한 보드에 정리하세요. 관련 상태 옆에 댓글을 남기고 미결 질문, 최신 명세와 테스트 결과의 링크를 기록합니다. 예를 들어 '결과 확인 중' 옆에서 백엔드 담당자에게 어떤 응답이 기존 주문의 생성을 확인해 주는지 질문할 수 있습니다. 보드는 논의의 맥락을 모으고, 실제 구현은 애플리케이션 테스트로 검증합니다.
모든 픽셀을 설명하는 것이 아니라 개발자와 디자이너가 검증 방법에 합의할 수 있어야 핸드오프가 끝납니다. 주문 조회 방식이 정해지지 않았다면 담당자와 다음 결정을 적고 해당 항목을 차단 상태로 남기세요. 화면이 완성됐다는 이유만으로 전체 흐름을 구현 준비 완료로 표시하지 않습니다.
