더 효율적인 디자인시스템 만들기
Last updated
Last updated
일반 사용자 중 고급 유저들이 소비자의 객관적인 입장에서 제품을 리뷰하고 분석한 것
디자인시스템을 먼저 적용하기 전, 실제 개발 환경에서 어떻게 사용되는지 검증과 테스트가 필요
웹페이지를 만드는 방법은 여러 방법이 존재
예를들어, React 웹을 제작할 때 레이아웃을 표기하는 방법은 수십가지 존재
즉, 프론트에서 레이아웃을 개발할 때 가장 이해가 잘 되는 컴포넌트 사용 방법으로 컴포넌트를 제공해야 한다.
예시) 코어, 컴포넌트, 인터페이스 등으로 레이어를 분리
실제로는 코어, 컴포넌트도 상세에 레이어가 더 분리되어 있어야 하며, 인터페이스는 필수로 분리되어 있어야 한다.
인터페이스를 분리해두어야 추후 피드백을 통해 인터페이스를 쉽게 교체할 수 있다.
인터페이스도 하나의 라이브러리로 버전을 관리하면 좋다.
실 사용 적합한 경우와 적합하지 않은 경우의 인터페이스를 체크하여 더 필요한 것이 무엇이 있는지 체크한다. 이 단계에서 html reference element, classname 등
이 단계에서 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을 확장한 컴포넌트와 같은 다양한 사례들로 디자인시스템에서 지원하는게 아닌, 각 워킹 그룹에서 공통/도메인별 사용할 수 있도록 제공하고, 디자인시스템에서는 각 워킹그룹의 작업을 한 눈에 볼 수 있도록 프로덕트를 제공한다.
변경이 될 수 있는 컴포넌트들은 코어나 디자인시스템 라이브러리에서 제공이 되지 않게 하는것이 가장 중요하다.
