화면설계를 위한 준비 사항

 

 

 

화면설계

- 지붕이다. 지붕이 잘 올라기기 위해 한장 한장 벽돌을 예쁘게 쌓아야 하는데, 이 아래 있는 것들이 잘 받쳐주어야 한다.

 

하부 구조

- 먼저, 정보 설계를 하지 못하면, 화면 설계서를 만들 수가 없다.

- 그리고 요구 사항 정의. 인하우스든 에이전시든 간에 주요 기능들이 요구 사항을 기반으로 만들어지는 것.

 

정책서

- 서비스 정책서에서 만들어줌으로써 어떤 기능이나 메뉴들이 만들어졌을 때 운영할 수 있는 어떤 원칙을 제공하는 것. 그래서 이것이 화면 설계서에 영향이 있다.

 

예시

회원 등급이 변경되게 되면 화면 설계서에 이 부분을 반영해줘야 돼 회원 가입을 할 때부터 이 사람의 등급을 설정할 수 있게 하거나,

자기가 갖고 있는 등급을 확인할 수 있는 마이 페이지 상세에서 등급 정보를 제공해 줘야 한다. 이렇게 이제 영향이 있다는 뜻.

 

회원가입 프로세스 설계

• 처음에 들어갔을 때 휴대폰이나 이메일로 체크.기존 회원인지
• 신규 회원이면 이메일 또는 휴대폰 번호 입력 등 기본 정보 입력시키고
• 그 다음에 아이디 비번 입력하게 시키고 추가 정보 입력시키고
• 그 다음 단계에서 이제 마케팅 동의 같은 걸 시킨다.

이 때, 아이디를 이메일로 할 건지 별도의 영문 숫자로 할 건지 닉네임을 둘 건지 말 건지 프로필이 필수인지 그렇지 않은지는 어디서 정의한다 정책서에서 이런 내용들을 쓴다.

회원의 등급과 타입과 정보들과 또 다양한 이제 마일리지 쿠폰 같은 오퍼들에 대한 부분들이나 상품의 유형과 주문의 형태 같은 것들을 정의한 이 문서를 정책서라고 부른다.

 

정책서를 작성하는 시기

보통 구축이나 신규 론칭 이전 단계에서 정의돼야 한다.

• 그래서 인하우스라고 한다면 신규 런칭 이전에 이게 있어야 한다.
• 에이전시 사이드이라고 한다면 고객사가 제공을 해줘야 되는 문서이다.

 

사용성

구축 단계에서, 전략에서 가져온다.

만약 전략이 없는 경우는 기본적 레이아웃만 정의한다.

 

전략과 구축은 목적이 다르다

전략 단계

• 서비스의 방향성과 핵심 사용성(UX) 요소에 대한 합의
• 주요 화면에 대한 공동 논의 및 결정
• 사용자 흐름과 정보 구조에 대한 정리

구축 단계

• 전략에서 도출된 결정사항을 기반으로 실제 화면 설계 및 구현
• 기능 상세화, UI 요소 배치, 설계 문서화 등 실질적 실행

 

전략과 구축을 나누지 않으면 생기는 문제

=> PO나 설계자(기획자)의 혼란을 초래한다.

- 사람들이 전략과 구축의 경계를 모르고 자신이 생각한 걸 모두 이야기하는데,
이게 전략을 말하는 건지, 구체적 구축을 말하는 건지 경계가 흐려져 혼란을 야기한다.
- 기획 문서도 자꾸 흔들리고 방향이 바뀌는 상황이 발생한다.