(번역) NNG 디자인 시스템 101

Won-Joon Lee·2022년 3월 27일
0
post-thumbnail

원문: Design Systems 101

역주

  • 일부 문장들에 한해 이해한 내용을 바탕으로 말이 매끄럽게 되도록 의역을 하였습니다.
  • 이 글에서의 '디자인'은 UI 디자인 뿐만 아니라 설계, 기획 등을 포괄하는 의미로 이해하시는 것이 좋을 것 같습니다.

요약: 디자인 시스템은 서로 다른 페이지와 채널들 사이의 공통된 언어와 시각적 통일성을 형성함과 동시에 중복을 줄여 대규모의 디자인을 관리하기 위한 기준들의 묶음이다.

By Therese Fessenden on 2021. 04. 11.

Topics: Design ProcessStrategyBranding


UI 디자인이 오랜 기간에 걸쳐 발전함에 따라, 만들어야 하는 UI 화면들의 규모와 속도가 함께 증가하였다. 수백만개의 앱과 수천만개의 웹페이지들(과 계속해서 새로 생겨나는 것들)이 있을 뿐만 아니라, 각각의 앱과 웹은 수백 수천개의 페이지들(또는 화면들)을 갖기도 한다. 이런 격렬한 팽창은 조직들에게 디자인 작업을 획일화하고자 하는 절박한 필요로 이어졌다. 그래서, 많은 디자인 팀들은 강력한 디자인 시스템을 활용하여 대규모의 디자인을 관리한다.

정의: 디자인 시스템은 재사용이 가능한 컴포넌트들과 패턴들을 사용하여 대규모의 디자인을 관리하고자 하는 기준들의 완전한 묶음이다.

왜 디자인 시스템을 사용해야 하는가?

디자인 시스템은, 잘 구현되었을 때, 디자인 팀에게 아주 많은 이점을 제공할 수 있다:

  • 디자인(과 개발) 작업을 빠르고 대규모로 제작하고 복제할 수 있다.

    디자인 시스템의 주요 장점은 이미 만들어둔 UI 컴포넌트들과 요소들을 활용하여 디자인들을 빠르게 복제할 수 있다는 점이다. 각 팀은 같은 요소를 계속해서 사용하여, 전에 만든 것을 다시 만들 필요와 이로 인해 발생할 수 있는 의도치 않은 불균일에 대한 위험을 줄일 수 있다.

  • 디자인 자원에 요구되는 부담을 줄여서 더 크고, 더 복잡한 문제에 집중할 수 있게 해준다.

    단순한 UI 요소들이 이미 만들어져 있고 재사용이 가능하기 때문에, 디자인 자원은 시각적 헝태를 조정하는 것에는 덜 집중하고, 보다 복잡한 문제들(정보의 우선수위, 업무 흐름 최적화, 여정 관리 등)에 더 집중할 수 있다. 이러한 손실은 적은 수의 화면만 만들 때에는 작아보이지만, 수십개의 팀과 수천개의 화면들을 넘나들며 노력들을 조율해야한다면 중요해진다.

  • 서로 다른 일을 하는 팀들 내에서와 사이에서의 통일된 언어를 만들어준다.

    특히 디자인 책임을 이전할 때나 팀이 서로 물리적인 거리가 생기게 될 때, 통일된 언어는 잘못된 소통에 낭비되는 디자인 및 개발 시간을 줄여준다. 예를 들어, 드롭다운 메뉴는, 디자인 시스템 내에서 특정하게 정의된 요소를 가리키는 표현으로 약속했기 때문에, 그 기능이나 형태는 논쟁 거리가 되지 않는다.

  • 프로덕트들, 채널들과 (완전히 분리될 가능성이 있는) 부서들 간의 시각적 통일성을 만들어준다.

    특히나 팀들이 사일로 형태, 즉 각 프로덕트나 채널이 서로에게 독립적으로 운영되는 방식으로 일을 할 때, 조직 수준 디자인 시스템의 부재는 균일하지 않은 시각적 형태와 여러 개로 조각난 또는 브랜드와 무관해보이는 경험들로 이어질 수 있다. 디자인 시스템은 컴포넌트, 패턴과 스타일의 단일 공급원single source을 제공하고 정돈되지 않은 경험들을 통일하여 이들이 시각적으로 결합되어 있고 동일한 생태계의 일부처럼 보이도록 한다. 여기에 추가로, 모든 주요한 시각적 리브랜딩이나 리디자인들이 디자인 시스템을 통해 대규모로 관리될 수 있다.

  • 주니어 수준의 디자이너들과 컨텐츠 기여자들에게 교육적 도구와 참고자료의 역할을 할 수 있다.

    명확히 작성된 활용 가이드라인과 스타일 가이드는 UI 디자인이나 컨텐츠 제작이 처음인 기여자들의 적응onboard을 도와주고 다른 기여자들에게는 리마인더의 역할을 한다.

