어느 기획자의 체크리스트

업무에 있어 익숙함이 가장 큰 리스크이자 문제라고 생각을 한다.

그래서 본인 직무(업무)에 대한 체크리스트를 작성하고 확인하는 습관이 중요하다.

아직 필자도 바쁘다는 업무를 핑계로 중구난방으로 작성했던 문서를 보고 반성을 해본다.

작성된 내용 일부는 사이트의 방문과 교육, 가이드 문서 기반으로 출처가 명시되어 있습니다.

1. 한 페이지(Screen)에서는 하나의 기능에만 충실해라

특히, 모바일을 중심 서비스가 증가하는 만큼 모바일에서 서비스를 이용하는 경우가 많다.
작은 화면에서 여러가지 기능을 수행하면,

- 사용자가 사용하기 힘들뿐더러 컨트롤(사용)도 힘들기 마련이다.

- 코치형 가이드가 마구마구 추가되어 복잡하게 될 수도 있다.

- 복합한 UI이나 기능은 사이드 오류를 양산하기도 한다.

특히 우리는 홈이나 메인 화면에서 이러한 실수를 자주한다.

초기 기획을 하거나 리뉴얼을 검토하고 있다면, 한 화면에서 하나의 메인 기능을 사용자에게 제공할 수 있도록 방향을 잡기를 바란다.

문서(화면설계서) 작성시 하나의 화면에 하나의 기능을 명세하게 되면,

기능 코드 1개당 1페이지로 작성될 수 있고 모듈화 재 사용도 용이해진다.

기획 초기 뼈대 설계를 잘 하여 페이지에 기능이 많더라도 한 페이지에서 하나의 기능이 동작할 수 있도록 기획하는 습관을 기르도록 한다.

Page Depth는 3단계가 적당하며 그 이상 Depth가 필요하다면 반드시 Navigation 을 두어서 현재 위치를 사용자에게 인지시켜야 한다.

2. 빈(empty) 페이지를 노출하지 마라.

빈 페이지는 사용자에게 오류인지 아니면 콘텐츠가 없는 것인지 로딩 중인지 알 수 없게 만든다.
아래 몇 가지 케이스를 제시한다.

2-1. 빈(empty) 페이지임을 명시해라 (Placeholder 지정)

제품의 슬로건이나 로고를 빈 페이지에 넣음으로써 페이지에 컨텐츠 영역을 표시한다.

text tagline : 긍정적이며 브랜드의 이미지와 부합 해야 함.
non-interactive image : 강조되지 않은 중립적 성향의 이미지를 사용

2-2. 빈(empty) 페이지를 만들지 마라

메뉴나 페이지 상황에 따라 빈페이지를 노출하지 않고 콘텐츠를 제공할 수 있다.

콘텐츠가 로딩되기 전 사용자에게 표시되어 콘텐츠가 표시될 것을 기대시킬 수 있다. 물론 콘텐츠 로딩(프로그레스)은 센스 있게 있어야 할 것이다.

Starter content

신규 사용자가 서비스를 배우고 흥미를 느끼게 유도하는 방법으로 사용한다.
사용자가 앱을 즉시 탐색하며 시작할 수 있는 컨텐츠를 제공한다.

Educational content

텍스트나 이미지로 사용자를 이해시키기 어려운 경우 컨텐츠로 작성하여 보여준다.
단, 최대한 간결하게 작성해야하며 단계를 Skip 할 수 있어야 한다.

Best match

검색 기능의 경우 조회된 결과가 없을 경우, No result 의 텍스트보다
유사 검색 결과를 노출시켜 사용자 실수에 의한 검색실패를 보정할 수 있다.

2-3. 검색 결과 없음은 빈 페이지가 아니다.

Placeholder 와 검색 결과/데이터 없음은 명백히 다른 영역이므로 별도 페이지 기획이 필요하다.

