화면설계 파일을 개발사가 읽기 좋게 넘기는 법

한 스타트업 대표님이 개발사에 화면설계를 넘긴 지 2주 만에 전화를 받았습니다. 「알려 주신 결제 화면이 두 가지인데, 어느 쪽으로 만들까요?」 하나는 지난달 버전이었고, 하나는 최근 버전이었습니다. 둘 다 같은 폴더에 들어 있었습니다.

개발사는 이미 옛 버전으로 일주일을 작업한 뒤였습니다. 화면설계가 틀린 것은 아니었습니다. 넘기는 방식이 틀렸습니다.

핵심은 개발사가 「무엇이 기준인지」 묻지 않아도 알게 만드는 것입니다. 기준 파일을 하나로 정하고, 읽는 순서를 잡아 주고, 확정된 화면과 아직 검토 중인 화면을 구분해 표시하면 됩니다. 바뀐 내용은 따로 기록해 함께 넘깁니다.

기준 파일은 하나만 둡니다

화면설계가 Figma에 있든 문서 파일에 있든, 개발사가 보는 기준은 하나여야 합니다. 옛 버전은 지우거나 「보관」 폴더로 옮깁니다. 같은 화면이 두 곳에 있으면 개발사는 둘 중 하나를 고를 수밖에 없고, 그 선택은 대체로 틀립니다.

파일 이름에는 날짜와 버전을 붙입니다. 메일이나 메신저로 파일을 따로 보내는 일은 피합니다. 한 번 메신저로 간 파일은 기준 파일과 따로 살아남기 때문입니다.

읽는 순서대로 묶습니다

처음 받은 사람은 어디서부터 봐야 할지 모릅니다. 그래서 파일 맨 앞에 안내 페이지를 둡니다. 순서는 보통 이렇습니다.

1. 서비스 한 줄 설명과 사용자 종류
2. 메뉴 구조와 전체 화면 목록
3. 주요 흐름. 가입, 주문, 예약처럼 끝까지 이어지는 길
4. 화면별 상세. 사용자 화면 다음에 관리자 화면
5. 이번에 하지 않을 것

화면 설명은 화면 바로 옆에 붙입니다. 설명을 별도 문서로 떼면 개발자는 두 창을 오가다 하나를 놓칩니다.

설명에는 번호를 붙여 화면 속 위치와 맞춥니다. 버튼 옆에 ①을 적고, 설명에도 ①로 시작하게 하면 「이 설명이 어느 버튼 이야기인지」 헷갈릴 일이 없습니다. 같은 버튼이 여러 화면에 나온다면 처음 나온 화면에만 자세히 적고, 나머지에는 「앞 화면과 같음」이라고 짧게 적습니다. 설명이 여러 곳에 흩어지면 한 곳만 고치고 다른 곳은 그대로 남는 일이 생기기 때문입니다.

확정과 검토 중을 표시합니다

모든 화면이 같은 날 확정되지는 않습니다. 그래서 화면마다 상태를 붙여 둡니다.

상태가 바뀌면 표시도 그날 바로 바꿉니다. 이 표시 하나로 「만들고 보니 바뀌었다」는 일이 크게 줄어듭니다. 개발사도 어디부터 손대야 할지 스스로 정할 수 있습니다.

바뀐 내용은 따로 적어 넘깁니다

넘긴 뒤에 화면을 고치는 일은 반드시 생깁니다. 이때 파일만 고치고 말없이 두면, 개발사는 바뀐 줄 모릅니다. 고칠 때마다 날짜, 화면 번호, 바뀐 내용을 한 줄씩 기록합니다. 「3월 4일, 결제 화면, 쿠폰 입력칸 추가」처럼 적으면 충분합니다.

처음 넘길 때는 짧게라도 전달 미팅을 엽니다. 주요 흐름을 함께 한 번 따라가면, 개발사가 무엇을 물을지 미리 드러납니다.

미팅 뒤에 들어오는 질문은 한곳에 모읍니다. 메신저, 메일, 전화로 흩어진 답은 나중에 아무도 찾지 못합니다. 질문과 답을 표 하나에 쌓아 두고, 답이 화면을 바꾸는 내용이라면 화면설계에도 반영합니다. 그래야 파일과 대화가 서로 다른 말을 하지 않습니다.

좋은 화면설계는 넘기는 순간까지가 기획입니다. 메뉴 구조, 화면설계, 기획서를 정리할 때 처음부터 넘길 형태를 생각해 두면, 개발을 어디에 맡기든 직접 하든 같은 질문을 두 번 받지 않습니다.

자주 묻는 질문

화면설계 파일은 개발사에 어떤 형식으로 넘겨야 하나요?

형식보다 기준이 하나인지가 중요합니다. Figma 링크든 문서 파일이든 개발사가 언제나 같은 곳을 보게 하고, 옛 버전은 치워 두시면 됩니다.

화면설계를 넘긴 뒤에 수정해도 되나요?

수정은 생길 수 있습니다. 다만 바뀐 날짜와 화면, 내용을 기록해 함께 알려야 합니다. 이미 만든 부분을 바꾸면 일정과 비용에 영향이 있을 수 있으니 미리 상의하는 것이 좋습니다.

개발사가 화면설계를 잘 이해했는지 어떻게 확인하나요?

전달 미팅에서 개발사가 주요 흐름을 직접 설명하게 해 보십시오. 설명이 막히는 지점이 곧 보완할 화면입니다.