디자인 시스템의 육하원칙-
3. 무엇을? 어떻게? -2
디자인 시스템의 기능적 패턴과 맥락적 패턴
시리즈 소개
이 글은 디지털 디자인 브랜드 'Data Driven Design'의 기획 콘텐츠, '디자인 시스템의 육하원칙', 세 번째 에피소드입니다. 디자인 시스템 도입에 장벽을 느끼는 실무자들에게 도움을 주고자 기획하였으며 총 4개의 에피소드로 구성되었습니다.
3. 무엇을, 어떻게? - part2
4. 그래서?
목차
0. 무엇을, 어떻게? - part2: 프롤로그
1. 디자인 시스템 성장 시나리오
2. 기능적 패턴을 이루는 두 가지 타입의 데이터
3. 맥락적 패턴과 사용자 경험의 접점
4. 정리하며
0. 무엇을, 어떻게? - part2: 프롤로그
이전 에피소드에서는 제품과 사업 환경에 맞는 디자인 시스템의 특징을 정의하고 이에 맞는 디자인 토큰을 어떻게 설계하면 좋을지에 대한 내용을 다루었습니다. 즉 디자인 시스템의 정체성과 디자인 토큰 구조의 관계를 깊게 들여다보았습니다.
이번 에피소드에서는 디자인 토큰을 실질적으로 적용하는 방식을 시작으로 팀의 환경에 따라 디자인 시스템을 어떻게 확장해 나가면 좋을지에 대해 다뤄봅니다. 특히 프로덕트 팀의 상황에 맞추어 선택할 수 있는 디자인 시스템의 성장 시나리오와 시스템의 중심이 돼 세 가지 패턴 중 기능적 패턴, 맥락적 패턴을 구성하는 방식을 얘기해 보겠습니다.
다시 한번 강조하지만 디자인 시스템은 궁극적으로 실무자들이 좀 더 편하게 일하고 긴밀하게 협업하기 위한 목적에 중점을 맞춰야지 언제까지 고도화된 시스템을 완성시키겠다거나 태도로 접근하면 주객이 전도될 수 있다는 점을 염두하시고 이번 에피소드를 읽어보시면 좋겠습니다.
1. 디자인 시스템 성장 시나리오
우리 프로덕트를 구성하는 디자인 시스템을 어떻게 발전시킬 것인가 라는 질문은 조금 애매하게 느껴지지만 지속가능성을 위해 진지하게 답변을 해볼 가치가 있습니다. 팀과 그 제품이 처한 상황 중 어떤 속성들이 디자인 시스템이 확장되는 과정에 영향을 미칠지 생각해봐야 합니다. 저는 각 팀의 적합한 디자인 시스템 성장 시나리오에는 제품의 성숙도, 리소스, 확장 가능성 이 네 가지 요소가 영향을 미친다고 생각합니다.
1-1 제품. 서비스의 성숙도
가장 첫 번째로 제품의 성숙도가 디자인 시스템의 성장 시나리오에 영향을 미칠 수밖에 없습니다. 신규 제품과 이미 운영 중인 서비스에 디자인 시스템을 도입하는 시나리오가 다르기 때문입니다. 신규 제품일 경우에는 당장 필요한 부분을 개발하는 과정에서 자연스럽게 디자인 시스템을 구축하는 것이 중요합니다. 특히 스타트업의 경우 모든 단계를 완성하고 넘어가는 것이 빠른 대응에 방해가 리스크가 있습니다.
반대로 이미 성숙기에 있는 서비스에 디자인 시스템을 체계화시키는 것은 리팩토링과정에 가깝습니다. 하지만 이 와중에도 서비스를 운영하고 있기에 업데이트와 리팩토링의 작업은 서로 이원화해서 관리할 필요가 있습니다. (이에 대한 얘기는 이전 에피소드 무엇을? 어떻게? - 02에서도 다룬 적이 있습니다.)
둘 중 어떤 상황이건 카테고리의 초안의 초안이라도 완성하고 다음 단계로 넘어가는 방식을 권장합니다. 예를 들어 신규 서비스인 경우 당장 필요한 사용자 경험에서 요구하는 컴포넌트들만 먼저 완성하고 화면을 디자인하는 것은 문제가 되지 않습니다. 하지만 컴포넌트들에 배포될 디자인 토큰의 카테고리(빈칸이 있을지언정)의 초안이라도 작성하는 것이 미래의 리팩토링 소요를 줄여줄 것이며 이때 앞선 에피소드에서 계속 강조했던 디자인 시스템의 특성과 디자인 토큰과의 관계를 생각해보셔야 합니다. 만약 이러한 과정이 부담스럽게 느껴진다면 기존의 UI library를 그대로 활용하는 옵션도 있습니다.
1-2 리소스: 제로 베이스 vs 기존 UI library 확장
우리 제품에 충분히 어울리는 디자인 시스템이 이미 오픈소스로 존재한다면 그대로 사용하는 것이 가장 이상적일 것입니다. 반대로 제품의 개성이 뚜렷하거나 커스터마이징의 자유도가 중요한 경우라면 처음부터 구축하는 것이 좋을 수도 있습니다.
가령 대시보드, 커머스 쇼핑몰, 커뮤니티 서비스 등 어느 정도 정형화되고 대부분의 컴포넌트들이 골고루 사용된 서비스인 경우는 기존 library를 그대로 사용하는 것의 장점이 클 것이며 반대로 비주얼 임팩트가 중요한 브랜드 플래그쉽 성격의 웹사이트나 인터랙티브 한 요소가 많이 요구되는 경우는 오히려 제품에 최적화된 디자인 시스템을 처음부터 구축하는 것의 장점이 클 수 있습니다. 물론 두 가지를 혼용하는 방식도 고려해 볼 수 있습니다.
하지만 기존 UI library를 사용했을 경우에는 시간이 지날수록 원하지 않은 종속성이 발생가능하다는 점을 염두해야 합니다. 앞선 에피소드에서 google의 MUI는 타 디자인 시스템에 비해서 규칙성이 엄격하고 커스터마이징의 자유도가 낮다는 점을 언급했습니다. 그리고 해당 library가 허용하는 룰 안에서 필요한 협업 프로세스의 학습 비용 또한 무시할 수없습니다.
어떤 라이브러리가 적합할지 판단하기 위해서는 해당 library의 공식 사이트의 document에서 디자인 토큰의 수정과 배포 방식, 각 컴포넌트들의 spec과 작동 방식 등을 살펴볼 필요가 있습니다. 참고로 Data Driven Design의 Datum Design System은 mantine UI라는 라이브러리를 사용했습니다. mantine UI는 디자인 키트를 따로 제공하진 않지만 design token과 inherit component의 customize의 자유도가 높은 편이며 미리 준비된 UI의 패턴들을 바로 코드로 활용할 수 있다는 장점이 있어 선택했습니다.
1-3 확장 가능성
디자인 시스템 성장 시나리오에 영향을 미치는 두 번째 요인은 확장 가능성의 영역을 어떻게 설정하느냐입니다. 이 말을 좀 더 기계적으로 표현하자면 결국 시스템의 확장이라는 것은 구성 요소의 카테고리가 마치 나무의 뿌리처럼 자라나는 것과 비슷한데 이 흐름을 어떻게 진행시킬 것이냐라는 문제입니다.
앞선 에피소드에서 google의 mui와 ibm의 carbon design system의 디자인 토큰 구조가 다른 이유를 각 시스템의 특성과 연관 지어 설명한 바가 있습니다. mui의 경우 design token 단계부터 modular 한 특성을 갖고 있습니다. 이 말은 구성요소들이 시스템 전체에 균등하게 반복돼서 사용되는 것을 지향한다는 얘기며 기본 컴포넌트들의 조합이 다양한 콘텍스트에서 활용하는 확장성을 혁신의 공간으로 마련하겠다는 의도입니다.
반대로 Carbon design system은 좀 더 실험적이고 빠른 확장을 위해서 design token부터 specific 한 기능들이 명시되어 있으며 이에 따라 컴포넌트들도 mui에 비해서 integrated 한 양상을 보입니다. 즉 구성요소들의 반복 사용도 중요하지만 빠른 제품의 테스팅을 위해 구체적인 맥락에 최적화된 컴포넌트들을 자유롭게 프로토타이핑 하는 과정을 통해 제품의 혁신을 불
위의 특징들을 우리가 이미 잘 알고 있는 에어비엔비와 비교해 보면 좀 더 이해가 쉬울 것 같습니다. 에어비엔비는 전 세계 사용자들이 사용하고 있는 부킹 서비스로 예약 및 결제 과정에서 사용성 문제를 최소화하며 각 문화권의 로컬라이징 이슈로 엄격한 룰을 기반으로 디자인 시스템을 운영하고 있습니다. 그리고 누구나 쉽게 사용 가능해야 하기 때문에 mui와 비슷하게 Modularity에 큰 가치를 두며 시스템 수정의 권한을 갖고 있는 사람이 피드백을 수렴하고 최종 결정을 통해 업데이트를 하는 중앙 집권적인 조직 체계를 갖고 있습니다.
2. 기능적 패턴을 이루는 두 가지 타입의 데이터
2-1 네이티브 컴포넌트와 콤플렉스 컴포넌트
기능적 패턴은 플랫폼에서 제공하는 네이티브 컴포넌트와 이를 2개 이상으로 조합한 콤플렉스 컴포넌트가 있습니다. 네이티브 컴포넌트를 각자의 디자인 시스템에 맞게 재구성할 때는 플랫폼의 가이드에 크게 벗어나지 않도록 주의할 필요가 있습니다. 플랫폼에서 제공하는 가이드에는 크게 정책상 허용하지 않는 것과 사용성 측면에서 권장하지 않는 것들이 포함되어 있습니다. 예를 들면 탭 안에 텍스트와 아이콘을 수직으로 배치하는 것은 권장하지 않는 디자인으로 여겨집니다.
간혹 디자인 시스템에서 추구하려는 개성이 플랫폼의 가이드라인과 상충하는 경우도 있지만 적어도 디자인 시스템에 참여하는 디자이너라면 이미 익숙한 컴포넌트들이라도 어떤 의도에서 개발되고 작동하는지를 한번 정도는 해당 플랫폼의 가이드라인을 훑어보는 것을 추천합니다. material design의 가이드가 안드로이드와 웹 전체 플랫폼을 대표한다고 보긴 어렵지만 가이드에 각 컴포넌트별로 기본적인 스펙과 do / don't list를 알기 쉽게 제공하며, ios의 human interface guideline 또한 ios에서 사용되는 컴포넌트들의 세세한 가이드를 제공하고 있습니다.
컴플랙스 컴포넌트는 사용자 시나리오의 맥락과 상관없이 자주 반복되는 액션들에 바로 대응하기 위한 기능적 패턴에 가깝습니다. 예를 들면 세부 콘텐츠를 속성으로 받고 나머지 액션은 모두 동일하게 작동하는 모달 컴포넌트나 결과갑의 소팅옵션을 속성으로 받는 서치바 등이 콤플렉스 컴포넌트에 해당되겠습니다. 이러한 컴펄 렉스 컴포넌트들은 주어진 속성에 따라 다양한 맥락에서 반복사용됩니다
2-2 디자인 토큰과 props
결국 디자인 시스템에는 2가지 유형의 데이터가 있습니다. 첫 번째는 디자인 토큰이며 두 번째는 각 컴포넌트의 속성이라 할 수 있는 props(properties의 약자 4)입니다. 디자인 토큰이 컴포넌트들의 조형원리에 관여하는 데이터라면 props는 컴포넌트가 어떤 디자인 토큰을 인덱싱 하는지 정하거나 어떻게 동작할지 혹은 컴포넌트 내부에 표시될 콘텐츠에 관여하는 데이터입니다.
Datum Driven Design 버튼 컴포넌트 가이드라인: props의 내용과 타입을 설명과 사용된 스페이스 토큰의 내용을 요약한다.디자이너가 가이드를 제작할 때 디자인 토큰뿐만 아니라 해당 컴포넌트 또는 템플렛에 필요한 props의 spec 또한 명시할 필요가 있으며 때로는 이와 관련된 정책은 디자이너 스스로 정할 수 없는 경우도 있습니다. 그리고 가이드에 명시된 props의 name과 type 또한 개발자와 동일한 언어와 형식으로 작성돼야 하며 앞선 에피소드에서 언급한 네이밍 컨벤션에서 camelCase로 적는 것이 관행입니다. 따라서 디자인 토큰으로 컴포넌트를 합성한다는 것은 시각적 특성을 정의하는 토큰(크기, 색, 레이아웃 규칙)과 동시에 작동 원리 혹은 내부 콘텐츠를 정의하는 props를 조합하는 과정과도 같습니다.
Datum Driven Design 버튼 컴포넌트 가이드라인: props에 따른 spec variation, interaction state에 따른 변화를 보여준다.2-3 디자이너가 데이터 모델을 알아야 하나요?
보통 제품 개발과정에서 데이터에 관여하는 사람은 DB를 다루는 백엔드 개발자나 클라이언트 사이드에서 사용자에게 보이기 위한 데이터 모델을 다루는 프런트 엔드 개발자를 떠올립니다. 저는 컴포넌트 이상의 구성요소를 설계할 때는 디자이너도 데이터 모델작성에 관여해야 한다고 생각합니다. 좀 더 개인적인 생각을 내보이자면 사실 UX 설계단계에서 오히려 프런트엔드 개발자에게 데이터 모델의 초안을 제시해야 한다고 생각합니다.
UX 디자인 프로세스가 사용자 경험을 백트래킹해서 설계 요소로 분해하는 것이기 때문에 그 접점에 있는 UI에서 어떤 내용을 어떻게 보여줄지에 대한 고민에서 자연스럽게 데이터의 내용과 타입이 정해지기 때문입니다. 이러한 방식을 쓰지 않아도 디자이너가 얼추 만든 GUI시안을 보고 기존의 기획서를 참고해서 개발자들이 클라이언트 사이드의 데이터 모델과 백엔드 사이드의 DB 스키마를 설계할 수도 있겠지만, 그것보다는 누락되는 정보를 최소와 하고 디자인 시안이 해석의 여지가 없도록 디자이너가 데이터 모델의 초안을 작성하는 것의 장점이 크다고 생각합니다.
2-4 스프레드 시트로 먼저 기획해 보기
때문에 디자인 시스템을 구축하는 과정에서 생각보다 문서 작업을 많이 하게 됩니다. 저는 비슷한 이유에서 디자인 토큰을 구성할 때도 카테고리부터 스프레드시트에 먼저 정리하는 습관을 들이며, 데이터 모델 또한 와이어 프레임과 ux flow가 나온 시점에서 페이지 단위로 필요한 데이터 모델을 정리하고, 그 이하의 것들은 디자인 가이드의 props에 세부적으로 명시합니다. 이러한 방식으로 작업을 하면 개발사이드에서 프런트 기획과 DB 설계 및 백엔드 api 기획에 관련된 예비동작을 할 수 있다는 프로세스적인 장점도 있습니다.
3. 맥락적 패턴과 사용자 경험의 접점
3-1 사용자 경험을 구성하는 블록
맥락적 패턴은 아토믹 디자인에서 template이상의 구성요소로 사용자 시나리오의 특정 맥락과 직접적으로 연관 있는 패턴을 얘기합니다. 예를 들어 웹서비스의 header, sidemenu, footer 등의 Global navigation 컴포넌트들을 한데 묶어서 관리하는 app shell은 서비스의 navigation을 담당하는 템플렛이라고 볼 수 있습니다. 그리고 구글의 검색결과를 보여주는 섹션도 검색결과를 다양한 콤플렉스 컴포넌트들로 리듬감 있게 보여주는 template입니다. 이러한 template은 결국 본격적으로 사용자 경험을 구축하는 기본 블록입니다. 잘 구성된 디자인 시스템일수록 template 간의 조합을 통해 디자이너가 개발자가 사용자 경험을 구축함에 있어 빠르고 유연한 대응이 가능하기 때문입니다.
3-2 이제 모든 것은 선택과 조합의 문제
선택과 조합. 디자인 시스템의 궁극적인 가치를 표현함에 있어 제가 가장 좋아하는 표현입니다. '바퀴를 재발명하지 말라'라는 유명한 인용문이 있습니다. 최소한의 동력으로 무언가를 이동시키고 싶을 때 바퀴를 선택하면 될 문제이 조. 파일럿이 여객기를 운행하는 모습을 상상해 봐도 동일합니다 이들은 단선적인 사고를 통해 마치 비행기 게임을 조작하듯 운전하지 않습니다. 미리 입력된 비행 동선, 고도, 기상, 기체 상황 등을 고려해서 각 계기판의 어떤 요소들을 어떻게 조합할지 결정할 뿐이죠.
이제 모든 것은 선택과 조합의 문제
이것이 디자인 시스템이 고도화되었을 때 우리가 스스로에게 기대할 수 있는 모습과 유사합니다. 위에서 디자이너가 데이터 모델을 직접 다뤄야 한다고 주장한 것도 비슷한 맥락입니다. 사용자 시나리오를 발굴하고 이것을 UX.UI 단계로 설계한다는 것은 결국 어떤 데이터들을 어떻게 조합해서 보여주거나 동작시킬 것이라는 문제로 귀결되며 이는 사용자 인터랙션에도 직접적인 영향을 줍니다. 이 와중에 유사한 패턴이 반복되었을 때 기존의 컴포넌트들을 구성해서 템플렛을 디자인 시스템에 추가합니다.
4. 정리하며
이번 에피소드에서는 팀의 상황에 맞게 디자인 시스템이 도입되는 시나리오를 4(제품의 성숙도, 리소스, 확장 가능성, 프로세스) 가지 요소별로 얘기해 봤습니다. 그리고 디자인 시스템 구축의 실질적인 작업인 인지적 패턴이 기능적 패턴에 적용되는 방식, 그리고 맥락적 패턴을 구성 운염함으로서 디자인 시스템이서 추구해야 할 가치에 대해 언급했습니다.
여기까지 읽으신 분들은 이제 왜 디자인 시스템 도입이 개별 태스크가 아닌 제품을 빌딩 하는 과정에서 자연스럽게 발생한 시스템을 체계화시키는 것에 가까운지 이해하셨을 것이라 생각합니다. 다음 마지막 에피소드 '그래서?'에서는 이번 기획 콘텐츠 (디자인 시스템의 육하원칙)를 전반적으로 요약하고 디자인 시스템의 사이클과 기타 알면 좋을 툴동에 대해서 다루면 마무리하려 합니다.
다음 에피소드: 그래서? 에서 계속됩니다>>
이전 에피소드: 무엇을? 어떻게? 보기
Creat Your Business Value With Data Driven Design
