생각
- 디자인 시스템 만들기란 업무가 주어져서 관련 자료를 서치해보았다. 자주쓰는 ui 요소 일부만 컴포넌트화 해도 엄청 편리한데, 이런 것들을 총 망라해 시스템화해두면.. 사실상 ui 를 그리는 작업 자체에는 디자이너가 거의 필요 없어질 것 같다. ux 자체도 기본적인 동작에 대한 규칙은 정해질 것이니, 더 세밀한 기획을 하게 될지도.
정리
- 디자인 시스템은 프로덕트와 브랜드의 구성요소를 관리하면서 진화하는, 계속 발전하는 규칙 세트다.
- 개발자가 디자인 시스템을 활용하기 위해선 시스템이 코드로 구현되어야 한다.
- 디자인은 인터페이스 설계에서 서비스 경험까지 확장되고 있지만, 기존 디자인 시스템은 인터페이스와 개발에만 집중하는 느낌이다. 브랜드 철학과 사용자 경험, 화면 단위의 구성요소가 하나의 흐름으로 부드럽게 이어진다는 느낌을 주어야 한다.
- UI 가이드라인과 UX 가이드라인과, 디자인시스템은 다른 것?
- UI 가이드라인, UI 를 표준화하고 화면간 일관성을 확보하는 것이 목적. 공통 UI 패턴과 주요 컴포넌트를 추출해 정의하고 상세 속성을 규정하여, UI/GUI 디자이너와 개발자가 정해진 기준에 따라 UI 설계를 할 수 있도록 한다. - 디자인 컴포넌트가 다른 것이 생기면 그것을 다시 만들고
- UX 가이드라인, 콘텐츠나 기능에 따라 사용자 행동과 니즈를 반영해 ux 원칙을 도출한다. 브랜드 측면에서 보면 더 넓은 범위를 아우른다. 기능 정의, 네이밍, 어투, ui/gui 적 요소 정의
- 디자인 시스템, 디자인 원칙, 규격, 다시 사용할 수 있는 ui 패턴과 컴포넌트, 코드를 포괄하는 종합 세트. 단순 스타일 가이드, 패턴 라이브러리 역할만 하는 시스템도 있고, 브랜드 원칙, ux 원칙에 이르기까지 하나의 철학을 구성하는 시스템도 있습니다.
- 디자인 가이드라인, 디자인 시스템이 필요한 이유, 공동의 디자인 자산 확충, 팀의 규모가 커질수록 싱크를 맞는 게 어렵다. 우리가 어떤 컴포넌트와 스타일을 사용하는지 등.. 그것이 문서든 툴킷이든 공동 지적 자산으로서 존재해야 한다.
- 커뮤니케이션 기준 마련, 여러 부서나 팀 간의 언어와 기준을 공유해 커뮤니케이션에 있어 오해를 줄여준다. - 필요
- 디자인 가이드라인을 만드는 시점, 제품/기능의 확장, 새로운 시장 진출, 채널 매개채 확장.. 등 기존 서비스를 바탕으로 다른 타입, 혹은 버전을 만들어야 할 경우.. - 현재 우리는 이런 상황은 아니다.
- 좋은 디자인 가이드라인이란, 내용이 좋은 가이드라인. 어디서나 볼 수 있는 당연한 이야기말고, 우리 도메인이기 때문에 지켜야 하는 원칙을 제시. 실무단의 인풋과 사용자 연구가 바탕이 되어야 우리 제품의 철학, 형태, 기술에 근거한 내용이 나올 수 있다. 추상적 원칙만 나열하는 것이 아니라 구체적인 요소까지 하나의 흐름으로 연결해야 한다.
- 탐색이 편리해야 한다. 목차 구성이 탐색에 큰 역할을 한다. 한눈에 전체 맥락이 이해되고 내용을 대략 예측할 수 있어야 한다. 목차 단계별로 내용의 수준이 일률적이어야 한다. 추상적인 개념과 구체적인 디테일을 분리한다.
- 가이드라인에 정체성으 부여할 수 있다. 동료와 이야기하듯 이해하기 쉽고 친근한 느낌일 수 있고, 사실과 원칙을 객관적으로 적시해 신뢰성을 높인 교과서 느낌일 수 있다. 이 가이드라인을 볼 사람, 예상 독자를 고려해야 한다.
- 잘 구축해도, 흐지부지 되기 쉽다. 업데이트되지 않거나 실무에 활용하지 않거나. 어떤 주체가 프로세스 가이드를 관리하고 시스템에 업데이트할지 정의해야 한다.
- 디자인 시스템의 정량적 평가, 개발 구축 완료 후 배포까지 하고, 이전과 이후의 시간을 비교해서 개발 효율을 수치화 한다..? 시스템 구축은 천천히.. 꾸준히 해야 한다는 결론
- 기본적인 순서, 프로덕트 디자인팀의 선행 연구, 조사.. 시스템 구축 확정하고, 시작 컬러, 타이포 - 아이콘, 그래픽 - 버튼 - 태그 .. 순으로 진행
- 의미론적 컬러 시스템, hex 값이 아니라 사용되는 목적과 적용되는 ui 에 따라 네이밍하고 시스템화하는 것 의미. 배경색에 적용되는 #FFFFFF 를 White 가 아닌 Background 라고 정의하듯이.
- 컴포넌트 네이밍 룰, 꼭 필요한 정보만 넣어 이름의 길이를 최대한 줄인다. 네이밍 규칙 예시 size_type_button[theme]. 3가지 사이즈와 3가지 타입으로 구분, large, regular, small 사이즈 구분하고 fill, line, text 로 타입 구분. large_fill_button[blue], large_fill_button[gray] 등등
- 컴포넌트, 각 버튼마다 고정 속성과 가변 속성을 구분. 고정 속성은 Origin 으로 정의 높이만 고정하고 너비는 기기 비율에 따라 번경된다면 높이만 고정으로 둔다. origin 속성중 하나라도 다르면 새로운 버튼 컴포넌트로 구분한다. Theme 에 따라 달라지는 속성을 Option 이라 정의한다. 컬러와 같은?
- 디자인 시스템은 장기 프로젝트라 기존 단기업무 중심의 프로세스에서 정상적으로 진행되기 어려울 수 있다.
- 버튼 개발이 아니라 컴포넌트 구축이라는 너무 큰 개념을 잡고 있다?
- 컴포넌트 구축 프로세스, 기획 - 킥오프 - 검토 - 제작 - 정리
- 기획 - 정의, 개발하고자 하는 컴포넌트 히스토리를 파악, 모든 화면을 살펴보면서 다양한 케이스를 살펴보고 용도와 용법, 형태를 정의한다. 이런 정리가 끝나면 컴포넌트 개발 가이드를 작성한다. 이 가이드의 용도는 개발자가 컴포넌트를 구축할 때 필요한 속성, Origin, Option 과 형태 정보를 담고 있다.
- Origin 으로는 Size, Textstyle, Border style, Radius, Pressedcolor, Loading animation, state / Option 은 Basecolor, Bordercolor, Textcolor, Pressdcolor..
- 네이밍은 size_type_button[theme],, large_fill_button[gray] 이렇게?
- 디자이너 입장에서 작성한 컴포넌트 기획은 개발 검토를 통해 수정해야 할 사항이 많을 것. 개발 검토 자체를 그 범위와 기간을 최대한 명확히 정의해서 진행해야 할 것.
참고링크
디자인 시스템 구축하기 1부 : 준비
https://brunch.co.kr/@thinkaboutlove/288
디자인 시스템 1편 - 디자인 가이드 / 디자인 시스템 왜 필요한가
https://story.pxd.co.kr/1434
쏘카의 디자인 시스템 맛보기
https://tech.socarcorp.kr/design/2020/06/23/socar-design-system-01.html
다크 모드 받고 디자인 시스템 더블로 가!
https://tech.socarcorp.kr/design/2020/07/10/dark-mode-01.html
컴포넌트, 제대로 만들어 쉽게 쓰자!
https://tech.socarcorp.kr/design/2020/07/31/component-01.html
컴포넌트, 제대로 만들어 쉽게 쓰자!(2탄)
https://tech.socarcorp.kr/design/2020/09/08/component-02.html
Airbnb의 디자인 시스템 만들기
https://brunch.co.kr/@designforhuman/2
Today I Learned