UXer가 개발자 이해하기 - 직접 개발해 보기
직접 경험하는 것만큼 빠른 길이 없더라
코로나 덕분에 원활하게 재택근무가 가능해졌다.
특히 이동하는 데 걸리는 시간(왕복 약 2시간)이 절약되어 그 시간 동안 다른 생산적인 활동을 할 수 있다는 것이다. 그래서 기왕 경험 쌓을 겸, 특히 많은 UX UI 디자이너 채용 공고에 있는 "개발자와의 협업"에 대한 조건을 충족시켜 보기 위해 일주일짜리 토이 프로젝트에 참여하기로 했다.
멤버는 친구 한 명이 디자이너로 참여하고 내가 웹 프론트 개발자로 참여했다. HTML, CSS, 바닐라JS는 멋쟁이 사자처럼 동아리 활동을 하며 익혀둔 터라 간단한 수준의 구현은 자신이 있었고 실제로 친구가 건네준 디자인 시안은 정말 간단했다.
그러나 모든 일이 순탄하지는 않았고 우여곡절 끝에 프로젝트는 성황리에 마무리되었지만 몇 가지 크게 느낀 점 들이 있어서 이번 게시물을 발판 삼아 공유하고자 한다.
첫째, 제플린의 numerical 값들을 신봉하지 말자
Handoff 툴로 제플린을 이용했다. UX UI 디자이너 업무를 할 땐 제플린이 만능 툴인 줄 알고 있었는데 이번 프로젝트를 통해 그 생각이 와장창 부서졌다.
우선 제플린 구조는 좌측: 디자인 시안 화면, 그리고 우측: 디자인 요소 패널 이렇게 두 영역으로 구분되어 있다.
예시 - [좌측: 디자인 시안 화면], [우측: 디자인 요소 패널]개발자는 디자이너가 제플린으로 건네준 화면을 보고 디자인 시안 화면에서 컴포넌트들의 크기, 간격을 각각 pt, % 단위로 확인한 뒤 프론트 코드를 짠다. 이때 우측 디자인 요소 패널을 보며 상세 width, height, X, Y 값들을 확인할 수 있으며 폰트 정보, 코드 정보를 볼 수 있다. 그리고 이는 꽤나 정확하게 나오기 때문에 개발에 큰 도움이 될 줄 알았다.
우리는 XD로 디자인, 제플린으로 공유했는데 XD툴의 문제인 건지 제플린의 문제있은 건지는 모르겠지만 제플린에 명시된 컴포넌트 width, height값대로 개발했더니 디자이너가 설계한 레이아웃과는 크기가 다른 레이아웃이 나와버려서 당황했다.
정말 이대로 개발해도 괜찮은 건가?
디자인 작업한 환경이 맥북 13인치에서 해서 그런 건지, XD의 1920*1080 대지에서 디자인 작업 시 콘텐츠 영역을 고려하지 않고 작업했는지는 한번 더 확인을 해야 했지만 전체적으로 컴포넌트 크기가 너무 크다는 느낌을 받았고 제플린에 명시된 X, Y값(위치 좌표)이 애매하게 떨어지는 부분들이 많았다. 프론트를 개발하는 과정에서 의심 스택이 하나둘씩 쌓여가던 도중 무언가 꼬여간다는 생각이 본능적으로 들었고 디자이너 친구에게 말을 했다.
"컴포넌트 간격이 애매한데, 이렇게 잡은 의도가 뭐야? 혹시 가운데 정렬인 거야?"
놀랍게도 가운데 정렬이 맞다는 것이다. 양옆 margin 값이 52pt, 51pt처럼 애매하게 적혀 있는 영역이 많았는데 디자이너 친구도 이 부분에서는 상당히 당황하는 모습을 보였다. 결국 여러 번 묻고 물어 제플린에 스티키 노트(cmd + 클릭)를 화면마다 남겨 가운데 정렬이라는 notation을 알려주는 작업을 거친 후에야 프론트 개발이 훨씬 쉬워졌고 코드도 간결해졌다.
둘째, 디자이너에게 반드시 인터랙션 관련해서 충분한 설명이나 문서를 받자
"이 버튼을 누르면 버튼색이 초록으로 바뀌고, 페이지가 넘어가면서 책 넘어가듯 인터랙션이 흘러가."
맨 처음 제플린을 통해 디자인 시안을 전달받았을 때 들은 말이다. 내용이 얼마 안 되니 기억해놨다가 개발하면서 모르겠으면 물어봐야겠다고 생각한 뒤 개발에 들어갔다.
문제는 여기서 일어났다. 개발을 하면서 친구가 설명해준 인터랙션이나 state 별 컴포넌트의 상태 설명을 수시로 까먹었고 이를 따로 적어놓은 문서가 없었으며 제플린에도 명시되어 있지 않아 모를 때마다 직접 물어보면서 파악해야 했었다. 이게 CSS문제에서 끝난다면 별 상관은 없는데 웹 사이트 내에서 일어나는 인터랙션, request 수에 따라 컴포넌트 상태가 변해야 하는 경우엔 JS 코드까지 건드려야 해서 문제가 많이 귀찮아진다.
만약 이 단계에서 피그마나 프로토파이로 전달받은 프로토타입이 있다면? 인터랙션이나 컴포넌트 state 같은 동적 요소에 대한 내용이 완전히 명시된 문서를 받는 것과 크게 다를 게 없으니 개발하는 입장에서 삽질하는 일 없이 꽤나 도움이 될 것 같다는 생각이 들었다. 만약 계산이 들어가거나 복잡한 인터랙션이 있다면 프로토파이(https://www.protopie.io/)를 통해 프로토타입 파일을 전달하면 개발자는 프로토타입을 보면서 어떤 인터랙션을 썼으며 duration이 얼마나 되는지 파악하기가 쉬울 것이다.
인터랙션 및 동적 요소를 설명해주는 피그마 프로토타입프로토타입을 만들 환경이 안 된다면 제플린 시안에 스티키 노트(cmd + 클릭)를 컴포넌트별로 추가 한 뒤 어떤 스크린으로 넘어가는지에 대한 설명을 달아서 넘겨주거나 사용자 시나리오를 화면별로 작성한 문서를 개발자에게 전달해 주면 개발하는 입장에서 삽질을 최소화하며 개발할 수 있겠다고 느껴졌다.
셋째, 디자인을 수시로 바꾸는 걸 지양하자
"혹시 이 기능 추가해 줄 수 있어? 다시 생각해보니 이 버튼이 들어가야 훨씬 완성도가 높아질 것 같아."
퍼블리싱(HTML, CSS) 작업을 끝내고 JS로 인터랙션을 구현하던 도중 들은 말이다. 그리고 동시에 과거의 내가 많이 하던 말이어서 놀랬다.
퍼블리싱을 다 끝내고 난 뒤 새로 구조 추가 및 변경 요청을 들으면 난처해진다. 인터랙션이 없는 경우엔 그냥 귀찮은 정도지만 본 프로젝트에는 상황에 따라 사라지는 버튼, 나타나는 버튼이 있었다(visibility: hidden; visibility: visible;). 문제는 사라지고 나타나는 좌표와 가까운 위치에 컴포넌트 추가 요청을 받았는데 그렇게 하는 경우 내가 짜 놓은 flex 구조가 다 뒤틀어져서 레이아웃이 뭉개진 상태로 화면에 나오게 된다. position 값을 하드 코딩하는 방법도 있지만 그렇게 될 경우 이후에 유지 보수할 때 어떤 어려움이 나오게 될지 막막함을 느꼈다. 따라서 HTML 구조를 다시 짜는 게 맘 편하지만 시간이 오래 걸리므로(단기간에 끝내기로 서로 약속함) 어떻게든 디자이너를 설득해야 했다..
디자이너 vs 개발자 - 서로 설득하기"우리가 약속한 기간에 네가 추가한 내용까지 개발하기는 시간이 너무 많이 걸려, 공수도 많이 들고. 맨 처음에 디자이 된 사항이면 거기에 맞춰서 구조를 짰었을 건데 하필 버튼을 추가해야 할 위치가 공수가 많이 드는 영역이라 ㅠㅠ 다른 영역에 추가하는 것은 어떨까?"
마치 과거의 나와 대립한다(?)는 느낌이 들어 기분이 오묘했다. 분명 사용성 측면으로 봤을 때 디자이너가 요구한 사항이 맞지만 개발 공수 측면으로 봤을 때 상당한 시간 리소스가 드는 게 뻔해 그나마 디자이너였던 내가 역으로 제안을 걸었고 다행히 제안이 받아들여져서 화면을 수정하게 되었다.
필드에 계신 프로덕트 디자이너 선배님들께 개발과 디자인 간의 우선순위를 정할 때는 개발이 우선인 경우가 많다는 말을 들었을 때 그렇게 많이 와 닿진 않았지만 막상 직접 개발을 해 보니 그 말이 무슨 의민지 깨닫게 되었다. 실제 프로덕트를 개발해내는 것이 우선인 게 수지타산적으로 봤을 때 맞지만 그로 인해 정말 좋은 디자인 솔루션이 묻힐 수도 있겠구나는 생각에 가슴 한 켠이 씁쓸해지는 순간이었다. 앞으로 필드에서 일할 때 개발 vs 디자인 중 순위를 점해야 할 순간이 매번 올 텐데 나는 그때 과연 어떤 결정을 내리게 될까. 기획, 디자인만 알던 과거에 비해 개발에도 발목을 살짝 담가 봤으니 전체 프로덕트를 보는 시선으로 결정을 내리게 될까, 아니면 사용자 중심 프로덕트를 만드는 걸 중요한 가치로 생각하며 디자인 구현에 중점을 두는 결정을 내리게 될까. 앞으로 커리어를 쌓아가는 과정에서 이 문제에 대한 고민을 많~~이 하게 될 것 같다. (결국 모든 것은 캐바캐인 것 같다)
회고
Hankoff 툴로 넘긴 이후 디자이너 할 일은 끝! 이 절대 아니라는 걸 깨달았다. 프로젝트가 종료될 때까지 반드시 지속적으로 소통해야 제대로 된 프로덕트가 나올 수 있다는 것을 몸소 느끼게 된 계기였다. 어쩌면 디자인 시안을 넘겨준 이후부터 디자이너의 2차 역할이 시작되는 걸지도 모른다. 왜냐면 개발자를 포함한 기타 stakeholders와 협동하며 완성도 높은 프로덕트를 도출해야 하므로 적극성, 소통능력 등 자신이 가진 능력치를 최대한으로 발휘해야 겨우 프로젝트가 굴러가기 때문이다. 괜히 공고에 "소통 능력", "개발자와의 협업 경험"이 있는 게 아니란 걸 느끼게 되었고, 역시 인생은 쉽지 않다는 인사이트를 가져다준 의미 깊은 프로젝트였다.
