디자이너와의 협업 방식 - insight

Doodream·2023년 2월 5일

"디자이너: Figma에 디자인 올려놨어요"
"프론트엔드: 넵 보고 작업할게요"

퍼블리싱 후

"프론트엔드: 퍼블리싱 끝났어요. 확인해주세요."
"디자이너: 여기 저기 굵기 0.1rem 이 아니라 0.2rem이에요, 수정해주세요."
"프론트엔드: 넵"

QA 후

"디자이너: font 굵기 차이나네 다시 올려야겠다. 온전하게 반영하기 힘들구나"
"프론트엔드: 하, 여기 놓쳤네, 꼼꼼히 본다고 보는데 비슷한 컴포넌트를 보면 font 굵기가 이랬었는데, 차이나는 구나 또 수정해야겠다."

디자이너와 협업 생산성

위 대화내용을 가만히 읽다보면 어쩔 수 없다고 생각할지도 모릅니다. 협업과정에서 언제나 충분히 일어나는 일이니까 말입니다. 위 문제에서 어떤 문제에 대해서 이야기 하고 있을까?

문제

프론트엔드 개발자는 꼼꼼하게 디자인을 반영하지 못했습니다.
프론트엔드 개발자는 비슷한 컴포넌트가 있는지 확인했지만 꼼꼼히 확인하지 않고 해당 컴포넌트를 그냥 가져다 써서 font 차이가 있는지 확인하지 못했습니다.
디자이너는 비슷한 컴포넌트에 대해서 컴포넌트화를 시켜놓지 않아 개발자가 비슷한 컴포넌트를 찾아 사용하게 됨으로서 잘못 사용하게 되었습니다.

무엇보다 위의 문제로서 생산속도가 느려지며 사소한 실수들은 일정에 의해 우선순위가 낮아지면서 완성도 높지 않은 결과물들이 배포됩니다. 이러한 배포가 쌓이다 보면 그대로 완성도 낮은 서비스가 되겠죠. 즉, 생산성과 서비스의 질이 둘다 낮아지는 안좋은 결과가 나타납니다.

그럼 더 나은 방식이 있나?

디자인 시스템 - 디자인 토큰

디자이너는 먼저 비슷한 컴포넌트에 대해서 따로 컴포넌트화 시켜놓았어야 합니다. 해당 컴포넌트는 여러군데서 쓰이기에 유연하게 사용될 수 있도록 설계가 되어있어야 겠죠. (디자인 시스템) 이러한 컴포넌트들은 개발자가 미리 코드화 시켜놓아 퍼블리싱 단계부터 가져다 쓰기 좋은 상황이 됩니다. (디자인 시스템을 따라 만들어진 컴포넌트들)

컴포넌트를 퍼블리싱하면서 프론트엔드 개발자는 정해진 디자인 규격으로 디자인 해야합니다. 완벽하게 디자이너가 설계한 그대로 컴포넌트를 작성해야 정확한 디자인이 반영될 수 있겠죠. 이러한 설계속에 정해진 속성 규칙에 대한 네이밍은 프론트엔드 개발자와 디자이너와의 일정한 네이밍 규칙에 따라 만들어져야 합니다. 그래야 서로 헷갈리지 않고 커뮤니케이션 비용을 줄 일 수 있습니다. 같은 속성에 대해 서로 다른 네이밍으로 소통한다면 당연히 커뮤니케이션 비용이 커지며 작업중 실수 할 확률이 높아지겠죠.

이는 디자인 시스템의 디자인 토큰 을 통해 생산성을 향상 시킬 수 있습니다. 디자인 토큰화가 잘 되어있으면 프론트엔드는 더이상 퍼블리싱에 대해서 어떤 속성을 어떻게 사용해야하는지 고민을 크게 덜 수 있겠죠.

디자인 속성에 대한 규격화를 통해 정확한 디자인 반영이 가능해집니다.
컬러, 폰트, radius같은 기본적인 속성 규칙을 디자이너가 네이밍 변경을 통해 테마 관리를 할수 있습니다
다양한 플렛폼 ( 안드로이드, ios, 웹 혹은 다양한 스타일링 라이브러리 )에서 통일된 디자인 규칙을 적용할 수 있습니다. 토큰.json 파일을 통한 통일된 규칙을 적용하게 됩니다.

uipkg - tailwindcss 퍼블리싱 자동화

프론트엔드 개발자는 또한 실제 퍼블리싱을 하면서 디자인 내용을 정확하게 반영해야합니다. 대부분 이부분에서 실수가 많이 일어나는데 이코드를 짜는 것 자체가 시간이 걸리는 일 입니다. 즉, 사람이 하는 일이 만큼 정확한 반영을 보장할 수 없습니다.

하지만 코드를 따면 자동으로 정확하게 퍼블리싱 해주는 도구가 있다면 ?
이러한 도구로 미리 아토믹하게 디자인되어 컴포넌트화된 것들로 만들어져있다면 퍼블리싱된 결과물도 간결하고 정확하게 반영되어 작업됩니다. 자동화된 퍼블리싱 코드를 크게 수정하지 않아도 될 일이죠. 더구나 디자이너가 컴포넌트화한 네이밍 그대로 가져오므로 컴포넌트의 네이밍 걱정을 덜게 됩니다.

storybook - 디자이너의 디자인 QA

디자인 QA를 하며 개발자가 개발서버에 올린 내용을 디자이너가 점검하며 다르게 개발된 모습이 있는지, 실제 동작하면서 문제가 되는 부분이 없는지 점검하게 됩니다.
이부분에서 애초에 작은 아토믹 컴포넌트들이 잘 설계되었는지 보장되어있지 않다면 사소하게 작은 부분들에서 실수가 나게됩니다. 더구나 이러한 설계가 없다면 어떤 컴포넌트가 있는지 각 작업자가 서로 모르기 때문에 검증된 ui 컴포넌트들의 모음을 볼 수 있어야합니다. 즉, ui 컴포넌트 설계부터 디자이너가 검증할 수 있는 docs가 있다면 해당 컴포넌트를 작업한 작업물 까지 확인할 필요가 없겠죠.

실제 컴포넌트가 원하는 디자인대로 동작하는지 확인하는 작업인 storybook이 필요합니다.