서비스 기획자의 업무 + 화면설계서, 기능명세서

업무중 시간이 나서 앞으로 계속 보고 공부/참고해야할 내용을 정리해서 기록함.

 

기획자의 업무는?

 

1. 요구사항 명세화

사용자 에게 필요한 사항을 어떻게 시스템에 표현하고 어떤 결과가 어떻게 도출될지 정의를 해나가는 업무. 말 그대로 요구사항을 정확히 만들어간다.

 

2. 서비스 방향 명세화

앞으로 개발될 서비스에 대한 구체화 작업 진행. 고객의 요구 발견, 발전된 방향을 만들어간다.

 

3. 결과물에 대한 사용자 측정

서비스의 방향이 구체화 되었다면 그 방향에 맞게 개발이 진행될 수 있게 개발자와 디자이너 사이에서 도움자 역할.
개발진행시 결과물에 대한 단계별 진행과 변경에 대해 초기 작업과 확인하며 방향성을 잃지않도록 사용자 중심의 길을 제시하는 업무.

 

이 세가지 업무가 다 녹아있는것이 화면설계서(UI 설계도)

 

UI 설계도에 해당하는 용어들
한글로는 화면 설계서
영어로는,

 

1. wireframe
화면 설계에 있어서 뼈대, 윤곽선만 잡아놓은 형태.

2. workflow
작업 흐름도. 디지털 제품 인터페이스가 처음에 어떤 일을 하고 다음에 어떤 일을 하는가 설명해 놓은 문서

3. 스토리보드
디지털제품 인터페이스가 처음에 어떻게 보이는지 그림과 글로 설명한 문서

4. MMI 문서, MMI 규격서
man-machine interface 요즘은 휴먼-머신 인터페이스라고 더 많이 쓰는것 같다.

5. 사용자 시나리오
사용자가 어떤 식으로 디지털 제품을 사용하는 상황이다 라는 측면에서 지칭할 때.

 

보통 화면 설계서(wireframe)와 스토리 보드를 보통 같은개념, 유사개념으로 이해하고 작성. 그러나 사실 화면 설계서와 스토리보드는 다른 문서임. 

화면설계서는 표면적으로 텍스트, 선, 버튼으로 이루어져 있지만 그 안에는 많은 정보를 표현함.
요구사항명세서에 작성된 기능을 시각적으로 배치.

 

 

화면설계서에는 어떤 내용이 담겨야 할까?

 

버전관리 *완전중요함

개정이력 : 첫 프로젝트는 없었지만 (그냥 텔레그램으로 파일 주고 받고) 이 점을 넘버링 / 날자 / 상세 내용(Description) / 어떤 이슈였는지, 어떻게 처리되었는지 / 작성자등으로 정리해 둘 필요가 있겠다.

 

나중에 디자이너가 개발부분에서 예. 여기는 왜 버튼이 없죠? 분명 기획단에서 그 이슈가 있었고 사용성이나 플로우 고려해서 없앤거였는데 그 전후 과정이 기억이 나지 않았다. 다만 우리도 그 부분을 알고있고 필요성을 전에도 고려했었고 없어도 되는것이 맞다. 문서가 복잡해지고 같이 일하는 이해관계자가 많아질 수록 문서관리의 필요성이 절실히 느껴짐.

정보 구조도 : 서비스 기획이 어느정도 완료 된 후 어느 정보를 어떤 중요도에 따라 위계를 결정할 것인지를 잘 결정해야 한다. 이 정보 구조를 구성할 때 개발적인 지식이 있다면 큰 도움이 될 것 같다는 생각이 들었다.

 

+ 서비스 윤곽이 어느정도 잡히면 정보 구조도부터 그리는것이 전체적인 흐름 잡기에 큰 도움이 된다. / 지금 프로젝트 같은 경우는 내가 화면기획을 하고 개발자출신 기획자(백앤드잘알)님이 백엔드 정보구조를 하실듯^^!

 

규칙(일종의 범례) : 경고나 종료, 안내창 등에 대한 내용을 미리 정해둠. 복잡한 작업일 수록 이 부분의 중요성이 커짐. 

화면 목록 : 문서에 감긴 화면 목록 정리. 개발자와의 커뮤니케이션을 위해 화면ID를 표시하기도함. 취소선과 비고를 적절히 활용하면 전체 히스토리를 파악할 수 있어서 좋음.

 

플로우차트 : 설계 화면이 간단하면 안만들어도 됨. 그러나 복잡해질수록 플로우차트를 정리하고 시작하기를 권장. 그리는법은 그려야 할 일이 생길때 다시 찾아서 참고하도록 하자.  웹의 경우 대부분 화면설계만으로 많은 것을 표현할 수 있는 반면, 앱의 경우 다양한 제스쳐와 기능키 등으로 더 많은 표현방법이 필요하고 웹과 같이 메뉴를 늘 고정시켜두지 않아 flow작성이 웹에 비해 중요해짐.

