이제 천천히 걷기로 했습니다.
그동안 지나쳐 온 것들을 눈에 담으며 걷습니다.

Topic/디자이너라면..

디자인 시스템의 해부

kimdirector 2022. 11. 2. 11:32 

디자인 시스템은 다양한 분야를 통합하고 일관성, 효율성 등을 개선할 수 있습니다. 시스템이 핵심 브랜드 요소를 디지털 인터페이스와 연결하고 팀이 효과적으로 협력할 수 있도록 하는 방법에 대한 공유된 이해를 정의해 보겠습니다.

 

 

Sparkbox는 설계 시스템과 관련된 프로젝트에서 많은 흥미롭고 혁신적인 고객과 함께 작업할 수 있는 행운을 얻었습니다. 수년간의 디자인 시스템 연구 및 작업에서 배운 것이 하나 있다면 필요한 출발점이 시스템에 대한 공유된 이해라는 것입니다. 단일 조직 내에서도 디자인 시스템은 많은 사람들에게 많은 것을 의미할 수 있습니다. 디자인 시스템이 무엇인지에 대한 명확하고 공통된 정의 없이는 해당 시스템의 잠재력을 결코 달성할 수 없습니다.

 

1. 디자인 시스템의 컨텍스트는 무엇입니까?

브랜드는 조직과 주요 고객 간의 커뮤니케이션이 시작되는 곳입니다. 대부분의 조직은 로고, 포지셔닝 선언문, 색상, 서체 등과 같은 브랜드 요소를 결정할 수 있습니다. 주요 고객에게 다가가기 위해 브랜드 요소는 광고, 인쇄, 디지털 경험, 소매 등 다양한 미디어를 통해 필터링됩니다.

 

디자인 시스템은 브랜드와 조직이 생성하는 디지털 경험 사이에 존재하므로 해당 브랜드를 일관되고 효율적으로 표현할 수 있습니다.



디자인 시스템은 디지털 경험을 위한 브랜드 표현을 감독하고 권한을 부여합니다. 디지털 경험은 웹사이트에서 기본 애플리케이션, 키오스크에 이르기까지 다양합니다. 단일 사용자는 종종 이러한 접점 중 하나 이상을 사용하여 조직과 상호 작용합니다. 경험이 일치하지 않으면 브랜드에 대한 신뢰가 무너집니다. 브랜드 표현의 일관성은 디자인 시스템을 사용하는 유일한 이유는 아니지만 가장 중요한 것 중 하나입니다.

 

2. 그렇다면 디자인 시스템이란 무엇입니까?

디자인 시스템은 디지털 인터페이스를 만드는 데 사용하는 내부 도구이자 방법론입니다. 디자인 시스템에는 다음과 같은 내용이 포함됩니다.

 

  • 조직이 디지털 인터페이스를 만드는 방법을 결정하는 자산, 문서 및 프로세스
  • 브랜드에 맞는 디지털 디자인을 대규모로 가능하게 하는 기초, 토큰, 핵심 시스템 및 구성 요소

 

디자인 시스템은 또한 건전한 협업과 효율적인 제공을 가능하게 하는 공통 언어를 제품 팀에 제공합니다. 디자인 시스템의 구조가 복잡하기 때문에 시스템을 일련의 레이어로 나누는 것이 가장 좋습니다. 이러한 계층은 보다 이론적으로 시작되며 각 계층이 다음 계층을 기반으로 구축되어 매우 실용적입니다. 4가지 디자인 시스템 계층에 대해서 살펴 보도록 하겠습니다.

 

 

4가지 디자인 시스템 계층

우리의 경험과 관찰을 바탕으로 디자인 시스템은 다음 네 가지 계층으로 나눌 수 있습니다.

 

 

 

디자인 시스템은 중심에서 시작하여 토큰, 핵심 시스템, 구성요소 순으로 4개의 동심 레이어로 나눌 수 있습니다.

 

Foundations (기초 레이어)

