신입 UX/UI기획자를 위한 10가지 실전TIP

4년차 UX 기획자 실무팁 대방출

신입 UX/UI기획자를 위한 10가지 실전TIP

-들어가며-

라이트브레인에서 UX/UI 기획자로 근무한 지 벌써 4년째가 되어갑니다. 그간 제가 느꼈던 UX/UI 기획 시 공통적으로 챙기고, 주의해야 할 것들에 대한 내용을 공유하고자 합니다.
특히 UI 가이드 문서(화면정의서) 작성에 관련된 TIP과 자주 하는 실수 등의 내용을 정리해보았습니다. 기본적인 내용이기 때문에 앞으로 UX/UI 업무를 하고 싶으신 분들에게 더 도움이 될 듯합니다.

 
1. UX/UI기획자의 실제 업무

UX/UI 기획자는 회사마다 원하는 역할이 상이하기 때문에 구체적으로 어떤 부서와 함께 누구를 대상으로 일하는가에 따라 조금씩 달라질 수 있습니다.
포털 사이트에 검색하면 UX와 UI를 구분하여 잘 정의되어 있으나, 실제 회사에 들어가서 UX혹은 UI 팀에 들어가면 생각했던 업무와 다른 경우들이 종종 있습니다.
(UX, UI란 용어가 붙은 부서에서 어떤 업무와 역량을 원하는지를 찾아보면 실질적으로 그 부서에서 어떤 일을 하는지 파악하는데 좀 더 도움이 될 것입니다.)

따라서, UX/UI 기획자로서 문서 작성 TIP을 주기 이전에 제가 라이트브레인에서
주로 어떤 업무를 하는지를 공유해야 할 것 같아 말씀드리면, 저는 회사에서 ‘Valuable UX Group’에 속해있고 주로 하는 업무는 다음과 같습니다.
(UX Group에서는 실제 구축을 위한 기획을 많이 진행하는 편이며, UX1 Consulting Group은 리서치와 전략 수립 등의 선행을 위한 기획을 많이 진행하는 편입니다.)

* 라이트브레인의 그룹 조직도

   [UX/UI 기획자의 주업무]
  1) 프로젝트 제안
  2) 리서치 & 인터뷰 & 컨셉 설정 & 주요화면 UI 기획 (때에 따라서 인터뷰 생략)
  3) IA(Information Architecture) 작성
  4) UI 화면정의서 작성
   * VUX일 경우, 발화 관련 기획문서 작성
  5) 디자인 검수 (디자인을 우리 회사에서 할 경우)
  6) 퍼블리싱 검수 (퍼블리싱을 우리 회사에서 할 경우)
  7) 사용성 테스트 (프로젝트에서 요청 시)

 
2. 가장 많이 사용하는 툴과 산출물

UI 기획자가 가장 많이 사용하는 툴은 파워포인트와 엑셀입니다.
근래엔 때에 따라서 스케치나 프로토파이 등을 쓰는 경우도 있으나, 이럴 경우는 애자일 업무 방식을 채택하여 대부분 빠르게 인터랙션이 가능한 목업을 통해 사용성 테스트 또는 시연을 해야 하거나, 디자이너와의 작업 효율성을 고려해 툴을 선택한 경우입니다. 디자이너들은 작업 효율성 및 다른 파트와의 공유를 위해 스케치로 많이 옮겨가는 추세입니다.

스케치를 사용하여 디자인하는 디자이너가 점점 늘고 있다.  출처: avocode.com

가장 많이 사용하는 파워포인트를 통해서 UI가이드 문서를 많이 작성하며, 해당 글에서는 UI 가이드 문서를 작성할 때의 주의점이나 TIP을 공유하고자 합니다.
UI 가이드 문서는 회사에 따라서 스토리보드 등 명칭이 상이할 수 있으며, 제가 말하고자 하는 UI 가이드는 실제 디자인과 개발이 가능하도록 기능 및 정책을 정의하고 선과 면으로 화면을 그린 문서입니다.

 
3. 히스토리와 버전관리

UI 문서에서 표지 다음으로 시작하는 페이지는 문서 수정 히스토리를 작성한 페이지입니다. 문서를 배포한 버전, 수정 및 추가한 내용, 작성자, 수정 내용을 발의한 사람 등의 내용으로 구성됩니다. 히스토리는 수정한 내용을 다른 협력사 또는 고객사에 공유하는 꼭 필요한 내용이며, 분쟁 발생 시 또는 반영해야 할 업무에 누락된 것은 없는지 체크할 수 있는 지표가 되기 때문에 수정된 페이지와 매칭하여 표기합니다. 보통은 색상으로 표시한 네모박스 안에 수정된 내용과 버전, 날짜를 기입하여 수정된 내용을 찾기 쉽도록 합니다. 또한, 화면에서 수정된 내용도 동일한 색상으로 표시합니다.