기본 정책 : 플로우차트에서 담지 못한 내용을 정책 문서로 따로 분리/정리. 각 항목에 대한 고민사항과 결정사항을 정리할 수 있음.

권한 정책 : 프로젝트 성격에 따라 권한 설계가 필요한 경우도 있고, 불필요한 경우도 있음.

유효성 검사 디스크립션 작성 : 설계를 하다보면 필수 입력항목과 유효성 체크 시나리오도 정리해야하는데 우측 공간이 너무 좁은 경우에는 디스크립션을 작성하기가 불편. 이때는 페이지를 별도로 분리해서 상황, 문구, 처리 시나리오를 표로 만들어서 정리하면 작성하기도 쉽고 개발자들이 보기에도 좋음.

 

이 내용에 대한 유투브 강의도 있으니 나중에 다시 공부해볼것.

youtu.be/ra3EpF9WTow

 

화면 설계 : 화면에는 관리자 화면의 설계도 포함. 화면을 설계할때는 실제 들어갈 데이터를 쌤플로 넣어줄 것. 그래야 디자이너나 개발자가 해당 영역에 얼마나 많은 텍스트가, 어떤 형태로 들어가는지 알 수 있을 것. 전화번호의 형식 등. 예. 01012345679 / 010-1234-5678 / +82 01 1234 5678 이런건 기획자가 지정해서 넣어준다.

 

 

화면설계서 작성 프로그램

1) 파워포인트
2) power mockup - 파워포인트 내에서 설치하는 프로그램이라 사용하기 좋음
3) 키노트
4) 스케치
5) Axure (정리를 하다보니 기획자 조영수(브런치 팔로잉 해둠)님은 Axure툴을 이용해 스토리보드와 프로토타입이 홉합된 형태의 설계 문서를 제작하신다고함. 나중에 시간나면 시도해 볼것. 아마 이번 프로젝트는 파워포인트가 아닌 다른 툴에 대해 조금은 더 알아둘 필요가 있을 것 같다.

 

기능명세서

구현해야 하는 기능에 대해 상세하게 설명하는 문서. 해당 기능이 어떻게 작동해야하고, 작동이 되지 않았을때는 어떻게 처리 해야하는지 (에러)에 대한 상태를 기재함.
디테일한 기능명세서 -> 프로젝트의 성공

 

기능명서에 무엇을 적어야 할까?

기능을 작동하게 하기 위해서는 1)무엇을 2) 어떻게 만드는지 정의되어야 구현됨.
기획자는 무엇을 만들 것인지에 초점을 두고 기재하면 된다. 개발자는 기능명세서를 보고 전체 구조/설계를 함께 고려하여 '어떻게'구현한다.

기능명세서 작성 방법 및 프로그램

1) 화면 명세서 우측에 작성
2) 별도의 문서로 작성 *엑셀 등에 별도로 작성하면(내용이 많을 경우) 물론 많은 내용을 기재할 수 있지만 개발자가 보기 불편할 수도 있음.

특별히 정해진 바가 있는 것이 아니며 개발자가 편한 방식으로 전달하면 된다.

 

*스토리보드(화면설계서)는 처음부터 완벽하기가 힘들다. 

 

 

실제 개발과 디자인에 돌입하면 모두가 예상하지 못했던 문제들이 나오기 시작하며 무한 토론과 수정을 거쳐야함. 기획자의 커뮤니케이션능력 발휘가 필요하다 하하하하하
그치만 그 누구도 완벽하게 모든 문제를 예상할 수는 없다!!

 

 

자료 출처 및 나중에 다시 참고할 것들

 

UI 설계도에 해당하는 용어들 (pxd.co.kr)

UI 설계도에 해당하는 용어들

화면설계서 (Wireframe)와 기능명세서 (Functional Specification) | by 송미경 | Medium

화면설계서 (Wireframe)와 기능명세서 (Functional Specification)

IT 기획 연구소 (yslab.kr)

[웹/앱 설계의 기본] 화면설계서 작성방법

[웹 기획] 화면 설계 용어 정리 (brunch.co.kr)

[웹 기획] 화면 설계 용어 정리

[기획#3]스토리보드(화면설계서) 작성법-템플릿제공 : 네이버 블로그 (naver.com)

[기획#3]스토리보드(화면설계서) 작성법-템플릿제공

기획자가 화면설계서(스토리보드)를 만든다구요? 기획자가 무슨 능력을 가지고 있는데요? - 강학주의 e-Biz Story (tistory.com)

기획자가 화면설계서(스토리보드)를 만든다구요? 기획자가 무슨 능력을 가지고 있는데요?