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

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

• 일반 사용자 중 고급 유저들이 소비자의 객관적인 입장에서 제품을 리뷰하고 분석한 것

• 디자인시스템을 먼저 적용하기 전, 실제 개발 환경에서 어떻게 사용되는지 검증과 테스트가 필요

무엇을 검증해야 할까?

• 웹페이지를 만드는 방법은 여러 방법이 존재

• 예를들어, React 웹을 제작할 때 레이아웃을 표기하는 방법은 수십가지 존재

• 즉, 프론트에서 레이아웃을 개발할 때 가장 이해가 잘 되는 컴포넌트 사용 방법으로 컴포넌트를 제공해야 한다.

검증을 위한 아키텍처 준비

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

• 예시) 코어, 컴포넌트, 인터페이스 등으로 레이어를 분리

• 실제로는 코어, 컴포넌트도 상세에 레이어가 더 분리되어 있어야 하며, 인터페이스는 필수로 분리되어 있어야 한다.

• 인터페이스를 분리해두어야 추후 피드백을 통해 인터페이스를 쉽게 교체할 수 있다.

  • 인터페이스도 하나의 라이브러리로 버전을 관리하면 좋다.

• 실 사용 적합한 경우와 적합하지 않은 경우의 인터페이스를 체크하여 더 필요한 것이 무엇이 있는지 체크한다. 이 단계에서 html reference element, classname 등

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

• 이 단계에서 html reference element, classname 등 react를 넘어 element 수준까지 접근을 허용할지 고민

• 쉽게 오픈하게 되면 디자인시스템 동작 혹은 레이아웃을 사용처에서 마음대로 변경할 수 있다.

• 최악의 경우, 오픈되어있는 버전으로 다운그레이드 등을 통해 마음대로 해킹하여 사용하는 등, 일관성을 유지하기 어려워진다.

• 그에따라 raw data 접근은 최대한 보수적으로 열도록 제공하며, 사용하더라도 방어 로직을 최대한 생성해두어야 한다.

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

피그마 플러그인

• 피그마에서 JS/TS를 이용해 피그마 기능에 접근하여 확장 프로그램을 제작하여 생산성을 올려줄 수 있는 도구

  • 원래 JS만 되었는데 Figma Config 2023에서 Figma의 파격적인 강화를 통한 장족인 발전이 있었음

• https://www.figma.com/plugin-docs/typescript/

  • 피그마 타입스크립트 플러그인 도큐먼테이션을 보고 구현 가능

• HTML/CSS/JS를 통해 레이아웃을 ifram으로 그리면,

• sandbox에서 figma 기능을 만들어서 postMessage로 서로간 통신을 시킬 수 있다.

• sandbox에서의 figma 기능을 접근하기 위해 메인쓰레드에서 작동하는 정도만 알면 된다.

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

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

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

• 세 번쨰: 피그마 사용을 도와주는 관점

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

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

• 예시) Raw Color를 계층별로 쪼개서 더 쉽게 사용하기 위한 고민을 통해, 웹/피그마에서 활용

• 이 구조는 개발이 가능하지만, 피그마에서 제공되지 않는 상황

• 이러한 문제를 피그마 플러그인을 통해 해결할 수 있다.

• 각 회사 별 디자인시스템에 정의된 컬러가 매우 많아지는 경우 이러한 피그마 플러그인은 필수불가결이 된다.

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

• 예시) 수 많은 UI를 디자인시스템 디자이너가 검토하는 상황, 자동화된 검토 flow 구축 필요

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

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

• 예시) 피그마를 사용하는데 있어 레이어를 맘대로 사용하다보면 이미지나 제데로된 이름이 안되어 있는등, 급하게 디자인을 하다보면 문제가 많이 생기게 됨

• 피그마의 html, css 등 코드를 가져와 활용하는 부분이 있는데, 이러한 부분에 대한 스코어링을 제공하고, 일정 미만의 점수이면 export 하지 못하도록 막는 등의 작업을 진행할 수 있다.