Placeholder : 구글 이미지 검색 시, 데이터 로딩 전에 노출되는 색종이 이미지
No data / No search data : 검색 결과 없습니다. No search results found ¯\_(ツ)_/¯

2-4. 오류 페이지를 지정해라

웹의 경우 잘못된 접근이나 삭제된 페이지 접근에 대해 page not found 페이지 사용을 권고하고 있다.
Http의 경우 4xx오류는 클라이언트 오류, 5xx 오류는 서버 오류로 분류된다. (2xx 성공)

오류 페이지는 오류에 대한 설명과 다음 액션들을 넣을 수 있다.

=> 주요 항목 : 오류 코드 + 메시지, 뒤로 가기, 홈으로 가기
ex> 404, page not found
ex> 500, Internal server error, 서비스 점검 중, 공사 중

오류 페이지는 서비스 업데이트나 점검중도 포함할 수 있어야 한다.

=> 공사중 페이지, 서비스 점검 중 페이지

3. 대화창의 내용과 버튼은 명시적으로 작성해라

(구글/애플/MS 등 여러 곳의 가이드 참조)

대화창 종류 : Dialog, Confirm, Alert
구성 : Title, Content, Button

3-1. 대화창의 구성은 제목과 내용, 버튼으로 구성되어야 하며, 제목은 생략할 수 있다.

제목은 리스크가 높은 상황이나 손실을 볼 수 있는 상황에서 사용하는 것을 권장한다.
제목은 내용을 읽지 않아도 대화창이 왜 노출되었는지를 인지할 수 있는 내용으로 구체적이며 명확하고 간결한 문장을 사용해야 하며 사용자로 하여금 대화창의 버튼을 선택할 수 있어야 한다.

ex>

좋은 예 : "Erase USB storage?"
나쁜 예 : "Are you sure?" , “Warning!”

대화창의 버튼은 범용적은 "예", "아니오"를 지양하고 내용이나 물음에 맞는 "네, OOO 하겠습니다.", "취소하겠습니다." 와 같이 명확한 행동을 지칭하는 것을 권장한다.

ex> Discard draft?

좋은 예 : "Cancel", "Discard"
나쁜 예 : "YES", "NO"

3-2. 대화창의 액션 버튼 중 긍정적인 버튼을 우측에, 부정적인 버튼은 왼쪽에 배치를 한다.

PC와 모바일은 전통적으로 버튼의 위치(왼쪽, 오른쪽 배치)가 다름을 인지해야 한다.

사용자는 학습을 통해 우측 버튼임을 인지하고 있으며, 무의식적으로 OK 버튼으로 생각하고 누르게 된다.
사용자 행위의 연속성을 보장할 수 있으며, 리스크가 높은 상황에서는 사용자의 실수를 막을 수 있다.

ex> 사용자 행위의 연속성 보장
"Delete from Libiray?"

우측 : "Delete", "삭제하기"
좌측 : "Cancel", "취소하기"

ex> 사용자 실수 방지 및 서비스 리스크 감소
"Using a Google's Location service?"

우측 : "Agree", "동의함" / "동의합니다." / "동의하기"
좌측 : "Disagree" , "동의 안 함" / "동의하지 않습니다." / "동의 안하기"

3-3. 대화창의 액션 버튼은 2개 이상 배치하는 것을 지양한다.

대화창은 기본적으로 사용자에게 이거 Yes or No의 선택을 요하는 기능이다.
대화창의 내용이 해를 돕기 위해 Learn more 와 같은 버튼을 추가할 경우, 선택은 이루어지지 않은 채 화면 밖으로 이동할 수 있다.
필요한 경우 Content에 Inline 확장 기능을 활용하여 대화창 내에서 펼쳐보기 식으로 추가할 수는 있다.
단, 권장하지는 않는다.

ex> 버튼 3개를 넣은 나쁜 예

"Using a Google's Location service?"

"Learn more"
"Disagree"
"Agree"

구글 가이드 참조 >

Material Design