Foundations Layer의 목표는 디지털 인터페이스의 설계 및 개발에 사용할 조직 브랜드의 하위 집합을 정의하는 것입니다. 최고의 디자인 시스템은 디지털 인터페이스 작업에 특정한 방식으로 브랜드 지침을 명확하게 하고 초점을 맞춥니다. 예를 들어 조직에서 브랜드 전체에 허용되는 색상의 하위 집합만 디지털 제품에 사용해야 한다고 결정할 수 있습니다. 또는 디지털 인터페이스 디자인에 사용되는 특별한 서체가 있을 수 있습니다. 가장 안쪽에 있는 핵심인 디자인 시스템의 기초 레이어는 이러한 구분과 브랜드 이면의 추론 및 원칙을 포착합니다. 여기에는 로고, 색상 및 사진 스타일과 같은 기본 사항이나 애니메이션에 대한 관점과 같은 세부 사항이 포함될 수 있습니다.

 

Tokens (토큰 레이어)
토큰 계층의 목표는 기초 계층에 표현된 디자인 개념을 취하고 디지털 인터페이스를 구성하는 데 사용할 수 있도록 체계화하는 것입니다. 이러한 디자인 개념에는 이름과 값이 부여되며 때로는 역할이나 상태와 같은 다른 속성이 부여됩니다. 토큰이 정의되면 여러 플랫폼에서 사용할 수 있는 형식으로 변환될 수 있습니다. 이것이 바로 토큰의 힘입니다. 디자인 결정을 관리할 수 있는 한 곳과 디자인 시스템을 사용하는 사람들이 필요로 하는 모든 곳에서 정의된 값을 사용할 수 있는 기능이 있습니다. 브랜드 요소가 토큰화되면 시스템 및 결과 인터페이스 전체에서 변경을 영속화하는 것이 훨씬 쉽습니다.

 

Core Systems (핵심 시스템 계층)
코어 시스템 레이어의 목표는 레이아웃, 유형 규모, 테마 등과 같은 일반적인 인터페이스 문제에 대한 솔루션을 제공하는 것입니다. 코어 시스템은 이러한 문제를 해결하는 데 사용되는 재사용 가능한 "빌딩 블록" 시스템입니다. 이것을 생각하는 한 가지 방법은 단일 디자인 결정을 코드화하면 토큰이 생성되지만 이러한 디자인 결정이 함께 작동하는 방식을 코드화하는 것이 핵심 시스템이라는 것입니다. 대부분의 경우 핵심 시스템은 토큰으로 구축되어 앞서 설명한 "변경 용이성"을 가능하게 합니다. 핵심 시스템은 또한 일관된 방식으로 구성 요소를 쉽게 구축할 수 있도록 하고 설계 시스템 가입자에게 일반적인 인터페이스 문제를 해결하기 위한 시도되고 진정한 접근 방식을 제공합니다.

 

Components (구성 요소 레이어)

구성 요소 계층의 목표는 디지털 인터페이스의 재사용 가능한 부분을 정의하고 사용할 수 있도록 하는 것입니다. 구성 요소는 단순한(버튼 또는 텍스트 입력)에서 복잡한(헤더 또는 탐색)까지 다양합니다. 적절하게 구축되면 기초, 토큰 및 핵심 시스템으로 구성됩니다. 많은 사람들이 디자인 시스템을 기본적으로 구성 요소의 집합으로 생각하며 구성 요소 계층과만 상호 작용하는 일부 사용자가 있을 수 있습니다. 구성 요소는 시스템 가치의 상당 부분을 차지하는 곳입니다. 효율성과 재사용을 촉진합니다. 그러나 구성 요소 뒤에 내부 레이어가 있으면 더 깊이, 추론 및 유연성이 제공됩니다.

 

 

디자인 시스템 계층의 세 부분

이 4개의 레이어 각각은 기능적이고 교육적이며 지속 가능한 디자인 시스템을 만들기 위해 함께 작동하는 세 부분으로 구성됩니다. 이러한 부분은 자산, 문서 및 프로세스입니다.

 

디자인 시스템의 각 동심 레이어는 자산, 문서 및 프로세스의 세 부분으로 구성됩니다.

 

 

세 부분을 각각 살펴보겠습니다.

 

Assets
자산은 디자인 키트, 코드 라이브러리, 소프트웨어 도구 또는 설치 스크립트 및 저장소와 같이 디자인 시스템의 각 계층을 사용 가능하게 만드는 것입니다. 레이어가 서로를 기반으로 구축됨에 따라 관련 자산의 수가 증가하고 있습니다. 예를 들어 기초 계층은 대부분 교육적입니다. 여기에는 많은 문서가 포함되어 있지만 자산은 거의 없습니다. 반면 구성 요소 계층에는 디지털 인터페이스를 구축하는 데 적극적으로 활용할 수 있는 많은 자산이 있습니다.

 

Documents

문서화는 당신이 기대하는 것입니다. 어떤 것이 있는 이유에 대한 상세한 설명과 그것을 사용하는 시기와 방법에 대한 분석. 자산과 마찬가지로 문서의 스타일과 범위는 계층마다 다릅니다. 기초 및 토큰 계층을 사용하면 문서에 조직이 선택한 이유에 대한 더 많은 정보가 포함될 수 있지만 핵심 시스템 및 구성 요소 계층의 경우 문서가 더 교육적이고 실용적입니다.

 

Processes

프로세스는 우리가 디자인 시스템에서 작업할 때 인간의 행동을 정의합니다. 그들은 "누가 무엇을 하는지"라는 질문에 답합니다. 자산은 기능적이고 문서화는 교육적이지만 프로세스는 지속 가능한 디자인 시스템을 만드는 데 도움이 됩니다. 시스템이 성숙해짐에 따라 더 복잡해지고 더 많은 사람들이 참여하게 됩니다. 프로세스는 시스템이 여러 분야의 팀에서 사용되는 동안 신뢰할 수 있고 안정적인지 확인하기 위한 것입니다. 여러 면에서 디자인 시스템은 사용되는 도구와 기술만큼이나 사람들의 커뮤니티에 관한 것입니다. 프로세스는 둘을 하나로 묶습니다.

 

설계 시스템의 구조에 대한 완전한 그림에는 4개의 동심 계층(기초, 토큰, 핵심 시스템, 구성 요소)과 각각을 구성하는 세 부분(자산, 프로세스 및 문서)이 모두 포함됩니다.

 

 

전체적으로 이 모델은 디자인 시스템의 조각과 부분을 고려하는 방법을 제공합니다. 레이어와 부품의 모든 교차점은 결국 채워져야 하므로 고려해야 할 작업 로드맵도 제공합니다. 그러나 가장 중요한 것은 디자인 시스템의 구조가 진정으로 가치 있는 시스템을 구축하기 위해 노력할 때 사용할 수 있는 공통 언어를 제공한다는 것입니다.

 

실제 해부학

순전히 이론적인 관점에서 더 많은 컨텍스트 없이 모든 레이어와 부품이 함께 작동하는 방식을 상상하기 어려울 수 있습니다. 보다 명확한 그림을 그리는 데 도움이 되도록 두 가지 공통 요소인 색상과 버튼이 디자인 시스템의 레이어를 통과하는 방식을 살펴보겠습니다.

 

Foundations (기초 레이어: 색상)

기초 레이어의 색상은 디지털 인터페이스 디자인에 사용할 브랜드 색상의 하위 집합을 명확히 하는 곳입니다. 이 계층은 주로 문서 및 프로세스로 구성됩니다. 기초 계층의 세 부분을 살펴보겠습니다.

 

Documentation

  • 필요한 고려 사항의 종류에 대한 지침(접근성, 일관성 등)
  • 다중 브랜드 경험, 어둡거나 밝은 모드 또는 고대비 모드와 같은 것에 대한 높은 수준의 설명
  • 뉴트럴, 1차 브랜드 색상, 2차 및 3차 색상과 같은 다양한 색상 수준
  • 감정 전달, 브랜드 일관성 보장, 색상을 사용하여 호버 또는 포커스 상태를 전달하는 등 색상 사용의 이유에 대한 설명

 

Processes

  • 조직 브랜드 팀과 디자인 시스템 팀 간의 커뮤니케이션
  • 색상 변경에 대한 정보가 적절하게 공유되도록 합니다.
  • 기초 레이어에 새로운 브랜드 색상 추가
  • 기초 레이어에서 브랜드 색상 제거 또는 변경

 

Assets

  • Foundations Layer의 개념적 특성으로 인해 색상에 대한 자산이 없습니다.

 

Tokens (토큰 레이어: 색상)

기초가 있으면 해당 색상을 토큰화할 수 있습니다. 토큰은 코드화된 디자인 결정입니다. 즉, 다른 속성과 함께 색상 이름 집합을 설정하고 값을 지정합니다. 색상 토큰을 사용하면 일관된 색상 사용, 색상 변경 용이성 및 다중 플랫폼 지원이라는 세 가지 뚜렷한 이점이 있습니다. 토큰 레이어의 세 부분을 살펴보겠습니다.

 

Documentation

  • 토큰의 이름을 지정하는 방법
  • 각 토큰의 값 및 해당 속성(예: 색상 역할, 색상 상태, 색상 변형, 색상 테마, 색상 계열)
  • 토큰의 레벨 및 계층
  • 토큰 사용 모범 사례 및 각 토큰의 용도
  • 각 토큰의 소유권 및 상태

 

Processes

  • 새로운 색상 토큰 추가
  • 기존 색상 토큰 수정
  • 색상 토큰 지원 중단
  • 색상 토큰 테스트
  • 구독자가 문제를 기록하거나 기능을 요청하는 방법
  • 새로운 플랫폼에서 사용하기 위해 토큰을 변환하는 방법

 

Assets

  • 토큰 관리 시스템
  • 토큰을 번역하는 데 사용되는 도구 및 스크립트
  • 플랫폼별 토큰 파일

 

Core Systems (핵심 시스템 계층: 색상)

Color Core Systems Layer는 인터페이스 디자인에서 색상을 사용하는 문제에 대한 체계적인 솔루션을 제공하는 곳입니다. 이러한 핵심 시스템은 이전 계층에서 정의된 토큰으로 구축되어야 합니다. 핵심 시스템 계층의 세 부분을 살펴보겠습니다.

 

Documentation

  • 각 핵심 시스템의 작동 방식
  • 이러한 시스템을 사용하기 위한 모범 사례
  • 해당 시스템으로의 마이그레이션 및 확장에 대한 정보
  • 각 시스템의 현재 상태 및 소유자 식별

 

Processes

  • 플랫폼 및 도구 간에 색상 시스템 동기화 유지
  • 색상 핵심 시스템 추가, 수정 또는 사용 중단
  • 컬러 코어 시스템 테스트
  • 현재 시스템의 문제 보고
  • 새로운 컬러 코어 시스템 기능 요청

 

Assets

  • SaaS, CSS 또는 기타 프레임워크로 구축된 색상 사용 또는 테마 시스템
  • 색상 대비 검사기
  • 디자인 도구에 사용할 색상 팔레트 파일

 

Components (구성 요소 레이어: 색상)

색상은 모든 디지털 인터페이스에서 중요한 역할을 하지만 처음 세 레이어를 넘어 색상에 대해 생각하는 데 많은 시간을 할애할 필요가 없습니다. 구성 요소 계층에 도달하면 이전 세 계층에서 수행한 모든 작업을 활용하게 됩니다. 따라서 색상 자체는 구성 요소가 아닙니다. 대신 사용자가 만든 구성 요소에 빌드됩니다.

 

버튼

우리는 시스템의 외부 계층인 구성 요소 계층에 도달할 때까지 색상이 독립적인 역할을 하지 않는다는 것을 관찰했습니다. 이미 완료된 작업에 포함되어 있습니다. 버튼은 반대로 생각할 수 있습니다. 버튼은 거의 모든 디자인 시스템의 한 요소가 될 것이지만 기초 레이어에서 시작하지 마십시오. 조직은 앱에서 버튼이 어떻게 보이는지에 대해 경영진 수준의 결정을 내리지 않습니다. 대신 버튼은 구성 요소로 이어지는 조직 표준(Foundations Layer), 토큰(Tokens Layer) 및 핵심 시스템(Core Systems Layer)과 같은 많은 결정의 산물입니다.

 

Documentation

각 구성 요소에 대해 구성 요소가 무엇인지, 언제, 어떻게 사용하는지, 모든 변형에 대한 자세한 문서가 필요합니다. 버튼의 경우 다음을 의미할 수 있습니다.

 

  • 버튼을 분해하고 모든 부분(테두리, 배경, 텍스트, 아이콘 등)에 이름을 지정합니다.
  • 버튼을 사용하지 말아야 할 때와 사용하지 말아야 할 때 설명하기
  • 버튼의 모든 변형 및 용도 설명
  • 버튼 크기 조정 방법 설명
  • 버튼 위치 지정 방법 설명(레이아웃 또는 그리드와 같은 핵심 시스템 사용)
  • 버튼으로 가능한 상호 작용 분석
  • 버튼의 텍스트에 대한 콘텐츠 고려 방법

 

또한 지원하는 디자인 도구 및 개발 프레임워크의 사용자를 위해 특별히 작성된 문서도 필요합니다(특정 도구 또는 프레임워크 내에서 설치, 사용, 확장 방법 등). 마지막으로 현재 상태와 구성 요소에 대한 향후 계획 작업을 나타내는 방법을 제공하는 것이 중요합니다. 이렇게 하면 가입자와 신뢰를 구축하고 귀하와 귀하의 팀에 대해 어느 정도 책임감을 갖게 됩니다.

 

구성 요소 수준 문서는 대부분의 구독자가 대부분의 시간을 보내는 곳입니다. 이는 이 콘텐츠가 그들의 성공에 절대적으로 중요하다는 것을 의미합니다. 구성 요소가 채택되면 구독자가 구성 요소를 사용하는 문제를 추적하고 이 정보를 문서에 계속 추가하십시오. 이 작업은 절대 완료되지 않으므로 그 관점을 염두에 두고 작업에 임하십시오.

 

Processes

구성 요소 계층의 프로세스도 중요합니다. 팀에서 사용하는 모든 도구와 프레임워크에 대한 버튼 구성 요소 자산을 만들었으므로 이러한 모든 자산을 동기화 상태로 유지하기 위한 훌륭한 프로세스를 마련해야 합니다. 디자인 시스템 팀과 구독자 사이의 신뢰가 깨지는 가장 일반적인 영역 중 하나는 디자인 중심 자산이 개발 중심 자산과 동기화되지 않는 경우입니다. 이 문제는 설계 시스템이 지켜야 했던 약속을 어겼음을 나타냅니다. 구성 요소가 빌드되거나 수정될 때 이러한 자산이 단계를 벗어나는 경우가 있으므로 이를 반복하고 릴리스하고 상태에 대해 전달하는 방법에 대한 견고한 프로세스가 절대적으로 필요합니다.

 

또한 구성 요소가 특정 가입자의 모든 요구 사항을 충족하지 못하는 상황을 관리하는 프로세스가 필요합니다. 그들은 이것을 디자인 시스템 팀에 어떻게 전달합니까? 문제를 보고하고 새 구성 요소 또는 변형을 추가하는 방법은 무엇입니까? 이러한 변경 사항이 발생하면 어떻게 테스트할 것입니까? 새로운 변형 또는 수정된 구성 요소를 디자인 시스템에 다시 통합할 수 있는지 확인하는 데 사용할 메트릭을 어떻게 캡처합니까?

 

Assets

버튼 구성 요소에는 디자인 시스템이 지원하는 모든 도구에서 사용할 수 있는 자산이 있어야 합니다. 여기에는 버튼과 모든 변형, 버튼 구성 요소의 코딩된 버전 및 조직에서 사용하는 프레임워크(React, Angular, iOS 등)의 변형, 심지어 버전이 있는 Figma 또는 Sketch(등) 파일과 같은 항목이 포함됩니다. Axure 또는 InVision과 같은 프로토타이핑 도구의 버튼.

 

 

3. 디자인 시스템 전체를 고려

또한 단일 계층 외부에 있고 시스템에 집합적으로 적용되는 자산, 문서 및 프로세스가 있습니다.

 

설계 시스템 문서

