[시론] 2022년

반응형

img

응용 프로그램의 프런트엔드를 설계하거나 엔지니어링한 경우, 설계 시스템의 개념에 이미 익숙할 수 있습니다. 익숙하지 않은 사람들을 위해, 설계 시스템은 규모에 맞게 설계를 관리하기 위한 일련의 지침과 원칙을 조직한다. 그들은 그 자체로 다른 제품의 개발에 도움이 되는 극도로 긴밀한 엔지니어링 및 설계 협업을 가진 제품이다. 저는 개인적으로 디자인 시스템으로 작업하는 것을 매우 좋아합니다. 이 기사에서는 수년간 디자인 시스템으로 작업하면서 배운 몇 가지 기본 원칙과 자신만의 시스템을 구축하는 데 사용할 수 있는 툴링에 대해 알아보겠습니다.

음 그래 예술. 바라건대, 당신이 이 기사를 읽고 이렇게 느끼길 바랍니다.

디자인 시스템이란 정확히 무엇입니까?

 

그렇다면 실제로 디자인 시스템이란 무엇일까요? 본질적으로, 디자인 시스템은 디자인과 엔지니어링 권장 사항을 결합하여 애플리케이션이 특정 스타일과 사용자 경험과 일치하도록 보장합니다. 또한 일반적으로 사용되는 구성요소 및 패턴 집합을 제공합니다.
누구나 쉽게 구현할 수 있습니다. 이는 차례로 인지 부하를 줄여 더 의미 있는 문제를 실험하고 해결하는 데 초점을 맞출 수 있도록 한다. 모든 디자인 시스템은 고유의 목표를 가지고 있지만, 많은 경우 일관성을 보장하고 제품 생산 시간을 단축하기 위해 존재한다. 이를 달성하기 위해 일반적으로 설계 시스템에는 세 가지 주요 부분이 있습니다.

• 스타일 가이드
• 구성요소 및 패턴 라이브러리
• (무엇에 요구되는, 또는 무엇을 입증할) 서류

설계 시스템 인터넷에는 수많은 예가 있다. 제가 과거에 본받고 싶었던 몇몇 훌륭한 사람들로는 GitHub의 Primer by GitHub가 있습니다.영국 디자인 시스템 및 미국 정부 웹 디자인 시스템.

영국의 Notification Banner 구성 요소를 예로 들어 보겠습니다.GOV 설계 시스템. 설계 시스템은 코드 스니펫으로 배너의 엔지니어링 구현을 위한 중앙 집중식 위치를 제공할 뿐만 아니라, 배너를 사용해야 하는 방법과 시기에 대한 매개 변수에 대해서도 알려줍니다. 이 지식을 쉽게 이용할 수 있기 때문에 문서를 읽는 사람은 누구나 주어진 문맥에 맞는 구성요소를 선택하고 있는지 여부에 대해 정보에 입각한 결정을 내릴 수 있으므로 시스템을 사용하는 사람에게 자율성을 제공할 수 있다. 저는 항상 디자인 시스템이 충분히 응집력만 있다면 누구나 최선의 판단을 할 수 있고, 그것을 이용해 프로토타입을 만들 수 있다는 것을 연결시키고 싶습니다.

왜 이것이 중요할까요?

 

팀이 성장하고 새로운 것이 도입될수록 불일치가 쌓이기 쉬워진다. 인접한 두 제품이 동일한 설계와 엔지니어링 구현을 공유하지 않으면 진로를 이탈해 특정 스타일에 해당하는 두 애플리케이션이 서로 상당히 다르게 보이고 느껴질 수 있다. 사용자 입장에서는 제품의 위치에 따라 패턴이 달라지면 상당히 당황스러울 수 있습니다. 일반적으로 모든 것이 일관되게 유지되도록 하는 것은 사용자와의 신뢰와 신뢰 관계를 구축하는 데 도움이 됩니다.

다음 예제에서 제공되는 유일한 방향은 색상 팔레트와 글꼴입니다. 이 버튼들은 모두 기술적으로 개요를 따르지만 서로 매우 다르게 보입니다. 이 예는 매우 낮은 수준의 예이지만, 표준이 없으면 모든 버튼이 다르게 보일 수 있기 때문에 대규모 설계 조직에서는 이러한 문제가 얼마나 심각해질 수 있는지 짐작할 수 있습니다.

스타일 가이드 소개