왜 디자인 시스템을 사용하면 안 되는가?

디자인 팀이 디자인 시스템을 활용하지 못하도록 방해할 수 있는 몇 가지 잠재적 문제점들과 한계들이 있다:

  1. 디자인 시스템을 제작하고 유지하는 것은 많은 시간을 요구하기에 헌신적인 팀을 필요로 한다. 디자인 시스템은, 안타깝게도, 한 번 뚝딱하면 끝나는one-and-done 해결책이 아니다. 이를 사용하는 사람들의 피드백을 모으면서 지속적으로 진화할 때 비로소 빛을 발한다at their best.

  2. 다른 사람들에게 디자인 시스템을 어떻게 사용하는지를 가르치는 시간이 필요하다. 모든 디자인 시스템은, 심지어 이미 있던 것으로부터 변화한 것이라고 하더라도, 사용을 위한 설명이 필요하다. 그렇지 않은 경우 각 화면이나 각 팀에서 균일하지 않거나 잘못 적용될 위험이 있다.

  3. 프로젝트들은 정적이고, 일회성이어서 일반적으로 재사용하는 컴포넌트를 필요로 하지 않는다는 인식이 있을 수 있다. 그것이 옳고 그름을 떠나서, 이러한 인식은 프로젝트들의 통일된 전략의 부족과 효율 상승의 기회를 놓쳤음을 의미할 수 있다.

디자인 시스템의 요소

디자인 시스템에는 두 가지 중요한 부분이 있다:

  • 디자인 저장소repository
  • 이를 관리하는 사람

디자인 시스템 저장소

디자인 저장소는 다양한 형태를 가질 수 있으나, 대체로 스타일 가이드, 컴포넌트 라이브러리, 패턴 라이브러리를 포함한다.

스타일 가이드

스타일 가이드는 인터페이스나 다른 디자인 결과물을 제작하기 위한 특정한 구현 가이드라인, 시각적 참조, 그리고 디자인 원칙을 포함한다. 가장 일반적인 스타일 가이드는 브랜딩(색상, 타이포그래피, 상표, 로고, 인쇄 매체)에 초점을 맞추는 경향이 있는데, 스타일 가이드는 컨텐츠에 대한 가이드(가령 어조tone of voice와 언어 권장사항)와 시각적인 것과 상호작용에 대한 (프론트엔드 스타일 가이드라고도 하는) 디자인 기준도 제공한다. 이러한 가이드라인들은 때때로 상황에 맞는 가이드를 제공하기 위하여, 컴포넌트 라이브러리에 통합되기도 한다.

1976 NASA Graphics Standards Manual (NHB 1430.2)은 철저한 브랜딩 스타일 가이드의 예시이다. 이는 놀라울 정도로 현대적인 시각적 예제들 그 이상(가시성과 가독성을 보완하기 위한 색 조합에 대한 가이드라인, "표지는 반드시 큰 머릿말로 생각되어야 한다; 따라서, 언어는 반드시 명료하고 정확해야 한다. 간결함은 빠르게 소통하기 위해서, 특히 교통 수단을 운전하는 운전자들에게 꼭 필요하다." 등 명확한 디자인 원칙)을 제공하고 있다.

Mailchimp의 컨텐츠 스타일 가이드는 다른 형태의 컨텐츠를 어떻게 작성하는지에 대한 강력한 가이드라인을 포함하여 Mailchimp의 기업 가치와 어조에 일치하도록 한다.

컴포넌트 라이브러리

