DEVOCEAN

[번외] UI 상세설계 (1)

 

 

  누가 UX 업무 중 제일 하기 싫은 일을 꼽으라 한다면 UI 상세설계 작업이라고 말할 것 같다. 그만큼 귀찮고 복잡하고 아무도 알아주지 않는 작업이다. UX 담당자들이 말하는 '지긋지긋한 PPT 작업'이 바로 이 단계이다. 키스크린 작업이야 Sketch로 하든 Adobe XD로 하든, 심지어 그냥 손으로 그려도 아무 상관 없지만, UI 상세설계 작업 때문에 결국 키스크린 작업도 PPT로 하게 되곤 한다. 문서 구성을 하나씩 살펴 보자.

 

 

1) 문서 제목

 

  문서 제목은 '서비스명_아이템명_UI Guide_버전_배포일.ppt' 로 한다.

 

 

 

 

  차량의 네비게이션을 예로 들어 보자. 서비스 명은 해당 프로젝트 이름으로 하면 된다. Benz의 MBUX가 이 프로젝트의 이름이라면, MBUX를 쓸 수 있을 것이다.

 

  아이템은 서비스 안에 각각의 독립된 아이템에 해당한다. 전화(Phone), 네비게이션, 라디오 각각이 그 아이템이 될 수 있다. 이 아이템들은 한 서비스 안에 속해 있기 때문에, 서로 연동 되거나 간섭되는 부분이 생기기 때문에 전체적으로 규칙(rule)을 세울 필요가 있는데, 그러한 규칙들은 'General'이라는 이름으로 문서를 만든다.

 

  General 문서에는 검색(searching)이나, 알림, 시스템 팝업 등 서비스 전반에 공통적으로 해당하는 UI들을 정리해 둔다. 그리고, 아이템들 간에 규칙이 필요한 경우. 예를 들어, 차에 시동을 켰을 때 시스템 홈(home) 화면을 보여줄 것인지, 마지막으로 재생한 '미디어'를 플레이할 것인지, 혹은 라디오를 플레이할 것인지를 사양으로 정해서 적어둔다. 

 

  이러한 사양들은 간단한 앱(app)이나 웹 서비스는 단독인 경우가 많아 그 내용이 그리 많지 않지만, 홈(home)이라는 형태를 갖고 있는 서비스들, 예를 들어 웹 포털이나 모바일, 차량 오디오 시스템 등은 상당히 양이 방대하고 까다롭다. UX 담당자의 단독재량으로 결정할 수 있는 경우가 많지 않기 때문에, 별 것 아니어 보이는 사양이더라도 파생되는 여러 사이드 이펙트(side effect)들을 검토하다 보면 상당한 시간이 소요된다. 어느 UX 담당자가 '뭐 하나 바꾸기가 너무 힘들다'라고 불평한다면, 열에 아홉은 이런 경우에 해당한다.

 

 

  UI Guide 라고 표시하는 것은, 개발사양서, GUI Guide 등과 구분하기 위해서이다.

 

 

  버전은, v1.00, v1.01 로 표기하기도 하고, v1.0, v1.1 정도로 표기하기도 한다. 그리고, 데모 단계에서는 v0.1, v0.2 정도로 표시해서 검토하면서 업데이트 작업을 진행하고, 개발팀이나 디자인팀에 '1차 배포'를 공식적으로 할 때 v1.0을 달아 준다. v1.0, v2.0, v3.0,... 은 굵직한 업데이트가 있는 경우에 달아주기 때문에, 프로젝트의 분위기에 맞게 업데이트가 상당히 잦을 것 같으면 v1.00으로 해주고, 그리 잦을 것 같지 않다면 v1.0으로 해주면 된다. 사실 그리 잦지는 않을거라는 예상은 늘 벗어나기 때문에, v100을 넘어가는 불상사가 발생하기 전에 v1.00으로 하는 걸 권한다.

 

 

  마지막으로 배포일은 20200331까지 할 건 없고, 200331 정도로 해 준다. 2100년 전에는 PPT에서 벗어날 수 있지 않겠는가.

 

  이렇게 하면, 아래와 같은 형태의 제목으로 파일을 만들 수 있다.

 

 

  MBUX_General_UI Guide_v1.03_200301

  MBUX_Phone_UI Guide_v1.10_200210

  MBUX_Navigation_UI Guide_v3.01_200304

 

 

  회사나 부서마다 상황은 다르지만, 파일이 여러곳으로 전달되거나 보관하는 과정에서 실수로 내용이 변경되지 않도록 문서가 배포될 때는 pdf로 만들어서 배포하고, UX 담당자만 ppt 원본 파일을 갖고 있거나 하기도 한다.

 

 

 

2) 문서 기본 형식

 

  각 문서는 회사나 부서마다 조금씩 차이는 있지만, 일반적으로 공용되는 형식과 순서가 있는데, 순서대로 하나씩 살펴 보도록 하자.

 

 

