오늘은 화면설계서에 대해 배웠다.
프로토타입을 바탕으로 피그마를 활용하여 역기회 프로젝트의 화면설계서까지 작성하였다.
프로토타입이 워낙 오래 걸리고, 계속 수정이 들어가기 때문에 동시에 진행된다.
체계적인 디자인 시스템은 내부적으로는 개발자나 디자이너에게 분명한 목표를 제공하기 위해 필요하다.
외부적으로는 정형화되고 안정된 느낌으로 인해 사용자의 경험을 극대화해 준다.
따라서 디자인 시스템이 정의되어 있지 않다면, 고객 신뢰를 잃을 수 있다.
1. 화면설계서란?
: 화면을 어떻게 표현할지를 그려 놓은 와이어 프레임과 함께 기능을 구현하기 위해 작성하는 기능 정의서를 합친 산출물
▷ 기획자가 기획한 서비스 화면이 어떤 형태로, 어떤 기능을 제공하는지를 상세히 적은 문서
※ 워터폴 방법론 (화면설계서 vs 스토리보드)
| 화면설계서 | 스토리보드 |
| 화면을 기반으로 작성하는 방식 | 영상 제작시 이야기의 흐름을 보여 |
| 화면을 구성하기 위해 기획 과정에서 나온 모든 산출물을 포함 | 서비스 이용 시나리오 혹은 인터렉션을 중심으로 전반적인 흐름을 보여줘야함 |
▷ 공통적으로 화면을 전제하고 만들어진 문서이지만 묘한 어감의 차이가 존재함
2. 화면설계서의 주요 내용
▷ 왜 필요하고 누가 사용하며 어떻게 사용하는 것인지를 케이스별로 조목조목 작성
1) 수정 이력 관리: 표 형태로 수정된 날짜와 버전명, 수정 내용, 수정자를 기록
2) 기획의도 / KPI: 기획한 서비스의 의도와 목표, 측정할 수 있는 과업목표를 작성
3) 프로세스 플로우 차트: 서비스의 사용자별 혹은 케이스별 프로세스 플로우 (화면적인 구분뿐 아니라 데이터적인 로직도 함께 볼 수 있게 만들면 좋음)
4) 수정 및 신규 화면 목록(IA), 화면 외 개발 대상: 해당 프로젝트에 포함되어 수정되거나 신규로 개발되는 화면 목록과 API 등 화면이 없는 형태로 개발되는 대상을 적음
5) 와이어프레임 또는 목업 인터렉션: 와이어프레임을 상황에 따른 노출 케이스별로 상세하게 세분화하여 작성
6) 디스크립션 (기능명세서): 와이어프레임에 숫자를 표시하여 해당 숫자에 해당하는 설명이나 로직, 디자인 솔루션 사용 등 설명할 수 있는 모든 것을 기입
3. 작성 시 주의사항
· 서비스를 단위별로 나누고 기능 단위로 나눠 관리 (단위 별로 나누게 되면 향후 업데이트 이력을 관리할 때 유용)
· 화면 ID는 아래와 같이
· Discription(기능 설명)과 Check Point(필수로 확인할 부분)에 들어가는 내용이 중요
· 개발자가 당연히 알만한 내용까지 쓸 필요 없음
4. 완성된 화면설계서
전체적으로 보면 이런 느낌이다.
몇 개의 중요한 페이지만 자세 보자면...
(2023.08.02) 오늘은 개발자 인터뷰를 한 날이다. 프론트랑 백엔드 두 분!
우리가 기획한 추가 또는 개선사항이 개발 가능한지를 피드백 받는 날이다.
근데 사실 우리가 기획한 건 이미 다 될거 알고 있었음...
그렇게 복잡한거도 아니고, 나도 개발 공부를 했으니까!
다만, 리뷰 부분은 프레제뉴가 만들어진 시스템에 따라 까다로울 수 있다고 했다.
그리고 다른 부분들은 며칠에서 몇주면 완성되는 부분이라고 하셨다.
※ 해당 카테고리는 서울경제진흥원과 에이블런에서 주최하는 <데이터 드리븐 서비스기획 체인저스 3기>에 대한 기록입니다.
'[SeSAC] 데이터드리븐 서비스기획' 카테고리의 다른 글
| #25 실무프로젝트 Day 16 // 2차 실무진 인터뷰 (0) | 2023.08.23 |
|---|---|
| #24 역기획 실무프로젝트 Day 14 // 마케팅 아이디어 + 이에 대한 실무진 피드백 (0) | 2023.08.22 |
| #22 서비스기획자가 알아야할 IT용어 // IA, 와이어프레임, 앱개발 관련, UI (0) | 2023.08.22 |
| #21 프로젝트 Day 9 (Sprint 6) // 요구사항 정의서, 스프린트 회고 (0) | 2023.08.22 |
| #20 프로젝트 Day 7, 8 (Sprint 4, 5) // 프로토타입, 고객인터뷰 (0) | 2023.08.21 |
