10. 디자인시스템, 코드를 넘어서

• https://so-so.dev/react/design-system-beyond-code/

• 디자인시스템은 만들기 전에 명확한 목표를 세우자.

  • 시스템의 강제성을 높여 깨질 수 없는 일관성과 높은 생산성을 추구 할 수도,
  • 시스템을 재료로 바라보고, 높은 확장성과 자유도를 추구 할 수도,

확장성을 추구한다면

• 높은 확장성 / 자유도를 추구한다면, 디자인 시스템은 일관성이란 책임을 사용처에 일부 위임하는 형태.
• 따라서 시스템 레이어 그 이상을 목표로 잡아야함

1. 디자인 시스템 계층
2. 프로덕트 시스템 계층

• 위와 같이 제품 컴포넌트의 레이어를 최소 두 가지 이상으로 보고, 사용처에서 프로덕트 시스템을 구축하기 위한 지원도 고려야함.

중요한 것은 퀄리티

• 디자인 시스템도 제품. 사용자가 두 그룹.
  • 제품을 사용하는 사용자
  • 그 제품을 만드는 팀원
• 팀원이 먼저 찾는 디자인 시스템이 되려면 '디자인 시스템 자체가 압도적인 만족감'을 줘야한다.
• 높은 수준의 UI/UX를 제공하여 제품에 적용하고 싶어야하고, 시스템 확장 시 방해가 되면 안된다.

대원칙 만들기

• 목표와 철학이 정해졌다면, 이를 바탕으로 시스템 의사결정의 핵심 원칙 세우기
• 디자인 시스템이 무엇을 하고 무엇을 하지 않을 것인지
• 코드 인터페이스는 디자인 제약사항을 어떻게 반영할 것인지. 가능한 구체적으로 문서화!

대원칙 수호하기

• 인터페이스 네이밍부터 컴포넌트 단위에서 일관된 추상화 레벨을 지향하는지
• 접근성과 같은 기본 책임을 충분히 수행하고 있는지

지속 가능성 추구하기

• 일관된 인터페이스에서 단순하게 구현하기
• 일관된 인터페이스는 기능을 예측 할 수 있게 하며, 단순한 구현은 다른 개발자가 시스템 코드를 쉽게 파악할 수 있도록 한다.
• 이것은 시스템에 기여 할 수 있는 기반을 만든다.
• 인터페이스
  • 구현의 단순함 보다 인터페이스의 단순함이 중요하다. 올바르게 동작하지 않는 경우를 제외하고, 인터페이스 일관성을 추구하기.
• 완전성
  • 내부 구현의 복잡함 대비, 얻는 완전성의 가치 크기가 크지 않다면 타협하기. 단순함을 중요한 가치로 바라보자.

정의를 잘 하기

• 디자인 시스템의 목표를 정한 것 처럼, 만드는 중에는 컴포넌트 목표를 정의해야함.
• 정의가 부족하다면, 컴포넌트 디자인 가이드를 합의된 정의라고 오해한다.

프로덕트 시스템과 컴포넌트 계층

• 제품이 여러 도메인을 가지고 있다면, 디자인 시스템만으로 전부 대응 불가능.

• 특정 도메인에서는 반복되는 패턴이 존재할 것.

• 이러한 도메인 내 반복되는 패턴은..디자인 시스템에 편입시켜야할까? '프로덕트 시스템'을 활용하자. 컴포넌트의 종류는 네가지와 같다.

  1. 도메인 컴포넌트의 조합으로 구성된 컴포넌트 (사용성 >>> 확장성)
  2. 도메인 컴포넌트 (사용성 > 확장성)
     • 도메인의 맥락을 담고 있는 영역. 도메인 맥락을 알고 있더라도 여러 서비스에 사용될 수도 있음
  3. 프로덕트 시스템 컴포넌트 (사용성 < 확장성)
     • 디자인 시스템을 제품에 맞게 한 단계 추상화를 낮춰서 제공.
  4. 디자인 시스템 컴포넌트 (사용성 <<< 확장성)
     • 확장성을 높여 커스텀에 용이한 레이어