안녕하세요, 주인장입니다.
오늘은 화면 설계서를 작성하는 방법에 대해 알아보려고합니다.
화면 설계서는 기획자가 작성하고 난 뒤 개발자들과 회의를 하면서 기술 검토를 보통 할 때 많이 쓰입니다. 개발자를 위한 메인 DOCS 중 하나입니다.
오늘도 차근차근 화면설계서를 작성하는 방법에 대해 함께 알아보겠습니다.
💡 화면 설계서를 왜 쓰나요?
먼저 PM, 디자이너, 개발자들의 협업 프로젝트 FLOW를 함께 살펴보겠습니다.
📍 협업 프로젝트 FLOW
이 진행 방향으로 기획자가 화면 설계서를 작성하고 이를 바탕으로 개발팀과 기술 협의를 진행한다. 검토가 완료 되면, 디자인 팀에게 화면 설계서가 넘어가게 되고 디자인팀은 이를 바탕으로 최종 디자인 시안을 확정하기때문에 기획자, 개발자, 디자이너에게 모두모두 중요한 기술 문서이다.
여기서 프론트 개발자인 나도 오해해서 기능 명세서 쓸 때 잘못생각했던 부분이 있었는데 이 화면설계서가 바로 개발자들에게 이렇게 개발해주세요! 라는 개발 요청서랑 같다고 생각했다.
📍 화면 설계서를 잘 작성하는 마인드
하지만 화면설계서는 개발 진행 시에 발생할 수 있는 이슈들을 확인하는 협업자들의 의견을 수렴하고 개선하는 한 마디로 커뮤니케이션을 위한 문서이다.
따라서 가장 중요한 점은, 설계서의 목적을 협업자들과의 소통에 중점을 두고 작성하면 훨씬 소통의 오류를 줄일 수 있다. 개발자들의 기능에 대한 이해를 돕고, 앞으로 예정된 추가적인 기능들에 대한 개발 방향도 함께 작성해주는 것이 좋다. 실제로도 단순한 기능이라서 기획자가 부연설명을 하지 않으면 개발자들은 컴포넌트들 간의 흐름이 어떻게 되는지 모르기에 계속해서 해당 부분에 대해 의견을 요구해야하므로 시간을 낭비할 수 있다.
💡 목적을 명확하게 전달하기
개발자와의 협업을 진행하면서 가장 중요한점은 pm 본인이 기획한 기능에 대해 개발자들에게 명확하게 설명하는 것이 매우매우매우 중요하다.
해당 프로젝트 아이디어를 모으다가 내가 낸 아이디어가 채택되어 pm도 되었는데, 내가 낸 아이디어 대로 각 팀에서 기술 이슈를 찾아보다가 내가 명확하게 해당 기능들에 대해 잘 전달하지 않아서 다른 팀과 우리 메인 아이디어 기능을 서로 생각하는 게 달랐다는 것을 알게 되었다.(ㄹㅇ 큰일날뻔)
암튼 pm은 개발자들에게 본인의 기획의 의도를 명확하게 전달해야한다. 만약에 부연설명이 부족하면
개발자들이 본인 생각대로 판단할 가능성이 높아진다. 또한 개발자들의 엄청난 질문들을 받게 될 것이다.
다음은 기획자들이 기획의 목적을 명확하게 전달하는 논리적인 문장 정리법을 소개한다.
- 출처: "오늘도 개발자가 안된다고 말했다. 87p"
(1) 개발 요청 기능을 정의하기(feat: 어떤 기능을 개발할 것인가?)
(2) 제공 대상(feat: 누구를 위해서 제공하는가?)
(3) 이유 및 목적 쓰기(feat: 이 기능을 만드는 이유와 목적이 무엇인가?)
(4) 예시/사례 작성(feat: 정성적/정량적 지표)
(5) 기대효과(feat: 무엇이 좋아지는가?)
개발자에게 본인의 기획 의도가 명확이 전달되면 큰 산이 하나 지나간 것과 같다. 기획자가 고민하던 부분도 개발자들이 더 나은 대안을 제공하기 때문이다. 하나의 아이디어를 제안하면 기술적인 부분을 함께 검토하면서 개발자들이 더 추가적인 좋은 기능을 제안한다. 자신의 아이디어를 매우 잘 전달하는 것이 매우매우 중요하다. 시간 낭비를 매우 줄인다.
💡 설계서 제목의 중요성
개발자들이 화면 설계서를 검토할 때 가장 먼저 보는 부분은 문서의 타이틀 부분이다.
- 출처: "오늘도 개발자가 안된다고 말했다. 89-90p
1. 작성 완료 날짜 / 2. 플랫폼 유형 / 3. 기능 상세 명칭과 기획 방향(신규/개선/고도화)/4. 문서 버전
ex) 문서제목(신규): 2021.01.01 _ a몰 __ 상품 검색 신규 기획 설계서_v1.0
위와 같은 형식으로 작성할 수 있도록 해보자.
💡 화면설계서를 스토리텔링으로
스토리텔링을 위한 화면 설계서의 구조는 타이틀, 목차, 버전 이력 관리, 설계 목적 및 기대 효고, 정책 프로세스 정의, UI 설계 총 6단계로 이루어져있다고 한다. 이 과정은 앞선 단계를 완료 후 자신의 화면 설계서를 다시 읽어보면서 검토하면서 스토리텔링으로 바꿔보는 것이 좋다.
💡 개발자들에게 리뷰 요청하기
개발자들에게 본인의 설계서에 대한 리뷰를 요청할 때 개발자들을 본인의 설득의 대상으로 생각하는 것이 좋습니다. 개발자들이 이 기능을 왜 개발해야되나요? 왜 필요하죠? 라는 질문을 하지 않게 하는 것이 좋다. 리뷰를 요청할 때는 제목, 요청 문구, 참석자, 회의 일정 및 장소, 중요도, 완료 요청 일정, 기획 배경, 세부 내용, 첨부 파일 9가지 내용을 포함해서 보내는 것이 좋다.
오늘의 포스팅은 여기서 마치겠습니다:)