스타일 가이드는 디자인 시스템의 핵심 제공물입니다. 브랜드 또는 제품이 세상에 어떻게 표현되어야 하는지를 정의하는 디자이너 유지 관리 문서(또는 문서 세트)입니다. 그들은 색상, 타이포그래피, 문법, 로고 등과 같은 것들을 위한 기초를 다졌다. 그들은 어떤 언어를 사용할지, 접근성 문제, 특정 색상을 언제 사용할지 등에 대해 이야기합니다. 하나의 스타일 가이드 또는 여러 개의 스타일 가이드가 있을 수 있습니다. 예를 들어, 브랜드를 표현하는 방법을 설명하는 브랜드 스타일 안내서와 해당 브랜드를 사용하여 특정 플랫폼에 대한 응용 프로그램을 설계하는 방법에 대한 지침을 제공하는 다른 스타일 안내서가 있을 수 있습니다. 스타일 가이드는 디자인 시스템을 뒷받침하는 원동력이며, 대개 창의력을 강화하는 문서로서 많이 참조됩니다.

 

실제 사례를 자세히 살펴보면, 다음 이미지에는 Microsoft Fluent 디자인 시스템의 일부가 나와 있으며, 제품 인식에 사용되는 다양한 색상을 시각적으로 나타냅니다. 색상에 대한 관련 이름과 함께 16진수 값을 제공합니다. 이 값들은 디자인 토큰이라고 알려진 것으로 추상화될 수 있다.

설계 토큰 라이브러리

디자인 토큰은 디자인 시스템이 스타일 가이드로부터 확립하는 많은 기본적인 제약들을 설정한다. 예를 들어, 엔지니어가 16진수 값을 요청할 때 디자이너가 Blue-400에 대해 말하는 것은 이상적이지 않습니다. 이 경우 blue-400은 다른 팀이 마지막으로 확인한 이후 스타일 가이드에 업데이트되었을 수 있습니다. 디자인 토큰에 대한 개요를 보시려면 다음 비디오를 확인하시고 자세히 읽어보시기 바랍니다.

설계 시스템을 구축하기 시작할 때, 토큰을 설정하는 방법을 사용 사례에 따라 달라집니다. 요약하면 이러한 변수들은 단순히 변수들이지만, 이러한 변수들을 어떤 형식으로 사용할 수 있어야 하는지 자문해 보아야 합니다. iOS 앱과 함께 웹 앱을 구축하는 경우, 두 가지 모두를 지원하기 위해 여러 가지 형식이 필요할 수 있습니다. 구성 요소 라이브러리에 없는 응용 프로그램 요소의 다른 형식이 필요할 수도 있습니다. 디자인 토큰에 대한 정보의 출처가 하나뿐이면 스타일 가이드와 애플리케이션을 업데이트하는 것이 훨씬 덜 고통스러울 것입니다.

 

이를 위해 제가 가장 좋아하는 도구 중 하나는 StyleDictionary인데, 공유 가능한 디자인 토큰 라이브러리를 쉽게 구축할 수 있기 때문입니다. .yml 또는 .json 형식을 사용하여 원하는 구조를 사용하여 토큰을 정의할 수 있으며 커뮤니티 기반 Figma 플러그인도 제공합니다.

color:
  base:
    access:
        value: '#a4373a'

    exchange:
        value: '#0078d4'

    excel:
        value: '#217346'

    office:
        value: '#d83b01'

    onedrive:
        value: '#0078d4'

구성 파일에 따라 토큰 변환 방법이 결정됩니다. 여러 기본 제공 변압기 중에서 선택하거나 덜 자주 사용되는 플랫폼을 지원해야 하는 경우 직접 변압기를 작성할 수 있습니다. 로고 및 글꼴 파일과 같은 정보에 대한 단일 출처를 구축하려는 경우에도 StyleDictionary를 사용하여 자산을 저장할 수 있습니다.

{
    "source": [
          "tokens/**/*.json"
        ],
          "platforms": {
                  "web": {
                            "transformGroup": "web",
                                      "buildPath": `build/web/`,
                                                "files": [{
                                                            "destination": "tokens.scss",
                                                            "format": "css/variables"
                                                }]
                  },
                          "ios": {
                                    "transformGroup": "ios",
                                              "buildPath": `build/ios/`,
                                                        "files": [{
                                                                    "destination": "tokens.h",
                                                                    "format": "ios/macros"
                                                        }]
                          }
          }
}
}

