brunch

매거진 매거진 목요일

라이킷 238 댓글 5

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 티몬 디자인스토리 Feb 11. 2016

디자이너와 개발자의 거리 1px

화성에서 온 개발자, 금성에서 온 디자이너

영원히 좁혀지지 않을 것만 같은

디자이너와 개발자의 1px 간격

모바일 UI 디자인 가이드 작업을 하다 보면 디자이너, 개발자 모두 의아한 상황이 발생합니다.

디자인 작업 시안과 실제 구현되었을 때 화면이 왜인지 모르게 항상 오차를 나타내기 때문이죠. 그렇기에 추후 디자인 QA를 진행하면서 조정하는 과정은 불가피한 일입니다.

우리는 이 과정에서 ‘화성에서 온 개발자, 금성에서 온 디자이너’라는 말을 실감하게 됩니다.

영원히 좁혀지지 않을 것만 같은 디자이너와 개발자의 거리, 1픽셀(px).

하지만 시안을 작업한 디자이너나, 전달받은 문서의 수치대로 작업한 개발자 모두 업무 로스를 줄이고 싶은 마음은 같을 겁니다.

디자인 시안 내 화면 요소들의 크기, 위치 및 간격을 정확하게 전달했는데 어디서 이런 오차가 발생하는 것일까요?

디자이너로서 다소 생소할 수 있는 '안드로이드 프로그래밍' 책으로 팀원들과 함께 스터디를 진행했던 것도 이러한 갈증을 해소하기 위함이었습니다.

실제 업무에서 공부한 것을 토대로 시안과 구현 화면의 간극을 줄이고자 시도하였던 과정들을 소개해볼 텐데요, 이를 레이아웃 상세 기술서(GUI 가이드) 단계를 중심으로 이야기해보려 합니다. 먼저, 오차가 생기는 원인을 아래 세 가지로 정리해 보았습니다.

1. 디자인 작업 시안과 실제 구현 화면의 오차가 생기는 원인

A. 다양한 화면(환경)의 안드로이드

B. 서로 다른 tool을 사용하는 것에서 생기는 오차

C. 화면 내의 고정 영역과 가변 영역에 대한 확실한 정의 부족

원인 A. 다양한 화면(환경)의 안드로이드

안드로이드 디자인이 iOS에 비해 어렵다고들 많이 얘기하시죠? 사실 그 문제의 가장 큰 이유는 안드로이드가 iOS에 비해 셀 수 없이 많은 크기의 화면을 지녔다는 것이 가장 결정적인 이유일 것입니다. iOS는 주어진 디스플레이의 집적도와 화면 크기가 손에 꼽힐 정도이지만(사실 아이폰6,6+출시 이후 이것도 옛말이 되어가고 있는 듯합니다) 안드로이드는 OS부터 화면 크기까지, 여기에 더해 사용자 개개인의 설정까지 포함하면 모바일 앱이 실행되는 환경은 천차만별로 달라지는 것이죠. 흔히 안드로이드의 파편화라고 이야기합니다.

안드로이드의 파편화 (출처: jasonondesign)

안드로이드는 제조사가 하드웨어 에 맞게 OS의 구성을 마음대로 선택 가능 하기 때문에 사용자의 다양한 취향을 만족시킬 수 있는 점이 큰 장점입니다. 하지만 디자이너나 개발자의 입장에서는 그만큼 많은 환경에서 최대한 쾌적하고 안정되게 돌아가도록 고민하고 노력해야만 하겠죠.

원인 B. 서로 다른 tool을 사용하는 것에서 오는 오차

개발자와 디자이너는 여러 부분에서 서로 다르지만, 이 중 제가 말씀드릴 부분은 연장(?)에서 오는 차이입니다. 디자이너도 업무를 진행하면서 개발 툴을 다뤄볼 일이 없고 개발자 또한 포토샵을 열 일이 없지요. 제가 일을 해보면서 디자인 화면 내 요소들 가운데, 구현 화면과의 오차가 가장 심했었던 부분은 텍스트로 들어가는 ‘정보 영역’이었습니다. 티몬은 딜 리스트 영역 내에 딜타이틀, 가격정보영역, 할인율 등이 옹기종기 모여있는 경우가 많아 텍스트의 배치나 간격 등이 화면 구성에 있어서 매우 중요합니다.

