개발 협업을 위한 안드로이드 디자인 가이드 #02

출처: http://leipiel.tistory.com/8

저번 포스팅에서 디자이너가 제작 전에 이해하거나 알아둬야 할 기본적인 안드로이드 UI 정보에 대해 정리해 보았다. 앞선 내용 전부 디자인 제작 시 반영이 잘 되었다면 개발파트에서 적용하는데 큰 문제는 없을 것이다.

이번에는 실제로 개발자와 협업할 때 필요한 UI 가이드 문서 제작 방법을 정리하려고 한다. 전에도 언급했다시피 UI는 결국 개발 파트를 거쳐 완성되므로 개발 파트와 디자인 파트 간의 밀도 있는 소통이 이루어져야 하며 그 중심에는 UI 가이드 문서가 있다. 정리하고자 하는 가이드 방식은 개인 경험을 통해 축적된 것이기 때문에 내 방식을 주장하거나 강요하는 것은 절대로 아니다. '그냥 이런 방식도 있구나.' 정도로 읽으시면 되겠다. (제 방식에 오류나 더 나은 방법은 알려주세요.)

1. Layout

레이아웃은 UI 구조 및 구성 의도를 잘 전달하기 위해 표시한다.
가상의 프레임들을 시각적으로 제공해 줌으로써 개발자는 버튼의 위치 및 정렬, 각 view의 부모, 형제, 자식 관계를 쉽게 이해할 수 있다. 나의 경우는 이 프레임들을 투명도가 있는 컬러 박스로 구분하되, 필요에 따라 선으로 구분하여 표시한다. 이 표시는 각 구성요소의 위치나 관계성을 이해하기 쉽게 하는 용도다. 개발 관점의 view 구성 가이드가 아니므로 개발자가 더 효율적인 방법으로 구성하면 된다.

2. Images

이미지는 기본적으로 사이즈가 고려된 분할 이미지 파일 형태로 제공되기 때문에 사이즈를 기재해줄 필요는 없다. 40dp x 40dp로 제작된 이미지는 40dp x 40dp로 표출되는 것은 너무 당연한 것이기 때문. (코드 상에서도 이미지 사이즈를 입력하지 않아도 리소스 사이즈 그대로 표시된다.)

이미지는 파일명 정보가 가장 중요하다.
물론 이미지 파일들을 보면 어디에 쓰인 것인지 알 수는 있겠지만 리소스가 많고 투명 값이 많은 이미지들의 경우 탐색기의 썸네일로만 구분하기 어렵기 때문에 가이드에 이미지 파일명이 기재되는 것이 바람직하다. 또 버튼과 같이 이벤트에 따라 여러 개의 이미지 리소스를 사용하는 경우는 미리 약속한 규칙으로 표현해주면 된다. 우리의 경우 파일명 접미사 규칙을 이용하여 구분하고 있다.

_n은 normal, _p는 press를 의미함

3. Weight

전 포스팅에서 전체 디스플레이의 가변성을 고려하여 디자인해야 한다고 언급한 적이 있다. 전체 영역 중 어떤 view가 가변성을 가질 것인지 표시해 주는 것이다. 나는 개발자가 사용하는 명칭 그대로 weight라고 약속하여 가이드에 표시하고 있다. 이런 명칭을 규정하기 나름이므로 각자 환경에 맞게 규정하여 표시하면 된다. 또 연속성을 갖는 여러 개의 가변 영역일 경우 해당 비율을 기재해주면 된다.

 

4. Spacing

모든 레이아웃 구성요소들의 간격은 기본 dp단위로 기재한다.
굳이 margin, padding 구분하여 세세히 기재해줄 필요는 없다. 부모 객체에 padding 값을 적용하는 것과 자식에 margin 값을 적용하는 것은 특별한 경우를 제외하고는 차이가 없다. 그러므로 간격 값만 표시하고 그것을 어느 객체에 margin / padding으로 처리할 것인지는 개발자의 몫으로 남기자.

Header에 left-padding:8 을 할지, btn_prev에 left-margin:8 을 할지는 개발자의 선택!

5. Align

안드로이드에서 구성요소의 위치를 좌표로 지정하여 사용하는 경우는 매우 드물다. 그렇기 때문에 정렬(Align)과 간격(Spacing)을 이용하여 위치 값을 가이드 해야 한다. 정렬 값은 가로 기준, 세로 기준 두 개의 값을 표시하며 이 또한 개발자와 사전에 약속한 규칙으로 기재하면 된다.
나의 경우, 안드로이드에서 사용하는 명칭은 익숙하지 않아 웹상의 용어로 규정하여 사용했었다. (align, v-align) 요즘은 가이드 내에서 최대한 텍스트를 줄이기 위해 선으로 표시하는 방법을 사용한다.

Prev 버튼이 Header 기준으로 align=left, v-align=center에 위치함을 점선으로 표시

6. Text

기본 서체 단위는 SP를 사용하며 이의 환산 방식은 DP와 동일하다. 다만 SP를 사용하는 이유는 OS나 어플리케이션 상에서 서체 크기를 변경하여 사용할 때 적용되는 단위가 SP라고 한다. 그러므로 서체는 SP 단위로 기재한다.(편의에 따라 단위는 생략하자.) 색상은 일반적으로 Hex 값으로 입력하니 hex 값을 기재해주면 된다.
행간은 조절 가능하나 자간은 불가능한 것으로 알고 있다.(문자의 가로 비율을 조절할 수 있으나 자간이나 커닝은 조절할 수 없는 것으로 알고 있음) 이런 부분은 OS의 버전업에 따라 변동이 있으므로 체크하여 표현성에 자유로움을 더하자.

굵기, 크기, 색상으로 표기되어 있다.
때에 따라 TextView가 고정 크기일 수도, 문자길이에 따른 가변너비일 수도 있다.

디자이너 관점에서 안드로이드 개발자와 협업하기 위한 GUI 개발 가이드를 작성하는 규칙(?)을 끄적여봤다.
사실 위에 쓰여진대로 app GUI 가이드 문서를 만든다는 것은 여간 번거로운 작업이 아닐 수 없다. 그래픽툴로 디자인하는 시간만큼 GUI 개발 가이드를 작성하는 시간이 소요되는 것이 나의 경험이다. 물론 시간을 줄일 수 있는 방법이 있고, 그런 방법을 계속 고민하고 테스트해 보지만 그럼에도 불구하고 GUI개발 가이드 작업은 참 재미없고 지루한 작업이다.
여기서 간과하지 말아야 할 것은 GUI 개발 가이드는 디자이너-개발자의 소통을 돕기 위한 미리 합의한 규칙 정도 되는 것이다. 소통을 위한 도구일 뿐이지 목적은 아니다. 그러므로 처한 상황과 여건에 맞게 최소한의 기재만 해도 GUI 개발하는데 무리가 없게 개발자와 많은 대화와 고민을 하는 것이 가장 중요하다.