[아티클 프로젝트 042] NAVER FE devtalk: 디자인 시스템에 대한 소개와 효율성 개선 및 구축 경험공유 - 플랫폼 디자이너 없이 디자인 시스템을 구축하는 프로덕트 디자이너의 우당탕탕 고통 연대기

플랫폼 디자이너 없이 디자인 시스템을 구축하는 프로덕트 디자이너의 우당탕탕 고통 연대기

 

가이드를 만들기로 결심

• 플랫폼마다 사용자 UI/UX 다름
• 업무 용어의 통일성이 없었음
• ===> 디자이너가 하나의 프로덕트에 고립되게 되는 현상

 

! 플랫폼의 공통사항을 정리하자

Style Guide 개선이유

• 사용성을 더 좋게 개선하자.
• 커뮤니케이션이 더이상 발전하지 않았다.
• 디자인 원칙을 세우자! (문법과 어조를 추가로 통일, 정리하자)

 

디자인 시스템

- 두가지 시스템을 예시로 들수 있다.

1. UX, Style Guide, Code가 왁벽한 가이드

2. Code가 빠져있는 가이드

 

스타일 가이드 장점

• 확장성이 있어서 커뮤니케이션 비용이 줄어든다.
• 일관된 사용성
  • 새로운 디자인을 할 때, 스타일 가이드를 토대로 재사용에 대한 근거가 됨 ("기존에 사용되고 있었다")
• 사용자 경험 디자인에 집중할 수 있음
  • 기본 값이 정의되어있기 때문에 흐름에 대한 디자인이나 추가적인 경험에 대한 디자인을 할 수 있는 시간이 확보됨
• 신입도 같은 결과물을 생성할 수 있음

 

스타일 가이드 단점

• 해당 가이드를 만들기 위한 리소스

 

다른 직군과의 커뮤니케이션을 위해

• 디자인 중심적으로 글 작성하지 않기
  • 간결, 쉽게, 일관성, 신뢰성
• 글 구성 템플릿화
  • 개요, 종류, 구성, 상태

  

• 관리
  • 해당 컴포넌트별 담당자를 나누어 오너쉽을 가진다.
    • 디자이너별로 리뷰하기

 

디자인 관리 툴

Sketch ----> Figma ----> zeroheight

Sketch는 로컬기반이라 실시간 공유이 어려웠다.

Figma는 클라우드 기반이라 여러명이 공유하면서 작업하기 쉬웠다.

 

zeroheight 

+ 개발자 도움없이 code snippet 추가 가능

 

 

+디자인 가이드를 만들때 프론트엔드 개발자도 고통을 받는다.

 

 

Q&A

1. 기존 시스템 디자인가이드를 만드는가? 리뉴얼에 적용하기 위해 만드는가?
   • 기존 시스템에 추가하기 위해 만들고 있다.
2. 성과 측정
   • Figma에서 가장 높은 단계의 플랜을 사용하면 어떤 컴포넌트가 가장많이 사용되는지를 확인할 수 있다고한다.
3. 커뮤니케이션 효율성에 대해 어떻게 설득하는가
   • 용어정리
   • 아이콘 디자인의 재활용
   • 설득이 필요없을 정도로 효율성을 느끼고들 있다.
4. 서로의 의견을 수렴하는 과정
   • 원칙을 정할때 동의를 기준으로 함
   • 시스템 대의를 만듬
   • 토론
5. 예외케이스 관리
   • 발생 정의, 정리 후 팀내 논의

 

---

NAVER FE devtalk: 디자인 시스템에 대한 소개와 효율성 개선 및 구축 경험공유

https://d2.naver.com/news/4194542

 

플랫폼 디자이너 없이 디자인 시스템을 구축하는 프로덕트 디자이너의 우당탕탕 고통 연대기

https://tv.naver.com/v/15841749