화면설계서는 선(Wire)으로 이루어진 화면 구조(Frame)를 표현하는 문서입니다. 화면을 도식화하기 때문에 시각적인 이해도가 아주 높습니다. 디자이너는 화면설계서를 보고 디자인 작업을 합니다.
화면설계서(Wireframe)와 스토리보드(Storyboard)
둘 다 많이 들어본 문서일 것입니다. 대개 이 두 문서를 같은 개념 혹은 유사한 개념으로 이해하고 사용하고 작성합니다.
두 문서를 설명하기에는 기획의 의도까지 되짚어 설명해야 하기에 오늘은 결론부터 말씀드립니다. 해당 내용에 대해서는 별도로 제공됩니다.
- 화면설계서(Wireframe)과 스토리보드(Storyboard)는 다른 문서입니다. 두 문서는 작성 목적부터 다릅니다.
- 그럼 내가 알고 있는 그 문서는 뭐지? 화면설계서(Wireframe)입니다.
- 따라서 오늘 스터디에서는 스토리보드(Storyboard)가 거론되지 않습니다.
화면설계서(Wireframe)
제품을 개발하기 위해서는 제품 설계 도면(좌), 건물을 짓기 위해서는 건축 설계 도면(우)을 설계해야 합니다.
마찬가지로 서비스를 구현하기 위해서는 ‘화면 설계’를 해야 합니다. 사용자가 웹/모바일을 통해 서비스 접하기 때문에 화면 단위로 작성합니다.
화면설계서는 선(Wire)으로 이루어진 화면 구조(Frame)를 표현하는 문서입니다. 화면을 도식화하기 때문에 시각적인 이해도가 아주 높습니다.
실제 작업자가 아닌 관계자도 화면설계서로 커뮤니케이션을 할 수 있습니다. 간혹 IT에 대한 경험이 부족한 관계자라면 선으로 그려진 구조를 보고, 실제 화면을 예상하기에 버거워하는 경우도 있는데, 이 분들은 디자인 단계까지 진행되어야 비로소 화면을 이해합니다.
화면설계서는 표면적으로 텍스트, 선, 버튼으로 이루어져 있지만 그 안에는 많은 정보를 표현하고 있습니다.
- 요구사항명세서에 작성된 기능을 시각적으로 배치
- User Interface (UI) 설계가 담김
- User Experience (UX) 설계 담김
화면설계서에는 어떤 내용이 담겨야 할까요?
1) 버전 관리
화면설계서가 완성되기까지 오랜 시간이 걸리기 때문에 다른 작업자가 지속적으로 문서를 확인합니다. 따라서 화면설계서의 내용이 변경되면 다른 작업자가 확인할 수 있게 표시해야 합니다.
2) 화면
버전과 작성일은 파일명, 표지에만 거론해도 좋습니다.
화면코드를 부여하는 이유는 빠르게 화면을 찾고 구분하기 위함인데, 영문/국문 화면명으로도 충분히 찾을 수 있어서 굳이 부여하지 않으셔도 됩니다.
화면설계서 작성 범위
이번에 ‘중고차 O2O 서비스 기획’ 계약을 했는데요. 계약하고 보니깐 관리자 화면도 기획해야한다고 하네요. 저는 고객 화면만 기획하는줄 알았어요. 관리자 화면도 기획해줘야 하나요?
기획자도 고객 역할을 많이 했었기 때문에 고객 중심으로 업무 범위를 파악하는 경우가 있습니다.
서비스 기획 목적은 서비스 정책을 수립하고 프로세스를 설계하는 업무입니다. 따라서 기획자는 서비스 운영에 필요한 모든 기획 업무를 해야합니다. 그렇기 때문에 고객만 생각하는 것이 아니라, 서비스를 운영하는 관리자(Administrator)도 함께 고려해야 합니다.
- 고객 화면 (Supply Side, Demand Side)
- 관리자 화면 (Administrator)
참고 : 1일차 스터디 비즈니스 기획, 서비스 기획의 정의에서 발췌
여기서 사용자(Actor)는 단순히 우리가 말하는 고객(End User, Supply Side)만 말하는 것이 아니라, 이 비즈니스에 관계된 관리자(Administrator), 공급자(Supply Side), 수요자(Demand Side) 등 다양한 사용자(Actor)를 포함합니다.
화면설계서 작성 프로그램
저는 파워포인트(PPT)를 사용합니다. 그렇다고 파워포인트를 만족하고 있는 것은 아니라, 더 나은 툴이 없기 때문에 유지하고 있습니다.
Power Mockup(파워 목업)은 파워포인트 내에서 설치하는 프로그램이라서 사용하기에 좋습니다.
프로그램을 선택할 때 고려해야할 것은 화면설계서를 가장 많이 보는 작업자(디자이너/개발자)가 사용하기 편한 프로그램을 택해야 합니다. 파워포인트 프로그램 자체가 없는 작업자를 위해 PPT 파일과 PDF 파일을 동시에 전달합니다.
그 외 프로그램 설명 : 한 번쯤 들어봤던 화면설계&프로토타이핑 툴 총정리 블로그 글 상단에 정의된 용어는 제가 정의한 용어와 상이하므로 감안하여 읽어주시길 바랍니다.
기능명세서 (Functional Specification)
기능명세서는 구현해야하는 기능에 대해 상세하게 설명하는 문서입니다. 해당 기능이 어떻게 작동해야하고, 작동이 되지 않았을 때는 어떻게 처리(에러)해줘야하는지에 대한 상태를 기재합니다.
기능명세서를 작성하지 않아도 된다고 생각하는 분들도 더러 계시는데, 기능명세서만 잘 작성해도 프로젝트가 성공적으로 개발될 수 있습니다. 이 말은 기능명세서가 없으면 실패 가능성이 크다는 말과 같습니다.
앞서 요구사항명세서, 화면흐름도, 화면설계서를 소개 하였는데, 저는 그 중에서 가장 중요한 것이 ‘기능명세서’라고 생각합니다.
기능명세서에 무엇을 적어야 할까요?
기능을 작동하게 하기 위해서는 1) 무엇을 2) 어떻게 만드는지 정의되어야 구현됩니다.
기획자는 ‘무엇을’ 만들 것인지에 초점을 두고 기재하면 됩니다. 개발자는 기능명세서를 보고 전체 구조/설계를 함께 고려하여 ‘어떻게' 구현합니다.
위에 작성할 내용 이외로 기능/상황/상태에 따라 작성해야할 내용이 정말 많습니다. 처음 기능명세서를 작성하다보면 ‘어디까지 적어야할까?’에 휩싸이는데, 이 때는 개발자에게 어느 부분에 대한 명세가 필요한지 물어보면서 작성하는 것을 권장합니다.
“이렇게 기재 했는데 혹시 개발하면서 명세가 더 필요한 부분이 있을까요?”
기능명세서 작성 방법 및 프로그램
(1) 화면설계서(Wifreframe)의 우측에 작성
(2) 별도 문서로 작성 : Excel
대개 많은 기획자들은 화면설계서 우측에 기능명세서를 작성합니다.
한 프로젝트에서는 기능명세할 내용이 너무 많아, 엑셀 파일로 분리하여 작성한 적도 있었습니다. 그런데 개발자께서 화면설계서와 기능명세서를 동시에 보기에는 불편하다는 피드백을 주셔서 그 이후로는 같이 작성하는 방식으로 진행하고 있습니다.
방법은 정해진바 없습니다. 다만 내 문서를 가장 많이 볼 개발자에게 편한 방식을 주면 좋습니다.
참고
현업에서는 Description(디스크립션)으로 말하는 분들도 계시니 참고하시기 바랍니다.
