Work

시스템으로 디자인 통일성 지키기

yiseo

Aug 25, 20242y ago

1. 시작하게 된 배경은?

제품 개선이 동시 다발적으로 이루어지고 주기가 빠르다보니 디자인 리소스를 자주 변경해야 하는
상황이었습니다.

표준 규칙이 존재하지 않아 매번 다른 요소가 생성되다 보니 UI의 일관성이 떨어졌습니다.

디자인 작업 만큼이나 싱크를 맞추는 데 상당한 시간이 허비되고 있었습니다.

앞서 제작된 그리고 제작한 UI 요소들의 관리가 제대로 이루어지고 있지 않다보니 관리하는데 어려움이
있었습니다.

이렇다 보니 개발자는 매번 새로운 코드를 생성하게 되어 비효율적으로 개발하고 있었습니다.

2. 시스템을 만들어야 하는 이유

디자인 시스템을 만들어놓았을 때의 이점은 상당합니다. 반복되는 컴포넌트 제작에 소비되는 시간을 아껴서 사용자에게 더 집중할 기회를 주고 제품의 일관성을 유지할 수 있도록 도와줍니다. 디자인 시스템은 그 명칭 때문에 디자이너들을 위한 시스템이라고 오해될 수 있지만 개발자 입장에서도 모든 UI 요소에 대한 완전한 참조 가이드를 제공받기 때문에 개발자에게 도움이 될 수 있습니다.

3. 우리의 목표는?

앞선 복합적인 이유 때문에 디자인 시스템 제작은 필수적이었고 아래와 같은 목표를 세우고 작업을 시작하게 되었습니다.

•

효율성 확보 : 재활용이 가능한 컴포넌트를 구축해 디자인 생산성을 높인다.

•

작업 능률 향상 : 싱크 시간을 줄이고 디자인 작업 시간을 확보해 일의 능률을 높인다.

•

일관성 보장 : 표준 규칙을 만들어서 일관된 사용자 경험을 제공한다.

•

협업에 기여 : 공동의 라이브러리 자산을 확충해 제품 생성에 관여하는 관계자들의 협업에 기여

4. 과정은 어떻게?

적은 인원으로 제품을 빠르게 개선하기 위해 디자인 가이드 외에도 많은 프로젝트를 진행해야 하는 상황이었기 때문에 선행 작업 된 것들을 참고하여 시행착오를 최소화하고 우리 조직에 적합한 형태로 변형하여 디자인 가이드를 빠르게 구축할 필요가 있었습니다.

① UI 요소 취합

일단 먼저 닥터나우 앱을 분해하여 어떤 UI 요소들을 사용하고 있는지 파악했습니다. 필요한 상황에 적절한 UI 요소들을 사용하고 있었습니다. 하지만 그것이 재사용이 가능할 정도로 컴포넌트화가 되어있지는 않았습니다.

② 구조화 작업

컴포넌트를 만들기 위해서 이미 사용되고 있는 UI 요소들을 어떻게 효율적으로 구조화하는가에 대해서 논의해야 했습니다. 이 점에 대해서는 이미 다른 기업에서 공개한 디자인 시스템과 Atomic Design을 참고하여 디자이너들과 논의해 UI를 나누고 조합하여 정해나갔습니다. 이 과정으로 단위를 Foundation(최소한의 디자인 규칙을 가지고 있는 가장 작은 단위의 디자인 요소)에서 Component(소프트웨어 시스템에서 독립적인 업무 또는 독립적인 기능을 수행)까지 포함하고 이미 있는 UI 요소들을 위주로 정리하기로 했습니다. 이렇게 UI에 관한 단위를 규정함으로써 체계적이고 일관된 관리의 시작점이 될 수 있었습니다.

button은 다시 action button, capsule button, floating action button, text button, icon button으로 나눌 수 있고 switch, checkbox, check mark, radio button은 control로 묶을 수 있습니다. 결과적으로 UI 요소들을 아래의 이미지처럼 구조화할 수 있었습니다.

③ 파일 작업

이미 닥터나우 디자인 파일은 사용자 앱, 약사 웹, 의사 웹 3개의 프로젝트로 분절되어 있었고 이 디자인 가이드는 사용자 앱 한정이었기 때문에 사용자 앱 안으로 들어가야 합니다. 파운데이션과 컴포넌트를 개별 파일로 관리기에는 이미 사용자 앱 안에서 작업 파일과 백로그 파일 등 여러 파일이 존재했었기 때문에 작업의 효율성을 높이기 위해 파운데이션과 컴포넌트를 단일 파일로 만들었고, 그 안에서 페이지로 분절했습니다.

