본문 바로가기

개발 안하는 공대생/SW 기획  ٩(*•̀ᴗ•́*)و

지극히 개인적인 기획자의 체크리스트 (1~3)

728x90

 


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

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

 

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

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

 


 

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

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

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

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

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

 

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

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

 

 

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

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

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

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

 

[개발 안하는 공대생/SW 기획  ٩(*•̀ᴗ•́*)و] - 소프트웨어 개발 회사에서 기획이란?

4번 항목 참조

 


 

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~8)

4. Backoffice (Admin) 사이트 구성 시, CRUD 를 지켜라. 5. Backoffice (Admin) 구성 고민. 6. 화면 설계시 기준 해상도를 설정해라. 7. 사용되는 폰트의 규격을 정의해라. 8. 모노톤을 사용하자 1. 한 페이지(Screen)에서는 하나의 기능에만 충실해라. 2. 빈(empty) 페이지를 노출하지 마라. 3. 대화창의 내용과 버튼은 명시적으로 작성해라

기획의 모든 것


 

728x90
LIST