화면정의서, 흔히 스토리보드라고 부르는 이 문서를 처음 썼을 때는 파워포인트에 화면 캡처만 붙여놓고 옆에 설명 몇 줄 적는 정도였습니다.
그런데 프로젝트 규모가 커지고 화면 수가 많아지면서, 이 방식으로는 개발자도 디자이너도 헷갈리는 지점이 계속 생겼어요.
몇 번의 프로젝트를 거치며 정리한 화면정의서 작성 노하우를 공유해보려고 합니다.
가장 중요한 부분중에 하나가 화면 번호 체계를 먼저 정하는 것입니다.
화면이 30개, 40개로 늘어나면 화면 번호 체계가 없으면 문서 관리가 순식간에 엉망이 됩니다.
저희는 초반에 "화면1", "화면2" 이렇게 순서대로만 번호를 매겼는데, 중간에 화면이 하나 추가되면 그 뒤 번호를 전부 다시 매겨야 하는 번거로움이 있었어요.
지금은 기능 영역별로 앞자리 숫자를 부여합니다.
예를 들어 로그인 관련은 100번대, 마이페이지는 200번대, 결제는 300번대로 큰 틀을 잡아두고, 그 안에서 110, 111, 112 순으로 세부 화면을 배치해요.
이렇게 해두면 중간에 화면이 추가돼도 뒤 번호 전체를 바꿀 필요 없이 111-1 같은 식으로 끼워 넣을 수 있어서 훨씬 유연합니다.
화면정의서를 쓸 때 가장 많이 하는 실수가, 화면 하나에 상태가 여러 개 있다는 걸 놓치는 겁니다.
예를 들어 상품 목록 화면은 "데이터가 있을 때", "데이터가 없을 때", "로딩 중일 때", "에러가 났을 때"처럼 최소 네 가지 상태를 가질 수 있어요.
저희도 초반에는 정상적으로 데이터가 있는 화면만 그려놓고 넘어갔다가, 개발 중간에 "빈 화면일 때는 뭘 보여주나요"라는 질문을 계속 받았습니다.
지금은 화면을 그리기 전에 먼저 "이 화면이 가질 수 있는 상태 목록"을 텍스트로 나열하고, 그중 대표 상태(주로 정상 데이터 상태)만 화면으로 그린 뒤, 나머지 상태는 텍스트로 "이 경우엔 이렇게 보인다"를 명시하는 방식으로 바꿨습니다.
화면 옆에 설명을 줄글로 쭉 적어두면, 개발자가 "이 설명이 화면의 어떤 요소를 말하는 건지" 다시 찾아야 하는 상황이 생깁니다.
저희는 화면 위에 동그라미 숫자(①②③)를 붙이고, 옆 설명란에도 같은 번호로 대응시키는 방식을 씁니다.
보통 우리는 이것을 디스크립션 이라고 이야기 하죠.
"① 상품명 - 최대 2줄, 그 이상은 말줄임 처리" 처럼 요소별로 짧게 끊어서 적어요.
이렇게 하니까 개발자가 특정 요소에 대해 질문할 때 "①번이요"라고만 말해도 서로 뭘 가리키는지 바로 알 수 있어서 커뮤니케이션 속도가 확실히 빨라졌습니다.
화면정의서 안에 화면 하나하나는 잘 정리되어 있어도, 전체적으로 어떤 순서로 화면이 이어지는지 파악하기 어려운 경우가 많았습니다.
저희는 이제 화면정의서 맨 앞 페이지에 전체 화면 흐름도를 박스와 화살표로 그려서 첨부합니다.
각 박스 안에는 화면 번호만 적어두고, 화살표 옆에는 어떤 액션으로 다음 화면으로 넘어가는지 짧게 적어요.
개발자들이 전체 구조를 파악할 때 이 한 장짜리 흐름도만 보고도 대략적인 그림을 그릴 수 있다는 피드백을 많이 받았습니다.
세부 화면정의서를 다 읽기 전에 이 흐름도로 먼저 맥락을 잡을 수 있으니, 리뷰 회의 시작할 때 이 페이지부터 보여주는 게 저희 팀의 루틴이 됐어요.
화면정의서는 한 번 쓰고 끝나는 문서가 아니라 프로젝트 진행 중 계속 수정되는 문서입니다.
저희도 초반에는 파일을 덮어쓰기만 했다가, 나중에 "이 화면이 원래 이렇게 생기지 않았었나요"라는 질문에 답을 못 하는 상황이 여러 번 있었어요.
지금은 문서 맨 앞에 변경 이력 표를 만들어서, 날짜와 변경된 화면 번호, 변경 내용, 변경 이유를 한 줄씩 기록합니다.
파일명에도 v1.0, v1.1처럼 버전을 붙이고, 큰 변경이 있을 때만 버전을 올리는 규칙을 정해뒀어요.
이 습관 하나로 나중에 "왜 바뀌었더라"를 찾는 시간이 확실히 줄었습니다.
화면정의서 전체를 한꺼번에 리뷰 요청하면, 리뷰어가 어디부터 봐야 할지 몰라서 대충 훑고 넘어가는 경우가 많았습니다.
특히 디스크립션이나 상세한 내용은 잘안보고 화면만 보고 넘기는 경우들도 많더라고요.
저는 이제 리뷰를 요청할 때 "이번엔 결제 흐름(310~315번 화면)만 집중해서 봐주세요"라고 범위를 좁혀서 요청합니다.
범위가 좁혀지니 리뷰어도 부담 없이 꼼꼼하게 봐줄 수 있고, 실제로 놓쳤던 예외 케이스를 짚어주는 피드백도 훨씬 많이 받게 됐습니다.
화면정의서는 결국 "내가 아는 걸 다른 사람도 똑같이 알게 만드는" 문서입니다.
아무리 화면을 예쁘게 그려도, 상태와 예외를 놓치거나 흐름을 파악하기 어렵게 만들면 그 문서는 제 역할을 못 하는 거예요.
저도 아직 완벽한 양식을 찾은 건 아니지만, 이번에 정리한 습관들을 다음 프로젝트에도 그대로 적용해보면서 계속 다듬어갈 계획입니다.