각 컴포넌트의 가이드에는 컴포넌트 이름부터 디자인 스펙까지 포함합니다. 크기, 상태, 위치가 있어야만 하는 컴포넌트에는 해당 값을 포함했고, 디자인 스펙은 개발자와의 커뮤니케이션이 필요할 때 옵션으로 제공했습니다.

가이드 예시 : FAB

빈화면에 대한 디자인 가이드

④ 컴포넌트 제작하기

유사한 구성 요소를 동일한 Variants로 묶으면 유용하게 컴포넌트 속성을 관리할 수 있습니다. 구성 요소 특성에 따라 하나의 Variants 안에서 state, size, count 등의 여러 property를 설정하여 자유로운 변형이 가능하도록 제작했습니다. 가능한 참/거짓, 설정/해제 또는 예/'아니요.'로 표시될 수 있는 속성을 두어 빠른 전환을 할 수 있도록 제작했습니다.

property 적용 모습

⑤ 라이브러리 활용하기

이렇게 만든 컴포넌트들은 사용자 앱에서 자유롭게 사용할 수 있어야 합니다. 가이드와 사용자 앱은 다른 파일이기 때문에 라이브러리 기능을 통해 제작한 컴포넌트들을 퍼블리시하여 사용자 앱에서 활용할 수 있도록 했습니다.

에셋 적용 시연 영상

5. 결과는?

가이드를 만들어야 하는 이유에서 디자인 가이드를 만들면 제작 속도가 30% 절감될 것이라고 했는데 이 말을 체감할 수 있었습니다. 제작해둔 컴포넌트들은 언제든지 재사용이 가능했고 안정적으로 확장할 수 있는 계기를 마련하게 되었습니다. 서비스의 퀄리티와 일관성은 점점 좋아질 것이라고 기대합니다.

이전에 알지 못한 것들을 배우게 됐다는 점에서 좋은 프로젝트였습니다. 가이드에 사용되는 용어가 개발 용어와 중복되면 힘들다는 것을 알게 됐고 폰트의 굵기를 다양하게 할수록 용량이 커져 속도가 저하될 수 있다는 사실도 알게 되었습니다.

6. 회고

서로의 합을 맞춰 나가는 길

디자인 시스템 과정 단순히 작업물을 만든다는 것 그 이상으로 디자이너들의 컨텍스트 합을 맞춰나가는 일이었습니다. 서로의 디자인 의견은 달랐지만 그래도 우리가 가졌던 제 1원칙은 닥터나우가 쌓아놓은 브랜드 자산이었고 그것을 놓치 않으려고 노렸했습니다. 혼자 하는 일은 없기에 이해를 바탕으로 한 협의의 중요성을 깨닫게 되었습니다.

앞으로의 변화

제작한 컴포넌트들을 모든 화면에 일괄적으로 바꾸기에는 물리적, 시간상으로 한계가 있기 때문에 각각의 디자이너들이 작업하는 프로젝트에 단계적으로 적용하는 방향으로 작업 능률을 끌어올리고자 했습니다.

그리고 현재 문서는 Figma로만 정리되어 있고 개발자들과의 원활한 소통을 위해 디자인 스펙까지 제작했지만, 여전히 불편한 점이 있습니다. 이에 따라 코드 기반의 최적화된 정리가 필요합니다. 현재 이와 관련한 대안으로 Storybook을 꼽을 수 있습니다. 이것은 UI 컴포넌트를 독립적인 환경에서 그려볼 수 있는 툴 중 하나로 이를 활용하면 여러 케이스를 미리 테스트할 수 있고 기존 UI 패턴을 쉽게 찾고 재사용할 수 있으며 리팩토링 효과를 부수적으로 얻을 수 있습니다.

디자인 시스템은 한 번 만들면 끝인 절대적 가이드가 아니며 권장 가이드입니다. 효율적이고 일관적인 제품을 만들기 위한 원칙이기 때문에 변화무쌍한 환경에서 지속적으로 개선하고 발전시켜야 합니다.

Subscribe to 'yiseo'

Subscribe to my site to be the first to receive notifications and emails about the latest updates, including new posts.
Join Slashpage and subscribe to 'yiseo'!