디자인 시스템 및 패턴 이해하기

디지털 워크플로에 접근하는 새로운 방식처럼 보일 수 있지만 디자인 시스템의 개념은 크리에이티브 산업에 "새로운" 것이 아닙니다. 모든 디자인 시스템의 핵심에는 디자이너가 직면할 수 있는 일반적인 문제를 해결하는 디자인 패턴 언어가 있습니다.

패턴 언어의 아이디어는 40여 년 전 건축과 도시 디자인에서 시작되었으며 거의 ​​모든 디자인 분야에 적용될 수 있습니다.

머티리얼 디자인(Material Design)과 같은 디자인 시스템은 트렌디한 주제이지만 디자인에 대한 체계적인 접근 방식은 수십 년 동안 잡지 발행인에게 필수 요소였습니다. 주요 잡지의 페이지를 넘기는 동안 각 섹션이 공통 레이아웃, 글꼴, 색상 등의 템플릿으로 고유하게 정의되어 있음을 쉽게 알 수 있습니다.

페이지 섹션에 사용된 디자인 패턴을 사용하면 출판물의 창의적인 비전을 보완하는 방식으로 텍스트와 이미지를 일관되고 효율적으로 배열할 수 있습니다.

경쟁 잡지를 볼 때 한 잡지의 디자인 언어가 다른 잡지와 어떻게 비교되는지 쉽게 알 수 있습니다.

아직 하지 않았다면 다양한 산업 분야의 디자이너가 곧 디자인 언어와 템플릿을 워크플로에 통합할 것입니다. 디지털 제품 디자이너의 경우 이 주제는 진화하고 있으며 많은 사람들이 복잡한 시스템 내의 패턴 라이브러리에서 처음으로 디자인하는 방법을 배우고 있습니다(또는 정의하는 데 도움을 주기도 합니다).

소프트웨어 디자인 패턴을 프런트 엔드 코드베이스와 정렬할 때 복잡성이 추가되어 디자인 언어를 배우는 것이 압도적으로 느껴질 수 있습니다.

디자인 언어는 총체적입니다

다른 언어와 마찬가지로 디자인 언어는 복잡하고 처음에는 배우기 어려울 수 있는 뉘앙스를 포함합니다. 이것이 디자인 언어를 "서로 상호 작용할 수 있는 많은 구성 요소로 구성된" 복잡한 시스템으로 생각하는 데 도움이 되는 이유입니다.

복잡한 시스템을 이해하려면 디자인 언어를 전체적으로 생각하는 것이 중요합니다.

• 디자인이 브랜드나 비즈니스에 미치는 영향에 대한 조감도부터 시작합니다.
• 그런 다음 교차 기능 팀 및 다른 디자이너와 함께 디자인의 역할을 고려합니다.
• 마지막으로, 디자인이 특정 순간에 제품과 사용자에게 어떤 영향을 미치는지 고려하십시오.

이 전체론적 관점은 디자인 워크플로에 대한 체계적인 사고 방식을 강조하고 특정 문제를 해결할 때 디자인 언어를 쉽게 적용할 수 있도록 합니다.

실제로 디자인 언어는 디자이너가 일반적인 디자인 문제에 접근하는 방식에서 중복성을 줄이고 연속성을 개선하는 데 사용되는 리소스입니다. 예를 들어, 제품 디자이너가 직면하는 일반적인 문제는 "사용자가 클릭하도록 클릭 유도문안을 작성해야 합니다."입니다.

이것은 이전에 해결된 것이므로 디자인 언어는 휠(또는 버튼)을 재발명하는 대신 모범 사례에 대한 지침과 함께 색상 및 모양과 같은 사전 설정 속성을 사용하여 재사용 가능한 버튼 "디자인 패턴"을 정의합니다.

디지털 제품 디자인 언어는 일반적으로 팀의 워크플로 효율성 및 협업 개선을 목표로 하는 교차 기능 리소스입니다.

어떤 경우에는 언어가 프론트 엔드 코드베이스 및 패턴의 메트릭 분석에 직접 연결된 라이브 패턴 라이브러리로 확장됩니다. 다양한 종속성을 갖는 이러한 유형의 복잡한 시스템은 문제 해결에 대한 전체론적 접근을 매우 필요하게 만듭니다.

디자인 언어를 배우는 데 있어 멋진 점은 팀원들이 일반적으로 제품을 정의하는 데 사용되는 인터페이스와 상호 작용에 대해 매우 열정적이라는 것입니다. 새로운 언어를 배우는 것은 일반적으로 어려운 일이지만 팀을 결속시키는 몰입형 경험이 될 수도 있습니다!

"디자인" 시스템 사고에 대한 일반적인 질문

유창한 디자인 언어는 다음을 포함할 수 있는 전도를 통해 시스템의 품질을 보장합니다.

• 새로운 디자이너 교육;
• 후배 직원 멘토링 및 계약자 관리; 또는
• 엔지니어와 직접 협력하여 릴리스 전에 제품 프론트 엔드를 개선합니다.