[Revision History 예시 / 문서 내 수정 태그 표시]

상대방이 이해하기 어렵게 축약해서 기입하지 않도록 하고, 한 번 문서가 배포된 이후에 수정된 경우에는 사소하다고 느껴져도 기입이 필요합니다. 예를 들어 홈에 있는 버튼 명이 수정된 경우에 다음과 같이 작성할 수 있습니다.

     [홈]
     1) 버튼명 수정: [구독하기] → [구독]

당연한 말이지만, 사소하다고 느껴서 리비전 히스토리에 작성하지 않은 경우 디자이너나 개발자가 확인하지 못하고 이전 버전으로 계속 결과물을 공유할 수도 있습니다.

 
4. 공통(Common)의 중요성

히스토리 다음으로 오는 페이지가 대개 ‘공통’ 항목이라고 정의되는 것들입니다.
(공통 항목 외에도 서비스 정책과 관련된 내용이 올 수도 있습니다) 공통이 왜 필요한가에 대해 이야기하면 다른 사람들이 나눠서 작업하더라도 공통적인 룰과 컴포넌트(요소)들로 작업할 수 있도록 하기 위함입니다. 또한, 여러 페이지에 들어갈 내용들을 공통으로 정의하면 모든 페이지에 내용을 수정하지 않아도 되는 이점이 있습니다.

     위의 예시는 언론사의 UI 가이드 문서에 발췌한 내용으로
     왼쪽은 홈에 있는 기사영역을 정의한 내용의 일부이고,

     오른쪽은 숫자/날짜와 관련된 표시법을 공통에 정의한 내용 중 일부입니다.

라이트브레인에서 웹 페이지나 앱을 개편할 경우, 기획해야 할 페이지가 많기 때문에 대부분 파트별로 담당자를 지정하여 나눠서 작업하고 있습니다. 그러므로 이러한 요소들을 정의할 때는 모든 페이지들을 고려하여 사전에 공통의 룰을 함께 정의하고 진행해야 하며, 작업 중 예외 Case가 발생하는 경우 서로 공유하여 공통 내용을 업데이트해야 합니다.

 
5. 공통의 요소들

그렇다면, 공통의 요소로 어떤 것들을 정의해야 하는지 살펴보겠습니다.
서비스마다 다를 수 있지만 아래 항목들은 거의 빠지지 않고 들어갑니다.
서비스에 따라 또는 문서 정책에 따라 아래 항목들이 가감될 것입니다.

GNB (Global Navigation Bar) / Footer / Menu (별도로 정의할 수도 있음)

처음 진입 시 (별도로 정의할 수도 있음)
- 스플래쉬, 업데이트 정책, 튜토리얼(추가 시), 권한 설정 팝업(카메라, 전화번호 등)

데이터 로딩 시
- 페이지 로딩, 이미지 또는 텍스트 로딩, 새로고침(폴다운 리프래시 시), 데이터 업데이트 시

데이터가 없을 경우 case
- 내용이 삭제되었거나, 데이터가 없는 경우 (ex. 마이페이지의 찜 화면/검색 결과 없음)

오류가 발생했을 때 case
- 삭제된 페이지, 네트워크 오류, 접근권한이 없을 시, 시스템 점검 시 등

팝업 유형 및 인터랙션 정의
- 시스템 팝업(알럿팝업)/커스텀 팝업(레이어 팝업, 알림 팝업, 토스트 팝업 등)

입력란 인터랙션 정의
- text 입력 전/입력 시/삭제 시/잘 못 입력 시 (Validation Check 포함) 등

텍스트 표기법
- 날짜, 시간, 금액, 전화번호, 나이 등

페이지 네비게이션/더 보기 버튼 인터랙션

선택 불가, 선택 가능, 선택된 상태 등에 대한 정의
- 선택 불가 시 Dimmed 된 버튼 노출, 선택 가능한 상태인 경우 색상 변경 등

댓글 영역 관련 정의(댓글이 없는 서비스의 경우 제공 안 함)
- 인터랙션, 답글, 신고, 리스트 노출 개수, 글자 노출 수, 공유, 좋아요/싫어요, 댓글 없을 시, 그 외 관련 정책 등

그 외 서비스에 따른 공통적인 정책 – 페이지간 이동, 프로필 및 배지 노출 정책 등

 
6. 빠뜨리기 쉬운 것들