위의 구성은 다음 출력을 작성하여 각 레지스트리에 배포할 수 있습니다. 이렇게 하면 각 플랫폼이 최신 업데이트를 제공하면 최신 업데이트를 받을 수 있습니다. 여기서 중요한 점은 시간이 지남에 따라 스타일 가이드가 발전함에 따라 변화에 대한 생각을 수용해야 한다는 것입니다. 예를 들어, 기존 색상으로 업데이트해야 할 경우 토큰에 대한 배포 시스템을 갖추면 모든 응용 프로그램을 더 쉽게 업데이트할 수 있습니다. 수작업이 적을수록 일관성과 효율성이라는 목표에 더 가까워집니다.

 

:root {
    --color-base-access: #a4373a;
    --color-base-exchange: #0078d4;
    --color-base-excel: #217346;
    --color-base-office: #d83b01;
    --color-base-onedrive: #0078d4;
}

#import <Foundation/Foundation.h>
  #import <UIKit/UIKit.h>

  #define ColorBaseAccess [UIColor colorWithRed:0.643f green:0.216f blue:0.227f alpha:1.000f]
#define ColorBaseExchange [UIColor colorWithRed:0.000f green:0.471f blue:0.831f alpha:1.000f]
#define ColorBaseExcel [UIColor colorWithRed:0.129f green:0.451f blue:0.275f alpha:1.000f]
#define ColorBaseOffice [UIColor colorWithRed:0.847f green:0.231f blue:0.004f alpha:1.000f]
#define ColorBaseOnedrive [UIColor colorWithRed:0.000f green:0.471f blue:0.831f alpha:1.000f]

여러 테마 지원

애플리케이션이 여러 테마를 지원하는 것이 일반화되고 있습니다. 밝은 모드와 어두운 모드, 다른 색상 구성표 또는 심지어 다른 브랜드입니다. 토큰을 구성하는 방법은 이러한 전환을 더 쉽게 만들 것입니다. 이를 위한 토큰을 구성하는 한 가지 대중적인 방법은 글로벌, 시맨틱 및 기본 토큰을 사용하는 것이다. 다음 표에서 의미 토큰은 기본 토큰에서 상속되는 전역 토큰에서 상속됩니다(스타일 가이드에 제공됨).

 

이 구조를 CSS로 번역하면 다음과 같습니다.

:root {
    --background-button: var(--background-interactive);
    --border-radius-button: var(--border-radius-interactive);
    --color-button: var(--color-interactive);
    --font-button: var(--font-interactive);
}

.btn {
    background-color: var(--background-button);
    border-radius: var(--border-radius-button);
    color: var(--color-button);
    font: var(--font-button);
    padding: 20px 10px;
}

응용 프로그램의 다른 곳에서는 전역 토큰을 기본 토큰에 매핑하는 변수 파일을 가져옵니다.

:root {
    --blue-100: #2B38AA;
    --border-radius-300: 6px;
    --grey-400: #E0E0E0;
    --font-primary: Helvetica;

    --background-interactive: var(--blue-100);
    --border-radius-ineractive: var(--border-radius-300);
    --color-interactive: var(--grey-400);
    --font-interactive: var(--font-primary);
}

 

향후 모든 구성 요소의 대화형 색상이 변경되어야 할 경우, 이 시스템을 사용하면 다른 기본 토큰을 가리키는 것만큼 간단합니다. 이 구조를 사용하면 전체 설계 시스템에 걸쳐 글로벌 토큰을 업데이트하는 동시에 필요한 경우 구성요소 수준의 변경을 지원할 수 있습니다. StyleDictionary와 같은 도구를 사용하면 서로 다른 테마에 대해 두 개의 변수 세트를 내보낼 수 있습니다. 그들이 공통 토큰 구조를 공유하는 한, 그것은 시스템 전체의 모든 구성 요소 인스턴스를 업데이트할 것입니다. 다음의 예에서, 우리의 CSS는 그대로 유지되지만, 버튼은 단순히 전역 토큰을 기본 토큰에 매핑하는 CSS 파일을 변경함으로써 다른 색 구성을 가질 수 있다.

아래의 각 변형으로 번역된 내용을 볼 수 있습니다. 단추가 서로 다르게 생겼지만 패딩으로 어느 정도 일관성을 제공합니다.

