개발자가 이해하기 쉬운 상세 설계서 만들기
이 화면에서는 무엇을 노출시켜주면 될까요.
컨셉안, 벤치마킹 그리고 정책서 등 일련의 작업들을 잘 해왔다면 오히려 상세 설계서가 가장 쉬울 수 있다. 상세 설계는 시간과 엉덩이만 있으면 할 수 있기 때문이다. 앞서 정리한 내용을 보고 화면만 그려가면서 설명만 적으면 된다.
하지만 이렇게 단순하게 말하더라도 주의해야 할 점은 항상 있다. 상세 설계서는 서비스에 대한 설명서가 되는 문서이다. 개발자들은 상세 설계서를 보면서 개발을 하며, 디자이너는 상세 설계서를 보면서 디자인 작업을 한다. QA는 상세 설계서를 보면서 TC(Test Case)를 뽑는다. 그만큼 많은 사람들이 보는 문서이기에 더 중요한 문서일 수 있다.
처음 만들 때 잘 만들어야 한다.
앞서 설명했듯이 상세 설계서는 보는 사람들이 많다. 그렇기에 수정을 하면 다시 공유를 해야 되는 경우가 많아진다는 것이다. 그렇기에 최대한 수정이 많이 일어나지 않도록 해야 한다. 하나의 수정이 생기면 그와 관련된 수많은 화면을 수정해야 하며, 그와 연관된 사람들에게 다시 수정된 내용을 공유해줘야 한다.
그렇기에 최초 작성 시에 신중에 신중을 더하고, 잘못 기입된 부분이 없는지 꼼꼼히 체크해봐야 한다. 상세 설계서 단계부터는 어렵고 머리 아픈 거보다는 귀찮고 번거로운 작업이 많은 편이다. 그중 가장 귀찮은 것이 수정과 공유이다.
기존 스펙은 모두가 알지만 모른다.
상세 설계서를 작성하다 보면 기존 스펙과 다르지 않은 경우가 있다. 그렇다고 기존 스펙과 같다고 방치해서는 안된다. 나의 상세 설계서를 보고 개발해주는 개발자가 신입 개발자라는 마음으로 상세 설계서를 작성해야 한다.
기존 스펙을 적으면서 현재 있는 스펙과 동일하다는 코멘트를 함께 적어줘야 오해 없이 개발이 진행될 수 있다. 원래 있던 것이라고 명시만 해두면 개발자가 확인해가면서 개발을 진행하게 된다. 오롯이 상세 설계서만 보고 개발을 할 수 있도록 적어주는 편이 설계서의 완성도를 높이는 일이다.
화면은 빠지는 부분 없이 꼼꼼하게 그리기.
사용자 플로우에 맞춰 화면을 그리다 보면 이 부분은 알겠지라고 생각될 때가 있다. 그럴 때 건너뛰기를 하면 안 된다. 모바일 화면 설계의 경우 한 스텝, 한 스텝이 잘 보이는 편이지만 Web이나 PC APP의 화면 설계의 경우에는 사용자 플로우를 그리기가 어렵기에 더 꼼꼼하게 그려줘야 한다.
사용자 플로우가 건너뛰기된 경우에는 개발자나 디자이너들이 확인을 위해 커뮤니케이션을 하게 된다. 그러면 다시 문서를 수정해야 하고, 다시금 공유를 해야 하는 악순환의 반복이 시작된다. 그렇기에 화면을 꼼꼼히 그려서 빠지는 부분이 없게 해야 한다.
수정은 하지만 삭제는 하지 말자.
상세 설계는 한 번에 끝날 수가 없다. 반드시 수정을 하게 된다. 그렇기에 수정을 하게 되더라도 좌절할 필요는 없다. 어차피 해야 될 수정이었던 것이다. 다만 여기서 수정을 한다고 기존 문서를 삭제를 하고 다시 처음부터 고치는 경우가 있다. 이것은 위험한 행동이다.
기존 문서를 삭제하게 되는 경우 변경 전 히스토리를 알기 쉽지 않으며, 어떠한 이유로 해당 문서가 변경되었는지 알아야 이후에 비슷한 수정이 있는 경우에 참고할 수 있기 때문이다. 그렇기에 문서를 수정하게 되는 경우 기존 문서에 덧붙여서 수정된 내용을 표시하는 것이 삭제를 하는 것보다 효율적이다.
인사이트를 찾고, 콘셉트 안을 만들고, 정책을 세운 뒤 상세 설계서를 만든다. 서비스 기획이라는 일의 기본적인 일들은 이 틀 안에서 반복되고는 한다.
이 중에서 상세 설계서를 만드는 것만큼은 노력하고 시간을 많이 쓴다면 그만큼 결과가 보이는 부분이다. 그렇기에 상세 설계서를 잘 만들고 싶다면 기존의 노력보다 조금만 더 노력해보면 더 좋은 결과물을 만들 수 있을 것이다.
