서비스 기획 도입 및 순서

기획자란?

- 문제 해결의 최전선에서 이 문제를 해결하기 위해서 나아가는 사람. 그런 것들을 고민하는 사람.

- 그런데 그 문제가 꼭 어떠한 극복해야 될 대상이 아니고 만들어야 할 대상이나 목표일 수도 있다.

 

기획의 범위와 특징

상황 설정 : 건물을 만든다.

• 이것 자체가 기획적 업무, 그리고 시공 과정에서는 시공자들이 건축을 만든다.
• 마찬가지로 웹사이트나 서비스에서도 일을 만드는 사람들이 있는데 이러한 기획을 하는 사람들이 점점 분화되고 있다.
• 그래서 어떤 비즈니스 레벨에서의 인사이트와 설계를 하는 사람들을 우리가 사업 기획자라고 부르는데, 이 사람들은 뭘 하는 거냐면 이 사람들의 산출물은 비즈니스 모델링이다.
• “돈이 어떻게 들어왔을 때 돌다가 어떻게 나가” 그 설계를 한 사람이 서비스 기획자라고 할 수 있다. 서비스 기획자는 이 택시 서비스를 어떻게 잘 만들 수 있을지에 대한 정보 구조와 화면 설계 이런 것들을 진행하는 사람이다.
• 택시 서비스가 많다 보니까 뭔가 경쟁력을 강화하기 위해서 사용자의 경험을 극대화하기 위한 노력이 필요하다. 이를 조사한 사람을 UX 기획자라고 부른다. 그래서 사용자 경험만 엄청 파는 것이다. 사용자 여정을 설계해서 어떤 페인 포인트가 있는지를 도출하는 사람 UX 기획자.
• 이를 화면에 녹이는 사람을 UI 기획자라고 한다.

 

사례 : 헬스케어 앱 설계

1. 프로토타입 설계 단계

: 전체 약 200페이지 분량 중 20페이지 정도만 프로토타입으로 제작

- 이유: 서비스 방향이 초기에는 불분명하기 때문에, 핵심 흐름만 우선 설계

 

주요 기획 요소

• 건강 체크 및 설문을 통한 사용자의 상태 진단
• 진단 결과 기반으로 부족한 점을 분석하여 솔루션 제시
• 상품과의 연계 흐름까지 연결

- 목적 : 고위층에게 기초 플로우를 설명하고 시각화하기 위함

 

 

2. 구축 단계

- 백오피스 화면 약 150페이지 분량 제작

 

구성 요소

• 점수 측정 기준 정의
• 구현을 위한 내비게이션 설계 및 정책 수립
• 상품 전시 및 연계 방식에 대한 플로우차트 설계

구축 단계의 핵심

• 실제 구현자들이 참고할 수 있도록 구조화된 설계를 제공
• 구체적인 정책 및 구성 흐름에 초점을 맞춤

 

3. 운영기획 및 버전 관리

- 특정 페이지 개선 시의 작업 방식

 

절차

1. 전체 설계서에서 해당 페이지 ‘뜯어내기’
2. 필요한 기능 추가 및 수정 작업 수행
3. 관련 부서와 협의 및 컨펌 완료
4. 구현 완료 후 해당 화면을 버전 업하여 원본에 재반영

- 운영 중인 화면 설계서와 실제 구현 상태를 항상 동기화해야 한다.

 

착수 → 설계

프로젝트 착수 시

• 요구사항 명확히 파악 (무엇을 하고자 하는지 정확히 듣고 정의)

 

이후 단계

1. 정보 설계 (IA: Information Architecture)
2. 화면 설계 (UI 설계서 등)
   → 이러한 흐름으로 전체 프로젝트를 체계적으로 추진한다.

프로젝트 관리에 필요한 산출물간의 연관 관계 이해

 

요구사항정의서

구축을 들어갔을 때 누군가가 이걸 만들거나 변경하려고 하는 의도나 목적이 있다.

-> 그 목적들 중에서 유의미한 것들을 정의한 문서.

이걸 다 요구 사항이라고 하는데 요구 사항을 객관적으로 적어줘야 한다.

 

=>요구사항 정의를 한 것은 반드시 확정이라고 하는 절차를 거쳐서 어떤 방식으로 만들 것인지를 이미지나 텍스트로 협의하는 과정을 거쳐야 한다.

 

