# 더 효율적인 디자인시스템 만들기

## 필드 테스트로 실사용 적합성 판단하기

* 일반 사용자 중 고급 유저들이 소비자의 객관적인 입장에서 제품을 리뷰하고 분석한 것
* 디자인시스템을 먼저 적용하기 전, 실제 개발 환경에서 어떻게 사용되는지 검증과 테스트가 필요

### 무엇을 검증해야 할까?

* 웹페이지를 만드는 방법은 여러 방법이 존재
* 예를들어, React 웹을 제작할 때 레이아웃을 표기하는 방법은 수십가지 존재
* 즉, 프론트에서 레이아웃을 개발할 때 가장 이해가 잘 되는 컴포넌트 사용 방법으로 컴포넌트를 제공해야 한다. 

### 검증을 위한 아키텍처 준비

<figure><img src="https://1912740209-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F3GVYdZvmqQyBVq29ebqk%2Fuploads%2FEFYWU1lIHji8nleEDxMj%2F%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202024-03-31%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%2010.53.22.png?alt=media&#x26;token=201fb7a9-dddf-41d2-84be-77e9b47fc109" alt=""><figcaption></figcaption></figure>

#### 기본적으로 사용자에게 전파되는 단계를 촘촘히 레이어를 구분해둔다.

* 예시) 코어, 컴포넌트, 인터페이스 등으로 레이어를 분리
* 실제로는 코어, 컴포넌트도 상세에 레이어가 더 분리되어 있어야 하며, 인터페이스는 필수로 분리되어 있어야 한다.&#x20;
* 인터페이스를 분리해두어야 추후 피드백을 통해 인터페이스를 쉽게 교체할 수 있다.
  * 인터페이스도 하나의 라이브러리로 버전을 관리하면 좋다.
* 실 사용 적합한 경우와 적합하지 않은 경우의 인터페이스를 체크하여 더 필요한 것이 무엇이 있는지 체크한다. 이 단계에서 html reference element, classname 등

#### 컴포넌트의 raw 데이터에 접근해도 되는가에 대한 적합성 판단

* 이 단계에서 html reference element, classname 등 react를 넘어 element 수준까지 접근을 허용할지 고민
* 쉽게 오픈하게 되면 디자인시스템 동작 혹은 레이아웃을 사용처에서 마음대로 변경할 수 있다.
* 최악의 경우, 오픈되어있는 버전으로 다운그레이드 등을 통해 마음대로 해킹하여 사용하는 등, 일관성을 유지하기 어려워진다.
* 그에따라 raw data 접근은 최대한 보수적으로 열도록 제공하며, 사용하더라도 방어 로직을 최대한 생성해두어야 한다.&#x20;

### 피그마 플러그인으로 디자이너향 디자인시스템 편의성 확장

#### 피그마 플러그인

* 피그마에서 JS/TS를 이용해 피그마 기능에 접근하여 확장 프로그램을 제작하여 생산성을 올려줄 수 있는 도구
  * 원래 JS만 되었는데 Figma Config 2023에서 Figma의 파격적인 강화를 통한 장족인 발전이 있었음
* <https://www.figma.com/plugin-docs/typescript/>
  * 피그마 타입스크립트 플러그인 도큐먼테이션을 보고 구현 가능

<figure><img src="https://1912740209-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F3GVYdZvmqQyBVq29ebqk%2Fuploads%2FB3FsYHZ4kft48XQhuz0Z%2F%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202024-03-31%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%2011.21.51.png?alt=media&#x26;token=71cd7c4d-a997-47ee-afd7-833889676165" alt=""><figcaption></figcaption></figure>

* HTML/CSS/JS를 통해 레이아웃을 ifram으로 그리면,
* sandbox에서 figma 기능을 만들어서 postMessage로 서로간 통신을 시킬 수 있다.
* sandbox에서의 figma 기능을 접근하기 위해 메인쓰레드에서 작동하는 정도만 알면 된다.&#x20;

#### 피그마 플러그인으로 디자이너의 편의성을 확장하기 위해 무엇이 필요할까

* 첫 번째: 디자이너와 개발자간의 협업을 도와주는 관점
* 두 번째: 디자이너간 협업을 도와주는 관점
* 세 번쨰: 피그마 사용을 도와주는 관점

