디자인이 시스템이 되기까지
디자인만 하면 되지 시스템이 왜 있어야되는데...
디자인 시스템 (Design system)이 뭐지
디자인 시스템이란 디지털 프로덕트상에서 서비스에서 시각적으로 일관성 있는 경험을 제공해주기 위해서 구축하기 위한 디자인 시스템을 말한다.
결과적으로는 서비스에 있어서 통일된 이미지를 제공해줄 수 있다. 따라서 서비스가 기능이 확장되거나 혹은 다른 나라로 진출을 하는 등 확장이 되는 경우, 디자인 시스템의 중요성은 더 높아진다. 디자인 시스템이 시스템으로 잘 구축이 되면 보다 효율적이게 다른 직군과 협업을 할 수 있고 업데이트가 있는 경우에도 빠르게 작업이 가능해진다.
때문에 많은 서비스에서는 디자인 시스템을 구축하는 데 공을 들이고 있고 규모가 큰 회사의 경우에는 이런 디자인 시스템을 관리하기 위한 ‘플랫폼 디자이너’라는 직군이 따로 생길정도로 디자인 시스템은 서비스 디자인에 있어서 중요한 부분을 차지하고 있다. 큰 기업으로 갈 수록 디자인시스템이 잘 활용된다면 효율적으로 일할 수 있는 시간 역시 커지기 때문이다. 토스의 경우, TDS (Toss Design System)을 도입한 이후 6개월간 메이커들이 절약한 시간을 계산해보면 4,500시간이였다고 한다.
여기에서 주의해야 할 점은 디자인 시스템은 단순히 시각적인 차원에서 머무는 UI 디자인 시스템만을 말하지 않는다는 점이다. 프로덕트 디자인에서 디자인은 1차원적인 비주얼 디자인에서부터 설계부분에 있는 서비스 디자인까지 그 의미가 유기적으로 확장된다.
출처: Pxd_디자인 시스템 1편 https://story.pxd.co.kr/1434사실 UI 디자인 시스템은 서비스 디자인이 된 후, 서비스가 어떤 톤앤 매너를 갖고 있고 그런 브랜드 이미지가 시각적으로 어떻게 전달할 수 있을까에 대한 고민이 시스템적으로 반영된 일부의 모습일 뿐이다.
UI적인 디자인 시스템이 구축되기 전 먼저 팀원들과 서비스에서 어떤 목소리로 유저들에게 다가갈 것인지에 대한 부분이 먼저 얼라인이 되어한다.
Jira, Trello 등 여러 협업툴 SaaS를 만드는 Atlassian의 Design system을 보면 이런 디자인 시스템이 종합적으로 잘 보여주고있는 좋은 예시라고 생각이 든다.
Atlassian Design SystemAtlassian Design system에서는 크게 3가지의 디자인 시스템을 가지고 있다.
Brand system
Atlassian 의 BX (Brand experience)를 구축하기 위한 시스템인데 사실 회사에 대한 비전과 어떤 태도를 갖을 것인지에 대해 시스템적으로 설명이 되어있다. ( 마치 특정 나라의 헌법을 보는 느낌이다…)
Foundation System
프로덕트를 제작하기 위한 UI에 대한 우리가 일반적으로 알고 있는 디자인 시스템에 대한 내용이다.
Content System
Atlassin의 UX writting voice tone 에 대한 시스템을 이야기 하는데 서비스의 태도와 직결되다 보니 Brand system과 중복되는 부분이 있다.
서비스에서 있는 UI 이던 콘텐츠들이 '그 서비스다움’을 잃지 않고선 유기적으로 연관되게 하는 것이 중요하고 이를 시스템적으로 Atlassian이 저렇게 구축을 하고 . 가독성있게 저렇게 정리를 해서 공유를 함으로서 서비스를 효율적으로 움직일 수 있게 도와준다고 생각한다.
나의 경험상 앞으로의 글에서는 UI 적인 디자인 시스템을 중점적으로 이야기 해보고자 한다.
디자인 시스템 파헤쳐보기
디자인 시스템이 만들어지는 과정
디자인 시스템은 서비스의 방향과 톤앤매너 등의 피상적인 관념을 팀원 모두가 명확히 소통하고 프러덕션에 활용할 수 있는 수 있는 언어로서 정리하는 과정이다.
그렇게 UI 디자인 시스템으로 정리되는 과정은 다음과 같은 것 같다.
N/N group에 따르자면 위의 용어들의 정의는 이렇다.
Style Guide:
앞 서 말했듯 서비스 브랜드의 성격, 톤앤 매너를 총체적으로 설명하는 가이드이다. 마치 한 사람의 프로필을 설명하듯 디자인 원칙, UI, UX, 콘텐츠 등 서비스를 구성하고 있는 것들에 대해 설명한다.
Component library:
디자인 라이브러리라고도 알려진 이 라이브러리는 보통 사람들이 UI 적으로 생각하는 디자인 시스템이다. 다른 직군들과 효율적으로 UI 에셋들을 활용할 수 있도록 도와주는 역할의 라이브러리이다. 이런 라이브러리를 만드는데는 꽤 많은 시간과 리소스가 쓰인다. 다음과 같은 항목이 해당 라이브러리에 들어갈 것이다.
- 컴퍼넌트 이름 (Component name):
컴퍼넌트 이름을 잘 짓는것은 생각보다 많은 협의가 필요하다.
- 컴퍼넌트에 대한 설명 (Description):
이 UI요소가 정확히 어떤 것이고, 어떻게 쓰이고, 언제 쓰이고 쓰이지 말아야할지에 대한 설명
- 적용방법(Attribute):
해당 UI 에셋이 특별한 컴퍼넌트에 적용되기 위해서 모양, 컬러등이 커스터마이즈가 되어야 하는가?
- 상태 (State) :
해당 UI 에셋은 어떤 조건에서 해당 모습을 띄고 있는지에 대한 설명
- 코드 스니펫 (Code Snippets):
디자인 시스템을 코드로 시스템화 해서 코드를 짜는 시간을 줄일 수 있게 도와준다.
- Front-end & Backend Framework:
불필요한 디버깅없이 해당 UI 요소를 어떻게 심을지에 대한 사항
Patten library:
컴퍼넌트 라이브러리와 많이 혼용되어서 쓰이는 단어이긴 하지만 엄밀히 말하자면 패턴 라이브러리는 각개의 컴퍼넌트요소가 아닌 그 컴퍼넌트들이 모여 만든 큰 레이아웃, 컨테이너 (예를 들면 page header 같은..), 탬플렛등을 다룬다. 컴퍼넌트와 마찬가지로 이런 라이브러리는 재사용되거나 적용되어서 사용된다.
→ 일차원적으로 UI 디자인만 한다고 했을 때에는 컴퍼넌트 라이브러리와 패턴 라이브러리까지 포함하는 것이다.
디자인 시스템의 구성요소
시스템을 구성하기 위해서 어떤 요소들이 있는가, 그리고 그 요소들에서 어떤 패턴을 발견할 수 있는가에 대해서는 사실 오래전부터 인터페이스 디자인 부분에서 연구되고 있었다. 2016년 Brad Forst 가 발제한 “Atomic design” 개념은 UI 툴들의 등장과 함께 실무적으로 본격적이게 적용이 되기 시작한다.
디자인 시스템의 구조는 마치 유기체를 쌓는 것과 비슷하다. 흔히 이를 원자가 분자에서 어떤 물체가 되는 과정( Atomic Design system), 아니면 세포에서 유기체가 되는 과정으로 비유(Cell design system)등등.. 어떻게 보던 본질적으로 작은 1차원적인 베이스 요소부터 시작하여서 특정한 기능을 할 수 있는 구조를 띈 무언가로 발전이 된다고 얘기하는 관점들인데 이를 시스템적으로 효율적으로 관리하기 위한 것이 디자인 시스템의 역할이다.
Atomic Design의 개념과 위에서 말했던 component, pattern library의 개념을 빗대어보자면 이렇게 나뉠 수 있을 것 같다.
Atomic design 표를 정리해봤다. 출처: https://atomicdesign.bradfrost.com/chapter-2/#the-part-and-the-wholeAtom 보다 더 베이스인 요소들
이론적으로 말하자면 원자를 더 쪼갤 순 없을 것이다. Atom design system은 기능에 따라서 인터페이스의 구조를 이해하기 위한 멘탈모형이다. 그렇기 떄문에 Atom 전에 어떤 것이 Atom을 구성하고 보여주게 할 것인지에 대한 설명은 없다. 예를 들면 컴퍼넌트에 쓰일 색, 타이포그래피, 그림자, 그리드 시스템 등이다.
Google material design system에서는 이런 요소들을 Style로 묶어 부르고 있다.
하지만 다른 조직의 디자인 시스템에서는 이런 요소들을 Foundation이라고 부르는 등 사실 용어를 정확히 명명하기는 어려운 것 같다. (Google material design에서는 foundation을 디자인 원칙에 관한 컨텐츠로 풀어서 설명하고 있으니 말이다.)
시스템은 환경을 위한 것
디자인 시스템은 절대적인 원칙이 아니다. 참고는 하되 각 회사에 맞는 조건의 디자인 시스템을 써야하니 말이다. 전사에서 쓰여질 디자인 시스템이 한 번 정해졌다 하더라도 시간이 지남에 따라 비즈니스의 방향과 트렌드에 따라서 꾸준히 업그레이드도 하며 유지보수를 해야한다.
------------
UI 디자인 시스템을 만들 때 나도 처음에는 디자인 시스템을 1차원적으로 시각적으로 보여주고 정리하는 작업에 신경썼던 것 같다. 사실상 디자인을 효율적으로 하기 위한 패턴 라이브러리르 만드는데 치중했던 것이다.
하지만 디자인 작업을 하면서 점점 '기능'에 따라서 혹은 형태에 있어서 패턴들이 생기기 시작했다. 가이드로 일괄적으로 정리를 하면 개발로 핸드오프를 할 때 불필요하게 커뮤니케이션을 할 필요가 없어질 수 있겠구나라는 생각이 들었다.
결정적 계기는 안드로이드 용으로 따로 디자인 작업을 해야하나..하면서 알게 된 '디자인 정책서'는 사실 이런 고민에 대한 답이 되었다. 후에 제작한 디자인 정책서에는 이런 패턴에 대한 내용들을 정리하면서 다음과 같은 내용들을 넣어봤다.
텍스트 입력 양식 (날짜, 시간 등에 있어서 어떻게 표기할 것인지)
컴퍼넌트들의 상태에 따른 값
레이아웃에 대한 특징, 기능에 대한 패턴들
컴퍼넌트별 반복되는 레이아웃 비율, 수치
... 등등 앞으로 계속 디벨롭을 해봐야할 것 같다.
참고한 자료
https://atomicdesign.bradfrost.com/chapter-2/#the-part-and-the-whole
https://www.nngroup.com/articles/design-systems-101/