이러한 협력적 노력을 통해 설계자는 시스템에 대한 지침이 필요에 따라 유지되거나 개선되도록 할 수 있습니다.

의무가 무엇이든 디자이너가 책임을 져야 한다고 생각하는 디자인 시스템에 대한 몇 가지 일반적인 질문이 있습니다.

디자인 시스템 내에서 디자인할 때 무엇을 고려해야 합니까?

설계 시스템의 복잡성에 따라 해결하려는 문제에 포괄적인 접근 방식을 취하는 것으로 시작하는 것이 중요합니다. 이전의 버튼 예제를 고려하십시오.

색상이 #1f9efc 로 사전 설정되어 있고 디자이너가 동일한 패턴 라이브러리를 사용하는 다른 디자이너와 먼저 상의하지 않고 #1b3e9b 로 만들 경우 시스템 오류가 발생할 수 있습니다.

설계 시스템 내에서 작업할 때 해결 중인 문제가 전체 제품 개발 주기에 어떤 영향을 미칠지 생각하십시오. 많은 경우에 패턴 라이브러리가 이미 검증되었기 때문에 큰 영향은 없을 것이며 그렇게 되어서도 안 됩니다.

해결 중인 문제가 디자인 시스템에 새로운 것이라면 패턴 라이브러리를 발전시키고 새로운 디자인 패턴을 정의하는 데 도움을 줄 수 있는 기회가 있을 수 있습니다.

시스템이 발전하면 팀의 워크플로에 새로운 것이 됩니다. 여기서 디자인 패턴은 시간이 지남에 따라 반복되기 때문에 유연성이 필요합니다. 그러나 버튼의 색상을 변경하는 것은 쉽지만 더 큰 시스템 복잡성을 항상 고려해야 합니다.

이를 위해서는 디자인 시스템과 패턴 라이브러리를 구성하기 위한 택소노미를 정의하는 것이 도움이 됩니다. 사용된 용어는 교차 기능적으로 쉽게 이해되어야 합니다.

클릭하면 전체 크기의 이미지를 볼 수 있습니다.

디자인 아티팩트를 일반적으로 이해되는 주제로 그룹화하여 패턴 라이브러리를 사용하면 시스템이 팀 워크플로 전반에서 작동하고 디자인 패턴이 언급되는 방식으로 커뮤니케이션을 개발할 수 있습니다.

디자인 시스템 내에서 패턴을 깨거나 새 패턴을 생성해야 할 때를 어떻게 알 수 있습니까?

새로운 디자인 패턴을 깨거나 만들어야 할 필요성은 일반적으로 시스템의 성숙도에 달려 있습니다. 디자인 시스템이 발전하면 패턴이 자주 바뀝니다. 시스템이 확립되면 연속성과 품질을 보장하는 데 도움이 되는 변경 요청 프로세스가 있어야 합니다.

시스템의 복잡성도 고려해야 합니다. 패턴 변경이 다른 디자이너와 팀에 영향을 미치는 경우 프로세스를 구현하는 데 시간이 더 오래 걸릴 수 있으며 더 깊은 수준의 노력이나 리소스가 필요한 경우가 많습니다(예: 디자인 언어 지침, 패턴 라이브러리 또는 프런트 엔드 코드베이스 업데이트).

일반적으로 패턴 라이브러리는 엄격하지 않습니다. 문제를 해결하고 작업을 완료할 수 있는 도구 상자로 생각하십시오. 패턴 라이브러리의 경계 내에서 디자인하려는 모든 시도가 프로젝트 목표를 달성하지 못하면 직관으로 인해 새로운 도구를 찾거나 기존 패턴을 변경할 수 있습니다.

아래 다이어그램을 살펴보십시오. 일반적으로 브랜드 및 디자인 아티팩트를 정의하는 데 도움이 되기 때문에 기본 브랜드 빌딩 블록인 아이덴티티 와 요소 는 거의 변경되지 않습니다.

대부분의 대규모 조직에는 브랜드 관련 요소, 특히 로고, 색상, 글꼴 등 자주 변경되지 않는 별도의 스타일 가이드가 있습니다. 버튼과 같은 요소 의 경우 디자인 언어의 발전에 따라 반복되거나 반복되지 않을 수 있지만 제품의 모든 측면과 연결되기 때문에 변경 빈도가 적습니다.

디자인 패턴 변경 또는 새로운 패턴은 사용자 흐름 및 기능 세트를 정의하기 때문에 구성 요소 및 상호 작용 수준에서 종종 발생합니다. 특히 기능을 출시할 때 새로운 사용자 흐름이 제품 로드맵에 정의되는 것이 일반적입니다.

새 디자인 패턴은 라이브러리에 이미 정의된 패턴과 유사한 속성(예: 글꼴 및 색상)을 갖지만 디자인 언어 외에 인터페이스 업데이트 또는 대화형 상태가 필요할 수 있습니다.