세 가지 관점으로 편의성 확장을 진행한다.

### 첫 번째: 디자이너와 개발자간의 협업을 도와주는 관점

<figure><img src="https://1912740209-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F3GVYdZvmqQyBVq29ebqk%2Fuploads%2F94ZsQYoMcQaRY3jJi2jy%2F%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202024-03-31%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%2011.24.06.png?alt=media&#x26;token=c9597062-f0f9-49e5-aabe-8442cd49614a" alt=""><figcaption></figcaption></figure>

* 예시) Raw Color를 계층별로 쪼개서 더 쉽게 사용하기 위한 고민을 통해, 웹/피그마에서 활용
* 이 구조는 개발이 가능하지만, 피그마에서 제공되지 않는 상황
* 이러한 문제를 피그마 플러그인을 통해 해결할 수 있다.
* 각 회사 별 디자인시스템에 정의된 컬러가 매우 많아지는 경우 이러한 피그마 플러그인은 필수불가결이 된다.&#x20;

### 두 번째: 디자이너간 협업을 도와주는 관점

<figure><img src="https://1912740209-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F3GVYdZvmqQyBVq29ebqk%2Fuploads%2FBcUUJ9JUO1iL7Xm7vJFF%2F%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202024-03-31%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%2011.25.28.png?alt=media&#x26;token=11190308-5621-4349-af4c-19f55a878dd6" alt=""><figcaption></figcaption></figure>

* 예시) 수 많은 UI를 디자인시스템 디자이너가 검토하는 상황, 자동화된 검토 flow 구축 필요
* 비즈니스를 디자인시스템을 이용해 개발할수록 디자이너의 할 일은 많아진다. 가이드 안에서 컴포넌트를 구축했는지 확인하기 때문에, 이러한 부분에서 피그마의 인스펙터 안에 컴포넌트 사용이 무엇이 되어있는지 판별하여 자동화된 검토 flow를 예측할 수 있다.

### 세 번째: 피그마 사용을 도와주는 관점

* 예시) 피그마를 사용하는데 있어 레이어를 맘대로 사용하다보면 이미지나 제데로된 이름이 안되어 있는등, 급하게 디자인을 하다보면 문제가 많이 생기게 됨
* 피그마의 html, css 등 코드를 가져와 활용하는 부분이 있는데, 이러한 부분에 대한 스코어링을 제공하고, 일정 미만의 점수이면 export 하지 못하도록 막는 등의 작업을 진행할 수 있다.
* 디자인하는 인원이 많아지고, 심지어 컴포넌트를 잘 작성해두면 이후에는 디자이너가 아닌 기획자들이 디자인을 주도할 수 있게된다. 그렇기 때문에 이러한 검증 프로세스를 필수불가결 하며, 일원화된 양식으로 export할 수 있도록 제공해야한다.&#x20;

### 디자인시스템에 추가하여, 디자인 가이드라인을 만든다는 것

<figure><img src="https://1912740209-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F3GVYdZvmqQyBVq29ebqk%2Fuploads%2FTP1wG2KkdzdKpkhUBI25%2F%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202024-03-31%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%2011.29.13.png?alt=media&#x26;token=80055a71-5733-43c6-98c9-81c89e2571c8" alt=""><figcaption></figcaption></figure>

* 디자인시스템은 구축이 되면서 점점 사용처가 분화된다.
  * 앱과 웹으로 나눠지고, 그 안에서 B2B/B2C가 나뉘고 PC/Mobile로 나눠진다.
* 각 사용처 별로 **"디자인시스템을 사용하는 가이드라인은 달라질 수 박에 없다."**&#x20;
  * B2B와 B2C는 보이는 정보의 양이 다르기 때문에 다를 수밖에 없다.
  * 모든걸 일원화 하는것은 어려운일이고 해서도 안된다.

### 조직에 대한 이해

* 조직 구성에 따라 디자인시스템은 유연하게 사용하는 부분이 달라질 수 있다.
  * 예를들어 조직이 B2B 비즈니스에 힘을 주면, B2B에 해당하는 디자인시스템을 집중해야할 수밖에 없다.
