Design System

Design System

컴포넌트 재사용이 필요한 시점

• 컴포넌트가 담당하는 역할이 많아져 공통의 역할이 되는 경우

• 여러 구성원이 하나의 컴포넌트를 개발하는 경우

• 동일한 로직이 여러 코드에 들어가는 경우

컴포넌트 재사용이 필요한 시점은 규칙이 되어야 한다.

• 동일한 코드가 2군데/3군데 이상 있는 경우

• 관심사가 두 개 이상이 되는 경우

  • e.g. DatePicker (캘린더를 보여주는 컴포넌트, 날짜를 선택하는 컴포넌트)

• 해당 컴포넌트에 리소스가 많이 들어있는 경우 (코드리뷰하기 벅참)

컴포넌트가 재사용이 가능한 시점에 컴포넌트를 재사용하는 규칙이 있어야 한다.

점점 비대해지는 공통 코드

• 공통의 규칙대로 작업을 진행하면 공통 로직이 많아진다.

• 공통 로직을 잘 볼 수 있도록 폴더링을 하고, 규칙을 만들어도 파일수가 절대적으로 많아짐

• 인원수와 더불어 개발 업무가 많아지면서, 파일을 수정해야하는 경우가 늘어나게 됨

공통 코드에 대한 버전 관리가 필요해지는 시점

• 공통 코드에 대한 의존도가 높아지고, 사용률이 프로덕트 별로 많아지는 상황

• 코드 한 줄을 수정할 때 사이드이펙트가 어떻게 발생할지 모름

• 프로덕트 레벨에서 신규 버전 테스트가 가능하도록 버전을 통해 하위호환성 유지 필요

컴포넌트 라이브러리와 디자인시스템

• 컴포넌트(UI) 라이브러리

  • 코드의 재사용성을 향상시키고, 팀 간의 협업을 간소화하여, 제품의 UI를 빠르게 구축하는데 도움이 됨

  • UI 라이브러리는 구체적인 코드를 포함하는, 재사용 가능한 UI 컴포넌트들의 모음

    • 실제 개발에서 사용할 수 있는 버튼, 입력 폼 등의 구현체

  • "공통으로 사용되는 컴포넌트 단위"로 "라이브러리화 하여 버전 관리"가 되는 것을 표현

• 디자인 시스템

  • 브랜드와 제품의 일관성을 유지하고, 팀 간 협업을 향상시켜 더 빠르고 효과적으로 UI를 디자인하고 구축하는데 도움이 됨

  • 사용자 인터페이스를 구축하는데 필요한 모든 요소를 정의하는 포괄적인 문서와 가이드라인 집합

    • 컴포넌트, 패턴, 디자인 원칙, 사용 가이드라인, 툴, 스타일 가이드 등

  • 다양한 프로덕트에서 디자인 철학을 바탕으로 시각적인 요소를 브랜딩 가치와 함께 표현할 수 있는 시스템

    • 단순히 "컴포넌트 단위"가 아닌, "시스템 단위" 이며

      • 컴포넌트 라이브러리는 디자인시스템의 한 분류

      • 한 조직이 디자인과 개발을 엮어 일관적인 UX를 제공하는 시스템/조직구조

컴포넌트 라이브러리는 개발에 한정적이라면, 디자인 시스템은 더 큰 범위

컴포넌트 라이브러리를 제작해야 하는 경우

• 단순 코드 레벨에서의 재사용을 커버하기 위한 정책이 필요한 경우

• 빠르게 개발해야 하는 경우

디자인 시스템을 제작 해야하는 경우

• 놀랍게도 디자인시스템을 제작해야하는 이유는 없다.

• 디자인 조직과 개발 조직이 대기업 수준이고 모두를 커버하는 아키텍처가 필요한 경우

• 그렇지 않다면 디자인 시스템은 오히려 독이며, 돈을 낭비하는 형태가 될 확률이 높음

• 또한 비즈니스의 힘이 너무 막강하여 오히려 역관계가 되어 시스템이 되지 않을수도 있다.

• 위의 대략적인 이야기를 커버할 수 있다면 개발하는게 좋다.

중요한건 대세를 따른다고 디자인시스템을 스타트업에서 개발하지 말 것을 추천

비즈니스 목표를 이루기 위해 디자인시스템이 있는것이지 비즈니스에서 디자인시스템 눈치를 보기위해 디자인시스템이 있는게 아니다.

디자인 시스템에 기대하는 것

형태 (style)

• 형태에는 정답이없다.

• 팀의 상황이나 개발 편의성에 따라 언제든지 달라짐

• 제약과 자유로움 중 적절함을 찾아야 한다.