Build beautiful, usable products faster. Material Design is an adaptable system—backed by open-source code—that helps teams build high quality digital experiences.

material.io

3-4. Alert 은 다른 대화창과 구분하여 사용할 수 있어야 한다.

Alert은 시스템에서 호출하는 대화창으로 강한 경고를 사용자에게 노출할 때 필요하다.
웹 브라우저에서 Alert 창이 호출되면 버튼 액션을 취하지 않고는 화면에서 어떠한 조작도 불가능하다는 것을 명심해야 한다.

=> 다시 되돌릴 수 없는 상황을 사용자에게 인지 시켜주는 경우 적합.

ex> 웹 페이지에서 입력 폼 작성 중 새로고침이나 뒤로 가기 버튼을 누를 경우

취소 버튼의 적용
예제 보기 > uxdesign.cc/the-microcopyist-cancellation-confirmation-conflagration-8a6047a4cf9

Nevermind : 색상 이용

=> 빨간색을 이용하여 사용자로 하여금 부정, 파괴, 취소의 의미를 전달

Keep 과 Cancel 이용

=> 취소 요청 대화창에서 유지할 것이냐, 취소할 것이냐 명시적인 버튼을 제공

4. Backoffice (Admin) 사이트 구성 시, CRUD 를 지켜라

Backoffice 와 같이 관리자 웹 사이트나 서비스의 경우 Database를 기준으로 화면을 구성하게 된다.
이 경우, 비지니스 로직보다는 단순 조회, 수정, 삭제 기능이 메인이다.

기본 기능은 CRUD

C (create) : 신규 생성 (new)
R (read) : 조회 (search)
U (update) : 수정 (modify, update)
D (delete) : 삭제

기본(사이트) 구조는

Menu
> Sub Menu
>> List
>>> Detail View
>>>> ADD / Modify / Delete

메뉴에 접근하면 데이터 리스트가 노출되고,
리스트를 선택하면 상세 내용이 노출되고,
데이터를 수정하거나 삭제할 수 있는 액션이 주어짐.
데이터 추가는 리스트나 상세 뷰에서도 가능하다.

List,

즉 그리드 or 테이블은 관리자 페이지 UX의 핵심이다.
어떤 데이터를 표시할 것인가, 순서와 정렬, 검색 조건을 고민해야 한다.
조회된 데이터는 사용자에게 유용한 정보를 즉각적으로 줄 수 있어야 한다.
조회된 데이터에서 다음 액션이 필요한 경우 UI를 통해 명시해서 다음 행동을 유도하는 것도 좋다.

검색창은 통일성을 유지하는 것이 좋다.
매번 바뀌는 검색창 UI는 사용자로 하여금 리소스 소모를 발생시키고 실수를 야기시킬 수 있다.
중요하고 자주 쓰는 검색 조건은 Shortcut 또는 검색조건 저장을 통해 생산성을 향상해라

5. Backoffice (Admin) 구성 고민.

관리자 페이지는 용도에 따라 서비스 분리도 고려해볼 만하다.

보통 3개의 서비스로 구분이 보편적이라 생각한다.

(하나의 사이트에서 권한 분리도 좋은 방법이기는 하나 보안 취약점이 노출될 수 있기에 도메인 분리가 좋다.)

서비스, 시스템 설정 사이트 : 서비스나 시스템 관련된 설정 정보를 다루는 민감한 부분 별도 도메인 분리, 개발/운영
파트너, 유저 관리 : 판매를 위한 CRM 사이트 분리, 영업
통계, 분석 : 사용 패턴 분석 및 데이터를 활용하는 사이트 분리 (DB 분리를 통한 실서버 영향 주지 않기 등), 마케터

대시 보드 구성

이 부분은 좋은 기사가 있어서 그대로 옮겨 왔다.

전략형 대시보드(strategic company dashboard)
작업형 대시보드(operational dashboard)
분석형 대시보드(analytical dashboard)

https://www.bloter.net/archives/311848