마이크로소프트나 트리뷴 퍼블리싱과 같은 기업들이 수많은 출판사를 위해 이런 식으로 대처하고 있다. 디자인에는 공통점이 있지만 색상과 글꼴과 같은 토큰화된 것들을 통해 각 브랜드에 고유의 아이덴티티를 부여하면서 제품 간 디자인을 공유할 수 있다. 그러나 이 시스템은 어느 정도까지만 확장되며, 구성요소의 모든 가능한 속성을 토큰화하는 경우 달성하려는 목표의 최종 목표에 대해 자문해 보아야 합니다. 테마입니까, 새로운 구성요소입니까?

 

셰어블 엔지니어링

설계 시스템의 또 다른 결과물은 구성요소와 유틸리티 라이브러리이다. 이 다음 영역은 가능한 웹 엔지니어링 접근 방식에 초점을 맞추겠지만, 이 솔루션이 일부 플랫폼에서는 작동하지 않을 수 있다는 점을 인식하는 것이 중요합니다. 네이티브 iOS 앱을 지원해야 하는 경우 웹 구현과 동일한 구성 요소 라이브러리를 공유할 수 없습니다. 현재의 요구사항은 미래의 요구사항을 반영할 필요는 없으며, 나중에 여러 플랫폼이나 컨텍스트를 지원해야 할 경우 문서와 함께 공유할 수 있는 강력한 토큰 구조를 갖추면 원활한 전환이 가능합니다.

유틸리티

설계 시스템 기반 라이브러리의 많은 예에서는 어느 정도의 유틸리티 클래스를 사용할 수 있음을 확인할 수 있습니다. 기본 토큰을 요소에 적용하는 데 자주 사용됩니다. 예를 들어, 특정 색상 값이나 특정 글꼴 또는 패딩 크기를 적용하는 유틸리티 클래스가 있을 수 있습니다. 이러한 유틸리티의 핵심은 :root에서 사용할 수 있는 변수를 참조하는 것입니다.

 

.text-2xl {
    font-size: var(--base-text-2xl);
}

.font-display {
    font-family: var(--base-font-display);
}

.color-white-200 {
    color: var(--base-color-white-200);
}

.px-400 {
    padding: 0 var(--base-size-400);
}

<h1 class="font-display color-white-200 px-400 text-2xl">
    10 Reasons Why Montezuma is the Best Cat in the World
    </h1>

이것은 라이브러리 소비자가 설계 시스템에 의해 설정된 제약 조건에 따라 작업할 수 있는 쉬운 인터페이스를 제공합니다. 스타일 가이드에 허용된 공간 옵션이 한정되어 있는 경우 엔지니어가 변수와 클래스를 통해 설계를 쉽게 구현할 수 있는 모든 옵션을 제공할 수 있습니다. 색상 등에도 동일하게 적용할 수 있습니다. 한편, 팀이 유틸리티 클래스를 사용하지 않고 자신만의 스타일시트 작성을 선호하는 경우에도 변수를 사용할 수 있는 옵션이 있습니다.

당신의 라이브러리를 가능한 모듈식으로 만들면 그것을 채택하는 데 도움이 될 것입니다. 팀은 응용 프로그램의 성능을 최대한 유지하기 위해 시스템에 필요한 부품을 선택하고 선택할 수 있어야 합니다. Sass, PostCSS, TailwindCSS와 같이 이 프로세스를 지원하기 위해 사용할 수 있는 수많은 도구들이 있다.

// @import '@brand/design-system/utilities'
@import '@brand/design-system/components/button';
@import '@brand/design-system/components/input';

 

구성 요소들

구성요소는 사용자 인터페이스를 형성하는 데 사용할 수 있는 빌딩 블록입니다. 버튼, 입력, 경고 등이 있을 수 있습니다. 구성 요소는 접근성 모범 사례, 필요한 마크업 구조 등을 고려해야 합니다. 버튼 구성 요소의 경우,
모든 변형에 대한 유틸리티가 있으며 모든 변형에는 스타일 가이드가 권장하는 적절한 호버 및 포커스 상태가 있습니다. 설계 시스템의 사용자인 경우
단추가 필요합니다. 제공된 코드 조각이 시작하는 데 필요한 모든 것이어야 합니다. 여러 테마를 지원하는 경우 앞에서 언급한 것과 같이 서로 다른 유형의 전역 및 의미 토큰을 활용하는 것을 고려해야 합니다.

:root {
    --background-button: var(--global-background-interactive);
    --color-button: var(--global-color-interactive);

    --background-button-hover: var(--global-background-interactive-hover);
    --color-button-hover: var(--global-color-interactive-hover);

    --background-button-focus: var(--global-background-interactive-focus);
    --color-button-focus: var(--global-color-interactive-focus);
}