디자이너와 함께 작업하는 제품 관리자 또는 제품 소유자는 비즈니스 목표에 부합하는 새로운 기능에 대한 요구 사항을 제공합니다. 새로운 디자인 패턴을 깨거나 생성하기로 결정할 때 복잡한 시스템 이론을 기억하고 솔루션이 공유된 결정인지 확인하십시오.

디자인 패턴을 깨거나 변경하는 방법을 생각할 때 고려해야 할 몇 가지 단계는 다음과 같습니다.

1. 품질 관리 및 연속성 보장

   품질은 제품의 공동 목표라는 것을 기억하십시오. 모든 사람은 디자인 시스템이 제대로 작동하는지 확인할 책임이 있습니다.

   항상 전체적인 접근 방식을 취하고 패턴을 깨거나 새로운 패턴을 생성할 때의 잠재적인 영향을 생각하십시오.

   자신에게 물어:

   • 패턴을 깨는 것이 내 문제를 해결하는 유일한 방법입니까?
   • 내가 이 패턴을 깨면 다른 팀은 어떤 영향을 받나요?
   • 이 패턴을 깨면 패턴 라이브러리는 어떻게 됩니까?

2. 공동 작업자와 의사 소통

   디자이너 및 교차 기능 팀 구성원과 이야기하여 다른 사람이 동일한 제한을 받고 있는지 확인하십시오. 플랫폼 요구 사항과 제안된 패턴이 전체 제품군에서 어떻게 작동하는지에 대한 모든 것을 배우십시오.

   자신에게 물어:

   • 이 제품이나 플랫폼에서 작업한 다른 사람은 누구입니까?
   • 내가 설계하는 플랫폼의 모범 사례는 무엇입니까?
   • 내 결정과 권장 사항에 대해 도움을 줄 수 있는 사람은 누구입니까?

3. 프런트 엔드 기능 이해

   프론트엔드 구현이 가능한지 알아보십시오. 변경 사항이 단순히 HTML/CSS/JavaScript 속성에 대한 업데이트인 경우 일반적으로 패턴을 깨거나 완전히 새로운 것을 만들 필요가 없습니다.

   오히려 디자인 언어 지침에 대한 간단한 업데이트일 수 있습니다. 디자이너로서 프론트엔드와 긴밀하게 협력하고 잠재적으로 매주 또는 매일 공동 작업하는 방법을 찾는 것이 중요합니다.

   자신에게 물어:

   • 프론트엔드 팀이 이 디자인 업데이트에 참여했습니까?
   • 내가 고려 중인 변경 사항이 프런트 엔드 업데이트입니까?
   • 모범 사례 지침에서 누락된 것이 있습니까?

4. 결정 확인

   새로운 패턴이 필요하다고 판단되면 협력자 및 최종 사용자와 함께 결정을 검증하고 비즈니스 목표에 맞춰야 합니다.

   프런트 엔드 구성 요소가 메트릭에 연결되어 있는 경우 빠른 A/B 테스트가 유효성 검사를 지원합니다. 그렇지 않은 경우 사용성 테스트를 수행하는 것이 좋습니다.

   자신에게 물어:

   • 우리 팀에는 새로운 디자인 패턴을 검증하기 위한 변경 요청 프로세스가 있습니까?
   • 내 결정을 확인하려면 어떻게 해야 합니까?
   • 이 결정이 새로운 사용자 흐름을 생성합니까, 아니면 추가된 기능입니까?

같은 일, 다른 마음가짐

시스템 내에서 디자인할 때 제품 디자이너가 의사 결정에 필요한 큰 그림 사고 방식을 채택하는 것이 중요합니다. 복잡한 시스템과 시스템 사고의 원칙은 디자이너가 경력을 쌓는 데 도움이 될 것입니다. 패턴 라이브러리에서 빌드하는 프로세스도 마찬가지입니다.

이러한 접근 방식은 새로운 디자인 언어를 시작하거나 기존 디자인 언어에 기여하는 데 유용합니다. 사고 방식이 자리를 잡으면 체계적인 방법이 "체계적"이 되기 때문입니다.

다른 산업 및 디자인 분야에서 수년 동안 워크플로를 간소화하는 유사한 방법을 사용했다는 사실은 제품 디자이너에게 모범 사례에 대한 훌륭한 참조 지점을 제공합니다.

결국 시스템 내에서 설계한다고 해서 작업 방식이 완전히 바뀌지는 않습니다. 물론 복잡성을 연결하고 관리하기 위한 몇 가지 새로운 도구가 있을 것이지만 궁극적으로 워크플로를 개선하는 데 진정으로 도움이 될 전체론적 사고 방식으로의 전환입니다.

• • •

Toptal Design 블로그에 대한 추가 정보:

• 스케치 스타일 가이드, 라이브러리 및 UI 키트를 만드는 방법
• 디자인 문제 설명 – 정의 및 구성 방법
• 영감을 사용하십시오 - 무드 보드 가이드
• 협업 디자인 - 성공적인 엔터프라이즈 제품 디자인을 위한 가이드
• 미래를 디자인하다: 우리를 기다리는 도구와 제품