---

 

 

(1) 표지

 

 

 

 

  보통 사내 공식 문서의 표지를 그대로 사용하고, 앞서 설명한 제목의 내용이 빠짐 없이 포함되면 된다. 버전과 일자가 제목과 맞지 않거나 실수로 이전버전 그대로 배포되면 골치 아파지니, 잘 확인하고 배포하도록 한다.

 

 

---

 

 

(2) Revision History

 

 

 

 

  문서 변경 이력을 표시하는 페이지이다. 이전 모든 버전의 변경 이력을 간단히 누적 표기 해서, 이력을 찾아야 할 일이 있을 때 모든 문서를 뒤져 보지 않아도 찾을 수 있도록 한 것이다. 

 

 

 

 

  문서에 변경된 내용이 있으면, 해당 페이지의 상단에 이와같이 버전/일자/내용을 표시 해준다. 한 페이지에 여러 번 수정이 덧입혀 질 수 있기 때문에, 보기 편하도록 색상을 다르게 하는데, 사실 ctrl+F로 날짜나 버전을 검색해서 찾기 때문에 굳이 그럴 필요까지는 없지만, 일단은 원래 페이지의 description과 구분하기 위해서라도 색을 넣는 것이 좋다. 버전이 늘어나다 보면 색을 고르는 것도 일이라서 대충 전후 버전과 겹치지만 않게 하면 된다. 

 

  내용은 해당 페이지 번호와 함께 기재 해준다. 설명이 길어지면 summary 하는 의미가 없어지니 가능한 간단하게 메모만 남겨 준다.

 

  작성자는 늘 자리는 있는데, 잘 쓰지 않고 대충 팀 이름 정도만 써 둔다. 원래대로면 작업자의 이름을 써야 하겠지만, 보증에 서명하는 기분이라 차마 손이 가지 않는다고나 할까. 자랑스럽고 증거를 남기고 싶은 프로젝트라면 꼭 써라. 주의할 점은 지금은 꼭 쓰고 싶어도 나중에는 이불 차며 후회할 수도 있다.

 

 

---

 

 

 (3) Table of Contents

 

 

 

 

  '목차'이다. 문서를 업데이트 하다 보면, 페이지 표기는 의미가 없어지기 때문에, 각 페이지의 타이틀 번호를 표기하고, 제목을 기재해 두어서 찾기 쉽도록 정리해 두는 것이다. 

 

  사실 파워포인트로 하는 무식한 작업 중에 하나이기도 하다. 문서 페이지를 새로 작업하면 이 목자 페이지도 수동으로 작업해서 늘려주고, 페이지 자동 적용도 안돼서 아예 기재를 안한다. 오타로 번호라도 잘못 매기면, 번호가 밀려서 나중에 다 다시 써주는 혈압 오르는 작업을 할 때도 있다. 위의 예시는 상당히 간단한 목차이지만, 복잡한 문서는 목차만도 십여장인 경우도 있다. 

 

  문서의 자동화 작업을 위해 Adobe inDesign을 시도해 보기도 하지만, 정리를 위한 정리작업이 또 다시 추가되기 때문에, 결국은 파워포인트로 돌아오곤 한다. Adobe든 Sketch든 어서 열심히 분발해서 파워포인트에서 벗어날 수 있게 해주면 참 좋겠다.

 

 

---

 

 

(4) Explanatory Note

 

 

 

 

  'Explanatory Note'라는 거창한 제목을 달았지만, '기타 등등' 이라고 보면 된다.

 

 

  본문에 넣기 애매한 것들. 주로 문서를 읽기 위해 필요한 기본적인 공통 사항들이나 정의 사항등을 기재해 둔다. 기본적으로는 UI 표기 방법들을 넣는데, 위의 예시는 상당히 간단한 동작만 표기되어 있고, Flicking, Double Click(Tab), Hold, Two Finger, Right Click 등등 상당히 많은 동작이 있을 수 있다.  그 밖에, 몸동작이나 음성, 표정등을 사용하는 NUI(Natural User Interface) 같은 경우에도, 그에 맞는 표기 방법들을 정의 해두어야 문서를 작성하거나 참고하는 여러 사람들이 혼선을 겪지 않는다. 

 

  표기 방법은 정형화된 방법이 있지는 않지만 누가 봐도 합당한(reasonable) 방법으로 표기하면 된다. 아래의 이미지처럼 직접 손 모양을 그려 넣어 주기도 한다. Google이나 Pinterest에서 Hand gesture icon을 검색하면 다양한 표기 방법을 참고할 수 있으니, 적당한 것들로 선택해서 문서에 적용된 UI 인터랙션(interaction)들을 기재해 주면 된다.

 

 

  간혹 버튼과 같은 UI 화면 내 요소(component)들에 대해 정의를 해 두기도 하는데, 요즘은 안드로이드나 iOS 기준으로 많이 정리가 되기도 했고, 필요하더라도 디자인 문서에서 정의하는 경우가 많아 꼭 해야 할 필요는 없다. 다만, 일반적인 상식(!)과 다르게 사용하거나, 독특한 UI 요소를 넣었다면, 이 페이지에 기재 해주면 된다.

 

 

 

 

