개발자와 디자이너가 보는 디테일의 차이
개발자가 읽어주면 좋겠다
-여기는 시안이랑 똑같이 해주세요.
-어디가 다른데요?
흔한 개발자와 디자이너의 QA (quality assurance) 대화
이 대화의 문제는 서로 다르게 보고 있음에 의해 발생합니다. 눈이 예민한 사람이 보기에는 명백히 차이가 있는데, 둔감한 사람에게는 그 차이가 인지되지 못하기 때문입니다. 비단 디자이너와 개발자 사이의 문제는 아닌 것 같습니다. 디자이너끼리도 눈의 레벨이 다르고, 현재의 나와 과거의 나의 눈도 다릅니다. 자신의 예전 작업물을 다시 봤을 때 미묘하게 틀어져 보이는 것들을 볼 수 있게 되면 예민함을 캐치하는 눈이 발달하고 있다는 증거입니다.
어쨌든 디테일에도 높은 레벨의 것과 낮은 레벨의 것이 있습니다. 분노는 기본적인 정렬이라던지 이미지가 깨진다던지 낮은 레벨의 디테일조차 지켜지지 않을 때 발생하죠. 그러다 보니 프로젝트 경험이 쌓일수록 애초에 문제가 되는 것들(주로 다양성)을 제거하고 작업하게 됩니다. 많은 UI 디자이너라면 공감하실 내용입니다. 코드의 경제성과 크리에이티브 사이에서의 절충.
그럼에도 불구하고 이것만큼은 포기하고 싶지 않은 디테일이 있습니다. 이번 글은 그에 대한 내용입니다.
UI 디자인은 최종 결과물이 JPG가 아닌 코드로 구현된 동적 화면입니다. 따라서 이미지 시안처럼 화면이 동일하게 나오지 않는다는 아쉬움이 있습니다.
디자이너가 의도하는 디테일을 전부 챙길 수 있는 방법은 두 가지입니다.
1. 직접 코딩한다. -개자이너 가즈아!!
2. css팀이 분리되어 있는 조직 (ex. 네이버)에서 일한다.
3. ui 가이드를 개발자가 보기 편하게 만든다. 가이드를 지켜서 디자인한다. 끈기 있게 소통한다.
*css(Cascading Style Sheets)의 약자로 마진, 행간, 자간, 컬러, 폰트 등 눈에 보이는 시각적인 스타일은 모두 css를 통해 구현됩니다. html(하이퍼 텍스트 마크업 언어-Hyper Text Markup Language)로 웹 문서의 구조를 잡고 css를 통해 꾸미는 식입니다.*
글을 전개하기 전에, 내 작업물을 어떤 개발자가 코딩해 주는지 대략적으로 파악해 보도록 합시다.
1. 퍼블리셔 (마크업 개발자)
2. 프론트엔드 개발자
3. 백엔드/풀 스택 개발자
1. 퍼블리셔 - 퍼블리셔는 디자인 시안을 코드로 화면에 띄워주는 역할에 주력합니다. 따라서 디자이너 입장에서는 가장 만족스러운 결과물을 얻을 수 있어요. css를 능숙하게 다루며 미적인 것에도 (비교적) 관심이 많은 직군이기 때문이죠.
2. 프론트엔드 개발자 - 최근에 분리되어 나온 직군입니다. 프론트엔드 개발자는 백엔드 개발과 퍼블리셔의 중간 역할을 합니다. 화면 디자인보다는 서버와 클라이언트를 이어주며 안정적이고 효율적인 개발에 더 관심이 있습니다. 따라서 물리적으로 css를 심도 있게 다룰 시간이 없으며 반응형 웹의 경우 정상적인 구현이 어려울 수 있습니다. *실력, 관심사에 따라 다름
3. 백엔드/풀 스택 개발자 - 디테일은커녕 큰 그림의 통일된 정렬, 여백, 간격을 지켜내는 것도 사실상 어렵습니다. 애초에 이 직군이 마크업 작업을 하고 있다는 것은 인력이 엄청나게 부족하다는 의미입니다. 또한 디테일을 지키지 않는다고 해서 비즈니스나 핵심 기능이 크게 타격을 입는 것도 아닙니다. 풀 스택 개발자와 단독으로 일 해야만 하는 환경에서 디자이너가 디테일을 주장하는 것은 시기적절하지 않을 수 있습니다.
*개인적인 경험에 의한 주관적인 판단이므로 대동소이하게 다를 수 있습니다.
포기하고 싶지 않은 디테일 1
정렬 (padding&margin)
디자이너는 정렬병에 걸려있는 것이 분명합니다. 정렬이 틀어지는 것은 참을 수 없지요. 기본적으로는 좌정렬, 중앙 정렬, 우정렬이 있습니다. 정렬을 하는 이유는 복잡한 것들을 정리하기 위함입니다. 널브러져 있는 것을 줄을 세워 정리하는 것만큼 효과적인 방법이 없죠.
정렬이 잘 되어 보이나요?위의 이미지를 봅시다. 정렬이 잘 되어 보이나요? 만약 그렇게 보인 다면 당신의 눈은 아직 덜 예민한 상태입니다.
인간의 인식 체계, 즉 감각 기관은 완전하지 못합니다. 대표적인 눈의 오류로는 착시 현상이 있습니다. 따라서 디자이너는 시각 보정을 고려해서 디자인을 해야 합니다. 사실은 그게 아닌데, 임으로 '그렇게 보이게' 만드는 것을 시각 보정 작업이라고 합니다.
다시 위의 이미지로 돌아가서, 위치 값을 숫자만으로 봤을 때 동그라미, 타이틀, 서브 타이틀이 모두 같은 위치에 있는 것은 '사실'입니다. 그러나 폰트가 가지고 있는 1~2px의 기본 여백 때문에 상단의 동그라미가 마치 아래로 떨어질 것처럼 불안하게 튀어나와 있습니다.
사실적 정렬코딩을 할 때 페이지 전체에 동일한 마진을 주면 사실적 정렬로 코딩이 됩니다.
동그라미의 시각 보정시각 보정이 된 정렬의 예시는 위 이미지와 같습니다. 여기서도 동그라미 그룹을 1px 왼쪽으로 들이면 더 딱 맞아 보이겠지만, 다른 글씨와 조합, 그리고 홀수보다는 짝수의 픽셀이 좋기 때문에 4px의 마진을 주는 선택을 했습니다.
paging component이것을 컴포넌트 가이드로 만들면 이렇게 표현이 됩니다. 코딩을 할 때 페이지 전체에 동일한 마진을 주는 것을 해치지 않고 소 컴포넌트의 위치를 조절할 수 있는 방법입니다. 디자이너의 의도를 가이드에 명시하면 커뮤니케이션이 한결 편리합니다.
예시를 하나 더 보겠습니다.
리스트와 아이콘의 조합문제점이 느껴지지 않나요? (안 느껴지는 것도 정상입니다 :))
여기서도 시각 보정을 위해 라인 끝에서 떨어질 듯한 아이콘을 좀 더 안 쪽으로 옮겨주면 좋겠습니다.
아이콘을 정렬시켜야 할 때 저는 주로 두 가지 방법을 사용합니다.
첫째, 아이콘 사이즈를 24px로 만들고 공간을 비운다.
아이콘을 통일된 규격 (24px/ 16px)로 만들어야 코드도 경제적으로 짤 수 있습니다.
24px 아이콘의 빈 공간 예시 (feat. 친절한 피그마)둘째, 오른쪽 패딩에 8px 여백을 추가한다. 이 또한 가이드 문서로 명시를 해줘야 개발자가 의도를 명확히 읽어낼 수 있겠습니다.
포기하고 싶지 않은 디테일 2
폰트의 행간과 자간
타이포그래피 가이드라인디자인 시안과 구현된 화면이 미묘하게 다른 느낌으로 보이는 가장 큰 이유는 폰트의 행간 때문입니다. 이 고질적인 문제를 해결하기 위해서 디자이너도 폰트 가이드를 꼼꼼히 만들 필요가 있습니다. 그때 그때 느낌에 따라 폰트의 사이즈, 행간, 자간을 다르게 디자인하면 디자이너의 의도가 개발자에게 전달되지 않습니다.
따라서 h1-h8의 폰트 스타일을 명시하고 (이때 사이즈, 행간, 자간은 한 세트입니다) 해당 스타일 외의 폰트는 가급적 사용하지 않는 것이 좋습니다. h1-h8로 폰트를 구분하면 시멘틱 html을 고려한 디자인 및 ux 라이팅을 할 수 있으며 검색 엔진 최적화(seo)에도 도움이 됩니다.
저는 폰트의 행간 문제를 해결하기 위해 행간이 있는 스타일, 없는 스타일로 구분해서 표기하였습니다. 사실 이 이슈만 따로 떼서 글을 쓸 수 있을 정도니, 여기서는 가볍게 넘어갈게요. :)
버튼 텍스트
바로 이런 현상이 나타납니다. 버튼의 위아래 여백이 동일하지 못하고 텍스트가 1~2px 아래로 떨어져 보이죠.
행간을 버튼 높이로 코딩하거나 h1~8의 1줄짜리 css를 생성한다피그마에서는 버튼 높이로 코딩하거나 %로 코딩할 것을 제시합니다. 버튼이나 테이블의 높이를 행간으로 잡으면 텍스트가 정확히 가운데 위치하게 됩니다. 그러나 버튼 텍스트 외에도 디자인할 때 행간이 없는 1줄짜리 폰트를 사용할 일이 은근히 많습니다. 따라서 행간 별로 폰트의 css를 정의하는 것을 사전에 개발자와 협의하는 것도 좋을 방법이 될 것 같습니다. 행간은 그만큼 디테일을 위한 중요한 요소입니다.
행간을 가지고 있는 폰트는 디자인을 할 때도 1px 아래로 떨어집니다
잘못 코딩된 예시버튼 텍스트가 가운데 정렬되지 못하는 사례는 정말 많은 서비스에서 찾아볼 수 있습니다.
포기하고 싶지 않은 디테일 3
그룹핑 마진
그룹핑은 그룹들의 마진이 시안과 동일하게 코딩되지 않았을 때, qa 항목 1순위로 올려놓는 부분입니다. 정보가 다른 정보와 섞여 보일 위험이 있기 때문입니다.
사실 이런 저런 방법을 다 뒤로하고 디자인 시안을 투명하게 깔고 코드와 숫자를 조절하는게 디자인과 '똑같이' 나오는 방법입니다. 많은 퍼블리셔들이 제플린에 완벽히 의존할 수 없었던 이유는 공통된 폰트, 공통된 간격만으로 해결할 수 없는 다양한 변수들이 존재했기 때문입니다. 지금 생각해 보건데, 그렇게까지 해서 똑같이 맞춰주려 노력했던 개발자님들의 노고에 감사하게 되네요. :)
디자인 이미지가 최종 산출물이 되는 작업물에서는 디자이너가 알아서 디테일을 챙기면 되지만, UI 디자인은 디자이너와 개발자의 합이 잘 맞아야 완성도 높은 결과물이 탄생합니다. 디자이너는 텍스트, 이미지, 아이콘, 컬러의 밸런스를 잡기 위해 많은 시간 다양한 테스트를 해 보면서 공을 들입니다. 여기에 들인 공이 개발자에게 의도로 읽히지 않는다면 조금씩 미묘하게 틀어진 간격과 통일성의 부재가 프로덕트의 전체의 퀄리티를 떨어뜨리게 됩니다.
디테일이란 하나만 놓고 봤을 때는 무시할만한 것이지만 이것들이 모이면 전체의 느낌과 경험을 좌우하는 것 같아요. 따라서 처음부터 디테일이 지켜질 수 있도록 디자이너가 ui 가이드라인을 잘 만들어 주고, 디자이너의 의도를 읽은 개발자는 컴포넌트 기반의 통일된 코드를 짤 수 있도록 노력하는 습관을 들인다면 서로 만족하는 프로덕트 제작이 되지 않을까 생각합니다. 이상 디테일 알못이었던 숲파 디자이너였습니다. :)
[하기로의 피그마 강의 보기]
성장하는 디자이너, 개발자, 마케터, 기획자, ceo가 세상이 필요로 하는 프로덕트를 만드는 세상을 꿈꿉니다.
프로덕트 기획과 디자인을 한 번에 끝내고 연봉 2배 올리세요!!!
