Figma가 2% 부족할 때
디자인에 온전히 집중하기 위해 필요한 ‘제3의 협업 공간’
Figma가 소프트웨어 세상에 가져온 변화
Figma가 소프트웨어를 디자인하고 만드는 세상에 가져온 변화는 이전 어느 제품과도 비교할 수 없을 정도로 컸다. 소프트웨어를 만드는 사람들은 이제 디자인을 따로 하지 않고 동시에 같이 인터페이스를 제작할 수 있으며, macOS뿐만 아니라 Windows, Linux 등 OS 환경의 제약 없이 자유롭게 협업할 수 있게 되었다. 처음에는 Sketch의 대안 정도로 시작했을지 몰라도 지금의 Figma는 인터페이스 제작 툴 그 이상이다. 인터페이스 및 인터랙션 디자인에 필요한 모든 도구를 처음으로 웹에 올린 사례이며 디자이너들의 동시 협업까지 지원한다. 소프트웨어 디자인에 있어 Figma는 미래다.
디자인은 더는 디자이너만의 업무가 아니다. 모두의 일이다. 예전에는 디자인이 그저 개발 후 포장 정도로의 인식이 컸다면, 이제는 정 반대다. 디자인이 제품 개발의 핵심이고 디자인 중심으로 사람들이 모여 협업한다. 백로그를 보고 제품을 상상할 수 있는 사람은 개발자밖에 없다. 화면을 봐야 사람들도 제품을 이해할 수 있다. 디자인이 먼저고, 디자이너뿐만 아니라 제품, 개발, 마케팅, 영업 등 회사의 여러 파트가 모두 함께 디자인해야 한다. 그래야 다양한 의견들을 수렴해 좋은 제품을 만들어낼 수 있는 것이다. Figma가 소프트웨어 업계에 가져온 변화의 시작 중에 가장 큰 것은 이것이다. Figma는 디자이너뿐만 아니라 다양한 직군에 있는 사람들이 디자인에 기여할 수 있는 발판을 마련해 주었다.
Figma가 2% 부족할 때
Figma가 제품 디자이너들에게 이전에는 할 수 없었던 것들을 하게 해주는 대단한 제품이라는 사실에는 이견이 없지만, 디자이너들이 창의적인 생각을 하도록 돕기 위해 자유도를 높임과 실시간으로 다른 사람들과 동시에 같은 화면을 볼 수 있도록 함으로써 Figma가 포기한 것은 바로 체계적인 협업과 비동기적 커뮤니케이션(asynchronous communication)이다. 리모트 환경에서는 체계적인 협업과 비동기적 커뮤니케이션 없이는 일을 효율적으로 하기가 정말 힘들다. 모두가 한자리에 있지 않고 떨어져서 일하기 때문에 협업 내역을 기록하고, 비동기적으로 필요한 소통을 주고받으며 제품의 형상(configuration)을 관리할 필요가 있다.
높은 자유도가 주는 혼란
Figma 화면Figma에서 디자이너는 다른 디자이너나 이해관계자들 (PM, 엔지니어링, 마케팅, 세일즈 등)을 게스트로 초대해 실시간으로 협업할 수 있다. 문제는 실시간 협업이 끝나고 디자인이 업데이트 되면서 다른 구성원들이 길을 잃고 디자이너에게 질문을 하게 된다.
“그때 공유해주셨던 그 디자인이 어디에 있었죠?”
디자이너는 해당 프레임을 찾아 링크를 복사한 다음에 공유를 하게 된다.
Figma는 디자인 작업 툴이기 때문에 UI내에서의 자유도가 매우 높아 사실상 여러 가지 방법으로 구성할 수 있다. 이렇다 보니 조금만 시간이 지나도 디자이너가 마음먹고 정리하지 않는 이상 Figma에 저장되는 프레임, 페이지, 파일의 단위가 수십, 수백 개로 불어나 버린다. Figma 이전처럼 디자인 작업을 하는 툴과 공유용 툴이 나눠져 있는 것이 아니라 올인원(all-in-one) 툴인 Figma에서는 디자이너가 임의로 직접 디자인 구성의 단위와 정리하는 방식 등을 정하고 체계화해야 하는 것이다.
디자이너는 이해관계자들의 이해를 돕기 위해 설명하는데 시간을 써야 하고, 어쩌면 미팅 전에 보기 좋고 알아보기 쉽게 정리도 해야 한다 (그러다가 하루가 다 갈지도 모른다). 설령 디자이너가 Figma 페이지를 들어가서 보더라도, 해당 Figma 페이지를 만든 디자이너가 아닌 이상 각 파일과 페이지의 구성을 이해하고 원하는 프레임을 찾아서 참고하기란 정말 쉽지 않다.
양보해서 디자이너가 시간을 내 프레임들과 페이지들을 정리한다고 가정해보자. 여기서 발생하는 문제는 디자이너마다 정리하는 방식이 제각각인 데다가 이 정리를 매번 할 수는 없지 않은가. 화면 만들기 바쁜데, 정리만 종일 하고 있을 수는 없는 노릇이다.
최종 디자인 전달과 세부적인 버전 관리에 대한 어려움
“OO님, 그래서 이게 최종 버전인가요?”
앞서서 말했듯, Figma는 공유가 가능한 디자인 작업 툴이기 때문에, 디자이너는 최신 또는 버전 업데이트 여부에 따라 다른 구성원들이 구분할 수 있는 장치를 마련해야 한다.
우리는 많은 제품 디자이너들과의 대화를 통해 Figma를 사용하는 디자이너들이 별도의 페이지를 만들어 최종 (또는 ‘마스터’)이라는 이름을 붙히거나 시간을 들여 작업 영역에서 색깔이나 ‘박스 처리’ 등으로 ‘이것이 최종임’이나 ‘작업 중’ 등 작업 현황을 알려 협업을 이어가는 것을 알게 됐다. 또한 Figma에서 이전의 디자인으로 돌아가거나 기록을 확인하는데 힘들어한다는 것도 알 수 있었다.
Figma에서 제공하는 timestamp 버전 히스토리 기능. 시간별로 작업을 기록할 수 있지만 세부적인 버전 관리는 하기가 어렵다.Figma는 Google Docs와 같은 원리인 타임 스탬프(timestamp) 방식으로 버전을 관리한다. Figma 파일을 페이지 단위로 일정 시간마다 끊어서 저장하는 방식이다. 이 방식은 무척 편리하고 직관적이어서, 특별히 저장 여부를 걱정하거나 수동으로 저장할 필요 없이 디자이너가 마음 놓고 디자인 작업을 할 수 있도록 도와준다.
이와 같은 timestamp 방식의 단점은 세밀한 변화까지는 추적하기가 매우 어렵다는 점이다. 페이지 안에 많은 프레임이 있으니 프레임 중 하나의 폰트를 키우거나, 레이아웃을 변경했을 시 이런 변화를 한 눈에 감지하고 추적하기에는 많은 수고가 들어간다.
디자이너가 한 명뿐이라면 어떻게든 일을 돌아가게 할 수는 있을 것이다. 하지만 새로운 디자이너가 합류하거나 일이 바빠지고 하면 분명 miscommunication의 리스크가 존재한다. 잘못 소통된 부분은 바로 잡으면 되긴 하지만, 제품 개발에서 잘못된 소통은 곧장 제품의 퀄리티에 직접적으로 영향을 미친다.
디자인 태스크 관리 및 협업
디자이너는 디자인을 일정 부분 작업 후에는 동료 디자이너나 혹은 이해관계자들에게 디자인을 공유하고 피드백을 받은 후에, 이 피드백을 토대로 작업을 추가로 진행한다. 이때, 우리가 만난 디자이너들 대부분은 각자 자기만의 방식으로 피드백을 받고, 할 일을 관리하고 있었다. 어떤 사람들은 Figma 화면내에 text box를 만들어 피드백과 할 일을 기록하고 있었고, 또 어떤 사람들은 노트패드를 들고 다니면서 직접 손으로 적었다. 어떤 사람은 구두로 피드백을 듣고, 머릿속에 할 일을 담아두고 작업한다고 했다.
엔지니어들과 디자이너들이 Jira보드를 공유하다보니 백로그에 개발 이슈와 디자인 태스크가 섞여서 결국 차고 넘치더라구요. 또 아무리 필터를 한다고 한들 디자인 태스크와 작업이 필요한 비주얼이 한 눈에 잘 들어오지 않아 아예 Jira를 안보기 시작했습니다. Jira를 보느니 차라리 손으로 직접 할 일을 관리하는게 편해요.
— UX Designer @ 뉴욕 디지털 에이전시
우리는 여러 디자이너와의 인터뷰를 통해 디자이너가 피드백을 받을 때는 꽤 다양한 루트로 피드백을 받는다는 것을 알게 되었다. Figma에서 댓글로 받는 것부터 시작해서 여러 명이 참석하는 디자인 리뷰 미팅, 이메일, 슬랙, 지라(Jira) 등 피드백이 전달되는 곳은 다양했다. 문제는 피드백이 너무 많아지면서 한눈에 모든 피드백을 정리해 보기가 힘들고, 우선순위를 결정하는데 시간이 오래걸린다는 것이다.
피드백이 한 곳에서 이뤄지지 않고 파편화되어서 전달되다 보니 어떤 피드백은 놓쳐버리고 마는 경우도 있었다. 게다가 피드백으로부터 만들어진 태스크는 개발자들을 위해 만들어진 Jira에서 따로 생성되거나 아니면 디자인의 문맥을 확인하기 어려운 Trello나 Asana 등에서 생성되곤 한다. ‘할 일 관리는 어디서든 되기만 하면 되지 않느냐’라고 반박할 수는 있겠지만 개발 이슈들과 디자인 태스크들이 섞이기 시작하면 디자이너들은 아예 태스크 보드를 보지 않고 로컬에서 할 일을 개인적으로 관리하기 시작한다는 것을 쉽게 관찰할 수 있었다.
실리콘 밸리에 있는 연 매출 200억 원이 넘는 HR 소프트웨어 스타트업의 리드 프로덕트 디자이너는 우리와의 대화에서 이렇게 말했다.
Figma에서 피드백을 주고받기란 사실 쉽지 않습니다. 한두 개면 모를까, 한 번에 수십 개에서 수백 개의 댓글과 제안, 피드백을 받고 나면 어디서부터 시작해야 할지 모르고 해야 할 일을 모으고 정리하는데 시간이 굉장히 많이 듭니다.
— Lead Product Designer @ HR Software Startup
2% Pixelic for Figma
우리는 꽤 오랜 시간 동안 많은 소프트웨어 팀들과 깊은 대화를 나눴다. 우리가 만난 팀 중에는 두 명이 하는 사이드 프로젝트도 있었고, 이제 막 성장하는 스타트업들도 있었고, Google, Facebook, DoorDash 등 수백, 수천 명이 근무하는 대기업도 있었다. 여담이지만, Figma의 제품 팀과도 만나 이야기를 나누기도 했다. 이들과 함께 위에서 설명했던대로 Figma가 때로 채워주지 못하는 2%를 채울 수 있는 방법을 고민했다. 여태껏 100명이 넘는 사람들과 “어떻게 하면 디자인 협업이 좀 더 원활하고 매끄럽게 될 수 있을까?”를 같이 고민해왔다.
이 질문에 대한 정답은 당연히 없다. 시스템은 어디까지나 사람의 역량이 받쳐주어야 효율성을 만들 수 있다. 하지만 우리는 우리와 대화한 대부분의 디자이너가 Design Ops 업무, 즉 디자인 협업에 시간을 생각보다 많이 쏟는다는 사실을 발견했고, 디자이너의 R&R에서 ‘협업’ 부분을 최대한 시스템화한다면 디자이너들이 디자인하는데 몰두할 수 있게 도울 수 있다고 판단했다.
Pixelic은 Figma를 사용하는 디자이너들이 Figma 페이지들과 협업기록, 프레임별 버전, 디자인 태스크 관리 등을 한 곳에서 할 수 있게 해주는 ‘제3의 협업 공간’이다. 여기서 디자이너들은 Figma와 연동해 클릭 한 번으로 Figma 파일내 모든 페이지와 프레임을 불러올 수 있고, 프레임별로 버전을 관리 할 수 있으며, 프레임 위에서 다른 사람들과 협업할 수도 있다.
Figma File Sync
Pixelic 화면.Figma 파일에 있는 모든 페이지와 프레임을 한 번에 불러올 수도 있고, 특정 페이지만을 선택해 불러올 수도 있다. 이렇게 불러온 프레임들은 페이지별로 정리되고, 각 프레임을 누르면 그 프레임 위에 코멘트를 남기거나 슬랙으로 공유해서 피드백을 받을 수도 있다. `Sync` 버튼을 누르면 Figma 에서 작업한 변경사항들이 Pixelic에도 업데이트가 된다.
2-way feedback with Slack
Pixelic을 통하면 각 Figma 프레임에 메시지를 담아서 슬랙으로 바로 공유할 수 있고, 또 슬랙에서 멤버들은 쓰레드(thread)에 코멘트를 달기만 해도 Pixelic에서 모든 코멘트가 기록된다. 대부분의 연동이 일방적인 업데이트에 그쳤다면, Pixelic의 연동은 seamless한 협업을 위해 양방향을 지원한다.
피드백(코멘트)을 태스크로 전환하기
팀 멤버가 디자인에 대해 피드백을 남겨주면, 그 피드백을 바로 액션 아이템인 태스크로 전환할 수 있다. 수많은 피드백을 여러 곳에서 동시에 받더라도 디자인에 대한 context를 잃지 않고 바로 태스크로 전환할 수 있기 때문에 피드백 업무와 디자인 태스크 업무를 구분해서 협업할 수 있다.
프레임별 버전 관리 및 협업과 진행 사항을 기록하기
Figma에서 timestamp 별로 버전 히스토리를 관리할 수 있지만, 프레임별로 버전을 컨트롤할 수는 없다. Pixelic에서는 세밀하게 변경사항을 기록하고 언제든지 버전의 기록을 볼 수 있게 되므로 더 쉽고 빠르게 디자인 업무를 진행할 수 있다.
Next Steps
10년 전의 시대가 코드의 시대였다면 앞으로 다가올 10년은 디자인의 시대라고 생각합니다. 예전에는 코드 중심으로 제품이 만들어졌지만,
앞으로는 디자인 중심으로 제품이 만들어 질 겁니다.
— 피터 레빈, 벤처 캐피털리스트 @ Andreessen Horowitz
이제는 디자인의 차례다. 프로덕트의 성공에 있어 디자인이 매우 중요한 역할을 차지하고 있음에도 늘 엔지니어링 중심으로 프로덕트는 개발되어 왔다. 앞으로의 제품 개발은 엔지니어링 중심이 아닌 디자인 중심, 그러니까 화면을 중심으로 개발이 이루어질 것이다.
Pixelic은 디자인 중심 프로덕트 매니지먼트 툴이 되는 것이 목표다. Figma 디자인 이후의 Design Ops와 더불어 엔지니어링 파트로의 연결까지 제품 개발의 중심이 코드에서 디자인으로 옮겨 오게 하는 것이다.
Christopher Chae 지음