다양한 정보가 담긴 티몬의 딜 리스트

때문에 디자이너들은 쫀쫀하게 잘 짜인 디자인 가이드를 개발자에게 넘깁니다. 하지만 왜인지 모르게 개발이 완료된 화면에서는 요소들이 벙벙하게 보이는 경우가 빈번했습니다. 가이드를 전달하는 방식(간격을 재는 방식이라던가..)은 작업자마다 다소 차이가 날 수 있으나 저는 보통 아래와 같이 생각하여 전달하였습니다.

[포토샵 안의 요소들과 사이 여백들(디자인 가이드)]

텍스트바깥으로 타이트하게 여백이 적용이 될 것이라 생각했다면 오산

[가이드에 따라 안드로이드 스튜디오 레이아웃 작업한 프리뷰 화면]

안드로이드 스튜디오 텍스트 뷰는 기본적으로 텍스트 좌우사방에 패딩값을 갖고있습니다.

Xml 텍스트 뷰에 하늘색 백그라운드를 설정했습니다. 텍스트 사방을 하늘색 공기가 감싼듯한 여백들을 확인할 수 있습니다. 텍스트 뷰가 기본으로 가지고 있는 패딩값이지요. 그리고 제가 의도한 여백은 이 바깥으로 적용되었습니다. 개발자에겐 텍스트와 텍스트 사이의 간격은 소용이 없습니다. 박스와 박스 사이로 간격이 들어가기 때문이죠.

[가이드와 비교한 프리뷰 화면의 오차]

텍스트뷰 기본패딩값+가이드에 명시한 여백=의도한 바 보다 여백이 더 넓어짐.

그리하여 결과적으로 여백 오차의 원인은 아래와 같습니다. 만약 빨간 선 기준으로 간격을 재서 전달한다면. 아마 텍스트 두개 사이의 간격은 디자이너의 예상보다 훨씬 더 많이 벌어지게 될 것입니다.

원인C. 화면 내의 고정 영역과 가변 영역에 대한 확실한 정의 부족

디자이너가 디자인 작업하는 해상도는 대부분 대표 해상도 한 가지로 작업합니다(+hdpi 이미지 리소스를 추가로 제공). 그렇지만 작업 해상도는 엄연히 ‘대표 해상도’이기 때문에 다른 레이아웃에서 어떤 영역을 고정하고 어떤 영역을 늘릴 것인지에 대한 정의가 필요합니다.

고정영역과 가변영역 표기의 예 (디자이너와 개발자가 함께 읽는 안드로이드 UI&GUI디자인 263p)

2. 레이아웃 상세 기술서(GUI가이드)및 xml 목업 작업

안드로이드 환경 특성 상 예측 불가능한 다양한 요소들이 많기 때문에 디자인 작업을 할 때 많은 기기 환경에 유연한 디자인을 고민하여 제작했다면, 의도한 디자인대로 나올 수 있도록 충분한 커뮤니케이션을 하는 것 또한 중요합니다. 디자이너가 작업한 해상도의 화면 한 장으로는 다양한 화면 해상도를 접하는 고객들의 사용자 경험을 전부 책임질 수는 없기 때문이죠. 따라서 이런 문제들을 미연에 방지하고 작업한 디자인 결과물을 개발자가 잘 이해할 수 있도록 일반적으로 실무에서는 레이아웃 상세 기술서(GUI 가이드)를 작성하여 전달하고 있습니다.

실제로 앞서 언급한 a, b, c와 같은 문제들을 해결하기 위하여 안드로이드 스튜디오로 레이아웃 작업을 하는 것을 연습해 보았습니다. 아래 그림(왼쪽)은 티몬 로그인 화면 관련하여 전달했던 가이드이고 오른쪽 화면은 스터디를 하면서 목업 작업으로 화면을 짜본 것입니다.