* 모든 회사는 조직이 수시로 개편되며, 관심사가 달라진다.
  * 하지만 불변하는 것은, **프로덕트를 운영하는 업무는 동일하다.**
  * 프로덕트를 기준으로 수많은 조직이 응집되고 사라진다.
* **디자인시스템은 이러한 조직의 구조를 이해하고 유연하게 가이드라인을 가질 수 있도록 준비해야 한다.**

<figure><img src="https://1912740209-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F3GVYdZvmqQyBVq29ebqk%2Fuploads%2FeQcqHXtgwYn1yX37aXqV%2F%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202024-03-31%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%2011.34.41.png?alt=media&#x26;token=136cc0c8-f776-41bc-9dcc-345fafadce76" alt=""><figcaption></figcaption></figure>

## 가이드라인

* 가이드라인은 따라야할 "필수적인 가이드"이나 비즈니스 요건에따라 허용이 되어야할 때도 있다.
* 컴포넌트 코드 단위, 문서, 혹은 디자인 시안일 수 있다.
  * 보통 피그마에선 컴포넌트를 가져와서 사용할 수 있도록 모듈화를 진행하여, 코드상에서는 라이브러리로 제공한다.
  * 또한 문서(스토리북 등)을 통해 개발자/디자이너가 아니여도 읽고 사용할 수 있도록 제공한다.
* 가이드라인의 주요 사용 주체는 개발자/디자이너일 수 있지만 사업간의 업무를 조율하는 PM/PO일 확률이 높다.
  * 해당 컴포넌트를 보고 시안을 빠르게 잡고 협의를 진행할 수도 있기 때문

#### 가이드라인의 필요한 정보

* 첫 번쨰: 어디에서, 어떻게 쓰이는지에 대한 정보
* 두 번째: 연관된 디자인시스템 컴포넌트는 어떤 것인지에 대한 정보
* 세 번쨰: 문제가 있을 때 혹은 궁금한 점이 있을 때 어디에 질문을 해야하는지에 대한 정보
* 네 번쨰: 대체할 수 있는 컴포넌트 혹은 현재 버전, 상황에 대한 정보

### 복잡한 형태의 컴포넌트 지원하기

#### 계층 기반의 디자인시스템

* 디자인시스템은 점진적으로 커지므로, 계층 단위로 가져가는 것이 중요

<figure><img src="https://1912740209-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F3GVYdZvmqQyBVq29ebqk%2Fuploads%2FYpl3PlHeAreE2W2ZmYaV%2F%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202024-03-31%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%2011.43.18.png?alt=media&#x26;token=6ca5f0d2-118a-465d-9c28-a63f38f2da6c" alt=""><figcaption></figcaption></figure>

#### 컴포넌트의 범위

* 디자인시스템 코어: 디자인시스템의 레이아웃을 제외한 로직을 들고 있는 컴포넌트
* 디자인시스템 라이브러리: 코어를 이용해 레이아웃을 붙여 각 도메인별로 제공하는 컴포넌트 라이브러리
* 디자인시스템 워킹그룹: 디자인시스템을 사용하여 비즈니스를 개발하는 도메인 단위의 라이브러리

### 컴포넌트 범위 예시

* 예시) Form 컴포넌트를 디자인시스템에서 지원해야하나?
* Form에 비동기 처리등 기능 제공은 "코어"에서 제공.
* 레이아웃 제공은 각 "라이브러리" 레벨에서 레이아웃 작성을 통해 제공한다.
* 실제 Form은 레이아웃이 아닌 기능인 경우가 많으므로 "가이드라인"레벨에서 디자인시스템 라이브러리를 이용해 하나의 가이드라인 라이브러리로 제공되는게 좋다.
* Table을 확장한 컴포넌트와 같은 다양한 사례들로 디자인시스템에서 지원하는게 아닌, 각 워킹 그룹에서 공통/도메인별 사용할 수 있도록 제공하고, 디자인시스템에서는 각 워킹그룹의 작업을 한 눈에 볼 수 있도록 프로덕트를 제공한다.&#x20;

{% hint style="info" %}
**변경이 될 수 있는 컴포넌트들은 코어나 디자인시스템 라이브러리에서 제공이 되지 않게 하는것이 가장 중요하다.**
{% endhint %}