.button {
    background-color: var(--background-button);
    color: var(--color-button);
    padding: var(--base-size-400);
    transition: 100ms opacity ease-in;
}

.button:hover {
    background-color: var(--background-button-hover);
    color: var(--color-button-hover);
}

.button:focus {
    background-color: var(--background-button-focus);
    color: var(--color-button-focus);
}

<button class="button">
    Click me
    </button>

React 또는 Angular와 같은 특정 프레임워크에 대한 구성 요소 작성을 피하고 대신 CSS 우선 방식을 선택하는 것이 좋습니다. 공유 가능한 솔루션으로 마이그레이션하는 것이 전체 애플리케이션 재작성을 추진하는 것보다 훨씬 더 쉽습니다. 특히 여러 프레임워크를 사용하는 경우에는 더욱 그렇습니다. CSS로 구성요소를 제공하는 또 다른 이점은 팀이 설계 시스템을 사용하여 파생 라이브러리를 스핀업할 수 있다는 것입니다. 특정 프레임워크에 사용하고 있는 구성 요소 라이브러리가 이미 있는 경우 일부 클래스 이름을 업데이트하기만 하면 마이그레이션이 쉬워질 수 있습니다. 궁극적으로, 가장 공유하기 쉬운 수준으로 구현을 제공하는 것은 목표 대상 고객에게 선택권과 유연성을 제공합니다.

 

필요에 따라 기본 웹 구성요소 API를 고려할 수도 있습니다. 웹 구성요소는 대화형 구성요소에 적합하며 상속된 CSS에 의해 구성요소가 수정되는 것을 더 이상 방지하는 스타일링 캡슐화를 제공합니다. Lit 및 Stencil과 같은 웹 구성요소에 사용할 수 있는 리소스가 많습니다. 위의 예는 대신 모든 스타일과 접근성 문제를 캡슐화하는 HTML 요소일 수 있습니다. 공유할 수 있는 어떤 것이든 비즈니스 논리를 이러한 유형의 구성요소에 포함시키는 것은 결코 좋은 생각이 아니라는 점을 명심하십시오.

<action-button>
    Click me
    </action-button>

(무엇에 요구되는, 또는 무엇을 입증할) 서류

당신의 디자인 시스템은 어딘가에 있어야 합니다. 설계와 엔지니어링 전반에 걸친 지식의 절정은 매일 지식을 사용할 필요가 없는 사람들을 포함하여 모든 이해 관계자가 접근할 수 있어야 합니다. 문서에는 각 구성요소 및 효용 사용의 시행 및 시행 금지 사항과 함께 엔지니어링 및 설계 구현이 모두 참조되어야 한다. 그것은 실제 사례, 기여, 소유권 등에 대한 정보를 제공해야 합니다. 설명서는 쉽게 전달되어야 하며, 엔지니어링 및 설계 관점에서 제공하는 시스템을 소비자가 쉽게 사용할 수 있도록 해야 합니다. 또한 일반적으로 사용되는 인터페이스 패턴을 강조 표시하는 패턴 라이브러리를 제공하여 일관성 목표를 더욱 높일 수 있도록 고려해야 합니다.

Storybook, Docz, Invision의 Design System Manager와 같이 이를 달성하는 데 도움이 될 수 있는 툴이 시중에 많이 나와 있습니다. 기존 오픈 소스 설계 시스템 중 일부를 살펴보고 이 시스템이 무엇을 활용하고 최선의 판단을 내리는지 확인하십시오.

 

마무리 생각

설계 시스템을 구축하기 위한 여정을 시작하기 전에 이러한 목표를 구현하여 달성하고자 하는 일련의 목표와 목표에 맞춰야 합니다. 이는 궁극적으로 여러 팀의 바이-인(buy-in)을 지원하고 채택 절차를 가속화하는 데 도움이 될 것입니다. 이 기사는 많은 부분을 다루고 있지만 이것을 하는 진짜 방법은 없다. 각 시스템은 다르고 당신이 선택하는 길은 결국 당신에게 달려 있다. 제가 과거에 구축한 디자인 시스템에 대해 읽고 싶으시다면 여기를 클릭하세요. 아니면 멜리사 에켈스에게 편집에 대한 큰 환호를 보내면서 기사를 잘 보셨기를 바랍니다. 아래 문의 사항이나 트위터에 문의해 주세요.