[디자인 시안에 기술한 가이드(왼쪽)와 xml 목업 작업(오른쪽)

왼쪽 가이드는 안드로이드 스튜디오를 연습하면서 바꿔본 형식인데 사실 마진인지 패딩인지, 어디의 마진인지 패딩인지는 중요하지 않습니다. 다만 사이의 간격이 얼마인지를 정확하게 기술하느냐가 더욱 중요한 문제이기 때문이죠. 요소들을 띄워놓는 최상의 방법은 개발자의 몫입니다.

디자인 QA과정에서 a, b, c와 같은 원인들로 인하여 디자이너가 개발자와 디테일들을 잡아가는 데 가장 큰 시간이 소요됩니다.

이 디테일이라는 것이 보통

그림자 크기를 조정하거나

컬러를 바꾸고

투명도를 조정하거나

‘이거 안쪽으로 얼마 넣어주시면 안 될까요’

‘폰트 크기가 너무 큰 것 같아요’

...

와 같은 부분이지요. 디자이너와 개발자가 핑퐁 하는 데에도 시간이 걸리고 문서로 전달하려면 문서 작업시간이 만만치 않게 들어가게 됩니다. 그래서 목업 작업을 하게 되면 내부적으로 작업을 거치고 1차적으로 디테일 조정이 들어 간 후, 가이드로 전달되기 때문에 완벽하게는 아니더라도 웬만한 간격들은 잡히게 됩니다. 덕분에 크게 어그러지거나 하는 사태는 줄어들게 되고, 폰트 크기나 간격 크기 혹은 그림자 투명도, 컬러 정도는 가이드를 넘기기 전에 디자이너가 먼저 프리뷰 화면으로 확인이 가능한 장점이 있습니다. 또한 다양한 다양한 크기의 화면에서 레이아웃이 어떻게 노출될지도 미리 예상할 수 있지요.

가이드 작업 전 디자인 목업 작업 (연습 화면)

다양한 해상도에서 프리뷰로 확인(연습 화면)

가로로 넓어질 경우 내가 의도한 고정/가변 영역

위와 같이 안드로이드 스튜디오 내 프리뷰 또는 에뮬레이터 등으로 확인이 가능하나 단말기에서 확인하는 것이 가장 정확합니다. (실제로 프리뷰와 단말기에서 보았을 때와 차이가 나는 경우를 많이 보았습니다. 비록 단말기마다 조금씩 다를지언정)

간혹 신규화면 개발, 혹은 기존 화면을 새로 개편하는 경우에는 참고 차 xml 파일도 함께 전달하는 경우도 있습니다. xml 파일을 전달하는 목적은 개발 작업 전에 우선적으로 큰 그림을 확인하고, 화면 디자인의 의도를 파악하는데 도움을 주기 위함입니다. (위 마지막 그림 참조)

3. 마지막으로

디자인 개발 가이드 단계에서 기존 방식인 PPT 가이드로 전달하는 방법과 디자인 목업 작업을 거친 xml 파일로 전달하는 부분에 대해서 함께 작업을 진행했던 개발자 분의 피드백을 들어보았습니다

xml로 전달받는 것과 기존 방식대로 PPT로 전달받는 건 정말 일장일단이다. 일단 기존 방법인 PPT로 전달받는 것의 장점은 정보가 한눈에 들어와 알아보기가 쉽다. 어느 곳의 간격이 몇 dp인지 화면과 함께 수치가 전달되기 때문에 작업할 때 시각적으로 전달력이 좋다. 대신 그 수치가 최종 수치가 아니어서(어차피 바뀔 수치) 디자인 QA 시 계속 변경된다는 단점이 있다.

xml로 전달받으면 일단 수치가 검증된 수치라는 점이 장점이다(특히 폰트 사이즈!). 그리고 파일을 전달받아서 확인해보면 전반적인 디자인 의도를 파악하는 데 도움이 된다. 다만 간격이나 이런 수치들을 일일이 까보면서(?) 확인해봐야 하는 점이 번거롭다.

그래서 저희는 장점만을 결합하여 현재 xml 목업 작업 후 1차 조정을 마친 후 결정된 수치를 PPT 형식으로 전달하고 있습니다.

위 내용은 개발 툴을 설치하여 디자인 시안을 가지고 xml 목업 작업을 진행하는 부분에 대한 내용이었습니다. 사실 이것뿐만 아니라, apk 리소스 용량을 줄이기 위하여 drawable xml을 적극적으로 활용하는 것, 그리고 후 작업인 디자인 QA를 진행할 때 xml 코드를 전달받아 효율적으로 커뮤니케이션을 하는 것 또한 앞으로의 바람입니다.