서론: 디자인 시스템
1. 디자인 시스템은 컴포넌트를 새롭게 만들거나, 개선을 하기 위한 조직화된 요소들의 집합체로, 디자인 원칙과 규격, 재사용이 가능한 디자인 패턴과 컴포넌트, 개발 코드 전부를 포괄하는 시스템이다.
2. 디자인 시스템을 통해 디자이너는 동일한 형식의 디자인을 제작하고, 개발자 또한 동일한 패턴의 코드를 작성해 일관적인 사용자 경험을 제공하는 서비스를 만들 수 있다.
3. 단순 스타일 가이드, 패턴 라이브러리 역할만 하는 디자인 시스템과 브랜드 원칙, UX 원칙에 이르기까지 하나의 철학을 구성하는 시스템이 있다
디자인 시스템 형식의 대한 설명글:
1. 디자인 시스템의 목적과 예시
목적:
1.
공통적인 디자인 자산
•
디자인 가이드라인과 시스템은 문서의 형태로 구성원들의 이해도 싱크를 맞추는 역할을 할 수 있다.
•
시스템을 운영하며 공동의 지식 자산을 쌓고 그 안에 있는 윈칙과 설계를 확장하고 정립한다.
2.
일관된 정체성과 사용성 유지
•
서비스 내 브랜드 아이덴티티를 일관되게 전달할 수 있다.
•
유저에게 통일되고 정돈된 디자인을 전달하여 사용성이 높아지고 제품의 가치도 올라간다.
3.
커뮤니케이션 기준점 정립
•
디자인 시스템은 여러 부서나 팀 간에 언어와 기준을 통일하여 커뮤니케이션 리소스를 줄일 수 있다.
행복한 예시 :
:•
디자인 가이드와 시스템을 디자인 근거 자료 및 검증 도구로 사용하며, 구성원들의 작업물을 자가 점검하여 완성도를 높일 수 있다.
•
새로운 인원이 충원될 경우, 실무에 쉽게 참여할 수 있는 온보딩 가이드로 사용할 수 있다.
예시:
[WEB] 디자인 시스템 문서 리스트
[MOBILE] 디자인 시스템 문서 리스트
2. 적용 방식
설계 가이드
디자인 시스템 설계 순서
아토믹 디자인 방식 (Atomic Design Pattern)
시멘틱 네이밍 (Semantic Naming)
도입에 필요한 일
1.
디자인 시스템을 전부 정리하기엔 규모가 방대하여 현실적으로 패턴 라이브러리 형식으로 먼저 적용하는 것이 기존 업무에 영향을 미치지 않을 것으로 예상.
•
설계 가이드 3-b 부터 적용
2.
디자인 시스템 도입 전 정리할 부분:
•
기존 asset (icon, image) 및 코드 정리
•
날짜, 시간 형식 적용하는 코드 정리
•
사용하는, 하지 않는 아이콘 정리
•
모바일 레이아웃 기준점 재정리
→ 사용하지 않는 코드를 미리 제거함으로서 추후 혼란을 줄일 수 있다
3.
컴포넌트 제작 시 필요한 작업:
•
어떤 컴포넌트를 정의할지 결정했다면 컴포넌트별로 어떤 내용을 담을지 결정한다.
◦
컴포넌트가 무엇인지, 어떤 종류가 필요한지, 디자인 스펙이 어떻게 되는지 등 정리 후, 코드를 추가한다.
◦
중복되는 역할을 가진 컴포넌트 뽑아내기
◦
뽑아내서 통합 후, props로 줄 수 있는 variation 구분
버튼 예시
•
효율성 확장성을 고려하며 각 컴포넌트의 레이블링 과정
•
설계 가이드 3~4 적용
4.
디자인 시스템 도입 KPI
METRIC | MEASUREMENT | VALUE |
협업 효율성 | 기존 스프린트 기간 동안 걸리는 시간과 디자인 시스템 도입 후 걸리는 시간 비교 | - 폰트, 컬러 등 foundation에 신경쓰지 않는다
- UI 개발 시간이 단축된다
- 같은 시간 대비 더 많은 업무를 진행할 수 있다
- 새로운 디자인과 기존 디자인간의 괴리가 줄어들고 디자인 적용이 빨라진다. |
시장 목표 지점 도달 지표 | 프로젝트 프로토타입이나 릴리즈까지 도달하는 기간이 마일스톤이나 로드맵에 미치는 영향 확인 | - 디자인 시스템 도입 시, 컴포넌트로 따로 테스트를 진행할 수 있다. 따로 테스트를 진행할 경우 개발 시작 전 논의하는 시간이 생겨 커뮤니케이션 리소스를 줄일 수 있다
- 프로젝트 시작 후 완성본을 보고 QA 하고 논의하는 기점이 가까워진다 |
코드의 미치는 영향 확인 | 프론트엔드 쪽에서 프로젝트 시작 시 작성하게 되는 코드의 양을 비교한다
집중하는 코드의 성격을 비교한다 | - UI 개발에 작성하게 되는 코드의 양이 줄어든다
- 로직적인 부분에 더 집중할 수 있어 코드의 완성도가 높아진다 |
프로세스 정립 유의할 점:
3. Plan of Action
•
회의 후 각 역할 별로 Plan of Action을 정리한다.
디자이너의 아젠다
프로덕트에 쓰이는 디자인 스타일을 카테고리별로 수집
•
아이콘
•
타이포그래피
•
헤더
•
바텀 네비게이션
•
버튼
•
모달
반복적 사용 요소에 대한 파악과 카테고라이징
- 컬러 (primary,secondary,point | 시멘틱 네이밍 - light,dark0~900)
- 순서&사이즈&형태 (primary,secondary | large,regular,small,가변 | round - 현재는 단일)
- 상태 (default, disabled)
- 추가 베리에이션 (아이콘 등등)
1번의 스타일을 2번 내용에 맞추어 디자인 수정 (일정 조정 필요)
디자인 수정과 함께 개발단 일정 조정 후 부분 or 일괄 적용
시스템에 포함되지 않는 스타일과 컴포넌트는 스프린트가 끝날때마다 정리한다. (parent or instance로 관리할지에 대한 판단은 이때 하기로)
디자인 시스템 추가 레퍼런스
개발자의 아젠다
•
안 쓰는 부분을 추려내서 전달 → 현재 디자인에 저장되어 있는 요소 중 대체할 수 있는지 확인 후, 대응 → 수정
•
디자인 토큰은 개념부터 정리되어 규모가 굉장할듯
•
현실적으로?
◦
컬러 중 하드코딩의 부분만 정리한다 step1
◦
그 이후 토큰화 + 토큰 계층화? → 추후 확인 필요
•
스타일가이드 형식의 예시 (상세한 부분) 가져오기 → 당장 가져올 수 있는! (피그마 파일?)
•
다크모드 관련 → 스타일 가이드에 어떻게 정리하는지
◦
색상을 따로? 컴포넌트를 따로? → 개발 적용 방식까지 포함
4. 디자인 시스템에 적용할 수 있는 툴
스토리북:
•
디자인 시스템에서 UI 요소들을 관리할 수 있는 툴. 비즈니스 로직으로부터 분리된 UI 컴포넌트를 만들 수 있다.
장점
단점
예시