• 디자인하는 인원이 많아지고, 심지어 컴포넌트를 잘 작성해두면 이후에는 디자이너가 아닌 기획자들이 디자인을 주도할 수 있게된다. 그렇기 때문에 이러한 검증 프로세스를 필수불가결 하며, 일원화된 양식으로 export할 수 있도록 제공해야한다.

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

• 디자인시스템은 구축이 되면서 점점 사용처가 분화된다.

  • 앱과 웹으로 나눠지고, 그 안에서 B2B/B2C가 나뉘고 PC/Mobile로 나눠진다.

• 각 사용처 별로 "디자인시스템을 사용하는 가이드라인은 달라질 수 박에 없다."

  • B2B와 B2C는 보이는 정보의 양이 다르기 때문에 다를 수밖에 없다.

  • 모든걸 일원화 하는것은 어려운일이고 해서도 안된다.

조직에 대한 이해

• 조직 구성에 따라 디자인시스템은 유연하게 사용하는 부분이 달라질 수 있다.

  • 예를들어 조직이 B2B 비즈니스에 힘을 주면, B2B에 해당하는 디자인시스템을 집중해야할 수밖에 없다.

• 모든 회사는 조직이 수시로 개편되며, 관심사가 달라진다.

  • 하지만 불변하는 것은, 프로덕트를 운영하는 업무는 동일하다.

  • 프로덕트를 기준으로 수많은 조직이 응집되고 사라진다.

• 디자인시스템은 이러한 조직의 구조를 이해하고 유연하게 가이드라인을 가질 수 있도록 준비해야 한다.

가이드라인

• 가이드라인은 따라야할 "필수적인 가이드"이나 비즈니스 요건에따라 허용이 되어야할 때도 있다.

• 컴포넌트 코드 단위, 문서, 혹은 디자인 시안일 수 있다.

  • 보통 피그마에선 컴포넌트를 가져와서 사용할 수 있도록 모듈화를 진행하여, 코드상에서는 라이브러리로 제공한다.

  • 또한 문서(스토리북 등)을 통해 개발자/디자이너가 아니여도 읽고 사용할 수 있도록 제공한다.

• 가이드라인의 주요 사용 주체는 개발자/디자이너일 수 있지만 사업간의 업무를 조율하는 PM/PO일 확률이 높다.

  • 해당 컴포넌트를 보고 시안을 빠르게 잡고 협의를 진행할 수도 있기 때문

가이드라인의 필요한 정보

• 첫 번쨰: 어디에서, 어떻게 쓰이는지에 대한 정보

• 두 번째: 연관된 디자인시스템 컴포넌트는 어떤 것인지에 대한 정보

• 세 번쨰: 문제가 있을 때 혹은 궁금한 점이 있을 때 어디에 질문을 해야하는지에 대한 정보

• 네 번쨰: 대체할 수 있는 컴포넌트 혹은 현재 버전, 상황에 대한 정보

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

계층 기반의 디자인시스템

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

컴포넌트의 범위

• 디자인시스템 코어: 디자인시스템의 레이아웃을 제외한 로직을 들고 있는 컴포넌트

• 디자인시스템 라이브러리: 코어를 이용해 레이아웃을 붙여 각 도메인별로 제공하는 컴포넌트 라이브러리

• 디자인시스템 워킹그룹: 디자인시스템을 사용하여 비즈니스를 개발하는 도메인 단위의 라이브러리

컴포넌트 범위 예시

• 예시) Form 컴포넌트를 디자인시스템에서 지원해야하나?

• Form에 비동기 처리등 기능 제공은 "코어"에서 제공.

• 레이아웃 제공은 각 "라이브러리" 레벨에서 레이아웃 작성을 통해 제공한다.

• 실제 Form은 레이아웃이 아닌 기능인 경우가 많으므로 "가이드라인"레벨에서 디자인시스템 라이브러리를 이용해 하나의 가이드라인 라이브러리로 제공되는게 좋다.

• Table을 확장한 컴포넌트와 같은 다양한 사례들로 디자인시스템에서 지원하는게 아닌, 각 워킹 그룹에서 공통/도메인별 사용할 수 있도록 제공하고, 디자인시스템에서는 각 워킹그룹의 작업을 한 눈에 볼 수 있도록 프로덕트를 제공한다.

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