제가 지금도 종종 빠트리는 case는 ‘아무것도 없을 때’의 케이스 정의입니다.
마이 페이지에서 내가 찜 한 상품이 없거나, 빅데이터를 통해 회원에게 콘텐츠를 추천해주는 case에서 쌓여 있는 데이터가 없을 경우, 검색 시 검색 결과가 없는 경우 등 사용자에게 보여줄 결괏값이 없을 때 어떻게 보여 줄지에 대한 정의입니다. 무심코 지나칠 수 있지만, 사용자에겐 오류로 느껴질 수 있는 페이지이기 때문에 서비스 컨셉에 따라 어떻게 ‘아무것도 없을 때’를 표현할지 설정해야 합니다.
예를 들면 검색 결과가 없을 경우, 단순히 ‘검색 결과가 없습니다.’란 text가 화면에 노출될 수도 있지만, 검색이 중요한 서비스일 경우 다른 결괏값을 추천해 사용자로 하여금 다른 경로로 우회하여 계속 서비스를 이용하게 할 수도 있습니다.
네이버의 경우, 검색바에서 특정 키워드를 검색했을 시 검색결과가 없는 키워드일 경우 사용자가 잘 못 입력했을 case를 고려하여 다른 검색어를 제안하여 해당 검색어로 검색한 결과를 리스트에 뿌려줍니다. 이때, 사용자가 어떻게 잘 못 입력할 수 있을까에 대한 고려를 하여 추천 기준을 설정할 수 있습니다.

[네이버에서 검색결과가 없을 시]

[네이버 고객센터 > 검색어 제안서비스 내용 중 일부]

이런 경우, 사용자는 서비스로부터 친절함을 느끼며 사용성에 대한 만족도를 느낄 수 있습니다.
반대로, 서비스에 따라 ‘명확하게 없음’을 명시해주는 것이 사용자에게 혼동을 안 줄 수도 있습니다. 아래 쇼핑 앱에서는 장바구니는 비어있는 것을 문장으로 분명하게 명시해주되, 다른 인기 상품들을 추천하여 다른 상품들을 둘러볼 수 있도록 기획되어 있습니다.

[h&m앱의 쇼핑백]

 7. 버튼이나 필터를 둘 때의 위계질서

제가 처음 화면을 그렸을 때, 제일 먼저 지적받은 것이 기능의 위계질서였고, 다른 신입기획자들도 대부분 처음에 비슷한 실수를 많이 했던 항목입니다.
예를 들면 단순한 리스트에서도 필터기능을 타이틀 옆에 둘 것인지, 아래에 둘 것인지 설정하게 됩니다. 같은 기능 버튼이라도, 어느 곳에 배치하냐에 따라 기능이 달라지기 때문에 공통된 룰로 배치하여 사용자로 하여금 혼란이 없도록 해야 합니다.
또한 동일한 기능을 제공하는 경우, 동일한 위치에 배치하여 사용자에게 동일한 경험을 줄 수 있도록 해야 합니다. 닫기 버튼은 무조건 오른쪽에 배치한다거나 확인 팝업에서 긍정적인 내용은 좌/우 버튼 중에 오른쪽에 배치하도록 설정하는 것 등이 예시가 될 수 있을 것 같습니다.
아래 예시에서 동일하게 생긴 필터 버튼이어도 댓글 타이틀 옆에 있는 경우 댓글의 리스트를 필터하는 기능을, 검색결과 화면에서는 검색어 입력란 옆에 배치하여 검색 내용을 필터하는 역할을 합니다.

[youtube에서 좌: 영상 내 댓글 영역에 있는 필터 / 우: 검색결과에 있는 필터]

아래 예시에서는 같은 검색 버튼이어도 통합검색과 시청 기록 내 검색으로 구분되어 있고, 이에 따라 위계를 상하로 구분하여 배치하고, 버튼 및 텍스트 굵기, 가이드 문구(시청 기록 검색) 등으로 기능을 구분한 것을 볼 수 있습니다.

[youtube의 시청 기록에서의 검색 영역]

8. 클릭영역과 입력영역의 최소/최댓값

화면 안에 입력 영역이나 타이틀, 버튼을 넣을 시 문서이기 때문에 해당 영역에 얼만큼의 텍스트가 최대로 입력될지, 클릭영역은 적당한지 예상하며 기획을 해야 합니다. 디자이너들이 화면을 그리면서 가이드를 주기도 하지만, 어느 정도 기획자가 고려하고 작업하지 않으면 조정 작업을 여러 번 거치게 되거나 디자이너들이 기능 버튼의 위치를 기획과 다르게 배치해야 하는 이슈가 생길 수 있습니다.
경험이 쌓이면 어느 정도 감이 올 수도 있는 항목이긴 하지만, 낮은 해상도의 디바이스에서의 환경도 고려하여 ‘텍스트는 몇 자나 들어갈 수 있을지, 버튼은 몇 개 정도 넣으면 적당할지’ 테스트해보거나 다른 서비스를 참조하여 기획하면 더 수월할 수 있습니다.

