프론트엔드개발자가 다른 직군과 협업을 잘 하는 것도 역량이 된다는 것을 이전 글 좋은 프론트엔드 개발자란? 에서 말했다.
그와 관련하여 우선 프론트엔드 개발자가 디자이너와 어떻게 협업하는 것이 좋을지에 대해 생각을 해보려고 한다.
1. 디자이너의 디자인 도구
디자이너는 디자인 리소스를 생산하기 위해 특정 디자인 툴을 사용할 것이다. 과거에는 포토샵, 스케치, Xd 등이 많이 쓰인 것 같고, 현재는 피그마나 제플린 등으로 옮겨가는 추세이다.
나는 Xd, 피그마 그리고 제플린을 사용한 경험이 있는데 Xd는 Adobe에 익숙한 디자이너에게 편하고 익숙한 디자이너를 위한 툴이라고 생각한다.
피그마와 제플린은 둘 중 하나를 선택하는 느낌이라기 보다는 피그마를 통해 디자인된 결과물을 제플린으로 변환하여 소스코드를 개발을 위한 기초 코드를 생성하는 느낌으로 이용하는 것이 일반적인 것 같다. 컴포넌트 단위로 코드를 재사용하는 것과 같이 피그마에서도 스타일 재사용에 특화된 기능이 특화 되어있는 것 같아 디자이너와 프론트엔드개발자가 모두 이점을 갖고 소통하기 편한 툴이 아닌가 싶다.
툴의 장단점이 어찌됐는 디자이너와 프론트엔드개발자 그리고 비즈니스 상황에 따라 특정 툴을 정한다는 것이 핵심이다.
2. 규격(Interface)에 대한 협의
디자인의 규격을 만드는 것은 첫째, 스타일 코드를 재사용할 수 있다는 점에서 의미가 있다. 이는 프론트엔드 개발자 뿐 아니라 디자이너에게 역시 유용할 것이다.
재사용성을 고려하는 것은 업무의 효율을 높이고 매 번 새로운 코드를 만들면서 발생할 수 있는 실수를 방지할 수 있다.
둘째, UX적인 관점에서 유리하다. 일관된 사용성은 서비스의 질을 높이는 것에 도움을 준다. 초기에는 규격이 없더라도 일관된 사용성을 지키는 것이 어렵지 않을 수 있지만, 비즈니스의 특성상 날이 갈 수록 서비스가 커지기 때문에 규격 없이는 휴먼 에러가 발생할 수 있으며, 일괄적인 관리가 어렵게 된다.
따라서 디자이너와 프론트엔드 개발자 간의 효율적인 소통과 비즈니스적 이로움을 얻기 위해 규격(Design System)을 확립하는 것은 필요하다.
그렇다면 어떤 것들을 규격화시키면 될까? 정답은 위에서 말한 재사용성과 일관성에 있다. 간격, 크기, 폰트, 색상, 버튼등과 같이 어떤 페이지 등 재사용될 수 있는 전역적인 스타일에 대한 규격을 기초로 하고, 일관성을 갖춰야할 만큼 재사용 횟수가 증가되는 특정 스타일이 생긴다면 추가하면 될 것이다.
3. 이미지 포맷
이미지는 텍스트와 동일하게 정적이지만 단기간에 시각적으로 큰 임팩트를 주어 자주 사용하는 데이터 리소스이다.
어떤 이미지 포맷을 사용할 지 약속을 해두는 것은 디바이스 사이즈 및 OS, 브라우저 등에 따라 실제 화면에서 이미지가 보여지는 것이 다를 수 있는 상황에 대해 대비하는 방안이라고 생각한다. 일관된 사용성과 연관된다고 볼 수도 있겠다.
예를 들어, PC에서는 어떤 이미지 포맷이든 동일하게 보이는 반면, ios의 사파리 브라우저를 이용했을 때는 svg 포맷의 이미지가 흐리게 나타나는 현상이 발생한다면 png를 사용하자는 약속 등을 하는 것이 예이다.
4. Interaction
interaction은 넓은 의미에서 사용자가 특정 이벤트를 시도했을 때 그에 따른 반응을 주는 것을 말한다. 더 나아가 디자인과 관련된 interaction은 사용자가 버튼에 마우스를 올렸을 때 배경색이 바뀌거나 글자가 커지는 등 스타일의 변화를 의미할 것이다.
적절한 interaction의 사용은 사용자에게 상품에 대한 좋은 인상을 주게 하며, 기억에 보다 오래남는 효과를 가져올 것이다.
반대로, interaction이 남용된다면 다소 산만한인상을 주기에 딱 좋다. 중요한 것은 서비스에 대한 내용인데 외관적인 과시에 집중한 나머지 배경이 수시로 변한다던지, 스크롤을 내릴 때 상단 GNB가 사라졌다가 올릴 때 생성되는 효과가 과도하게 느리다던지 하는 것 말이다.
이렇게 산만한 interaction의 발생은 협업 과정에서 interaction이 이중 적용되었기 때문에 발생했을 수 있다. 디자이너가 생각한 interaction과 프론트엔드 개발자가 생각한 그것이 일치하지 않았을 경우, 혹은 A개발자가 처음에 생성한 interaction을 B개발자가 수정하던 과정에서 중복 적용된다던지 하는 경우가 발생할 수 있다.
해당 문제를 방지하기 위해 일반적인 interaction에 대한 약속을 한다면 적어도 중복 적용에 의한 산만함이 발생하지는 않을 것이다.
*디자이너는 디자이너의 관점에서 이유가 있는 디자인 결과물을 만들어낼 것이다. 예를 들어 버튼을 디자인할 때 이용한 색상과 버튼의 배경, 마우스를 올렸을 때 일어나는 interaction등에 대한 나름의 이유 말이다.
**이러한 디자이너의 디자인 근거는 그들의 전문가 지식의 영역이기 때문에 그 이유나 개선에 대해서 의견을 낼 때는 무척이나 조심스러워야 한다고 생각한다.