컴포넌트 라이브러리(또는 디자인 라이브러리)는 많은 사람들이 디자인 시스템이라고 생각하는 것들로, 이 철저한 라이브러리들은 미리 결정된 재사용 가능한 UI 요소들을 보관하여 디자이너들과 개발자들 모두에게 특정한 UI 요소들에 대해 배우고 이를 구현할 수 있도록 하는 원스톱샵one-stop shop의 역할을 한다. 이러한 라이브러리르 만드는 것은 엄청난 시간과 자원을 요구한다. 라이브러리는 컴포넌트들의 시각적 예제들 뿐만 아니라, 다음의 요소들을 포함한다:

  • 컴포넌트 이름: 디자이너와 개발자 간의 잘못된 소통을 방지하기 위한 특정하고 유일한 UI 컴포넌트 이름

  • 설명: 이 요소가 무엇인지와 주로 어떻게 사용되는지에 대한 설명, 때때로 상황과 설명을 위해 해야 할 것과 하지 말 것에 대한 내용을 포함

  • 속성: 커스터마이즈하거나 특정한 요구를 위해 컴포넌트를 변화시키기 위해 만들 수 있는 변수나 조정 (예: 색상, 크기, 모양, 복제)

  • 상태: 권장 기본값과 상태에 따른 형태의 변화

  • 코드 스니펫: 요소에 대한 실제 코드 일부 (몇몇 디자인 시스템들은 여러 개의 예시를 공유함을 넘어서 다른 컴포넌트 커스터마이즈를 시도해볼 수 있는 "샌드박스" 환경을 제공하기도 함)

  • 프론트엔드 & 백엔드 프레임워크: (적용 가능한 경우) 라이브러리를 구현하기 위한 것으로, 고통스럽고 불필요한 디버깅을 회피할 수 있도록 해줌

구글의 Material Design System은 구현 가이드라인과 특정한 OS와 프레임워크를 위한 (위 이미지의) 코드 스니펫 뿐만 아니라, 철저한 가이드라인과 사용성 측면에서의 해야 할 것과 하지 말아야 할 것을 별도의 탭으로 포함한 컴포넌트 라이브러리를 제공한다.

IBM의 Carbon design system은 사용처, 스타일, 코드 가이드라인과 함께 접근성 고려사항 및 디자이너들과 개발자들이 모든 커스터마이즈를 구현 전에 시각화 할 수 있도록 하는 코드 샌드박스를 갖추고 있다.

패턴 라이브러리

때때로 ‘컴포넌트 라이브러리’와 ‘패턴 라이브러리’는 동의어로 사용되곤 하는데, 이 두 종류의 라이브러리 사이에는 차이가 있다.

컴포넌트 라이브러리는 각각의 UI 요소들을 특정하는 반면, 패턴 라이브러리는 UI 요소의 그룹핑grouping이나 레이아웃에 대한 모음을 제공한다. 패턴 라이브러리는 간혹 컴포넌트 라이브러리에 비하여 덜 강력하다고 생각되곤 하는데, 필요한 만큼 철저하거나 높은 수준이 될 수 있다. 일반적으로 컨텐츠 구조, 레이아웃 그리고/또는 템플릿을 제공한다. 컴포넌트만큼이나, 패턴도 재사용되고 조정되어야 한다.

Atlassian 디자인 시스템에는 페이지 헤더 양식을 포함한 여러가지 재사용 가능한 패턴들이 있다. 시각적 예제를 보여줄 뿐만 아니라, 디자이너들이 활용해야하는 정확한 컴포넌트를 강조하고 각 컴포넌트들이 어떻게 사용되어야 하는지 설명한다.

많은 공공 부문 웹사이트들이 갈 길이 멀지만, US Web Design System (USWDS)는 서로 다른 여러 부서와 기관들을 명확한 가이드라인으로 통합하기 위한 좋은 시작점이다. USWDS는 (위 사진과 같은) 페이지 양식뿐만 아니라, 디자인 원칙, 컴포넌트 그리고 구체적인 코드까지 제공한다.

디자인 시스템 팀

디자인 시스템은 오직 팀이 관리하는 만큼만 효과적이다. 새로 만들었든 기존의 시스템을 적용했든, 디자인 시스템은 구식이거나, 쓸모가 없어졌거나, 중복되는 요소들로 과밀화되지 않음을 보장하기 위한 지속적인 유지와 관리를 필요로 한다. 팀의 크기는, 디자인 시스템 자체의 크기나 커스터마이즈 정도가 다르기 때문에, 차이가 있을 수 있으나, 최소한 1명의 인터랙션 디자이너, 1명의 비주얼 디자이너, 1명의 개발자를 포함하여 각각 상호작용 디자인 가이드를 작성하고, 시각적 예제를 만들고, 각 요소에 대한 코드 예제와 구현 명세를 제공할 수 있도록 해야 한다. 이상적으로는, 조직 내에서 이러한 역할들이 명확히 결정되어 있는 경우, 비상주 형태의 연구원part-time researcher, 비상주 아키텍트part-time architect, 컨텐츠 라이터도 포함해야한다.