효과적인 대시보드를 만들기 위해 고려해야 할 6가지

우리는 데이터를 모니터링하고 인사이트를 얻기 위해 대시보드를 이용합니다. 여러 정보들로 구성되는 대시보드는 때때로 레고를 조립해 하나의 판을 만드는 것처럼 느껴지기도 합니다. 레고

www.bloter.net

#1. 대시보드의 잠재 사용자 이해하기
#2. 대시보드 목적과 활용 방식 결정하기
- 임원 등 조직의 주요 의사결정자가 전체 데이터를 보는 전략형 대시보드(strategic company dashboard)
- 비상상황이나 이상치를 빠르게 인지하고 반응하도록 하는 작업형 대시보드(operational dashboard)
- 트렌드를 이해하고 분석하는 분석형 대시보드(analytical dashboard)
- 실시간성과 탐색(Depth)
#3. 정보 영역 구성하기
#4. 정보 표현 방식 결정하기
- 1. 이 정보 영역에 차트를 사용할 것인가?
2. 차트를 쓰기로 했다면 어떤 차트를 쓸 것인가?
3. 차트 간의 이동이 있어야 한다면 어떤 인터랙션이 적합할까?
#5. 시각적인 가독성·이해력 높이기
#6. 결국 계속 만들고 테스트하고 고치기

6. 화면 설계시 기준 해상도를 설정해라.

화면을 설계할 때 기준 크기와 반응형에 대한 고민을 해야한다.

최소한 Min/Max 의 크기 기준으라도 정의해야 실제 개발된 산출물이 사용자 환경에 따라 원치 않는 모습으로 보여지는 것을 피할 수 있다.

- Windows OS는 괜찮지만, Mac OS의 해상도는 작게, 보통, 크게 등..변태 해상도가 많으니 유의해야 한다.

- SPA(Single page application) 화면 구성시, 아래(옆)에 다음 컨텐츠가 있다는 것을 현재 화면에서 알 수 있어야 한다.

- 즉, 현재 보여지는 화면에 다음 컨텐츠가 걸치도록 구성(낚시)하여 컨텐츠 소비를 유도해야 한다.

ex> Apple 사이트는 해상도를 변경하더라도 하단에 추가 컨텐츠가 있다는 것을 유추할 수 있도록 UI를 구성해놓았다.

메인 컨텐츠가 화면 전체를 차지하지 않고 다음 컨텐츠에게 양보를 하고 있다.

해상도 설정은 플랫폼 기반으로 3가지 타입을 정의할 수 있다.

- PC 기반 : 윈도우, Mac 과 같은 응용 어플리케이션 또는 웹 서비스

- 태블릿 기반 : 가로/세로 모드에 따른 레이아웃 배치

- 모바일 기반 : OS 플랫폼에 따른 기준 해상도과 Min 해상도의 레이아웃 정의 (기준 모바일기기 모델을 설정하는 것도 좋음)

Material 사이트를 참고하여 현재 기획하고 있는 제품이나 제품의 도메인에 맞는 해상도를 선택하면 좋을 것이다.

참고 예> material.io/resources/resizer/

Maximum 1600px : 최대 해상도를 넘을 경우 Fix, Strech, Re-arrange 등 방법을 정의해야 한다.
Baseline 1200px : 주요 컨텐츠들은 기본 해상도에 모두 표시되어야 한다.
Minimum 480px : 반응형에 대한 최소 사이즈로 모바일에서도 컨텐츠 소비에 제약이 있으면 안된다.

Tablet landscape 1024px : 태블릿의 가로모드로 컨텐츠가 배치되는 해상도.
Tablet portrait 720px : 태블릿의 세로모드로 레이아웃이 배치되는 해상도.
Mobile landscape 600px
Mobile portrait 360px

모바일 레이아웃이나 디자인쪽에 더 관심이 있다면 아래 링크를 확인해보면 좋을 것 같다.