그리고 이것은 일종의 계약이다 보니까 “확정된 요구 사항은 반드시 어떻다” 구현을 해줘야 된다.
그러면 이 구현을 하기 위해서 특정 요구 사항에 대한 부분이 어떻게 될까?
→ 화면 설계서에 들어가야 한다. 화면 설계서에. 이것은 “이 요구 사항이 발휘된 거야”라고 하는 부분이 연결이 돼야 한다.

 

예시

 

=> 요구사항 추적을 하였을 때 요구사항이 나오지 않으면 기획자의 잘못이다.

그러니까 반드시 요구 사항이 화면 설계서에 아이디 형태로 들어가 있어야 된다.

 

 

정보구조도

: 만들어야 될 사이트나 시스템을 “페이지 단위로 정리한 문서”.

• 페이지 단위. 페이지라고 하는 게 왜 중요하냐면, 화면 설계를 페이지 단위로 하기 때문에 그런 것.
• 그러니까 몇 페이지인지라고 하는 것을 우리가 인지하게 되는 시점은 정보 구조도가 확정되는 시점.
• 그래서 요구 사항을 누락하지 않는 가장 좋은 방법은 정보 구조도에서 요구 사항을 연결시켜주는 것.
  • 요구 사항을 연결시켜줘서 요구 사항이 특정 화면에 반드시 들어갈 수 있게끔 만들어주게 되면 이것을 누락하기는 힘들다. 정보 구조를 만들었을 때는 요구 사항을 매핑 시켜주는 게 정석이다.

 

---

메뉴 vs 페이지

1. 메뉴

: 사용자에게 정보를 효과적으로 전달하기 위해 구성한 페이지의 그룹

- 폴더와 같은 개념

 

2. 페이지

: 서비스 내의 독립된 문서 또는 파일을 의미

- 일반 / 팝업 / 탭 / 스텝 형태 포함

- 인터페이스를 지닌 파일

 

만약 쇼핑몰을 만든다면? 당연히 모든 페이지를 다 정의해야. 한다.

그런데 무작정 하는 것인가? 아니다. 그룹을 만들어서 동일 그룹별로 페이지를 정리하는 것.

즉, 메뉴는 실제 파일이나 페이지가 아닌데, 사람들이 원활하게 사용하기 위해 만든 폴더같은 개념

 

페이지

• 채소 목록 페이지, 카테고리 상세 페이지, 문의 페이지 등.
• 이거를 전체 카테고리, 신상품, 베스트, 알뜰 쇼핑 이렇게 그룹핑 하고 있다 ⇒ 이게 메뉴
• 그러니까 190페이지를 쭉 펼쳐놓으면 접근이 어려우니까. 메뉴로 그룹핑해서 제공하는 것

 

메인 그룹

- 메인 페이지나 메인 페이지 팝업

ex. 앱인 경우에는 스플래시 권한 설정, 온보딩, 코치 마크 등

 

프로덕트 그룹

- 상품을 판매하는 목적으로 만들어진 그룹

ex. 상품 카테고리나 상품 상세, 기획전, 이벤트

 

검색 그룹

- 검색, 검색창, 검색 결과 등

 

유틸리티 그룹

- 상품은 아니지만 없으면 불편한 것들

ex. 로그인, 회원가입, 아이디 찾기/비밀번호 찾기, 마이페이지, 구매 이력 등

 

컴퍼니 그룹

- 회사 소개, 사업자의 정보 개인 정보 취급 방침 이용 약관처럼 의무적으로 게시해야 되는 것들을 의미

 

 

페이지 분량과 일정관리

정보구조에서 페이지에는 ‘1’이라고 하는 마크를 표시한다.(1 숫자 넘버링).

이 페이지에는 반드시 화면 아이디를 부여해서 이 아이디를 기반으로 해서 화면 설계가 이루어지는 것.

• 그래서 이 아이디가 화면 설계를 할 때 이 아이디 화면, 이렇게 연결되는 것이다.
• 그러니까 정보 구조에서 잘 만들어둬야지만 누락된 거 없이 화면 설계까지 올 수 있다는 것이다.

 

사례

- 이렇게 전체 페이지가 나오고 그 등급이나 투입 인력이 설정되게 되면 화면 설계 일정이 나오는 것.

- 그러니까 이걸 뽑기 위해서 정보 구조도를 명확하게 만들어줘야 한다는 것이다.