제약된 스타일 (Constrain)

• 규칙이 정해져있어 원하는 값만 넘기면 알아서 컴포넌트가 나오는 형태

• 사용하기 쉽지만, 모든 케이스에 대해 대응하기 빡셈

자유로운 스타일 (Custom)

• 합성(컴파운드) 패턴을 통한 컴포넌트 조합으로 작성하는 방식

• 다양한 케이스에 대해 대응하기 쉽지만 사용하기 빡셈

타 서비스 디자인 시스템 둘러보기

• Adobe
• Material UI

디자인시스템 구조

디자인시스템 구조는 크게 8가지 구조로 나눌수 있다.

원칙 (Principles)

• 디자인과 개발에 대한 핵심 가치 및 지침

• 디자인과 관련된 지침뿐만 아니라 ESLint, CSS 및 Naming 규칙, 테스트 등 기술적인 규칙도 이에 포함됨

테마 (Theming)

• 색상, 타이포그래피, 그리드, 스페이싱 등과 같은 기본 디자인 요소에 대한 지침

• 디자인시스템의 토대가 되는 부분이라해서 파운데이션(Foundation)이라 부르기도 한다.

컴포넌트 (Components)

• 버튼, 입력 폼, 모달 등과 같은 재사용 가능한 UI 요소의 라이브러리

• 각 컴포넌트는 사용 방법, 목적, UI, 동작에 대해 문서와 함께 제공되는 경우가 많음

패턴 (Patterns)

• 여러 컴포넌트를 결합하여 만들어진 복잡한 사용자 인터페이스 요소

• ex: 검색 폼, 네비게이션 메뉴, 데이터 테이블, 옵션 필터 등이 패턴에 해당된다.

도구 및 유틸리티

• 디자인시스템을 실제 제품에 통합하기 위한 도구와 플러그인

• CSS Framework, 컴포넌트 라이브러리, 디자인 툴 플러그인 등

  • ex: Chakra UI, Radix UI, Panda CSS

문서화 (Documentation)

• 디자인시스템의 모든 요소를 사용하는 방법 등

• 버튼 컴포넌트는 어떤 파라미터를 전달받을 수 있고 어떻게 보여지는지 코드 스니펫 등

• Storybook, Nextra

가이드라인[지침 및 권장사항] (Guidelines)

• 좋은 사용성, 접근성 등의 가이드와 권장사항 등

• 웹 표준성

프로세스 및 워크플로우

• 디자인시스템 업데이트, 확장하는 것에 대한 프로세스

• 새로운 컴포넌트나 스타일을 디자인 시스템에 추가하려는 경우 검토 및 승인등의 프로세스가 구축되어있어야 함을 의미

유저 시나리오

디자인시스템 체크포인트

1. 디자이너와 개발자간의 커뮤니케이션 비용이 개발비용보다 크게 드는 경우

2. 프로덕트가 많아 전방위로 컴포넌트가 재사용되고, 디자인 일관성이 크게 중요한 경우

3. 컴포넌트를 전문적으로 유지보수할 인력(리소스)가 있는 경우

4. 브랜딩 철학이 있어 디자인에 해당 철학이 녹아들어가야하는 경우

5. 이미 컴포넌트 라이브러리 혹은 비슷한 것을 시도해본 경험이 있는 경우

OR 조건이 아닌 AND 조건, 아니라면 디자인 시스템은 시도하지 말기를?

디자인시스템으로 가는 첫 번째 걸음

디자인시스템을 개발할 때 고민해야하는 두 가지

1. 디자인시스템 개발자

   1. 개발자

   2. 디자이너

2. 디자인시스템 사용자

   1. 개발자

   2. 디자이너

   3. PM

디자인시스템을 구축하기 전, 명심해야 할 사항

디자인시스템을 사용하는 사람은 크게 세 분류로 나뉨

• 첫 번째로 디자인시스템을 이용해 개발하는 개발자

• 두 번째로 디자인시스템을 이용해 디자인하는 디자이너

• 마지막으로 디자인시스템을 이용해 기획을 만드는 PM

디자인시스템은 세 가지 방향성에서 사용할 수 있도록 고민해야 한다.

디자인시스템 개발자와 디저이너 입장에서만 고민하게 되면 안된다.

디자인시스템 사용자 관점에서 고민해보기

• 디자인시스템 적용이 필요한 앱/웹 커버리지 살펴보기

• 어떤 사용자가 어떤 고통을 겪고 있는가

  • 어떤 고통을 어떻게 해결해주어야 빠르게 해결이 되는가

• 고통을 겪는 개발자/디자이너/PM의 관점에서 고민해보기

  • 피그마 등의 디자인 툴에서 협업이 해결된다면 실제 컴포넌트 라이브러리를 구축하지 않아도 된다.

