피그마 개발 전달 기준, 화면 선별하는 법
피그마 개발 전달 기준, 화면 선별하는 법
기획자의 작업대 · 실무 가이드
스프린트 막바지에 화면 30장을 한꺼번에 개발자에게 넘긴 적이 있습니다. 일정이 촉박해서 "일단 다 넘기고 보자"는 생각이었는데, 그중 절반은 빈 값이나 에러 상태가 정의되지 않은 화면이었습니다.
개발자가 화면마다 "이 경우엔 뭘 보여줘야 하나요"를 하나씩 물어오기 시작하면서, 전달이 아니라 문답이 되어버렸습니다. 그날 이후로 화면을 넘기기 전에 반드시 확인하는 기준을 따로 만들어두게 됐습니다.
이번 글에서는 어떤 화면을 먼저 넘기고 어떤 화면은 보류해야 하는지, 그 기준을 어떻게 잡는지 정리해보겠습니다.
1. 개발 전달 기준, 무엇을 봐야 할까
화면을 넘길지 말지는 "다 그렸는가"가 아니라 "개발자가 이 화면만 보고 구현할 수 있는가"로 판단해야 합니다. 이 질문에 답하려면 세 가지 축을 확인하면 됩니다.
① 화면 상태가 다 정의됐는가
정상 상태 화면 한 장만으로는 부족합니다. 데이터가 없을 때, 로딩 중일 때, 에러가 났을 때 화면이 각각 어떻게 보이는지까지 있어야 합니다. 이 세 가지가 빠진 화면은 겉으로는 완성돼 보여도 실제로는 절반짜리 화면입니다.
② 인터랙션과 분기 스펙이 명확한가
버튼을 눌렀을 때 어디로 이동하는지, 조건에 따라 다른 화면을 보여줘야 하는지가 화면만 봐서는 알기 어려운 경우가 많습니다. 이 부분이 명확하지 않으면 개발자는 임의로 추측해서 구현하게 되고, 나중에 다시 고쳐야 할 확률이 높아집니다.
③ 예외 케이스까지 화면에 반영됐는가
권한이 없는 사용자가 접근했을 때, 네트워크가 끊겼을 때처럼 자주 일어나지 않는 케이스도 화면에 포함돼야 합니다. 예외 케이스는 나중에 추가하면 된다고 미루기 쉬운데, 실제로는 QA 단계에서 가장 많이 걸리는 부분입니다.
2. 화면 선별 기준 적용해보기
앞서 말한 세 가지 기준을 실제 화면에 적용하면 어떻게 될까요. 예를 들어 마이페이지 화면 세트가 있다고 가정해보겠습니다.
프로필 조회 화면은 정상, 빈 값, 에러 상태까지 다 그려져 있고 버튼 인터랙션도 명확합니다. 이 화면은 바로 전달해도 됩니다. 반면 포인트 내역 화면은 정상 상태만 있고, 포인트가 0원일 때나 API 응답이 늦어질 때 화면이 없습니다. 이 화면은 보류 대상입니다.
모든 화면을 한꺼번에 완성한 뒤 넘기려 하지 말고, 이렇게 화면 단위로 기준을 통과한 것부터 먼저 넘기는 방식이 실무에서는 더 현실적입니다. 전달을 나누면 개발자도 먼저 받은 화면부터 작업을 시작할 수 있고, 기획자도 남은 화면에 집중할 수 있습니다.
3. 실무 팁 3가지
팁1. 화면 상태값부터 다 그려졌는지 확인한다
팁2. Dev Mode 주석으로 "왜 이렇게 설계했는지"를 남긴다
팁3. 전달 전 체크리스트로 화면별 완성도를 점검한다
4. 마무리
- 전달 기준은 "다 그렸는가"가 아니라 "이 화면만 보고 구현할 수 있는가"입니다.
- 화면 상태, 인터랙션 스펙, 예외 케이스 세 가지를 기준으로 전달 여부를 판단합니다.
- 기준을 통과한 화면부터 먼저 넘기면 전달 이후 되돌아오는 질문이 줄어듭니다.
지금 전달을 앞둔 화면이 있다면, 넘기기 전에 세 가지 기준으로 한 번씩 체크해보세요. 여러분 팀은 개발 전달 기준을 어떻게 정하고 계신가요. 댓글로 공유해주시면 다음 글에서 더 자세히 다뤄보겠습니다.