디자인 시스템
회사에 프로덕트 디자이너가 점점 많아지면서 이전에도 살짝 느끼고 있던 문제가 더욱 크게 와닿기 시작했다. 2명이었던 디자이너가 5명이 되니 스타일이 5개가 되었고, 심지어 한 명의 디자이너(=나)가 시기에 따라 작업하는 이슈마다 또 다른 스타일의 디자인이 나오기도 했다. 메인 색상은 있었지만 메인 색상을 제외하고 많은 것들이 뜯어보면 차이가 있었다. 사용하는 색상의 범위나 텍스트의 크기, 텍스트 두께, 간격 등 하나의 서비스임에도 통일성이 부족했다.
후기 기능을 약간의 텀을 두고 2번 정도 작업한 적이 있다. 그러나 같은 정보가 표시됨에도 불구하고 작업할 때마다 레이아웃이나 작동하는 방식을 다르게 작업해버렸다. A 페이지에서는 별점/상품명 > 후기 최대 2줄 미리보기 > 썸네일 > 고객명/작성일 순으로 표시가 되었고, B 페이지에서는 상품명 > 고객 정보 > 별점/작성일 > 썸네일 / 후기 최대 3줄 미리보기 방식으로 디자인되었다. 정보의 순서도 제각각이었고 색상, 여백, 두께, 말줄임 처리되는 기준 등 모든 것이 따로 놀았다. 서비스 전체적인 흐름을 생각하지 못하고 그때 주어진 기능과 화면만 고려했던 결과였다. 숲을 보지 못하고 나무만 보았던 것 같다.
무엇보다도 텍스트 색상 차이에 대한 부분이 이 글을 쓰게 된 이유다. 위 후기 예시의 작성일을 보면 매우 연한 색상으로 표시가 되고 있다. 곳곳에 이렇게 연한 색상으로 정보를 제공하고 있었다. (아무리 플레이스홀더라도 하더라도 일종의 작성 가이드의 역할을 하기 때문에 잘 보여야 함에도 불구하고) 정보의 위계를 나눈다는 이유로 일부 텍스트들은 아주 약한 색상으로 디자인하곤 했는데, 나중에 다시 보니 너무 가독성이 떨어져 보였다. 주의 깊게 보지 않으면 내용이 눈에 들어오지 않았고, 제대로 보려고 집중하면 눈이 피로해졌다. 고객의 입장이 아니라 그저 디자인에만 초점을 두었던 것 같다.
간격(Margin, Padding)이나 둥근 정도(Radius)와 같은 부분들은 일반 고객들은 대충 보면 눈치채지 못할 부분이기도 했지만, 가독성이 떨어지는 것은 서비스에 있어서 큰 문제인 것 같았다. 정보를 제공하려고 문자를 사용하는 것인데 잘 보이지 않아서 정보가 제대로 전달되지 않으면 목적에 맞게 디자인된 것이 아니므로. 사실 색상뿐만 아니라 너무 작은 텍스트 크기를 사용하는 것도 가독성에 영향을 주지만 크기는 다음 기회에 기준을 더 명확하게 잡아보기로 했다.
무엇이 문제일까?
최근에 새로운 도메인 서비스를 기획하면서 디자인 시스템도 새로 구축해야 하는 업무를 맡았다. 예전에는 그냥 결과물만 잘 나오면 된다고 생각했는데 공부를 하다 보니 디자인 시스템이 왜 중요한지에 대해 조금씩 느끼게 되었다. 현재 디자인 시스템에서 개선할 수 있는 부분과 디자인 시스템이 제대로 작동하기 위해서 어떻게 해야 할지 고민하는 시간이 된 것 같다. 다만, 디자인 시스템을 전반적으로 다루기에는 배울 것이 너무 많아서 이번에는 텍스트에 주로 사용되는 컬러 시스템 중 Gray scale에 대해서만 정리해보기로 했다.
프로덕트에 디자인 시스템이 필요하다는 인식은 있었지만 왜 중요한지에 대한 깊은 고민을 해보지는 않았던 것 같다. 사실 초반에는 '아무것도 없는 것보다는 기준이 있으면 나으니까' 이 정도로 생각을 했던 것 같기도 하다. 하지만 이런 단순한 생각으로 작업을 하다 보면 결국 의미 없는 결과가 나오게 될 것이 뻔했다. 없는 목표를 이룰 수는 없으니까. 현재 내가 생각하기에 디자인 시스템의 중요성은 통일성, 효율성, 접근성의 기준으로 설명할 수 있을 것 같고, 주요 대상은 고객, 디자이너, 개발자인 것 같다.
통일성
고객이 하나의 서비스를 접하는 과정은 동일한 감정과 경험의 연장선상이어야 한다. 브랜드마다 철학과 제공하는 서비스가 다르기 때문에 어떤 방식이 정답이라고 말을 할 수는 없지만, 적어도 첫 만남과 헤어짐에 있어서 한 사람을 만나고 있다는 느낌이 들어야 한다. 예를 들어 어떤 가게에 들어갔는데 상품을 고를 때는 캐쥬얼 차림의 직원이 친근하게 상품을 설명해주다가 상품을 주문하려고 하니 정장을 입은 직원이 다소 딱딱한 말투로 안내한다면 다소 생뚱맞은 느낌이 들 것이다.
효율성
회사의 자원은 한정되어 있다. 직원을 무한정 채용할 수도 없으며 우리나라는 법적으로 하루 근로 시간이 9시간으로 정해져 있다. 따라서 시간은 중요한 부분에 사용해야 한다. 덜 중요하거나 무의미하게 반복되는 부분은 시스템화하여 빠르게 처리할 수 있도록 해야 한다.
디자이너들이 매번 똑같은 버튼을 그리고 있거나 개발자가 매번 똑같은 버튼을 코딩하고 있는 것은 시간 낭비다. 이미 다른 페이지에서 사용한 것들을 바로 가져다 쓰면 이런 불필요한 시간을 줄일 수 있다. 그렇기 때문에 자주 사용하는 UI는 컴포넌트화 하여 디자인 시스템으로 구축하고 가져다 쓰는 것이다. 결국 이는 디자이너와 개발자가 시간을 더 중요한 일에 사용할 수 있도록 도우며 기업 입장에서도 이익이 된다.
접근성
위키 백과에 따르면 접근성을 아래와 같이 설명하고 있다.
접근성(Accessibility)는 사용자의 신체적 특성이나, 지역, 나이, 지식 수준, 기술, 체험과 같은 제한 사항을 고려하여 가능한 많은 사용자가 불편 없이 이용할 수 있도록 제품, 서비스를 만들어 제공하고 이를 평가 할 때 쓰는 말이다. 접근성이 높다는 것은 이러한 제한 사항을 가진 사용자도 불편 없이 사용할 수 있다는 것을 뜻하며 접근성이 낮다는 것은 어떠한 제한 때문에 사용하기 불편하거나 사용할 수 없을 때를 말한다.
한마디로 최대한 많은 사람들이 서비스를 쉽게 사용할 수 있어야 한다는 것이다. 디자인 시스템을 구축함에 있어서 가장 중요한 부분이지만 가장 주의하지 않는 부분이기도 한 것 같다. 나도 그랬고.
'디자인 시스템'이라고 하면 일반적으로 떠올리는 이미지가 있다. 컬러 스케일, 타이포, 아이콘 리스트, 버튼, 인풋(정보 입력을 받는 UI) 등의 UI 모음이다.
사업의 규모가 확장되면서 회사에서는 계속 프로덕트 디자이너를 채용하고 있었다. 그에 따라서 포트폴리오도 많이 보게 되었는데, 디자인 시스템을 구축해본 경험을 가진 디자이너도 많았다. 그러나 나도 디자인 시스템을 구축해야 하는 프로젝트를 담당하게 된 후에 레퍼런스를 많이 찾아보면서 디자인 시스템에 중요한 것이 무엇인지 조금이나마 알게 되었고, 일반적으로 포트폴리오에 보여지는 UI의 나열은 디자인 시스템이 아니라 그저 비주얼 이미지처럼 느껴졌다.
포트폴리오에 모든 것을 담을 수 없기 때문에 실제 디자인 시스템을 만든 경험을 다 전달하지 못했을 수도 있다. 그러나 디자인 시스템을 어떻게 설계할지 깊게 고민하고 그 과정에서 얻은 경험이 있다면 적어도 비주얼 이미지만 몇 장 보여주고 끝나지는 않았을 것 같다.
디자인 시스템은 단순히 UI들의 크기와 상태를 화면에 그리고 끝나는 것이 아니라 언제, 어디서, 어떻게 사용할 수 있는지 맥락에 대한 가이드도 있어야 하며 실제 개발자들의 작업 공수와 디자이너들의 작업 공수도 줄여주는 협업 시스템이어야 한다. 또한 추후 다른 이용 사례가 발생하여 처음부터 다시 제작하는 공수를 줄이기 위해 확장성 있게 만들어져야 하고, 수정하기 쉽게 구성되어야 한다.
UI를 그리는 것은 쉽다. 참고할 레퍼런스도 많고 상태별로 구성된 이미 만들어진 UI KIT를 사용할 수도 있다. 그러나 UI를 만드는 것과 실제 서비스에 통일성 있게 운영하는 것은 다른 이야기인 것 같다. 디자인 시스템이 정말 시스템으로 작동하기 위해서는 UI 리스트업에만 그치지 않고 사용 목적을 이해할 수 있는 가이드 정리와 디자인을 할 때 기존 시스템을 최대한 활용해서 디자인하려는 디자이너의 책임감도 중요하다. 나도 이전까지는 특정 기능 작업에만 급급해서 디자인했기 때문에 이 부분에 대한 책임감이 매우 미흡했던 것 같다.
색상은 중요하다. 모든 UI에 기본적으로 적용되는 기본 디자인 요소이기 때문이다. 보통의 컬러 시스템은 색상의 강도에 따라서 팔레트처럼 나열되어 있다.
브랜드에 따라 다르지만 기본적으로는 Primary, Secondary, Tertiary, Gray/Neutral, Blue, Green, Red, Yellow로 구성되는 것 같다.
Accent color : Primary, Secondary, Tertiary
브랜드의 정체성과 관련 있는 색상으로 Primary 하나만 사용하거나 Secondary, Tertiary를 함께 사용하기도 한다. 용어에서도 알 수 있듯이 화면에서 가장 강조되는 액션을 Primary 색상으로 표시한다. UI의 위계에 따라 색상을 설정하여 중요도를 인식시킬 수 있다.
Neutral : Gray, Black
배경, 구분선, 텍스트 등 레이아웃을 구성하고 계층 구조를 전달하기 위하여 가장 일반적이고 다양한 방식으로 사용되는 색상이다.
Semantic color : Blue, Green, Yellow, Red
긍정과 부정같이 색상 자체에 의미를 포함하는 색상이며 보통 Blue, Green, Yellow, Red 4가지 색상으로 제공된다. 파란색은 정보, 초록색은 성공, 노란색은 주의, 빨간색은 경고를 표시한다. 색각이상자를 위하여 명확한 의미 전달을 위해 아이콘과 주로 아이콘과 함께 사용된다.
Data visualization color
이 외에도 브랜드 감성과 사용 목적이 명확하지 않은 비주얼 컬러도 있다. 뱃지 또는 시각화 구분이 필요한 UI에 사용된다. 각 색상들은 저시력자를 위하여 철저한 대비를 고려하여 구성되는 편이다.
Neutral, Gray 팔레트는 디자인에서 가장 많이 사용되는 색상이다. 텍스트, 아이콘, 배경, 구분선 등 레이아웃을 구성하고 인터페이스의 위계를 표현하는 데에 중요한 색상이다.
우리 디자인 시스템에서도 아래와 같이 색상 팔레트가 있었다.
문제는 언제 어디서 어떤 색상을 사용해야 하는지 바로 이해하기가 어려운 부분이었다. 실제 디자인을 보면 디자이너마다 텍스트에 사용하는 색상의 범위가 다양했다. A 디자이너는 400까지, B 디자이너는 500까지, C 디자이너는 600까지 사용하고 있었다. 명확한 기준이 없었기 때문에 스스로의 기준에 따라 작업했고, 그렇게 결과물도 다르게 나올 수밖에 없었던 것 같다. 기본 텍스트로 사용하는 주 색상이 달랐기 때문에 어떤 화면에서는 콘텐츠가 강하게, 어떤 화면에서는 약하게 보여지기도 했다.
사실 페이지마다 목적이 다를 수 있기 때문에 색상이 다소 차이나는 것은 큰 이슈는 아니었지만, 문제가 되는 부분은 너무 가독성이 떨어지는 색상을 텍스트에 사용하는 경우였다.
플레이스홀더(Placeholder)나 비활성화(Disabled) 상태는 기본 상태보다 다소 약하게 표현이 되기는 하지만 적어도 정보를 인지할 수 있는 범위 내에서 위계를 낮춰야 했는데, '위계 구분'에만 집중한 나머지 글자가 잘 읽히지 않을 정도로 약하게 사용하기도 했던 것 같다. 플레이스홀더는 어떻게 입력해야 하는지에 대한 가이드이기 때문에 있는 듯 없는 듯 표시되면 안됐음에도.
프로덕트, UXUI에서 가장 중요한 것은 고객이 화면에 있는 정보를 파악하고 목적에 맞는 플로우를 통하여 원하는 것을 이루고 나갈 수 있는 경험이다. 그러나 중요한 정보를 제대로 파악할 수 없어서 큰 주의를 기울여야 한다거나 못 보고 지나친다면 좋지 않은 UX라고 할 수 있다. 정보는 제대로 전달되어야 한다. 이전까지 접근성에 대해 크게 신경 쓰지 않고 디자인을 한 것 같아서 반성하는 시간이 되었다.
가독성의 중요성
핀터레스트에서 비슷한 레이아웃, 기능을 가진 화면을 일부 찾아보았다. 비슷한 기능의 UI지만 표현하는 방식은 천차만별이었다. 표현 방식은 브랜드에 따라서 달라지는 것이기 때문에 정답은 없겠지만, 색상을 너무 연하게 사용하는 경우 눈의 피로도가 증가하고 정보 전달이 제대로 되지 않는다.
명암비(Contrast radios)는 한 색상과 다른 색상 간의 차이를 나타낸다. 빛의 강도에 따라 1-21 값을 가지며 일반적으로 1~21:1과 같은 형식으로 표현한다. 명암비가 높을수록 잘 보인다. 색상 대비는 정보를 인지하고 올바르게 상호작용하는 데에 도움을 준다. 요소 사이의 색상 대비가 충분해야 저시력자가 문제없이 서비스를 이용할 수 있다.
W3C(World Wide Web Consortium)의 웹 접근성 지침인 WCAG(Web Content Accessibility Guidelines)은 웹 콘텐츠를 보다 더 접근 가능하게 만들기 위한 광범위한 권장 표준을 포함하고 있다. 지침을 준수하면 저시력, 난청, 청각장애 등 훨씬 더 광범위한 장애인들을 위한 콘텐츠를 만들 수 있다고 한다. WCAG의 명도 대비 지침에 따르면 두 가지 명암비 수준이 정의되어 있다.
Web Content Accessibility Guidelines (WCAG) 2.1
Web Content Accessibility Guidelines (WCAG) 2.1 한국어 번역본
레벨AA (최소 대비)
일반 텍스트 = 최소 4.5:1
큰 텍스트(최소 18pt)또는 굵은 텍스트(최소 14pt) = 최소 3:1
레벨AAA (향상된 대비)
일반 텍스트 = 최소 7:1
큰 텍스트(최소 18pt)또는 굵은 텍스트(최소 14pt) = 최소 4.5:1
Adobe spectrum의 경우 웹 접근성 지침에 따라 Gray palette에서 텍스트 사용 색상 기준을 명시하고 있다. 기본 배경 색상인 Gray-100을 기준으로 4.5:1의 명암비를 충족하는 범위를 Gray-600이상, 3:1의 명암비를 충족하는 범위를 Gray-500 이상으로 표시를 하고 있다. 범위 내에서도 통일성 있는 디자인을 위하여 총 4가지 색상만 텍스트에 사용하는 것으로 가이드가 되어있다. (Adobe spectrum의 Color system)
Gray-900 : Heading (주로 타이틀)
Gray-800 : Text (기본)
Gray-700 : Subdued text (서브 텍스트)
Gray-500 : Disabled text (비활성 텍스트)
Gray-500의 경우 비활성화 텍스트, 플레이스홀더 또는 꾸밈요소로 사용하는 목적이기 때문에 최소 대비값 4.5:1을 충족하지 않는다. 비활성화된 텍스트는 고객에게 상호 작용을 할 수 없다는 것을 명확하게 나타내야 하기 때문에 기본 정보보다 위계를 낮게 표시할 수 있다.
Google의 Material design도 웹 접근성을 고려한 색상 팔레트를 구성하고 있다. 색상 팔레트에서 40단계가 차이가 나면 3:1, 50단계 차이는 4.5:1, 70단계 이상 차이는 7:1의 차이가 난다.
명암비를 체크할 수 있는 유용한 사이트는 많다.
https://coolors.co/contrast-checker
배경색과 텍스트 색상을 지정하여 작은 텍스트와 큰 텍스트의 명암비를 파악할 수 있다. 값의 상태에 따라 Poor, Good, Super와 같은 상태 표시로 적절한 대비 상태를 직관적으로 인지할 수 있다.
https://accessibleweb.com/color-contrast-checker/
위 사이트는 WCAG(Web Content Accessibility Guidelines)의 AA, AAA 기준으로 Small text, Large text, UI components에 따라서 Pass 또는 Fail을 표시해준다.
https://leonardocolor.io/theme.html#
한 번에 여러 개의 색상을 체크하거나 색상 팔레트의 명암비를 체크하고 싶을 때 유용하다. 여러 가지 색상을 추가할 수 있으며 색상 대비를 조정하거나 밝기를 조정해서 팔레트를 구성할 수 있다. 우측에 표시되는 팔레트에는 배경 색상 대비 명암비가 자동으로 표시된다. 배경 색상을 변경하면 명암비도 자동으로 변경된다.
https://chrome.google.com/webstore/detail/wcag-color-contrast-check/plnahcmalebffmaghcpcmpaciebdhgdf
현재 운영 중인 사이트의 명암비를 체크할 수 있는 플러그인이다. 플러그인을 설치하고 실행하면 좌측 패널에서 현재 보고 있는 페이지의 각 콘텐츠 명암비를 체크해준다. 사이즈도 Small, Large로 자동으로 보여주며 요소를 클릭하면 해당 위치로 자동 스크롤 되어 확인할 수 있다.
아래 플러그인을 사용하면 피그마 내에서 선택한 디자인의 명암비를 바로 확인할 수 있다. 웹접근성 지침(AA, AAA)의 기준에 따라 표시도 해주며, 제안 색상을 선택하면 일괄적으로 별경할 수도 있다. 변경은 Pro 버전이라서 그냥 확인하는 용도로도 충분히 사용성이 좋은 것 같다.
https://www.figma.com/community/plugin/732603254453395948/Stark
아래와 같은 Black 팔레트가 있었지만 사용 가이드가 명확하지는 않았다.
실제 피그마에서 작업을 할 때는 900, 800, 700, ... 이렇게 숫자만 보였다. 화면에서 두 번째 중요도로 표시할 텍스트 색상을 고를 때 무엇을 선택해야 할지 헷갈렸고, '800? 700? 정도면 되겠지?' 하는 개인적인 기준으로 작업을 하게 됐던 것 같다. 물론 수많은 회색 계열의 색상에서 10가지를 추려서 디자인을 하는 것 자체로도 어느 정도 통일성을 주기는 했지만, 조금 더 명확하게 가이드를 해서 고민하는 시간도 줄이고 더 일관된 서비스를 제공할 수도 있을 것 같았다.
명암비 체크하기
흰색 배경(#ffffff) 기준으로 위 색상들의 명암비를 체크해보았다.
웹 접근성 지침에 따라서 일반 텍스트에는 대비가 4.5:1 이하인 Black 600미만의 사용은 지양해야 했다. 다만, 비활성 텍스트는 명확하게 상호 작용이 되지 않는다는 인지를 주어야하기 때문에 Black500까지 사용해도 괜찮을 것 같았다. 다만 Black 500의 2.61이라는 대비가 다소 약한 것 같아서 3까지 올리고 싶기는 하다.
이미 작업된 화면이 많았기 때문에 색상을 바로 바꾸는 것은 쉬운 일이 아니라서 이런 개선 사항들은 리스트업하여 새로운 디자인 시스템을 구축하는 데 참고하기로 했다. 일단 현재는 기존에 있는 시스템을 바탕으로 사용 가이드를 개선해보는 것까지만 체크를 해보기로 했다.
텍스트에 사용 가능한 색상
Black 600 이상 : 일반 텍스트에 사용 가능
Black 500 : 비활성, 플레이스 홀더, 꾸미기 텍스트에 사용 가능
Black 500 이하 : 일반 텍스트에 사용 불가
그러나 일부 피그마 문서에 위와 같이 표시만 해 둔다고 작업할 때마다 목적을 제대로 이해하고 사용할 수 있을 것 같지는 않았다. 디자인 작업을 할 때 색상의 사용 목적을 명확하게 인지하고 개인의 기준이 아니라 서비스의 정책에 따라서 빠르게 선택하는 방법은 없을까? 어떻게 가이드를 하면 고민을 시간을 줄이고 통일성 있는 디자인을 만들 수 있을까?
시맨틱(Semantic)은 단어의 의미 그대로 '의미'를 뜻한다. 즉 시맨틱 컬러는 색상에 사용 목적을 부여하여 이름 짓는 방식이다. 위에서 잠깐 설명했던 색상 자체에 심리적인 인식이 있는 초록, 파랑, 노랑, 빨강도 있지만 Black, Gray처럼 실제 색상 자체의 의미는 없는 색상들도 정책적으로 네이밍을 할 수도 있다.
'Green600'이나 'Gray900'만 보고는 이 색상이 어떻게 쓰이는지 인지하지 못한다. 그러나 'Success', 'Text_default'를 보면 색상이 쓰이는 용도를 이해할 수 있다.
시맨틱 네이밍은 색상 뿐만 아니라 icon, size, spacing, shadow 등 디자인의 기본 요소에 적용할 수 있다.네이밍을 하는 방법도 다양하며 서비스마다 정책이 다르기 때문에 네이밍 정책만 해도 많이 공부해야 해서 나중에 더 깊게 학습하고 기록을 남겨보려고 한다(더 나아가면 디자인 토큰 개념으로 확장하여 디자인 시스템에 적용할 수 있다).
일단 이번에는 Gray color에 대해서만 정리를 해보기로 했다. 시맨틱 컬러에 대해 더 잘 알고 싶다면 Fabien Gavinet의 아티클 Colors that make sense을 보는 것도 큰 도움이 될 것 같다.
Gray를 주로 사용하는 UI 요소 기준으로 시맨틱 컬러를 구성해보았다. Text, Icon, Border, Divider, Background 5가지로 구분했다. 우측에는 Role을 추가하여 색상 이름 외에도 구체적으로 어떻게 사용할 수 있는지 이해할 수 있도록 도왔다. (아직 작업 중이라 설명과 구분이 다소 부족하지만 지금 수준에서 정리해본 것을 일단 공유해보려고 한다.)
팔레트로 구성된 Base color를 UI의 기본 요소에 따라 범위를 나누었다. 정리된 후에 다른 디자이너들에게 공유하게 된다면 디자인 작업을 할 때 Base color를 그대로 사용하는 경우는 없도록 작업 정책을 만들려고 한다.
사용 목적에 따라서 네이밍을 하기 때문에 동일한 Base color가 다른 이름의 Semantic color로 생성되어 다소 많아 보일 수도 있다.
하지만 실제 색상을 적용할 때는 UI 요소에 따라 그룹핑 되므로 오히려 선택지가 더 줄어들고, 색상의 카테고리과 이름을 확인하고 용도에 맞게 디자인에 적용할 수 있게 된다.
피그마에도 시맨틱 컬러로 추가를 해보았다.
UI에 그레이 색상만 사용되는 것은 아니기 때문에 다른 색상을 고려하여 시맨틱 컬러를 구성한다면 지금보다 간단하게 표시되지 않을 수 있다. 아직 고려해야 할 문제와 추가로 정리해야 할 부분들이 있기 때문에 실제 작업에 사용해보지 않아서 훨씬 간편해졌다고 말할 수는 없고, 계속해서 발전시켜 나가야 할 것 같다.
하지만 적어도 기준에 맞게 사용한다면 예전만큼 디자이너마다 색상이 차이나는 디자인이 만들어지는 경우는 줄어들 것이라고 기대한다. 초반에는 주요 정보에 명암비가 약한 가독성 떨어지는 색상만 사용하지 않도록 가이드하는 것 자체로도 충분한 것 같다. 여전히 부족한 것들이 많지만 새로운 시도를 하면서 불편한 점을 고민하고 계속 개선하다 보면 이전보다는 더 나은 시스템을 구축할 수 있지 않을까.
알면 알수록 어려운 디자인 시스템
디자인 시스템을 제대로 알지 못할 때는 오히려 '디자인 시스템 이미지'만 보고 따라 그리면 되는 것이 아닐까 하는 생각을 했다. 검색만 해도 비슷한 형식의 비주얼이 많이 나왔기 때문이다. 하지만 디자인 시스템을 공부하기 시작하면서 알면 알수록 더욱 어렵고 복잡하다는 것을 느끼게 되었다. 단순히 UI를 그리는 것이 중요한 것이 아니라 논리적으로 사용자를 생각해서 설계하고 실제로 다른 동료들과 협업하여 운영하는 것이 중요했다. 사용자는 통일된 UI를 접하는 고객도 있었지만 실제 작업을 하는 디자이너, 개발자 모두가 포함됐다.
짧은 시간에 제대로 된 시스템을 만들기는 어려워 보였다. 어느 정도 구축이 된 후에도 실제로 작업해보면서 계속해서 개선하는 것이 중요한 것 같다.
구조화의 어려움
목적에 따른 시맨틱 컬러 네이밍을 생각하면서 어디까지 나누어야 할까 고민도 많았다. 위계 단계(상, 중, 하)로 나누어야 할지, 상태(default, hover, press, acitve, disabled 등)로 나누어야 할지, 아니면 모든 것을 다 부여해야 할지. 표시 방식도 고민됐다. 위계를 Primary, Secondary, Tertiary, ...과 같이 표현할지 Strong, weak, weaker, ...과 같은 식으로 표현할지 등.
하지만 선택지가 많아질수록 작업할 때 복잡도가 늘어서 고민의 시간이 늘어날 것이 분명했다. 고민을 줄이고 빠르게 통일성 있는 디자인을 만들기 위해서 시맨틱을 부여한 것인데 오히려 악영향이 될 수도 있을 것 같았다. 생각해보니 버튼의 상태를 표현하고 싶다면 버튼 자체를 상태별로 컴포넌트화 하여 해당 컴포넌트만 바로 사용하면 되기 때문에 굳이 색상을 상태별로 나눌 필요가 없는 것 같다. 지금은 필요해 보이는 것을 이것저것 추가하는 과정이었다면 앞으로는 실무에 어떻게 사용할지에 대한 구체적인 프로세스를 생각하며 제거하는 과정을 거쳐야 할 것 같다.
얼마나, 언제, 어디까지?
Gray scale 하나만으로 긴 고민의 과정을 거쳤는데 다른 색상이나 다른 foundation, component를 생각하면 과연 제대로 된 디자인 시스템을 구축하기 위해서 어느 정도의 학습과 시간이 필요할지 감이 잡히지 않는다. 하지만 업무 시간은 한정되어 있기 때문에 완벽하지는 않지만 지금 내가 할 수 있는 수준으로 정리하면서 계속 다듬어 나가야 할 것 같다.
디자인 토큰!!
디자인 시스템을 공부하면서 디자인 토큰 개념을 알게 되었다. 위에서는 시맨틱 컬러를 이야기했지만, 컬러를 넘어서 size, spacing, shadow, font-weight, line-height, radius, border-with 등 기본 UI 요소를 모두 토큰으로 만들어서 활용할 수 있었다. 베이스 토큰, 시맨틱 토큰, 컴포넌트 토큰 개념인 3단계의 토큰을 사용하여 확장성이 뛰어난 디자인 시스템을 구축하는 방법이다.
기본 foundation 요소를 토큰화하여 사용하기 때문에 참조하는 값만 바꾸면 하나의 컴포넌트를 다양한 브랜드에서 다른 감성으로 사용할 수 있으며, 추후 일부 요소만 일괄적으로 수정하기에 용이하다. 동일한 UI를 다른 스타일로 사용할 수 있다는 것이 매우 매력적으로 느껴져서 꼭 디자인 토큰을 활용한 디자인 시스템을 만들어보고 싶었다.
협업도 중요
내 작업뿐만 아니라 새로운 프로세스를 가이드화하여 동료 디자이너와 개발자에게 공유하고, 공감을 얻고 실제 업무에 운용하는 것도 만만치 않은 일이 될 것 같다. 너무 꿈만 컸거나 막상 한계가 있어서 흐지부지될 수도 있다고 생각하지만 그래도 새로운 개념을 배워서 시도하는 것 자체로 의미가 있다고 본다.
효과적인 디자인 시스템을 구축하기 위한 시행착오 과정은 앞으로도 계속...
웹 접근성 지침
https://www.w3.org/TR/WCAG21/#contrast-minimum
http://www.kwacc.or.kr/WAI/wcag21/#contrast-minimum
디자인 시스템
https://spectrum.adobe.com/page/color-system/
https://m3.material.io/theme-builder#/dynamic
https://polaris.shopify.com/design/colors
기타 아티클
https://medium.com/getaround-eu/colors-that-make-sense-505d0f3509c1