brunch

You can make anything
by writing

C.S.Lewis

by seezak Feb 10. 2023

디자이너-개발자 협업, seezak팀의 해결과정

디자이너와 개발자의 팀워크

안녕하세요, 디자이너 채용플랫폼 시작(seezak) 팀의 Sunny 입니다.


저는 시작 서비스 기획자이자, 일과시간의 절반 이상을 서비스를 개발하는 데에 쓰는 개발자입니다.


이번 브런치 아티클에서는 제가 서비스를 기획/개발하면서 가장 많이 고민했던(하고있는),

<디자이너-개발자 간 협업> 을 다루고자 합니다.


시작 팀은 개발자 2명과 디자이너 1명, 운영 팀원 1명으로 구성되어있습니다.

소수 인원임에도 불구하고, 디자이너-개발자 간 커뮤니케이션과 피드백 과정에서 어려움이 적지 않았는데요.


그동안 스타트업 협업에 관한 아티클들을 읽으면서,

디자이너와 개발자 두 포지션에 집중한, 보다 생생한 갈등 사례와 구체적인 해결방안들이 공유되면 좋겠다는 바람이 있었습니다.

그래서 저희 팀은 지난 6개월 간(서비스 빌딩 초창기) 직접 겪었던 어려움을 3가지로 정리하고, 해결과정을 정리해보았습니다.



Q1. 디자이너-개발자 피드백 툴: “어떻게” 전달해야할까?


초기 6개월간 시작 팀은 디자이너가 파트타임으로 협업을 하고 있어 소통 과정에서 여러 제약조건이 있었다.

상호 간 피드백이 실시간으로 이루어질 수 없어 서면 피드백에 의존해야했고, 서비스 초기 시시각각 변화하는 기획/개발 내용과 우선순위를 업데이트 하기 어려웠다.


Before: Figma 댓글 기능 활용

초기에는 디자이너가 UI를 구성하면, 개발자가 Figma 댓글 기능을 통해 피드백을 남기는 방식으로 소통했다.

Figma 댓글 기능은 UI 화면을 지칭하며 필요한 곳에 피드백을 직관적으로 전달할 수 있는 장점이 있었지만,

개발자 입장에서는 노션 등 다른 협업 프로그램을 통해 이루어지는 기획/개발 업데이트 프로세스와 분리되는 불편함이 있었고, 댓글이 최신순으로 정렬되어 있어 업무의 우선순위를 정리하기 어려웠다.

디자이너 입장에서는 피드백 한 사안에 대해 개발자가 현재 개발을 진행 중인지, 어떤 이슈를 해결했는지 등을 파악하기 어려웠다.

시작 팀 Figma 댓글 일부


After: Jira 소프트웨어의 활용

우리 팀은 먼저 팀 협업 프로그램을 Jira로 통합시켰다.

Jira의 스프린트, 백로그 등을 활용하여 업무 우선순위를 실시간으로 확인할 수 있도록 하고,

각 이슈에는 Type 지정을 통해 개발/디자인 피드백을 구분했다.

Jira 소프트웨어 백로그(Backlog) 화면


또한 Jira에서는 이슈 진행도를 표시하는 기능을 기본으로 제공하고 있어, 디자이너와 개발자 모두가 서로의 업무 진행도를 한눈에 파악할 수 있다.

Jira 소프트웨어 이슈 진행도 표시 기능



Q2. 디자이너-개발자 피드백 타이밍: “언제” 전달해야할까?


피드백 방식만큼이나 피드백을 전달하는 시점도 중요하는 것을 깨달았다.


Before: 개발 과정 중에 피드백

우리 팀은 개발 인원이 적은 데다, 팀 전원이 MVP 서비스를 운영하면서 플랫폼 개발을 병행했기 때문에 항상 개발 시간이 부족했다.

시간에 쫓기다보니 초기에는 디자인 시안이 나오면 꼼꼼히 보고 분석하기 보다는 ‘일단 개발부터 빨리하고, 나중에 고치자’ 식의 접근을 많이 했다.

이렇게 하면 개발 속도는 조금(하루이틀) 빨라질 수 있어도, 개발 과정에서 디자인 수정 사항이 눈에 들어오면서 뒤늦게 피드백을 하게 되고, 이는 디자이너와 갈등으로 이어질 가능성이 높았다.

사소한 수정이면 다행이지만 최악의 경우 UI가 유기적으로 연결되어있어 디자인을 처음부터 다시 해야하는 상황까지 이어졌다.

의사소통 차원에서도 디자이너 입장에서는 이미 팀적으로 합의된 사안을 개발자가 갑자기  번복하는 것으로 인식할 수도 있다.


After: 개발 시작 전 피드백

개발을 시작하기에 앞서 팀 모두가 디자인 시안을 꼼꼼히 검토하고, 충분히 토론하는 시간을 갖기 시작했다.

모든 피드백을 개발 시작 전에 전달하는 것은 어렵지만, 이는 잠재된 갈등 리스크 최소화하기 위해 필수적이다.

또한 향후 불가피하게 개발 과정에서 디자인 수정 요청이 생기더라도 우리는 디자이너의 의도에 반하지 않은 방향으로 제안할 수 있게 되었고, 개발자가 디자인 수정 범위를 대략적으로 예측할 수 있게 되면서 의사소통이 보다 원활해졌다.



Q3. 개발 속도를 높이는 법: 디자인 먼저? 개발 먼저?


우리 팀은 개발할때 속도를 가장 중시하고, 유저에게 필요한 서비스가 배포되어 전달되는 과정을 효율화 하는 데에 집중한다. 웹페이지 하나를 개발하더라도 디자인 시안이 나오기까지 개발자들이 막연히 기다리는 시간을 줄이고자 했다.


Before: 기획 -> 디자인 -> 개발

이전의 방식은 서비스 기획이 끝나면, 디자인 와이어프레임을 만들고, 디자인을 보고 코드로 옮기는 순서로 일했다.

이전 프로세스

그런데 디자인 단계에서 소요되는 시간이 길어질 경우, 개발 진행도가 0의 상태에 정체되는 문제가 생겼다.

물론 디자인 완성도를 높이면 그만큼 최종 결과물의 퀄리티도 좋아지겠지만, 우리 팀은 완성도 보다 속도를 우선시했다.


After: 기획 -> 개발(와이어프레임) -> 디자인 x 개발

그래서 우리는 기획이 끝나면 개발부터 시작했다. 와이어프레임을 개발해놓고 꼭 필요한 디자인 요소만 더해가는 방식이다.

이렇게 하면 개발자 입장에서는 가장 효율적으로 구현할 수 있는 방법으로 코드를 구성할 수 있게 되고, 디자이너 입장에서도 꼭 필요한 디자인 요소만 더해갈 수 있어 작업시간도 아끼고, 군더더기 없는 디자인을 할 수 있게 된다.

시작 플랫폼 채용공고 상세페이지의 와이프레임

            


시작(seezak) 플랫폼 바로가기


시작(seezak) 오픈채팅방 바로가기


작품 선택

키워드 선택 0 / 3 0

댓글여부

afliean
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari