2023. 6. 16. 01:22ㆍ기록/UXUI 스터디
🎁 9일차 주제: 디자인 시스템
- 디자인 시스템을 시작하는 효과적인 접근 방법과 유지/변경하는 방법
- 디자인 시스템 구성 원리 (ex. Atomic Design)
- 국내외의 좋은 디자인 시스템 소개 및 분석
- 스타일 가이드, UI 패턴 라이브러리 등 디자인 리소스를 관리하는 다른 방법과 디자인 시스템의 차이
_ 디자인 시스템을 실제로 구축하고 유지하기 위한 툴들
- 디자인 시스템이 프로덕트의 전반적 UX와 비즈니스 목표에 기여하는 방식
- 기타 등등, 디자인 시스템과 관련된 아티클이라면 무엇이든 좋아요.
내가 필요해서 정리한 디자인 시스템에 관한 모든 것
어떤 툴을 사용해야하는지, 라이브러리를 써도 되는지, 추후에 수정 및 관리는 어떻게 하는지 궁금한게 참 많아지더라구요. 그래서 정말 수십 개의 글을 읽고 수십 명에게 물어본 것들을 정리한
medium.com
[디자인 시스템이란?]
- 팀원들이 제품을 디자인, 실현, 개발할 수 있도록 하는 모든 요소들을 묶는 하나의 진실의 원천
- 팀이 브랜드에서 일관되게 느껴지는 프로덕트와 디지털 경험을 만드는 방법
- 일관된 제품 및 웹 설계를 위해 공유 언어를 제공하는 ‘재사용 가능한’ 구성 요소, 원리 및 지침 집합
[디자인 시스템이 필요한 이유]
- 프로덕트와 인터페이스의 일관성
- 크로스 펑셔널한 협업 가능
- 디자인/개발 속도와 확장성 -> 조직의 시간, 비용 절약
[디자인 시스템 구성 요소]
디자인 시스템은 단순히 패턴 라이브러리나 스타일 가이드가 아니다
- 디자인 원칙(Design principles)
- 스타일 가이드 (타이포, 색상,아이콘 등)
- UI 컴포넌트 라이브러리 (버튼, 위젯, 등)
- 디자인 프로세스 가이드라인
[디자인 시스템 제작 시 유의사항]
- 제품이 발전함에 따라 디자인 팀은 새로운 UXUI를 추가한다
- 디자인 원칙을 기반으로 구축하면 일관된 언어를 유지하는데 도움된다
- 엄격함과 유연성 사이에서 밸런스를 찾는 게 중요하다
- 효과적으로 공유하고 운영하기 위해서는 프론트엔드 인프라 구조를 포함해야 한다
[디자인 시스템 설계 가이드]
- 기존 사용하던 컴포넌트와 디자인 확인
- 다른 디자인 시스템 사례 리서치
- 컴포넌트 리스트로 정리
- 타임라인 계획
- 컴포넌트에 관해 리서치 하고 토론
- 컴포넌트 제작
- 디자인 시스템 공유 및 관리를 위한 디자인
- 디자인 시스템 구현
[디자인 시스템을 위한 툴]
- 아티클 작성자의 지인들에게 물어본 결과 피그마+스토리북 조합이 가장 많았다
- 프레이머나 UXPin은 실제 리액트 코드로 변환해서 볼 수 있어 개발까지 걸리는 시간을 줄여주고, 개발한 코드를 디자인 할 때 재사용할 수 있게 하는 툴이다
-> 이론적으로는 가장 최상의 툴이지만, 디자이너에게는 자유도가 낮고 러닝커브가 상대적으로는 높다는 단점이 있다
[공유 및 관리를 위한 툴 : 개발한 컴포넌트를 가시화하고 도큐멘테이션을 공유하기 위한 툴]
- 스토리북, 인비젼 DSM, 제로헤이트
[라이브러리 사용 vs 자체 디자인 시스템 제작]
대부분 자체 디자인 시스템을 제작하고 있다
- 고도화된 라이브러리를 커스터마이징 해서 사용하는 경우의 문제점
: API 확장 시 자체 디자인 시스템과 맞지 않는 경우가 생긴다. 확장 시 원본 컴포넌트에 의존성이 생긴다 - 라이브러리에 따라 컴포넌트 수정, 속성 추가가 어려운 경우가 있고, 디자이너가 만들고자 하는 형태로 커스텀 하기 어렵다
- 라이브러리를 Fork해 수정된 버전을 사용해도, 라이브러리 코어에 버그가 발견될 경우 일일이 업데이트 해야한다
- 라이브러리에 없는 컴포넌트가 있을 때 완전히 새로 구현해야 한다
-> 서비스 복잡도가 현저히 낮다면 고도화된 라이브러리를 사용해서 제작해도 괜찮다.
-> 복잡도가 높거나 브랜드 보이스가 담긴 프로덕트를 구축하고 싶다면 자체 디자인 시스템 제작이 좋다
[느낀점]
디자인 시스템 자체에 대한 내용보다 회사의 입장을 같이 생각해서 작성한 것이 현실적으로 많이 도움이 될 것 같았다. 누구나 디자인 시스템을 체게적이고 퀄 높게 제작하고 싶지만, 현실적으로는 업무 상황상 어려운 경우가 대부분이다. 또한 개발팀을 비롯해 타 부서와 함께 사용되어야 하는 것은 생각만큼 쉽지 않기 떄문에 현실적으로 고려되는 동시에 중요 내용만 잘 정리되어 있어서 다음에 실무에서 디자인 시스템을 설계해야할 필요가 있을 때 이 아티클을 참고해서 제작해 보고 싶었다.
디자인 시스템 사례 모음
https://pixso.net/kr/skills/design-system/
디자인 시스템의 정의와 중요성, 실제 사례 10가지
본문에서는 디자인 시스템이 무엇인지, 왜 기업들이 시간을 들여 디자인 시스템 구축을 어떻게 하는지, 디자이너에게 영감을 주는 열 가지 실제 디자인 시스템 사례를 알아보겠습니다.
pixso.net
해당 아티클에선 디자인 시스템의 필요성과 영감을 얻게해 줄 9가지 사례들을 다루고 있습니다.
(1가지가 더 있었는데 홍보성이 보여서 제외했습니다)
[왜 회사들은 디자인 시스템을 만들까?]
- 디자인 시스템은 공통의 언어, 시각적 일관성을 만들어 반복되는 작업을 줄인다
- 제품 제작 초기에는 기업마다 만든 디자인 규칙이 잘 이행되지만, 시간이 지나면 규칙을 지키지 않는 경우가 많아진다
- 디자인 시스템 가이드를 활용하면 혼란을 방지하고 효율적인 작업이 가능하다.
[Top 영감을 얻기 위한 디자인 시스템 사례]
1. 구글 머티리얼 디자인
: ‘Material’에는 ‘물지적인’, ‘재료’ 등의 뜻이 담겨있다.
: 질감이 느껴지는 표면, 선명한 그래픽, 자연스러운 애니메이션 등 물리적으로 실제와 비슷한 디자인을 구현하족자 하는 것이 구글 디자인 시스템의 지향점이다.
2. 마이크로소프트 풀루언트
: 스마트폰, 데스크톱, 태블릿 등 다양한 디바이스에서 동일한 사용자 경험을 제공하기 위한 디자인 시스템 가이드이다.
: 빛, 깊이, 움직임, 재질, 규모라는 5대 구성 요소로 이루어져 있다.
3. 에어비앤비
: 디바이스와 해상도에 상관없이 동일한 디자인 적용’을 목표로 디자인 시스템 구축을 이뤘다.
: AOS, IOS 가이드 라인을 따르는 대신 모든 디바이스의 UI를 통일시킨다.
(모바일 사용자 수가 급격히 많아지면서 웹에서 모바일 우선으로 변경했다고 한다)
4. 토스 디자인 시스템
: 여러 시행 착오를 통해 디자인 시스템을 구축, 1000시간을 절약했다고 한다.
5. 아틀라시안
: 상세한 시스템 설계 패턴, 스케치의 UI 자산 라이브러리 등으로 구성되어 있다.
6. 라인 디자인 시스템
: 19개 언어로 제공되는 서비스로, 각국 라인 디자이너들이 사용자에게 동일한 라인 디자인의 가치와 원칙을 전달하는 시스템을 만들게 하자 라는 목표로 제작된 디자인 시스템 가이드이다.
: 핵심 가치는 사용자의 대화 경험을 중요하게 다루는 것이다
7. IBM 카본
: IBA의 Accessibility Checklist를 준수하고, 접근성에 영향 받는 사용자(시력 저하자 등)을 위한 경험 디자인을 적용하는 것이 특징이다.
8. 아우디
: 앱에서 찰야까지 사용자가 다양한 솔루션과 균형 잡힌 시스템을 경험하는 것을 목적으로 디자인 시스템이 제작되었다
9. 어도비 스펙트럼
: 어도비가 제공하는 디자인 킷을 모은 서비스이다.
-> 그 외 사례 모음 링크를 찾게 되었다 : https://wildpuppy.tistory.com/entry/%EB%94%94%EC%9E%90%EC%9D%B8-%EC%8B%9C%EC%8A%A4%ED%85%9C-%EC%8B%A4%EC%A0%9C-%EC%82%AC%EB%A1%80-%EA%B4%80%EB%A0%A8-%EC%82%AC%EC%9D%B4%ED%8A%B8-%EB%AA%A8%EC%9D%8C-Design-System
다른 참여자들의 아티클 공유
[구글 Material Design 3의 디자인 토큰 개념]
https://m3.material.io/foundations/design-tokens/overview
토큰은 글꼴, 간격, 색상 등 디자인과 관련된 각종 값들을 추상화하고 체계적으로 관리하기 위해 도입된 개념이라고 합니다. MD3에서는 토큰을 레퍼런스 토큰, 시스템 토큰, 컴포넌트 토큰으로 구분해요.
예를 들어 시스템 토큰은 "디스플레이용 폰트의 굵기"라는 식으로 시스템 차원에서의 의미를 담는 이름을 쓰고, "레귤러 굵기"라는 이름의 레퍼런스 토큰을 가리킵니다. "레귤러 굵기"라는 레퍼런스 토큰은 "400"이라는 구체적인 값(또는 다른 레퍼런스 토큰)을 가리킵니다.
값을 직접 쓰는 대신 이런 식으로 의미에 따라 계층적으로 나누어 추상화하면 전체 디자인의 일관성을 높이기 쉽고, 수정이 용이해지며, 여러 시스템(예: 안드로이드, iOS, 윈도 등)에 쉽게 대응할 수 있고, 다크모드/고대비모드/저시력자용 큰 글씨 모드 등 다양한 모드를 지원하기도 쉬워진다고 해요.
[Line 디자인 시스템 제작 과정]
https://engineering.linecorp.com/ko/blog/line-design-system
LINE 디자인 시스템을 만든 고민의 과정과 결과물이 담긴 아티클을 읽었습니다.
디자인 시스템은 UX 가이드뿐만 아니라 브랜드에 대한 철학이 포함되어야 한다는 부분이 인상 깊었습니다. 그리고 구성원이 사용하지 않는 디자인 시스템은 무용지물이기 때문에 어떤 구성원이 어떻게 사용하는지에 대한 고민이 선행되어야 하며, 업데이트 후 구성원과의 소통이 중요하다는 내용을 담고있습니다.
[Headless Design System]
https://brunch.co.kr/@kja0717/23
피그마 플러그인 ‘Tokens Studio for Figma’를 통해 Headless Design System의 개념과 디자인 시스템을 만드는 방식을 설명하고 있습니다. (텍스트로 열심히 정리하긴 했는데, 해당 글의 이미지와 같이 보면 더욱 이해가 쉬울 것 같습니다!)
<Headless Design System>
Headless Design System은 시각적 디자인과 컴포넌트의 기능을 분리해 각각 독립적으로 개발한 디자인 시스템을 말한다고 해요. 예를들면, Headless Component(버튼 모양) + Design Tokens(버튼 컬러) = Themed Component(완성된 버튼)이 되는 방식이에요!
<Design Token>
Headless Design System에서 Design Token은 시각적 디자인 속성에 대한 정보를 갖고 있는 재사용 가능한 작은 정보 조각입니다. 여기에는 색상, 간격, 타이포그래피, 크기 등의 관리가 가능하다고 해요.
<Semantic Token, Option Token>
Semantic Token은 Design Token의 Core Token을 참조하고 있는 상태에서 버튼의 디자인 일부를 변경하고 싶을 때, 사용한다고 합니다!
<Component Specific Token>
Headless Design System에서는 Component Specific Token도 필요하다고 해요. 이 토큰은 어떤 컴포넌트가 어떤 값을 사용하는지 구체적으로 표기한다고 합니다. 이 토큰은 Sementic Token을 참조한다고 해요!
이렇게 디자인 시스템이 3개의 토큰을 가지게 되면 여러 개의 테마를 만들어 UI에 적용할 수 있다고 합니다.
Headless Design System은 하나의 파일 안에 다수의 컴포넌트들을 관리하는 방식(Single file components)으로 사용하면 관리가 간편하고, 피그마 파일과 코드 라이브러리가 동일한 구조를 가지고, 피그마 파일에서 발생하는 성능 이슈를 겪지 않아도 되는 3가지의 강점을 가진다고 해요! 좀 어려운 개념들이긴 한데, 이런 개념들도 알아둔다면 디자인들을 시스템화 할 때 도움이 될 것 같아요
[디자인 시스템 구축기]
https://brunch.co.kr/@besigner/4
✅ 디자인 시스템이란?
디자인 원칙과 규격, 재사용할 수 있는 UI 패턴과 컴포넌트, 코드를 포괄하는 시스템.
✅ 디자인 시스템의 종류
1️⃣ UI 가이드라인 (스타일 가이드)
👉 UI를 표준화하고 화면 간의 일관성을 확보하기 위한 가이드. 주로 화면에서 사용되는 공통 UI 패턴과 주요 컴포넌트를 추출해서 정의함.
2️⃣ UX 가이드라인
👉 서비스와 브랜드 측면에서 사용자가 일관적이고 차별화된 경험을 하도록 만든 가이드. 해당 서비스의 정체성을 담은 기능 정의, 네이밍, 어투, GUI 요소 정의함.
✔️ 디자인 시스템은 1번처럼 스타일 가이드만 포함할 수도 있고, 2번까지 통합해서 UX 원칙에 이르는 철학까지 포함할 수도 있음.
✅ 디자인 시스템이 필요한 이유
1️⃣ 정해진 디자인 패턴과 컴포넌트를 재사용해서 제품을 구축하고, 개선하는데 시간 단축.
2️⃣ 제품의 인터페이스가 일관성 유지. 일관되지 않은 UI는 사용자 경험을 해침.
✅ 디자인 원칙
1️⃣ 명확하게 : 누구나 쉽게 이해할 수 있게
2️⃣ 간결하게 : 꼭 필요한 요소만, 사용자가 목적지에 빠르게 도달할 수 있게
3️⃣ 일관되게 : 빠르게 적응하고 쉽게 사용할 수 있도록 일관된 경험 제공
4️⃣ 유용하게 : 데이터를 바탕으로 근거있는 의사 결정
[디자인 패턴을 먼저 구축하는 것이 더 좋은 작업 방식이다]
https://www.smashingmagazine.com/2023/05/design-patterns-collaborate-design-system/
여기서 말하는 디자인 패턴이란, 목적에 따른 재사용 가능한 조합인데요. 예를 들면 TV앱에서의 타일 View, GA같은 데이터 분석 툴에서의 대시보드 미터 등이 있습니다. 여기까지 읽었을 땐 저도 감이 잘 안잡혔는데 아티클 하단에 가상의 서비스를 예로 들며 설명한 걸 읽으니 이해가 가더라구요.
여행갈 때 함께 가는 사람들이 계획을 제안하고 투표할 수 있도록하는 서비스를 만든다고 하면, Person이라는 패턴이 나올 수 있습니다. 계획에 투표하는 '사람'에 관련된 패턴입니다. 이 패턴에 필요한 요소들 -프로필 사진, 이름, 이 사람이 할 액션- 을 정리하면 이게 하나의 디자인 패턴이 됩니다.
이런 패턴을 모아모아 페이지를 만들어 관리하는 겁니다. 디자인 패턴을 기반으로 한 시스템 제작의 장점은 모두가 병렬적으로 작업이 가능하단 건데요. 예를 들면 person 패턴을 구현하던 개발자가 '이 요소가 더 필요하겠는데요?' 하고 제안하면 디자이너는 곧바로 시안에 업데이트할 수 있어서 hand-off의 과정이 필요없습니다. 다같이 동시에 작업하기 때문에 최종 시안이 더 빨리 완성됩니다.
또 이런 패턴을 라이브러리화 함으로써 재사용이 잘 되고 있는지 체크할 수도 있고요. 즉, 디자인 시스템의 성과를 정량적으로 측정할 수 있습니다.
디자인 패턴으로 만드는 시스템의 가장 중요한 전제는, 디자인 패턴은 제품의 고유한 경험을 기반으로 해야한다는 겁니다. (Product-specific)
잘 만든 컴포넌트가 디자인 시스템의 가치를 증명해주진 않는 것 같습니다. 제품의 경험을 좋게 만들어주지도 못하고요. 하지만 제품에서의 사용자 경험을 기반으로 한 디자인 패턴은 경험을 개선시켜줄 수 있는 것 같습니다~
이 아티클을 읽고 그럼 아토믹 디자인에서 말하는 organism과 다른게 뭐지? 하고 생각해봤는데요. organism은 단순히 molecule을 조합한 것이고, 디자인 패턴은 목적/맥락/사용성 등을 고려해서 만든 것이기 때문에 작은 것->큰 것 / 전체 -> 작은 것 으로, 서로 발산하는 방향이 다른 것 같다고 생각했습니다.
규모가 큰 집단의 디자인 시스템에는 적용하기 어렵겠지만, 디자이너가 한두명인 조직에서는 시도해볼만한 방법론인 것 같아요!