디자인 스타일 가이드와 컴포넨트 관리하기
스타일 가이드, 디자인 시스템, 버전 관리, 개발팀에게 전달 프로세스
* 이 글은 저의 개인 프로젝트인 Work Better Project 중 하나의 글입니다.
스타일 가이드와 디자인 시스템은 무엇이 다를까요?
스타일 가이드는 컬러, 타이포그라피 등의 디자인 요소와 버튼, 카드 등의 컴포넌트 디자인의 스타일 가이드 입니다. 주로 규모가 작은 중소기업에서 플랫폼을 개발할 때 사용됩니다. 디자인 시스템 가이드는 더 큰 개념으로 디자인 컴포넌트들이 어떤 구조로 어떻게 작동하는지에 대한 가이드입니다. 즉, 디자인 시스템은 스타일 가이드를 포함해 UX 원칙, 철학, 프레임 워크, 코드 가이드, 디자인 리소스 등으로 이루어져 있습니다.
스타일 가이드: 컬러, 타이포그라피, 버튼 등의 디자인 요소의 스타일 안내
디자인 시스템: 어떤 구조로 어떻게 시스템이 작동하는지 안내
시스템 가이드는 사용자가 경험하는 제품 안에서 구성요소가 어떻게 사용되는지에 대한 지침을 제공합니다. 디자인 스타일 가이드가 완성되면 팀원들은 이를 다양한 조합으로 재사용할 수 있습니다. 이는 UX UI 팀이 제품의 일관성을 유지할 수 있도록 도와주며 전체 제품 팀과 회사 차원에서도 디자인 가이드를 회사의 자산으로 활용 할 수 있게 해줍니다.
스타일 가이드 버전 관리와 전달
일반적으로 디자인팀은 디자인 스타일 가이드을 관리하고 팀이나 제품의 규모에 따라 디자인 팀이나 프런트 엔드 개발팀이 디자인 시스템을 관리합니다. 기업이나 제품의 규모에 따라 시스템을 유지 관리하고 업데이트하는 데 전념하는 시스템 디자이너가 있을 수도 있습니다. 스타일 가이드와 시스템을 구축함에 있어서 이들은 결코 ‘완성’ 되지 않는다는 것을 유의해야 합니다. 시간이 지남에 따라, 제품이 업그레이드 됨에 따라 스타일과 시스템 가이드 또한 지속적으로 추가, 수정을 반복하며 업데이트 되어야 합니다. 다시말해, 디자인 시스템을 만드는것은 지속 가능한 디자인 시스템 생태계를 구축하는것과 같습니다.
디자인 시스템은 전체 플랫폼을 결합하는 결합 조직 역할을 한다. - Drew Bridewell, Invision
모든 시스템에 대한 가장 큰 위협은 방관이다. - Alex Schleifer. Airbnb
1. 디자인 시스템 버전 관리
최초의 스타일 가이드와 함께 출시 된 제품의 버전은 1 이라고 할 수 있습니다. 일반적으로 앱이나 플랫폼은 시맨틱 버전 시스템을 따릅니다. 시맨틱 버전 넘버는 제품에 어떤 기능이 추가 되거나 버그를 해결하기 위해 업데이트 됨에 따라 버전 넘버가 바꾸는 방식이고 v 1.1.1 과 같은 형식을 갖추고 있습니다. 그렇다면, 디자인 스타일 가이드는 어떻게 버전을 관리해야 개발자와 디자이너가 효율적으로 협업 할 수 있을까요? 아래는 제가 사용하는 피그마 스타일 가이드의 버전 넘버입니다. 이 넘버 시스템이 일반적으로 통용되는 디자인 버저닝 시스템과 같은지는 확신이 없습니다. 경험이 있으신 분은 지식을 공유해주세요 �
E.g. Style Guide [ v 1.1.1 ]
2. 무엇을 버전 관리 해야 할까?
버전 넘버는 전체 스타일가이드에 사용 할 수도 있고 개별 컴포넌트에 사용 할 수도 있습니다. 예를 들어, ‘개발자님, 브랜딩 리뉴얼에 따른 스타일 가이드 v 2.1 이 프러덕션 사이트에 전체적으로 배포된것을 확인 했습니다. 특정한 이유로 인해 Secondary 버튼은 아직 v 1.3으로 유지해 주시기 바랍니다. ’ 이렇게 명확하게 버전을 지칭하여 소통한다면 오해를 줄일 수 있습니다.
3. 피그마 버전 관리 팁
a. 버전 히스토리
피그마 버전 히스토리에서 코멘트와 함께 퍼블리시하면 쉽게 수정 이전 버전으로 복구가 가능합니다. 또한 개발자에게 버전 업데이트를 알릴 수 있습니다.
b. 에셋을 활용한 업데이트 표시
가끔 특정 에셋을 더이상 사용 하지 않지만 스타일 가이드 다큐멘드에서 삭제 할 수 없는 경우가 있습니다. 이 경우, 해당 컴포넌트를 블러 처리하여 에셋 패널에서 더이상 사용 할 수 없음을 한눈에 보기 쉽게 표시 할 수 있습니다.
c. 개발팀에게 새 컴포넌트 추가 혹은 버전 업데이트 전달
개발팀의 작업을 요구하는 업데이트의 경우 아사나에서 티켓을 발행합니다. 아사나의 티켓은 작업의 진도를 확인하기도 편하고 나의 컴포넌트 관련 디자인 업무도 관리하기도 편합니다.
과거 워터폴 방식에서는 기획팀이 기획을 하면 디자이너는 그에 따라 디자인을하고 개발에서는 디자인을 토대로 개발을 하는 정도로 업무 방식이 단순했습니다. 하지만 작업 방식이 애자일로 변화했고 아이디어를 구체화 하는 상위 단계에서부터 디자이너와 개발자가 의견을 제시하고 함께 의사 결정을 해야 합니다. 소프트웨어를 만드는 과정은 협업과 커뮤니케이션이 반이라 할 정도로 중요합니다. 그래서 스타일 가이드 버전 관리와 이를 개발팀에게 전달 하는 방법은 소통을 위한 '방법'이고 '노력'라고 생각합니다. 애자일과 같은 방법론 또한 수많은 사람들이 함께 정립하고 테스트하고 고쳐나간 노력의 결과입니다. 크던 작던 그 팀안에서 효율적인 업무 프로세스를 찾아내는것 역시 우리가 시간과 공을 들여 해야 할 필수적인 업무 중 하나라는것은 다시 한번 느낍니다.
참고 자료
Frost, B. 2016. Atomic Design. Brad Frost Web
