크몽 디자인 시스템 v.2.0구축기

안녕하세요. 크몽 프로덕트 디자이너 kate 입니다. 저는 크몽 디자인 시스템v.2.0을 구축하며 경험했던 것들을 알려드리려고 해요.

크몽에서는 v.1.1의 디자인 시스템을 사용하고 있지만, 몇 가지 문제점들을 갖고 있어 개발자와 디자이너들이 업무와 협업에서 어려움을 겪고 있었어요. 그래서 이번에 이러한 문제점들을 해결하고 효율적이며 편리한 작업환경을 만들기로 했어요. 그 결과 v.1.2이 아닌 완전히 새로워진 v.2.0으로 개선을 시작하게 되었어요!

크몽 디자인 시스템 v.1.1은 어떤 문제가 있을까?

그렇다면 어떻게 v.2.0으로 업데이트하게 되었는지 알려드릴게요. 계기는 스토리북와 v.1.1의 싱크가 맞지 않는다는 이슈에서 시작되었어요. 하지만 입사 후 디자인 시스템을 사용하면서 여러 불편함이 있었고 업데이트하면서 아래와 같은 문제점들을 개선하고자 했어요.

1. 어떤 용도로 사용되고 있는지 모르는 컴포넌트

입사하고 나서 이 컴포넌트는 어디서 사용되는지 슬랙에 물어보는 일이 잦았어요. 누가 제작했는지, 누가 개발했는지 파악조차 어려워 매번 슬랙에 물어봤고 소모적인 커뮤니케이션이 생겨 작업이 딜레이되곤 했어요.

2. 웹 접근성을 고려하지 않은 컴포넌트 디자인

많은 컴포넌트들이 웹 접근성이 고려되지 않은 채 사용하고 있었어요. 4.5:1 대비가 충족되지 않는 컴포넌트가 많았어요.

3. 동일한 기능, 다른 디자인

동일한 기능을 가진 컴포넌트임에도 불구하고 디자이너의 재량에 따라 각기 다른 형태로 사용되고 있었어요.

4. 다양한 BM에 대응할 수 없는 컴포넌트

각종 컴포넌트에서 크몽의 브랜드컬러인 옐로우를 많이 사용하고 있었어요. 하지만 다른 브랜드 컬러를 사용하는 BM 서비스에서 사용 시 브랜드 컬러와 충돌이 생겨 이질감이 많이 들었어요.

5. 타이포 시스템 부재

크몽 서비스에서는 레귤러, 미디엄, 볼드 모두 디자이너 재량껏 사용하고 있어 정해진 규칙이 없었어요. 그래서 정보의 우선순위에 따라 타이포 스타일을 결정하는 것이 아닌 심미성에 따라 디자인하고 있었어요.

그렇다면 v.2.0 업데이트 후 어떤 것이 달라졌을까?

v.1.1을 사용할 때 소모적인 커뮤니케이션이 많아, 개발자와 디자이너들의 시간이 낭비되고 있었어요. 그래서 2.0 업데이트를 통해 작업 효율을 극대화하고자 했고 원활한 커뮤니케이션을 할 수 있게 되었어요.

이렇게 진행했어요

1. 목표 설정

“foundation, common ui 싱크 100%로 맞추기”

현재 common UI, service ui 이렇게 두 가지로 나눠지는데요. 가장 우선순위가 높은 common ui를 기준으로 스토리북와 피그마의 싱크로율을 100%로 맞추는 것을 목표로 정했어요. 기존 스토리북과 피그마의 싱크가 맞지 않아 디자인과 개발이 서로 맞지 않는 경우가 매우 많았는데, 이 부분을 최소화하기로 했어요.

2. 디자인 챕터내에서 방향성 정의

사용하지 않는 것과 사용되는 것을 분리할 수는 있었지만, 스타일 정의와 컴포넌트 규칙을 정하기 위해서는 디자이너들 모두와의 커뮤니케이션이 필요해요. 그래서 제가 분석한 결과를 가지고 디자인 챕터와 논의하는 시간을 가졌는데, 아래와 같은 기준을 통해 논의를 진행했어요.

• 디자인 방향성크몽이 추구하는 UI 스타일을 반영한 컴포넌트 디자인
• 확장성어떤 BM에서라도 사용할 수 있는 확장성
• 웹 접근성컬러 명암 대비를 충족할 수 있는 규칙 재정의
• 지속적인 관리휘발되는 슬랙대신 히스토리 작성(디자이너, 개발, 반영 여부 표기)

3. 컴포넌트 분석 후 디자인 챕터와 논의 진행

각자 맡은 프로젝트가 있었고, 모든 디자이너가 병행할 수 없었기에 제가 담당자로서 리드하게 되었어요. 저 또한 프로젝트와 병행하며 매번 많은 분량을 준비할 수 없었기에 조금씩 부분적으로 준비 후 논의하며 확정하는 시간을 가졌어요.(나와의 싸움..!🥹)디자인 시스템 버전업을 하며 많은 과정이 있었지만, 이 과정이 특히 오래 걸리고 커뮤니케이션이 많은 작업이었어요.

많은 작업들을 했지만 대표적인 케이스 3가지를 뽑아봤어요.

• Case 1 : 파운데이션 > 타이포그래피