모바일 기기 화면에 대응하는 방법 : material.io/devices
화면 크기 계산 사이트 : www.omnicalculator.com/other/pixels-per-inch
GSMArena 모바일 기기 찾기 : www.gsmarena.com/search.php3?
안드로이드 개발자 사이트 - 화면 크기 부분 : developer.android.com/training/multiscreen/screensizes

iOS 개발자 사이트 - 화면 크기 부분 : developer.apple.com/design/human-interface-guidelines

7. 사용되는 폰트의 규격을 정의해라

화면 설계 시 UI 목업화 및 폰트 목업화를 진행할 것이라 생각한다.

UI 목업에 대해서는 다들 필요성과 생산성을 인정하여 잘 하고 있지만

UI 목업 내부를 구성하는 폰트나 전체 타이포그래피(typography)에 대해서는 좀 둔감한것 같아 언급한다.

웹 에디터나 위키 작성할때 사용하는 태그를 생각하면 쉽게 이해할 수 있을 것이다.

Header, Label, Title, Body, Cation, Button 등 생각보다 많은 영역에 텍스트에 대한 정의가 이루어진다.

각 플랫폼별로 정의되는 명칭의 차이는 있으니 프로젝트나 회사 내에서 필수 항목만 정의해서 사용하면

좀 더 깔끔한 화면설계를 할 수 있을 것이라 생각한다.

아래 예시로 3개 플랫폼에서 제시하는 타이포그래피를 공유한다.

좌측 부터 Google Android, Apple Mac, Microsoft APP

필자는 10개 이하의 폰크 규칙을 만들어 사용하면 적당하다고 생각한다.

물론 비주얼을 강조하기 위해 디자이너가 세분화하여 늘어날 수 있지만.. 기획과는 무관하다.

또한 해당 타이포그래프의 폰트 사이즈는 플랫폼별로 다르게 적용될 가능성이 높기 때문에 지정하지 않는다.

Header (Bold) : 가장 큰 글씨, 로고에 사용한다.
Subheader : 두 번째 큰 글씨, 화면을 대표하면 명칭에 사용한다.
Title (Bold) : 컨텐츠의 제목으로 사용한다.
Subtitle : 제목에 대한 설명이나 서브 카테고리에 사용한다.
Body 1 : 메인 본문에 사용한다.
Body 2 : 서브 본문에 사용한다.
Caption : 부연 설명이나 헬프 문구, 툴팁에 사용한다.
Button : 모든 텍스트 버튼에 적용한다. (문장 사이의 하이퍼링크는 Body 로 사용)

8. 모노톤을 사용하자

화면설계서를 작성할 때에는 와이어프레임은 모노톤을 유지하여 작성을 하도록 한다.
화면설계서는 디자이너와 개발자와 소통하는 프로토콜 역할을 수행한다.

디자이너는 제품의 특성에 따라 Identity 부여하고 전체 색상 및 컴포넌트 스타일을 정의할 것이다.
만약, 기획서에 여러 색이 들어가 있다면 디자이너는 이 색을 사용해 달라는 건지, 중요성이 높다는 것인지 혼란을 겪는다.

개발자는 화면설계서에 구성된 UI 요소들과 Description을 보고 기능에 대한 개발 태스크를 정의하고 개발을 한다.
만약, 특정 UI나 설명문구에 강조색이 들어갈 경우 시선이 집중되어 자칫 화면의 일부만 인지하게되어 기능의 예외 상황들이 발생할 수 있다.

화면설계서에서 색상은 요구사항 변경이나 기능의 수정에 의해 해당 부분을 알려줄 때 강조용으로 사용하길 권장한다.
UI 요소에 직접적인 색상을 표시하는 방법보다는 영역을 표시하는 용도로 사용해도 좋다.

Material Grey

이제 화면 설계시 기준 해상도를 설정하고 UI 목업에 폰트까지 정의하는 센스있는 기획자로 태어나길 바란다.

어느 날 문뜩,