더 가까워집시다 우리
저는 지난 타 사이드 프로젝트에서 디자이너는 디자이너 개발자는 개발자 그 사이에 벽이 있는 것 같은 느낌을 받았었어요. 모두 열심히 임했지만 마치 각자의 영역에서 더는 궁금해하지 않은 채 각자 역할에만 최선을 다하는 느낌 🥲
하지만 이건 디자이너 입장에서 결과적으로 많은 아쉬움을 남겼어요. 플러그인 사용으로 인한 디자인 임의 수정이나, 미세하게 달라진 디자인 시안의 수치 (ex. 요소들 간의 간격, 페이지 별 같은 버튼이지만 다른 수치)들로 디자이너는 매번 수정사항을 체크해서 전달하고, 프론트에서는 디자인 작업에 오래 시간을 쓰게 되고 서로를 지치게 만들었던 것 같아요. (미세한 수치일지라도 달라진다면, 시각적으로 기능적으로 의도했던 바가 달라지기도 하거든요.ㅠ)
근본적인 원인을 찾고 싶었고, 결론적으로 이 문제점이 제가 의도했던 바를 제대로 전달하지 못했기 때문이라고 생각했어요. 그래서 이번엔 더 적극적인 소통을 위해 노력하고, 명확하고 규칙적인 지표를 전달드려야겠다! 다짐했죠. ✊🏻
각자의 벽을 부셔보자!
이번 Vi.NO 프로젝트는 pm과 디자이너 개발자 이 세 직군이 실제 협업 과정에서 효율적으로 소통하는 부분을 경험할 수 있는 기회였어요.
이번 글을 통해 지난번의 아쉬움을 보완했던 지극히 주관적인! 제 방법을 소개하려 합니다:)
우선, 1) 디자인 단계에서 체계적인 틀을 만들어 제공하고, 2) 각 역할 간의 소통을 용이하게 하여 프로젝트에 참여해야겠다는 것을 목표의 큰 틀로 잡았어요.
이번 프로젝트의 목표는 다음과 같습니다!
- 체계화된 디자인 시스템 전달
- 개발자와의 소통 방식 파악
- 빠른 피드백 수용
- 변수 상황에 대한 빠른 대처 및 제작
⚙️ 명확한 가이드 전달하기 : 컴포넌트 제작
이번 프로젝트에서는 디자인 시스템에 대한 가이드를 체계적으로 설정해두고 싶었어요.
📍 효율성 측면에서
우선 컴포넌트 제작이 실제 프로젝트의 능률을 높일 수 있는지 확인해 보고 싶었어요. 추후 서비스 디벨롭 가능성이 열려있을 경우를 대비해 개발 후에도 새로운 화면이 추가되면 효율적으로 제작이 가능하기 때문이에요.
📍 개발 측면에서
개발자분들도 미리 컴포넌트 제작을 통해 페이지마다의 중복되는 코드를 최소화할 수 있고, 각 요소들이 규칙 된 상태를 제공하기 때문에 실제 적용할 때도 혼란을 줄일 수 있을 것이라고 생각했어요.
📍 디자인 측면에서
시각적으로는 통일된 디자인 베리에이션으로 안정감을 제공하고, 사용자들에게도 일관된 서비스를 경험을 제공할 수 있어요.
결정적으로 명확한 가이드 제공은 곧 효율적인 소통으로 이어지니까 공을 들일 이유가 충분하다고 생각했습니다!
진행 과정
우선 컴포넌트들을 제작하고 정리하는 과정에서 명칭 표시의 어려움을 느꼈는데요. 제작할 때마다 제각각의 이름을 붙여주는 건 오히려 스스로에게나 개발자분들에게나 혼란을 줄 수 있다고 생각했어요. 따라서 분류 체계가 명확해 보일 수 있도록 ‘/’를 사용해서 각 변주되는 요소들의 차이가 잘 나타나도록 작성하고자 했습니다. (ex. 상위 / 하위)
크게 컴포넌트 별로 사용 목적 혹은 분류 기준에 따라 Type(타입)을 규정했고, 버튼과 같이 시각적인 부분에서 변형이 되는 경우 Style(스타일)로 유형을 구분해두었습니다. 각 타입별로 액션이 있는 경우에는 States(상태)를 제공했어요.
또한 필요에 따라, 구체적인 설명이 필요한 경우
- Placement(배치) : 고정된 위치가 있는 요소들 간의 간격 혹은 위치 값 제공 (ex. 카드 리스트 간의 간격은 세로 20px 가로 40px을 유지합니다.)
- Behavior(행동) : 고정된 특정 행위를 통해 진행되는 경우 또는 애니메이션 값 제공 (ex. [최근 읽은 영상]은 항상 폴더 상단에 고정되어 순서를 수정할 수 없습니다.)
- Element(내부 요소) : 구성요소의 제한 값 안내 또는 요소 별 글자 수 전달 또는 글자 수 초과 시 처리 방식 안내 등 (ex. 해시태그는 최대 2개까지 노출됩니다.)
이와 같은 추가 설명으로 최대한 세세한 정보도 작성해두고자 했어요.
개발자분들은 주로 디자인 시안을 최종으로 확인하고 작업을 진행하기 때문에 PM 님이 전달해 주신 화면 정책집의 내용을 최종적으로 확인할 수 있는 창구라고 생각하며 꼼꼼하게 작업을 진행했어요.
📂 진행 된 내용은 피그마를 통해 확인해주세요! : VI.NO 피그마
가이드 레퍼런스로는 주로 라인 디자인 시스템의 전달 방식을 참고하며 공부했습니다.
저는 라인 가이드가 분류측면이나, 설명방식에서 정말 친절하다고 느껴서요. 이미 유명하지만 링크 함께 첨부해둘게요! [라인 디자인 시스템]
그리고 피그마의 컴포넌트 지정 기능을 통해 제작된 원본은 다른 페이지에 두어 그곳에서 수정사항이 생기면 해당 공간에서 전체적으로 컨트롤이 가능하도록 했어요.
개발자분들이 보는 디자인 가이드에서는 복사본을 사용하여 컴포넌트들을 재정리하였는데, 이는 컴포넌트 기능에서 베리에이션 준 것과는 다르게 유형을 구분해서 전달하고 싶기 때문이었습니다.
효과
결론적으로 모든 상태가 반영되어 있는 페이지를 제작하지 않더라도, 각 요소들의 상태 변화를 파악할 수 있어 불필요한 시안의 페이지 수를 줄일 수 있었어요. 또한 개발 진행 중에 새로운 화면이나 컴포넌트가 필요해질 경우 빠른 제작과 추가가 가능했어요.
- 시각적인 정리를 통한 이해도 증가
- 효율적인 페이지 제작
- 추후 컴포넌트 추가에 용이
- 추가 페이지 제작 시 빠른 대처 가능
이전 프로젝트에서 컴포넌트는 그저 디자이너가 자신의 디자인을 통일성 있게 하고 기록하기 위한 요소로만 느껴져 아쉬움이 있었는데, 이번 경험은 개발자분들이 실제 활용하는 과정을 통해 컴포넌트 제작을 직접 체화하고 중요성을 느끼게 된 소중한 시간이었습니다!
+) 최대한 구체적으로 컴포넌트 가이드를 제작해 보고 싶은 욕심이 있었지만 시간상의 이유로
- Anatomy (컴포넌트 내부 요소) : 컴포넌트 별 컴포넌트를 구성하는 기본적인 UI 요소 설명
- Spec (제작 가이드) : 제작 시 권장 수치 제공
- 실제 모션이 적용되는 애니메이션을 시각적으로 전달
등 과 같은 부분까지는 제작해 보지 못했는데요. 추후 해당 부분까지 보완된 구체화된 시스템을 구축해 보고 싶다는 목표가 생겼습니다.
📢 개발자와 소통하기 : Figma
저희는 PM과 디자이너 개발자의 소통 창구로 노션, 슬랙, 디스코드를 이용하기도 했는데요, 아무래도 실질적으로 디자이너와 개발자로 소통했던 주 채널은 Figma였습니다.
왜 Figma?
Figma는 최종 디자인을 확인하는 공간이자 동시에 PM과 디자이너 그리고 개발자가 연결될 수 있는 공간이기도 했어요. 실시간으로 다수가 접근할 수 있고, 원하는 화면을 보며 상호작용할 수 있으며 변경 현황을 가장 빠르게 확인할 수 있는 곳이기도 했죠. 최종적으로 확인하는 공간이다 보니, 피드백이 들어올 때마다 빠르게 수정하고 그 사실을 전달하는 과정이 중요하다고 느꼈어요.
진행 과정
Figma에서의 소통은 코멘트 기능을 적극 사용했는데요. 개발자분들이 구현 과정에서 디자이너가 놓친 부분이 보이거나, 의문이 생길 경우 해당 시안 부분에 코멘트를 남겨두었습니다. 그럼 PM과 디자이너가 하단의 답글을 남길 수 있어요. 이는 공동 편집이 가능하기 때문이죠.
해당 방식을 사용하면서 느꼈던 장점은
- 원하는 페이지 부분에 유동적으로 코멘트를 남길 수 있어 피드백이 필요한 부분을 직관적으로 확인 가능
- 해당 코멘트는 모두 열람 가능하기 때문에 바로 확인 후 해당 답변을 공유할 수도 있어 그 공간에서 원격 논의 가능
- 상대의 답변도 확인할 수 있어 잘못된 답변을 바로잡기 가능
- 읽음을 체크해도 추후 히스토리에 남아 어떤 과정을 논의 했는지 기록 가능
하지만 단점도 있었는데요,
- 너무 많은 코멘트가 쌓이면 오히려 디자인 시안을 확인하는데 방해가 되기도 했고
- 알람 기능이 있지 않기 때문에, 수시로 피그마에 들어가지 않으면 신규 코멘트에 대한 확인이 늦어지는 경우도 빈번했습니다. 같은 맥락으로 코멘트 답변 확인도 늦어졌어요.
(ex. 4일이 지나서야 코멘트 확인하게 되는..) - 또한, 디자인 수정을 진행해도 수정 여부가 한 번에 파악되지 않아 불편했어요.
따라서, 급한 시안일 경우 따로 카톡을 통해 개인적으로 문의하게 되는 일이 빈번했습니다. PM과 상의해야 하는 경우 또 한 번의 확인 카톡이 오갔기 때문에 시간이 지연되는 불편함이 있었어요.
해결 방법
이를 개선하기 위해서, 해결된 코멘트들은 지우기 시작했습니다. 나름의 기준을 정했는데요. 최종적으로 수정 반영이 완료된 코멘트들을 우선적으로 지웠습니다. 한 번 지운 코멘트는 히스토리를 통해 확인할 수 있지만 그 과정이 꽤 번거롭거든요. 그래서 더 신중했습니다! 하지만 남아있는 코멘트들 사이에서 시안을 수정하거나 답글을 달았을 때 변경 여부를 확인하기 어렵기 때문에 따로 근처에 빨간 선으로 표시를 해둔다거나, 멘트를 써 두어 정확하게 확인할 수 있도록 노력했어요.
하지만, 장기적으로는 소통 창구의 개편이 필요함을 느꼈어요. 피그마를 활용하되 상단에서 진행상황을 체크할 수 있는 요소를 제작하고자 하는데, 프로젝트가 지속된다면 적용시켜보고자 합니다! (To be continued..?)
개발자 분들과 소통을 위해
제가 중요하게 생각했던 부분은 다음과 같아요.
✅ 진행 상황을 수시로 확인하고 있기
우선 전체적인 페이지 제작으로 디자인 파트가 끝나도 진행 상황을 숙지하고 있는 것은 중요하다고 생각해요. 언제 어떤 오류로 프로세스가 바뀔지 모르고, 구현 중 놓친 부분들이 보이면 개발 중에도 계속해서 수정이 진행되게 되거든요. 따라서 저는 늘 귀를 열어두었습니다. 빠른 디자인 수정을 통해 스케줄링에 차질이 가지 않도록 노션과 회의록을 상시 체크하며 진행 상황을 확인하는 습관을 들였어요.
✅ 혼자 결정하지 않기
디자이너에게 디자인에 대한 권한은 많지만, 새로운 기능을 더하거나 협업하는 과정에서 단독적으로 결정할 수는 없기에, 디자인 수정 시 사소한 수정을 제외하고는 항상 PM님과 개발자분들과 의논하는 과정을 거쳤습니다.
모든 시안에 대해서는 왜 이렇게 제작하고 싶은지 그 이유를 명확히 전달하고자 했습니다. 납득이 가야 구현의 이유도 생기니까요. 그리고 PM님과 함께 ‘혹시…가능할까요?’를 가장 많이 물어본 것 같아요(ㅎ) 그리고 마지막에 서로 해결할 수 있는 선에서 아이디어를 모아 새로운 방안을 내는 과정이 즐겁기도 했습니다. 서로의 입장에서 생각해 볼 수도 있고요!
✅ 수정 된 부분은 빠르게 확인할 수 있도록 돕기
수정을 요청받고 디자인 수정본을 전달하는 과정에서, 해당 부분을 빠르게 찾을 수 있도록 피그마에 표시해 두었어요. 새로 수정 한 부분 근처에 빨간 테두리로 표시를 해두고, 멘트를 써 두어 정확하게 확인할 수 있도록요.
또, 카톡에서 어디가 수정되었는지 한 번 더 피그마 화면을 캡처해서 전달함으로써 소통의 오류를 최소화하기 위해 노력했어요. 사소한 변화나 미세한 차이의 경우 타인이 보면 빠르게 찾기 어려울 수 있으니까요.
✅ 이미지 혹은 GIF파일 전달 시 용량 확인하기
비노의 로딩 페이지에 들어가는 로고 GIF 파일을 전달드리는 상황에서 최대한 고화질로 전달하고 싶은 생각에 앞서 냅다 21.8MB파일을 드린 적이 있어요. 기본 중에 기본이지만 이 사실을 간과했다는 게 좀 부끄러웠습니다. 파일이 너무 크면 서버의 속도를 느리게 만들기 때문에, 파일 크기를 체크하고 전달하는 과정은 꼭 필요하다는 것!
+) 추가적으로, 현재는 디자인 화면 페이지와 워딩으로만 개발자에게 서비스의 프로세스를 전달하는 형식으로 진행했어요. 하지만 이해의 한계가 있다고 판단하여 다음에는 프로토타입 제작을 통해 서비스 흐름에 대한 이해도 높일 수 있도록 하고 싶다는 생각을 했습니다!
뒤돌아보니 아직 부족했던 점이 많고 개선하고 싶은 부분이 많네요! 하지만 고민이 많았던 만큼 배우는 것도 많고 또 다른 목표가 생기는 시간이였습니다 🌞
함께 좋은 서비스를 만들기 위해 으쌰으쌰 마인드로 팀을 잘 이끌어주신 PM님 그리고 구현하면서 미처 놓쳤던 부분들을 찾아내주시고 함께 고민해 주신 프론트, 백엔드 개발자분들께 너무 감사하다고 말씀드리고 싶어요 :) 최고의 팀원들이 분명합니다 !!