마지막으로, 디자인 시스템 작업을 조율하는 데에 도움을 줄 (리더급) 임원을 확보하는 것을 고려하라. 없다고 하여 더 진행할 수 없게 되는 것은 아니지만, 이들은 자본과 자원을 확보함과 동시에 디자인 시스템의 전략적 중요성을 조직 내 다른 이들에게 전파할 수 있다.

디자인 시스템 채택에 접근하는 방법

디자인 시스템을 사용하는 데에는 일반적으로 세 가지 접근이 있다.

  • 이미 있는 디자인 시스템을 채택
  • 이미 있는 디자인 시스템을 적용
  • 고유하거나 커스텀(맞춤형) 디자인 시스템을 직접 만들기

각각의 장단점이 있지만, 일반적으로 디자인 시스템이 커스텀일수록, 구현하는 데에 더 많은 시간과 돈이 든다. 따라서, 이미 있는 디자인 시스템을 사용하는 것이 가장 저렴하고 구현에 최소한의 시간을 필요로 하는 접근이다. (하지만 기존의 방식대로 디자인을 하는 것보다는, 여전히, 시간이 더 걸리긴 하는데, 일부 UI 요소들을 기준에 맞도록 교체하거나 고쳐야 하기 때문이다.)

커스텀한 디자인 시스템에 투자하는 것은 만약 조직이 다른 오픈소스 디자인 시스템으로는 충족할 수 없는 특정한 요구사항을 갖는 경우 충분한 가치가 있을 것이다. 디자인 시스템에 가해지는 커스터마이즈와 조작이 커질수록, 기존에 있는 디자인 시스템을 사용함으로부터 얻을 수 있는 비용 절약이 줄어들 것이며, 장기적으로는, 결국 독자적인 디자인 시스템을 만드는 것이 더 나을 수 있다. 디자인 시스템 시도에 뛰어들어 손익을 평가하기 전에 조직이 원하는 것이 무엇인지 확실히 알아야 한다.

예산과 필요에 기반하여, 조직들은 디자인 시스템에 대한 세 가지 접근 중 하나를 선택한다: 이미 있는 시스템을 완전히 채택하거나, 있는 시스템을 요구에 맞게 적용하거나, 완전히 새로운 것을 만들거나.

끝으로, 개념 증명이나 바뀌기 쉬운 초기 프로토타입의 경우, 온전한 디자인 시스템을 만든다고 하여 단기간에 원하는 투자 대비 효율ROI을 내지는 못할 것이다. 결국, 이득은 디자인을 복제할 수 있음이며, 이는 앞으로의 이야기다. 물론 밑바닥부터 이러한 것들을 만들어나가는 것이 끌릴 수 있지만, 디자인 시스템은 일의 포트폴리오로 생각되기보다는, 디자이너와 개발자가 더 빠르게 일하기 위한 기능적 툴킷 또는 자원으로 여겨져야 함을 명심하라. 다시 말해, 만약 디자인 시스템의 유용성에 대해 의구심이 있다면, 디자인 작업을 평가하는 데 쓰이는 시간을 고려하는 것이 더 가치 있을 수 있다는 것이다. 디자인 시스템은 조직이 향후 몇 년간의 반복적인 디자인 작업을 내다볼 때 가장 좋다.

결론

디자인 시스템은 많은 컴포넌트, 패턴, 스타일 그리고 가이드라인을 이루어져, 디자인 작업을 운용화하고 최적화 하는 것에 도움이 된다. 하지만, 디자인 시스템은 사람에 의해 디자인되고, 관리되고, 구현된다. 디자인 시스템을 만들 때 고려해야 하는 주요 요소로는 프로젝트들의 크기와 반복성, 가능한 자원과 시간이 있다. 빈약하게 구현되고 유지된다면, 디자인 시스템은 컴포넌트와 코드의 난잡한 묶음이 되겠지만, 잘 구현된다면 디자인 시스템은 팀 구성원들을 교육하고, 업무를 능률화하며, 디자인들이 복잡한 UX 문제들을 해결하도록 할 수 있다.

profile
Web Frontend Engineer

0개의 댓글