먼저 어떤 타이포그라피가 사용되고 있는지 모두 확인했어요. 타이포그라피는 위 사진처럼 다양한 스타일을 사용 중이었어요. 크몽에서 가장 많이 노출되는 페이지(홈, 서비스 상세, 검색)를 기준으로 가장 많이 사용되는 폰트들을 선정했어요. 이렇게 선정한 폰트들을 분별력 있도록 폰트 간 크기를 2px 이상으로 정하고 추려냈어요. 하지만 13px은 너무 많은 곳에서 사용하고 있어 예외 케이스로 추가되었어요.

기존 볼드, 미디움, 레귤러로 규칙 없이 혼재된 것을 막고자 폰트 유형을 정의한 뒤, 미디움 삭제 후 시각적 위계에 따라 사용할 수 있도록 정했어요.

1. Display(Bold)
   Display는 화면에서 가장 큰 텍스트입니다.
2. Heading(Bold)
   Heading은 화면에서 대표로 중요한 정보를 전달하는 데 사용합니다. 페이지 및 템플릿, 모듈에서 핵심이 되는 텍스트일 때 사용합니다.
3. Body(Regular)
   Body는 본문에 사용되는 서체로 가장 보편적으로 사용합니다.
4. Caption(Regular)
   Caption은 부수적인 정보나 옵셔널한 정보에 주로 사용합니다.

• Case 2: 컴포넌트 > 버튼

버튼은 다른 컴포넌트에 비해 많은 종류와 다양한 형태를 가졌어요. 이렇게 많은 버튼을 효율적으로 관리하기 위해 디자인팀은 버튼의 형태를 통일(스퀘어 타입, radius 8)하기로 약속했어요.

통일시키고 난 뒤에 버튼들의 이름을 고민했어요. 기존 default와 outlined은 형태나 스타일이 아닌 컬러를 기준으로 네이밍되어 있어 커뮤니케이션할 때 오류가 발생하는 일이 빈번했어요. 이런 혼란을 방지하기 위해 형태를 기준으로 하는 새로운 네이밍 규칙을 도입했어요.

1. Contained
   사용자 액션을 확인하거나 실행할 때 주로 사용합니다.
2. Outlined
   구매하기 또는 저장 같은 기본 작업 이외의 부수적인 액션을 요구할 때 사용하며, 2가지의 액션을 제공할 때 우선 순위가 낮은 액션에 주로 사용합니다.
3. Text
   시각적으로 덜 두드러지므로 옵션과 같이 우선순위가 낮은 작업에 사용합니다.

• Case 3: 아이콘

기존 스토리북과 피그마의 아이콘이 달랐기 때문에 먼저 스토리북의 아이콘을 먼저 공유받았어요. 받아본 아이콘들의 형태가 일관성이 없고 제각각이었어요. 그래서 서비스 내 일관성을 맞추기 위해 규칙을 세워 모든 아이콘을 워싱하기로 했어요.

기존 네이밍은 기능, 사용되는 위치에 따라 임의로 정했기 때문에 일관된 규칙이 없어 매번 피그마에서 육안으로 찾아서 진행해야 하는 이슈가 생겼어요. 키워드, 쉐입, 컬러 + icon으로 일관성 있는 네이밍 규칙을 세웠고 분기점이 생길 때마다 아이콘 이름을 정하기로 개발자들과 약속했어요.

4. 개발 챕터와 논의

이렇게 모든 컴포넌트를 정리했다면 개발 챕터와 논의가 필요해요. 먼저 디자인 변경 점을 공유하고 어떻게 개발할 것인지, 구조는 어떻게 하는 것이 좋을지 커뮤니케이션하는 시간이 필요해요.

• Case: 플로팅 버튼

개발 전 피그마에는 플로팅 버튼이 있었어요. 개발자와 논의하면서 플로팅 버튼은 다른 버튼에 비해 사용 빈도가 낮기 때문에 페이지에 있을때 만 건별로 대응하는 것으로 약속했어요.

5. 라이브러리 구축 및 QA

많은 논의 후 최종 개발이 되었고 QA를 진행했어요. 실제 크몽 웹사이트에 적용했을 때 어떤 이슈가 생기는지, 혹시 놓치는 부분이 있는지 확인하기 위해 꼼꼼히 사이트를 돌아다니며 오류 난 부분을 확인했어요.

6. 라이브러리 적용

이렇게 최종적으로 2.0버전의 스토리북이 릴리즈되었고, 크몽 웹사이트도 새롭게 단장했어요!

도움 주신 분들께 감사 인사를..

상반기 약 5개월 동안 많은 개발, 디자이너분들이 정말 열심히 함께했어요. 그 과정에서 많은 커뮤니케이션과 의사결정이 있었지만(험난했던 중간 과정은 생략한다..) 디자인과 개발의 간극을 줄일 수 있는 유의미한 시간이었어요.

버전업되면서 2.0을 적용한 크몽을 유저들이 만났을 때 이질감을 느끼지 않을 수 있도록 최대한 기존 것을 유지했고, 불필요한 프로세스를 없애고 크몽에 필요한 것들을 도입할 수 있었어요. 많은 디자이너, 개발자분들이 적극적으로 의견 주셔서 일정에 맞춰 배포까지 갈 수 있었어요. 2.0이 끝이 아닌 3.0, 4.0..계속 다듬어 나갈 예정이예요. 앞으로도 많은 기대 부탁드려요!