---

 

 

(5) 구조도

 

 

  이 페이지부터 본격적으로 컨텐츠에 대한 상세 설계가 포함된다.

 

 

 

 

  메뉴 구조도(menu tree) 는 키스크린들을 기준으로 어떻게 구성되었는지를 보여주는 표이다. 

 

  메뉴 구조가 상당히 복잡하거나, 방대한 서비스라면 General 문서에 메인 키스크린 구조만 기재하고, 각 문서 별로 하위 구조를 작성하기도 한다. 그렇지 않고, 서비스 전체를 한 페이지에 담을 수 있다면, 샘플 이미지처럼 전체의 메뉴 구조를 작성하고, 해당 문서에 속한 부분을 표시 해준다.

 

 

---

 

 

(6) 영역 정의

 

 

 

 

  이제 서비스 전반에 해당하는 화면 구조를 기재할 차례이다.

 

  보통 '상단 메뉴 영역 / 본문 / 하단 영역(footer)'으로 구성되는데, 예를 들어 '상단 메뉴 영역에서 로고(logo)는 좌측 상단에, 로그아웃 버튼은 우측 상단에 상시 노출되도록 한다.' 라는 정의를 이 페이지에서 해 주는 것이다. 이 페이지에서 정의된 내용은 메뉴 구조도의 어느 키스크린으로 이동하더라도 공통적으로 적용된다.

 

  화면 사이즈. 즉, 구체적인 pixel 사이즈도 함께 기재해 주는데, 개발/디자인팀과 의논해서 결정한 사양을 적어 넣으면 된다. 그리고, 하이브리드 웹앱이라면 브라우저 사이즈 변경에 따른 화면 구조를 이 페이지에 표시해 준다. 

 

 

---

 

 

(7) 기본 정의

 

 

 

 

  화면 구조도와 연관되는 페이지로, 상세 키스크린 페이지에 기재가 불가능한 사양들을 정리 해두는 페이지이다. 예를 들면, 메인 화면에서 서브 화면들로 넘어가는 데는 다양한 조건들이 존재할 수 있다. 유료 서비스 회원만 보이는 서브 화면의 경우, 일반 무료 회원에게도 페이지를 노출 시킬 것인지, 혹은 아예 보이지 않도록 할 것인지 라던가, 네트워크 상태에 따라 다른 페이지를 접근하도록 유도한다거나 하는 등의 조건들을 정리한다. 

 

  그 밖에도 해당 문서에서 전반적으로 상태나 조건들이 정의될 필요가 있다면, 이 페이지에 정의한다. 해당사항이 없다면 굳이 만들지 않아도 되는 페이지이다. 

 

  유의할 점은, 조건이나 상태 등에 기재하는 용어가 개발팀이 정리하는 개발사양서와 일치해야 한다. 예를 들어, '서비스 중지 상태'인 사용자와 '해지 상태'인 사용자가 동일한 화면으로 넘어간다고 해서, 대충 하나로 합쳐 '서비스 중지'로 기재해서는 안된다. 적용되는 모든 상태 조건을 개발팀과 의논하거나 요청해서 싱크(sync)를 맞춰야 혼선이 생기지 않는다. 

 

  간혹 문서에 작성하는 용어를 그다지 신중하지 않게 사용하는 UX 담당자들을 볼 수 있는데, 용어는 반드시 문서 전체에 일관되게 쓰여야 하고, 개발사양서와 가능한 - 반드시라고 말하고 싶지만, 쉽지 않은 일이다 - 일치하도록 신경써야 한다. 단순한 앱이나 간단한 서비스 같은 경우에는 개발 인원 규모가 작기 때문에 이심전심으로 해결하는 경우가 많지만, 규모가 커지고 복잡해 지게 되면 용어 하나가 불러 일으키는 나비효과를 경험할 수 있다. 

 

  물론, 개발사양서를 아름답게 정리 해 두는 개발자를 만나면 UX 담당자 입장에서도 참 행복하겠지만, 드물긴 하다. 그럴 때는 사양서 내놓으라고 싸우지 말고, 같이 정리 하고 용어도 정의해 나가는 마음가짐을 가져 보자. 개발자도 일 잘하는 UX 담당자를 만나고 싶겠지만, UX 담당자도 마찬가지로 일 잘하는 개발자를 만나면 몸과 마음이 편하기 마련이다.

 

 

---

 

 

To be continued...