세균무기가 알려주는 서비스 기획의 모든 것(4-1)
뛰어난 제품을 만들기 위해 서비스 기획자 및 PM/PO가 알아야 할 가이
04. 화면(상세) 기획
화면 기획을 위한 스토리보드를 작성하는 방법과 스토리보드를 작성할 때 주의해야 할 사항을 알아보자.
또한, 서비스 구현의 최소 단위인 컴포넌트와 기타 서비스 구현에 필요한 요소들을 살펴보자.
4-1. 기획서 작성 시간과 프로젝트 기간과의 상관관계
프로젝트 작성 시간과 프로젝트 기간과의 상관관계는 비례하기보다는 반비례하는 경우가 많다.
대다수의 매니저는 기획서 작성 시간이 길어지면 길어질수록 프로젝트 기간도 그만큼 늘어난다고 생각하지만, 그렇지 않은 경우가 많다. 또한, 수정 횟수나 QA 시간을 크게 단축할 수 있다.
성공 케이스: 시스템이나 서비스가 정상적으로 작동하는 경우
엣지 케이스: 시스템이나 서비스가 정상적으로 작동하지 않는 경우
4-2. 스토리보드 작성하기
프로젝트 진행이 결정되고 요구사항 정의서(PRD, Product Requirements Docu-ment)나 서비스 정책서를 작성하는 등의 요구사항과 정책이 확정되면 이제 화면 기획을 하게 된다(또는 상세 기획이라고 한다).
UI는 연습장에, UX는 프로토타이핑 툴에
스케치 과정이 중요한 이유는 프로덕트 팀이 서술형의 텍스트로 작성된 정책서나 요구사항 정의서를 잘 읽지 않을 때도 있고, 목업이 이해가 빠르기 때문이다.
최근에는 오픈소스 라이브러리나 Open AI, SDK 등을 활용하여 개발하기 때문에 이를 찾고 분석한다. 즉, R&D에 많은 시간을 할애한다. 따라서 사전에 스케치를 통해 공유하는 시간을 갖고 기획서를 작성하면 기획자가 기획서를 작성하는 동안에 개발자들은 개발에 필요한 라이브러리나 API, SDK 등을 찾고 분석하는 등의 워밍업을 하며 프로젝트 일정을 단축할 수 있다.
특히, 신입이나 주니어 기획자는 논리적 오류가 있는 기획을 할 수 있는데, 스케치를 공유하는 과정에서 사전에 실수를 줄일 수 있다.
변동성과 확장성을 고려해야 한다
스토리보드는 여러 상황과 환경의 변화, 논리적 오류, 동료와의 협의 등에 의해 수시로 수정되거나 변경될 수 있다. 세상에 완벽한 기획서는 있을 수 없기 때문에 항상 수정과 추가, 삭제를 고려하며 작성해야 한다.
1. 변경 이력의 제공: ex 연월일_파일명_버전 정보
2. 페이지 코드의 사용: 기획자마다 다를 수 있다. ex FO(1)-HF(2)-01(3)-01(4)
(1) 어떤 기획서인지 의미하는 영문: FO=Front Office, MO = Mobile, AO = Android, IO = iOS, BO=Back Office
(2) 주요 페이지나 화면의 기능을 구분하는 영문; HF = Header/Footer, SU = Sign up/Log in, HM = Home main
(3) 해당 기능을 구현하는 데 필요한 페이지나 화면의 개수
(4) 페이지나 화면을 설명하기 위해 작성된 기획서의 페이지 개수
기획서를 최초로 작성할 때 미래에 나오게 될 페이지 코드를 알 수 없기 때문에 설명에 '[PC: ]'와 같이 남기며 기획서를 작성한다.
모듈화
빈번하게 자주 사용하는 컴포넌트는 모듈화해 놓거나 자신만의 포트폴리오에 별도로 정리해서 보관하면 좋다.
프로토타이핑 툴이 좋은 이유는 UI 템플릿의 제공과 함께 컴포넌트의 모듈화가 잘 되어 있어 와이어프레임 중심의 목업을 만들고 수정하기가 쉽고 빠르기 때문이다.
"머릿속에서 서비스가 잘 돌아가요?"
[ 끊임없이 시뮬레이션하기 ]
4-3. 기획은 규칙과 패턴이다
사용자들에게 익숙해진 UX/UI를 바꾸는 것이 얼마나 어려운 일인지 이해한다면 새로운 규칙과 패턴을 만들어 정착시키는 것 또한 얼마나 어렵고 힘든 일인지 충분히 이해할 수 있을 것이다.
4-4. 프런트와 서버, API, 어드민
사용자의 액션에 따라 API를 통해 서버와 통신할 때는 서버에 요청하기 위해 전달해야 할 데이터가 무엇인지, 서버에서 이 데이터를 저장하고 처리하여 그 응답으로 어떠한 데이터를 클라이언트에 보내야 하는지 정의해야 한다. 또한, 사용자 액션에 따른 정상적인 처리 결과는 물론이고 엣지 케이스에 따른 예외 처리도 함께 고민해야 한다.
API(Application Programming Interface): 클라이언트 간 또는 클라이언트와 서버가 서로 통신할 수 있도록 하는 규약으로 요청과 응답을 사용하여 통신하는 방법.
4-5. 컴포넌트
웹사이트의 페이지나 모바일의 화면, 즉 클라이언트를 기획하려면 클라이언트를 구현하는 가장 최소한의 요소인 버튼이나 인풋 박스 등의 컴포넌트에 대해 알아야 한다.
기획자가 디자이너, 개발자와 소통하기 위해서라도 코드를 직접 작성할 필요는 없지만, 기본적인 HTML과 CSS를 이해하는 것은 중요하다.
CSS 박스 모델 검색하기
버튼의 높이에 따른 유형을 늘리는 것이 개발 및 테스트의 복잡도를 높이기 때문에 프로덕트 일정에 많은 영향을 미칠 수 있어 버튼 유형을 제한할 필요가 있다.
HTML(Hyper Text Markup Language)과 CSS(Cascading Style Sheets)는 웹 개발에서 가장 기본적인 기술이다.
HTML: 태그를 사용하여 웹페이지의 요소나 속성, 구조를 정의하는 언어, <h1> 태그를 사용해 웹페이지의 제목을 정의하거나 <p> 태그를 사용해 웹페이지의 단락을 정의한다.
CSS는 HTML로 정의된 웹페이지의 요소에 색상, 크기, 위치, 배경 등의 스타일을 지정하는 언어로 h1
{ color: red; }와 같이 웹페이지의 제목에 색상을 지정할 수 있다.
HTML과 CSS를 함께 사용해 웹페이지를 개발하게 된다.
인풋박스: 자동 완성이나 제안 기능 지원. 입력 글자 수 제한하는 등의 형식 유효성 확인하기. 인풋 마스킹
기획자에게는 사용자가 CTA 버튼을 누르기까지 걸리는 시간이나 인풋, 클릭 등의 과정(depth)을 최소화하며 전환율을 높이는 것이 중요한 미션이다.
입력값의 유효성 검사
형식 유효성 검사
이메일 주소의 형식이나 비밀번호의 자릿수, 입력한 비밀번호와 비밀번호 확인이 일치하는지 여부 등 서버와의 통신 없이 클라이언트에서 입력값의 자릿수나 형식을 실시간으로 검사하는 것.
형식이 일치하지 않는 경우, 인풋 박스 하단에 '이메일 주소를 확인해 주세요'와 같이 유효성 메시지를 표시한다.
보통은 인풋 박스에서 포커스 아웃 이벤트를 트리거 삼아 입력값을 검사한다.
데이터 유효성 검사
회원가입할 때 이미 가입된 이메일 주소인지 확인하는 것처럼 서버와의 통신을 통해 서버에 저장된 데이터와 일치 또는 중복 여부를 검사하는 것.
일치하지 않거나 중복된 경우에는 인풋 박스 하단이나 다이얼로그 팝업 등을 통해 '이미 사용 중인 이메일 주소입니다.'와 같이 유효성 메시지를 표시하게 된다.
보통 서버와의 잦은 통신을 지양하기 위해 전송 버튼을 클릭했을 때 입력값의 데이터 유효성을 검사한다.
국내 서비스로 제한하여 이름을 입력하는 인풋 박스를 기획해야 한다고 하자.
한글을 몇 글자까지 입력할 수 있게 지원해야 할까?
이와 관련해서는 가족관계등록예규 제509호 '이름의 기재문자와 관련된 가족관계등록사무'에서 이름의 기재 문자 수에 대한 규정을 살펴봐야 한다.
해당 규정에 따르면 이름은 5자까지 사용이 가능하나, 성에는 그 제한이 없다.
그런데 인터넷에 '국내에서 가장 긴 이름'을 검색해 보면 17자 이름을 가진 사람과 30자 이름을 사용하고 있는 이중국적자가 검색된다.
1993년 관련 예규가 제정되기 전에 등록된 이름이라면, 해당 규정으로는 이름 인풋 박스에 입력할 수 있는 정확한 글자 수를 정의할 수 없다. 그래서 이는 기획자의 재량 행위가 된다.
관련 규정상 이름을 5자까지는 지원해야 하므로 이름 인풋 박스의 입력 가능한 글자 수 기준은 최소 7자 이상은 되어야 한다.
필자의 경우 이름 인풋 박스의 글자 수 입력 기준을 2자 이상 8자 이내로 정한다.
dot(@)과 닷(.)을 사용했는지 여부와 함께 최소 6자 이상 최대 40자 이내로 이메일 인풋 박스의 글자 수 입력을 제한한다.
비밀번호 형식의 기준
최소 길이
최소 10자리 이상: 문자 조합 필요 없음
최소 8자리 이상: 문자, 숫자, 기호 중 2종류 조합 구성
링크(link)
링크는 특정 웹사이트의 메인으로 연결되는 단순 링크와 해당 사이트의 하위 페이지로 연결되는 딥 링크로 구분할 수 있다.
모바일의 등장과 함께 동적 링크 또는 원 링크라 불리는 딥 링크의 한 유형이 등장하게 되었다.
참고 영상: 구글의 동적 링크 소개 영상
URL은 URI의 한 종류로 URI가 더 광의적인 개념
URL(Uniform Resource Locator): 웹 브라우저가 서버에 요청하는 웹페이지를 구성하는 리소스의 경로.
URI(Uniform Resource Identifier): 일반적으로 HTTP, HTTPS, FTP 등과 같이 웹 서버와 통신하는 방법인 프로토콜과 웹 서버의 도메인 이름인 호스트 이름, 포트 번호, 웹 서버의 디렉터리 구조에서 리소스의 위치를 나타내는 경로, 그리고 리소스에 대한 추가 정보를 담고 있는 쿼리 문자열 등으로 구성.
팝업(pop-up)
팝업의 유형: 일반 팝업, 다이얼로그, 토스트 바, 팝오버, 모달 팝업 ⇢ 웹 기준
일반 팝업
페이지에 진입했을 때 페이지 로딩과 동시에 열리는 창. 주로 공지사항이나 배너를 띄우기 위한 목적으로 사용되나, 최근에는 브라우저에서 팝업창이 열리는 것을 강제로 막고, 브라우저 옵션에서 사용자가 팝업 허용을 해야만 표시되기 때문에 잘 사용하지 않는다.
마우스로 팝업의 헤더를 드래그했을 때 브라우저 밖으로 이동시킬 수 있다면 일반 팝업 ⇢ 비추
다이얼로그 팝업
Confirm or Yes or No와 같이 사용자로부터 확인이나 의사를 묻는 팝업.
1) 시스템 팝업: 브라우저나 클라이언트 운영체제에서 기본으로 제공하는 UI 사용
2) 디자인 팝업: 기본 UI를 사용하는 대신 브랜드 아이덴티티를 유지하기 위해 직접 디자인한 UI를 사용
필자는 기본적으로 디자인 팝업을 사용하지만, 네트워크 연결 장애나 단말기 모듈 접근 오류와 같이 서비스 내에서 발생하지 않은 문제로 팝업을 표시해야 할 때는 시스템 팝업을 사용한다.
토스트 바
알림을 위한 팝업
모니터나 브라우저의 좌우측 하단 또는 우측 상단이나 모바일 화면의 상하단에 몇 초간 나타났다 사라지는 형태의 팝업
사용자의 작업 흐름을 방해하지 않고 저장이나 삭제 등의 액션 처리 결과를 안내하거나 광고, 마케팅 메시지를 표시하기 위한 목적으로 사용한다.
Web: 토스트바의 유지기간이 길어도 괜찮다. 화면이 넓음 + 닫기 버튼 제공
Mobile: 스낵바는 작은 화면으로 인해 콘텐츠 이용 방해 + 닫기 버튼 제공의 어려움 ⇢ 유지기간 짧아야 함(1,500ms) / 토스트 바보다는 스낵 바라는 이름으로 불림
사용자의 이동을 최대한 방해하지 않도록 상단 앱 바(내비게이션 바)의 하단이나 하단 탭 바(메뉴 바)의 상단에 기본 마진 값의 간격만 주고 붙여 배치한다.
팝오버
마우스 오버했을 때 나오는 팝업
툴팁과 같이 버튼이나 메뉴에 상세한 추가 설명을 하는 데 주로 사용됨
쉽게 확인하는 방법은 마우스를 포커스 아웃 했을 때 자동으로 닫히는지 확인하기
최근 웹사이트에서 사용하는 대부분의 팝업은 라이트 박스 모달 팝업이라고 부른다.
일반 팝업과 다른 점: 딤 처리가 되어 모달 팝업을 해제하지 않으면 배경화면의 요소와 인터랙션 할 수 없다는 것이다.
모달 팝업은 웹 페이지처럼 구성할 수 있기 때문에 여러 인풋 박스를 둘 수 있다.
이중 팝업은 좋은 UX는 아니기 때문에 딤 영역을 클릭했을 때 모달 팝업이 꺼지지 않도록 하는 것이 좋다.
대신 웹 접근성을 준수하기 위해 팝업 내 닫기 버튼이나 취소 버튼 이외에도 키보드의 esc 키를 이용해 모달 팝업을 닫을 수 있게 지원하는 것이 중요하다.
모바일에서 바텀 시트를 띄우는 경우,
바텀 시트 상단에 핸들바나 닫기 버튼을 잘못 기획하는 경우가 있다.
핸들바를 사용하는 경우에는 핸들바를 홀드 한 다음 상하 스와이프 액션에 따라 바텀시트 영역이 위아래로 이동하며 높이를 조정할 수 있다.
별도의 닫기 버튼을 제공하지 않고 핸들바를 통해 닫거나 상단의 딤 영역을 탭 해서 바텀 시트를 닫는다.
높이가 고정된 바텀 시트의 경우, 핸들바와 닫기 버튼이 동시에 표시되는 바텀 시트가 자주 보인다.