• 시작부터 엄청난 것을 만드려고 시스템을 견고하게 설계하지 말기

  • 시스템은 점진적으로 커가는 것, 처음부터 모든 시스템을 설계하려고 하지 말고 필요한 부분 부터

예시 1) 디자인이 자주 변경 되어서 개발이 따라가기 힘들어요

• 디자인에서 변경되는 것이 어떤 단위인지 체크 필요

  • 색상, 간격 등의 atomic한 요소인지

    • 색상, 간격 등의 요소를 피그마에서 분리하여 공통으로 사용할 수 있도록 제공

  • 레이아웃의 조합(패턴)이 많아지는 것인지

    • 레이아웃의 조합이 많아진다면 여러 최소화된 컴포넌트를 분리하고, 조합과 레이어를 둔다.

  • 디자인 툴의 여러 기능을 체크 (e.g. 피그마)

    • Variable

    • Dev Mode

    • Custom Plugins

예시 2) 디자인을 개발에서 개발할 때 싱크가 안맞는 경우가 많다.

• 디자인과 개발의 원활한 sync-up을 위해 자동화할 수 있는 여지를 체크하기

  • 디자인 툴에서 제공해주는 플러그인 기능 체크

  • "코어"와 "컴포넌트"를 분리하기

    • "코어"를 "값" 단위로 만들어서 자동으로 추출할 수 있도록 제공하기

    • e.g.) 실행시마다 플러그인으로 데이터를 가져와서 기존 값을 덮어쓰기

  • 배포될 때 최종적으로 validation 하는 스크립트 짜기

  • 툴 등에서 버전관리가 될 수 있도록 하기

예시 3) 컴포넌트는 잘 분리되어 있는데 기획서랑 정책이 충돌이 일어난다.

• 기획서를 작성하는 PM이 프리뷰나 정책을 쉽게 만들 수 있도록 도큐먼트 제공하기

  • Docusaurus, Nextra 등 현재 스펙에 맞는 간단한 문서 제공

  • 이를 가이드라인이라고 제공하여, 플레이그라운드 제공

    • 해당 플레기으라운드로 PM이 스크린샷 만들 수 있도록 제공

  • PM이 디자인 툴까지 다루는 경우 원자단위 컴포넌트 제공 X

    • 충돌이 많이 발생하기 때문

    • 조합된 컴포넌트만 제공할 수 있도록 하기

디자인시스템으로 가는 두 번째 걸음

디자인시스템은 현재 비즈니스 상황에 따라 개발 방법론 부터 리소스 사용 방향까지 모두 다를 수밖에 없다.

1. 탑 다운이 강제된 조직의 경우

   1. 비즈니스 조건 상 수익을 올리기 위한 상위의 결정대로 움직여야 하는 경우

2. 애자일 조직의 경우

   1. 목적 단위로 성과를 이루기 위한 팀 단위로 빠르게 움직이는 경우

비즈니스 상황에 따른 디자인시스템의 니즈

• 조직마다 다른 비즈니스 개발의 형태, 디자인시스템이 비즈니스 형태에 어떤 영향을 끼치는지 알아야 한다.

  • 현재 비즈니스 형태에 따라 디자인시스템의 커버리지가 넓어질수도 있고 좁아질 수도 있기 때문

사례 1. 탑 다운이 강조된 업무 형태 상황

상위 혹은 사업의 업무 요구 -> PM/PO의 정리 및 기획서 작성 -> 디자인 -> 개발 -> 완료

개발: 여러 상황을 커버할 수 있는 디자인 컴포넌트 라이브러리의 중요성 대두

디자인: 상위의 여러 요구사항을 커버하며 디자인 일관성을 가진 디자인시스템의 필요

PM: 상위 의사결정을 빠르게 정리할 수 있는 여러 도구의 필요

상위의 의사결정이 빠르고 빈번하게 일어남에 따라 UX/UI를 통일하면서 속도를 낼 수 있는 무언가가 필요

사례 2. 애자일 형태의 목적을 해결하는 조직

해당 조직의 경우 조직 내의 문제를 해결하기 보단, 전사적인 문제점을 바텀업해서 정제하고 해결을 위한 결정이 되었을 확률이 높다.

목적을 빠르게 달성하기 위한 중앙화된 시스템에 대한 니즈로 결정이 되었을 것 해당 문제를 해결하기 위한 애자일 조직이 마련되고 시스템 고도화 진행

빠르게 돌아가는 여러 애자일 조직에서의 공통 문제를 해결하는 중앙화된 디자인시스템 필요