디자인 시스템에 대한 문서는 디자인 시스템을 사용하여 다양한 분야의 다양한 가입자가 여기에서 소속된 것처럼 느끼게 하는 데 중점을 두고 있습니다. 사용자의 요구 사항이나 과제에 중점을 둔 콘텐츠를 보는 것은 사용자에게 환영받는 느낌을 줄 수 있습니다. "디자이너로 시작하는 방법"을 생각해 보십시오.

 

시간이 지남에 따라 구성 요소가 함께 작동하여 청중을 위한 우수한 디지털 경험을 만드는 방법을 설명하는 데 필요한 많은 문서도 있을 것입니다. 시스템 사용을 위한 모범 사례는 무엇입니까? 버튼은 페이지에서 어떻게 함께 있어야 합니까? 빈 상태를 어떻게 처리합니까? 이러한 지침(모범 사례 또는 패턴이라고도 함)은 실제로 시스템에 대한 문서입니다.

 

마지막으로 사람들이 시스템에 기여할 수 있는 방법을 문서화하는 시간을 가져야 합니다. 시스템 사용의 일부가 시스템에 기여한다는 기대를 설정하면 시간이 지남에 따라 배당금이 지급됩니다.

 

디자인 시스템 프로세스

물론 이러한 기여 및 커뮤니케이션 아이디어는 정의하고 공유해야 하는 프로세스로 이어집니다. 많은 디자인 시스템 팀은 가입자의 의사소통을 초대하기 위해 평의회 또는 정기적인 열린 문을 두었습니다. 사람들이 어떻게 기여하기를 원하는지에 대한 구체적인 아이디어가 있을 수 있습니다. 이 모든 과정을 설명해야 합니다.

 

설계 시스템 자산

디자인 시스템 자체의 주요 자산은 문서화 사이트입니다. 이것은 우리가 방금 논의한 모든 것을 위한 저장소입니다. 문서 사이트가 혼란스럽다면 시스템 자체에 제대로 반영되지 않는다는 점을 기억하십시오. 검색 가능성과 직관적인 정보 아키텍처가 필요합니다. 가입자는 해서는 안 되는 방식으로 시스템을 사용합니다. 필요한 구성 요소를 찾을 수 없으면 직접 만들 것입니다. 이러한 종류의 문제는 시스템에 대한 신뢰를 약화시킵니다. 문서화 사이트에 대한 투자는 모든 설계 시스템의 건전한 성숙도에 매우 중요합니다.

 

 

 

4. 결론적으로

디자인 시스템은 회사의 디지털 경험을 향상하는 데 도움이 되는 엄청난 잠재력을 가지고 있습니다. 그러나 경험에 따르면 시스템이 무엇인지에 대한 공통된 이해 없이는 이점을 실현하기가 매우 어려울 것입니다. 우리는 이 모델(설계 시스템의 구조)이 팀에 필요한 명확성을 정의하는 데 도움이 되기를 바랍니다.

 

디자인 시스템은 단순한 구성 요소 집합 이상이라는 것을 기억하는 것도 중요합니다. 구성 요소는 브랜드와 아이덴티티의 가장 기본적인 요소로 시작하는 의도적인 작업의 레이어의 산물입니다. 견고한 기초가 없으면 시스템이 불안정하고 팀의 진정한 가치를 깨닫지 못할 것입니다.

 

그리고 아마도 디자인 시스템 작업의 가장 가치 있는 측면은 팀에서 가질 수 있는 통합 측면일 것입니다. 디자인 시스템은 조직의 이익을 위해 모든 분야의 요구 사항을 통합합니다. 완전히 통합되고 여러 기능을 갖춘 다중 도메인 팀이라는 이 고상한 비전은 달성할 수 있습니다. 당신의 디자인 시스템이 그것을 절대적으로 만들지는 않겠지만, 조직이 인터페이스 작업에 접근하는 방식에 대한 공유된 이해를 모든 사람에게 제공함으로써 올바른 방향으로 나아가는 데 도움이 될 수 있습니다. 직원들이 동의할 때 작업이 더 잘되고 고객이 더 행복해집니다. 이것은 디자인 시스템의 약속입니다.

반응형
이전보기 카테고리 글 더보기