또한 화면에서 텍스트가 너무 짧은 경우에도 심미적으로 오류처럼 보일 수 도 있습니다. 최근에 언론사의 홈페이지 기획을 하면서, 기사 제목이 너무 짧거나 기사 내용일 너무 짧은 경우에는 어떻게 대처해야 할지에 대한 고민이 있었습니다. 이런 경우 전체적으로 콘텐츠가 가득 차 있는 화면에서 오류처럼 눈에 띌 수 있기 때문입니다.
기자들이 빠르게 속보성 기사를 발행하게 될 경우, 억지로 텍스트를 길게 늘릴 수 없기 때문에 해당 이슈를 해결하기 위해서 속보를 위한 기사 유형을 만들거나 어느 정도의 텍스트가 입력된 기사들이 추출될 수 있도록 개발하는 것으로 논의가 되었었습니다. 데이터가 없을 때와 마찬가지로 부족할 때도 고려되어야 하는 것 입니다.

 
9. 서비스 플로우

플로우, 플로우 차트 또는 유저 시나리오라고도 불리는 항목입니다.
화면을 기획함에 있어서 누락되는 것은 없는지 점검할 수 있는 역할을 합니다. 이미 그려진 것들을 다시 배치하며 ‘이 버튼을 누르면 당연히 로그인 팝업을 띄워야지’하고 생각할 수 있는 것들도 ‘이 버튼을 누르면 내용을 입력해 달라는 알럿을 먼저 띄워야지’라고 생각할 수 있도록 만드는 항목입니다.
모든 화면에 필수는 아니지만, 로직이 필요한 화면에는 필히 추가하여 기획자로 하여금 놓친 기능이나 case는 없는 지 생각하게 합니다. 또한 이 문서를 함께 보는 개발자나 디자이너로 하여금 더 서비스를 잘 이해할 수 있도록 돕습니다. 버튼을 선택했을 때, 텍스트 입력란을 선택했을 때, 어떠한 인터랙션과 어떠한 시나리오로 화면이 이동하는지 이해가 어렵다면 문서를 읽는 사람이 기획자에게 여러 번 질문하는 사태가 벌어질 수 있습니다.

 
10. Why?

UI 가이드 문서에 화면을 그릴 때뿐만 아니라 모든 업무에 적용되는 항목인 것 같습니다. ‘왜? 이렇게 했는가?’ 에 대한 타당성을 가지고 기획해야 합니다. ‘직감에 따라, 이게 익숙해서’ 라는 이유가 아닌 ‘~사용성을 고려하여, 서비스가 ~사용자를 타겟으로 한 ~ 한 컨셉이기 때문에, 또는 콘텐츠가 한정적이기 때문에’ 등 화면을 또는 서비스를 ‘이렇게’ 기획한 의도를 설명할 수 있어야 합니다.

제가 생각하기에 기획자는 다른 사람들을 설득하고 다른 사람들에게 내가 기획한 작업물을 이해시킬 수 있는 능력이 뒷받침되어야 하는 것 같습니다. 그렇기 때문에 기획문서를 작성할 때 항상 ‘왜?’라는 것을 고려하여 화면을 기획해야 할 필요를 종종 느낍니다. 본인의 생각을 담아 기획을 했다면 디자이너, 개발자 또는 다른 기획자가 ‘ㅇㅇㅇ씨, 이건 왜 이렇게 기획하신 거죠?’ 라고 질문하는 일이 많을 것입니다. 이때 설명할 수 있으려면 본인이 타당성을 가지고 있어야 하며 상대방을 이해시키지 못했을 때, 본인의 생각이 잘 못 되진 않았는지 고집을 부리고 있지는 않은지도 한 번 생각해봐야 할 것입니다.

 
마무리

연차가 쌓일수록 트렌드나 기술은 계속 바뀌지만, 기본적인 것은 바뀌지 않는다는 생각이 듭니다. 기획자의 문서는 여러 사람이 보는 문서입니다. 디자이너, 개발자, 운영자, 관계자들이 보는 문서입니다. 그렇기 때문에 모두가 해당 문서를 읽는 데 어려움이 없도록 ‘가이드’를 지키며 관련된 요소들을 설명하고 그려내야 합니다. 위에서 공통적으로 말하고 싶은 점은

기획자의 말과 문서는 다른 사람을 이해시키기 위한 것

 

이라는 것입니다. 이 글을 정리하는 본인도 아직까지 문서를 작성하다 보면 종종 놓치는 것들이 있어, 항상 놓치는 것들은 없는지 돌아보게 되는 것 같습니다. 완벽하진 않더라도 완벽을 추구하다 보면 잦은 실수는 줄어들 것이라 생각합니다. 이 글이 처음 문서에 화면을 기획하는 분들에게 조금이라도 도움이 되었으면 합니다.

– 라이트브레인 가치UX그룹 윤소연