이 글은 John Choura가 작성한 Stack mirroring: Designing for code and coding for design의 번역문입니다. Design Systems 사이트를 운영하는 Figma의 허락을 구한 후 번역하였습니다.
서문
솔직히 말하자면, 지금 디자인 시스템은 오랫동안 코드가 해왔던 일을 하고 있다.
기본적으로 프로그래밍은 기능적이고, 재사용할 수 있고, 확장 가능하며 버전 관리가 가능하다. 지금의 디자인 시스템은 프로그래밍과 비슷한 것 그 이상을 달성하는 것을 목표로 하므로 프로그래밍의 동작 방식으로부터 방향을 가져올 수 있다.
디자인 시스템은 더 빠른 디자인 사이클, 팀과 제품 확장성, 프로그래밍적 사고를 가능하게 하므로 중요하다. 나는 항상 첫 번째와 두 번째 사실(빠른 디자인 사이클, 팀과 제품의 확장성)에 집중했지만, 현재 가장 관심을 두고 있는 것은 마지막 사실 - 프로그래밍적 사고이다. 디자인 시스템을 구축하고 구현할 때 프로그래밍 방식으로 생각하게 되면 제품 디자인 팀은 강력한 힘을 가지게 된다.
디자인 파일의 코드 구조 미러링
가장 최근에 겪었던 일을 소개한다. 나는 피그마에 웹앱을 위한 UI 컴포넌트 라이브러리를 구축하고 있었다. UI 엔지니어링 팀은 이미 리액트에서 이 컴포넌트 라이브러리를 npm 디펜던시로서 구축한 상태였다. 나는 리액트에 익숙했기 때문에 Figma 인스턴스를 빌드를 위해 리액트 컴포넌트 코드를 사용해서 거꾸로 작업 하기 시작했다. 모든 사이즈의 컴포넌트를 분리하고 중첩했으며, 리액트 스키마에 존재하는 옵션과 props에 대한 이점을 바로 확인할 수 있었다.
몇 년 동안 나는 마크업 코드 작성 후 레이어와 그룹을 모델링 해왔다. 중첩하고, 순서를 지정하고, 레이어 이름을 지정하고, 클래스 이름을 미러링하는 등의 작업을 해왔기 때문에 디자인 파일에서 코드 구조를 미러링하는 것은 나에게 낯설지 않은 일이었다. 내가 코드부터 시작해서 거꾸로 작업하며 얻은 교훈이 있다. 바로 디자인 미러링 코드에는 힘이 있으며 그 반대도 마찬가지라는 것이다.
위의 예에서는 중첩된 컴포넌트 Form Group > Input > Label을 사용해 Form Input을 구성하는 방법을 소개했다. input과 label은 자체적인 마스터 컴포넌트다. 이러한 input및 label 인스턴스가 FormGroup의 마스터 구성 요소에 번들로 제공된다. 리액트와 비슷하게, 이를 통해 구성 요소를 독립적으로 관리하고 통합할 수 있다. 바뀔 가능성이 많이 있는 구성 요소를 처리하거나 리액트의 props를 시뮬레이션하려고 할 때는 토글로 간단하게 관리 할 수 있다.
디펜던시 레벨에서 스택 미러링
마크업 미러링은 꽤 훌륭하고 괜찮았지만 나는 거기서 멈추고 싶지는 않았다. 디자인 스택(Figma, Figma Libraries, Figma Components, 레이어 및 그룹 등)을 사용하여 프론트 엔드 코드 스택(Node, npm, React, Javascript, Markup 등)을 미러링할 수도 있다고 생각했다. 스택 미러링에 대한 내 생각을 소개한다.
나는 디펜던시 레벨에서 미러링하는 방법에 대해 고민하기 시작했다. npm 같은 플랫폼은 외부에서 관리되는 패키지 및 디펜던시를 무제한으로 포함할 수 있다(npm에 대해 알고 싶다면 여기로). 예를 들어 앞서 소개한 컴포넌트 라이브러리는 우리가 happy UI라고 부르는 디펜던시다. 이 Happy UI 디펜던시는Figma의 공유 라이브러리와 다르게 우리 웹 제품 전반에 걸쳐 공유되는 프론트 엔드 컴포넌트 라이브러리이다. 이러한 차이를 맞추기 위해 우리는 미러링을 활용할 수 있다.
노드 프로젝트의 package.json 파일에 디펜던시가 포함될 수 있는 것처럼 Figma의 팀 라이브러리도 같은 방식으로 생각할 수 있다. 우리는 Happy UI 디펜던시를 core, web, native와 같은 몇 가지 다른 프로젝트로 분리했다. Happy UI core 는 브랜드 자산이나 색상, 아이콘 그리고 유틸리티 컴포넌트와 같은 기본 요소를 공유한다. Happy UI web은 웹 인터페이스를 구축할 수 있는 모든 기능을 갖추고 있으며, Core와 함께 사용한다면 요리도 할 수 있다. 따라서 나는 웹을 위한 새로운 온 보딩 플로우를 작업하게 된다면 나는 web과 core를 사용할 것이다. 이렇게 작업하게 된다면 그 과정은 매우 쉬울 것이다.
UI 엔지니어나 소프트웨어 엔지니어와 함께 작업할 때, 우리는 공유된 네임스페이스와 모델을 사용하여 빠르게 작업이 진척되는 환경에서 확장성, 효율성과 반복을 쉽게 만들어준다. 스택 미러링을 사용하면 목표를 달성하기 위한 방법과 수단에 대한 혼란이 줄어들 것이다.
마무리하며
나는 네임스페이스, 툴 및 모델에 대한 얼라인이 맞추어졌을 때 디자인과 개발이 함께 더 잘 작동한다고 생각한다. 그런 부분에 있어 정신적인 부담을 줄이면, 팀은 기능을 빠르게 구축하고 내보내는 동안에도 품질에 대해 타협할 필요가 없어진다. 개발과 디자인을 동시에 유지한다는 건 제품을 유지 관리하고 테스트하고 업데이트하기가 더 쉬워진다는 뜻이다. 자, 이제 개발자와 협력하여 스택 미러링을 시작할 준비가 되었는가?