디자인 시스템 튜토리얼 및 사용의 이점 – Indigo.Design

디자인 시스템과 디자인-개발 협업 요구 사항에 대한 가장 핵심적인 개요

디자인 시스템을 사용하고 구축하는 것은 새로운 일이 아닙니다. 새로운 것은 이를 어떻게 사용하고 어디에 적용하느냐입니다. 제대로 하면 규모에 맞게 프로세스를 더 잘 수행할 수 있습니다 - 제품 디자인, Sketch나 Figma 디자인으로부터의 전환, UX 디자인, 핸드오프, 사용자 테스트, 프런트엔드 개발까지 말이죠.

저희의 Design Systems RefCard를 통해 디자인 시스템을 재사용 가능한 UX 패턴과 브랜드 스타일 가이드라인의 신중한 목록 이상의 것으로 인식할 수 있도록 심층적인 개요를 얻으실 수 있습니다. 또한 크로스펑셔널 팀 간에 일관된 경험과 디자인-투-코드 프로세스 정렬을 가져오기 위해 디자인-개발 환경에서 무엇을 해야 하는지도 이해하게 될 것입니다.

오늘 RefCard를 읽고 다음에 대해 알아보세요.

• “디자인 임파워먼트”의 중요성: 비용이 많이 들고 그렇지 않아도 피할 수 있었던 재작업을 줄이는 것.

• 디자인 시스템이란 무엇인가: “디자인 자산의 모음”을 넘어서, 팀이 디자인에서 코드로 더 빠르게 이동할 수 있게 하는 엔드투엔드 도구 사용의 개념을 포괄합니다.

• 디자인과 개발 간 협업의 4단계: 목업과 스타일 가이드를 교환하는 것에서부터 App Builder와 같은 도구를 사용해 디자인 특화 컴포넌트를 생성하는 것까지.

• 디자인 시스템의 해부학: 원자, 분자, 유기체에 비유할 수 있는 디자인 시스템은 제품과 도구를 염두에 두고 특정 UX 요구 사항을 반영하도록 변화합니다.

• 더 많은 디자인 시스템의 이점: 반드시 디자인 개발 팀을 확장하지 않고도 기업이 빠르게 확장할 수 있도록 도우며, 완전한 기능을 갖춘 앱을 제공하는 데 드는 비용과 시간을 줄여줍니다.

• 디자인 시스템의 미래: 자동화 디지털 제품 개발 도구 및 DevOps와 쉽게 통합할 수 있는 잠재력으로, 개발자를 초기 단계부터 참여시킵니다.

• 한눈에 보는 App Builder™: 팀이 디자인 시스템의 견고하고 미래에도 통하는 아키텍처를 구축할 수 있게 해주며, 시간과 노력을 절약해 줍니다.

서론

디자인과 개발은 소프트웨어 제품 개발 내에서 핵심적인 기능적 분야로 남아 있지만, 문제는 대부분의 경우 이들이 각자 독자적으로 발전한다는 것입니다. 그러나 실제로는 현대적인 앱 구축 이면에 있는 복잡성과 시간 부족은 디자이너와 개발자 모두에게 동등하게 유익한 단일 진실 공급원(single-source-of-truth)을 요구하는 현실 점검으로 작용합니다.

그러나 디자인 시스템을 구축하는 것은 새로운 일이 아닙니다. 새로운 것은 이를 어떻게 사용하고 어디에 적용하느냐입니다. 제대로 하면 규모에 맞게 프로세스를 더 잘 수행할 수 있습니다 - 제품 디자인, Sketch나 Figma 디자인으로부터의 전환, UX 디자인, 핸드오프, 사용자 테스트, 프런트엔드 개발까지 말이죠.

비즈니스 성공의 관점에서 기업들은 애플리케이션에서 매력적인 UX를 제공해야 할 필요성을 인식하고 있습니다 [#]. 그러나 매력적인 UX를 제공하려면 디자인과 개발 간의 높은 수준의 협업이 필요합니다. 그리고 이러한 수준의 협업은 현대 업무의 원격 및 분산 특성으로 인해 비용이 많이 들 수 있습니다. UX 제공 비용은 디자인 의도를 전달하는 데 필요한 노력이나 시각적 명세를 코드로 변환하는 것과 같은 다른 요인들로 인해 더욱 가중됩니다. 이러한 비용을 낮추지 않는 한, 가장 의지가 강한 기업조차도 매력적인 UX를 제공하는 것이 실현 불가능할 수 있습니다.

최근 몇 년간 디자인 시스템은 디자인과 개발 간의 협업을 개선하는 솔루션으로 부상했습니다. 디자인 시스템 접근 방식은 Salesforce.com, IBM, Atlassian 등의 조직에서 채택되었으며, 이는 그 매력을 증명하는 증거입니다.

하지만 디자인 시스템이란 사용자 인터페이스를 구축하는 데 사용하는 디자인 자산의 모음이라는 대중적인 정의가 있습니다. 간단히 말하면, 맞습니다. 이는 소프트웨어 애플리케이션 구축을 위해 재사용하거나 맥락화할 수 있는 매칭 소프트웨어 컴포넌트로 구현되는 UX 패턴과 브랜드 스타일 가이드의 목록을 나타냅니다. 더 큰 관점에서 보면, 디자인 시스템은 재사용 가능한 UI 컴포넌트 라이브러리 그 이상입니다. 이는 다음과 같은 손수 제작된 “디자인 임파워먼트”입니다.

• 제품 팀을 위한 단일 진실 공급원 역할을 합니다.

• 특정 사용 맥락과 앱 도메인에 맞춰집니다.

• 디자인 프로세스를 가속화하고 일관성을 크게 향상시킵니다.

이들은 또한 콘텐츠 작성을 위한 보이스 & 톤 가이드, 페이지 템플릿, 심지어 사용자 흐름까지 포함하도록 확장될 수 있지만, 각 조직의 특정 애플리케이션 도메인과 사용 맥락에 맞게 손수 제작된 방식으로 이루어집니다.

이 모든 것을 이해하기 위해, 이 글에서 다룰 내용은 다음과 같습니다.

• “디자인 임파워먼트”의 중요성

• 디자인-개발 협업 단계

• 디자인 시스템의 해부학

• 디자인 시스템 사용의 이점

• 디자인 시스템의 미래는 자동화 및 로우코드 도구와 얽혀 있습니다

• App Builder 한눈에 보기

”디자인 임파워먼트”로 보는 디자인 시스템

인프라지스틱스는 최근 저희 웨비나에 참여한 개발자 388명을 대상으로 설문조사를 실시했으며, 그중 약 26%만이 디자인 팀과 협업한다는 사실을 발견했습니다 - 즉 4명 중 3명 이상의 개발자가 UI 디자이너 역할도 겸하고 있다는 뜻입니다. 개발자의 70% 이상이 HTML/CSS로 작업하고 화면을 디자인하는 것이 웹 앱 구축 측면에서 가장 큰 도전 과제이며, 이것이 프로세스를 지연시키고 더욱 복잡하게 만든다고 말합니다.

사용자 인터페이스(UI)가 애플리케이션 개발 시간의 60%를 차지하는 상황에서, 디자이너-개발자 핸드오프 과정에서 실수가 발생할 가능성은 매우 크며, 애플리케이션이 배포된 후에는 그 비용이 10배까지 늘어날 수 있습니다. 팀들이 흔히 겪는 문제는 동작 및 시각적 혼란, 브랜드 불일치, 낮은 사용성, 잘못 전달된 디자인 표준, 그리고 제품 디자인 및 개발 주기 내의 기타 불일치들입니다. 또 다른 경우에는 디자인 시스템을 구축하는 시점과 이를 제대로 구현하는 시점 사이에서 실패의 순간이 발생하기도 합니다.

그러나 디자인 시스템이 갖춰져 있으면 앱 제작이 훨씬 원활하게 진행되어, 애플리케이션이 시장에 빠르게 출시되는 것을 방해하는 비용이 많이 들고 그렇지 않아도 피할 수 있었던 재작업을 줄여줍니다.

디자인과 개발 간 협업의 진화 단계

디자인 시스템에 대해 알아보기 전에, 디자인과 개발 간의 협업 산출물이 어떻게 발전해 왔는지 살펴보겠습니다. 이를 크게 네 가지 수준으로 분류할 수 있습니다.

• 레벨 1: 정적 시각 명세

• 레벨 2: 인터랙티브 시각 명세 (검사)

• 레벨 3: UI 컴포넌트에 연결된 시각 명세 (디자인 시스템)

• 레벨 4: 디자인 명세로부터 앱 생성 (디자인 시스템 +)

모든 수준에서 개발에 앞서 어떤 형태의 디자인 활동이 선행되었다고 가정할 수 있습니다. 즉, UI와 흐름에 대한 명세가 개발 이전에 생성됩니다.

레벨 1: 정적 시각 명세

이러한 형태의 디자인-개발 커뮤니케이션이 가장 흔합니다. 이 수준에서는 시각 디자이너가 사용하는 도구(예: Sketch와 Figma)를 사용해 시각적 목업이 생성됩니다. 스타일, 레이아웃, 크기 등에 대한 명세는 검토를 위해 목업 위에 주석으로 추가됩니다.

개발자는 개발 프로세스의 일부로 이 문서를 참조하여 수동으로 코드에 구현합니다. 이 접근 방식은 유지 관리가 필요하지 않은 커스텀 일회성 프로젝트에는 적합합니다.

레벨 2: 인터랙티브 시각 명세 (Inspect)

이 수준에서는 시각 디자인 팀이 여전히 목업과 스타일 가이드를 개발자와 공유하지만, 정적 문서 대신 더 접근하기 쉬운 형식으로 명세를 제공하는 도구에 의존합니다. Zeplin.io와 같은 도구를 사용하면 디자이너는 디자인에 별도로 마크업을 추가하는 수고 없이 디자인을 업로드할 수 있고, 개발자는 브라우저에서 디자인을 볼 수 있습니다. 더 중요한 것은 개발자가 디자인을 클릭하면 필요할 때마다 명세를 볼 수 있고, 이는 대상 플랫폼(예: HTML, CSS)에 맞는 형식으로 제공된다는 점입니다.

이 접근 방식의 핵심 이점은 디자이너가 수동으로 주석을 추가할 필요가 없고, 개발자는 여전히 UI의 어떤 부분에 대해서도 에셋과 명세를 추출할 수 있다는 것입니다. 하지만 이는 조직이 사용하는 어떤 소프트웨어 컴포넌트와도 연결되어 있지 않습니다.

레벨 3: UI 컴포넌트에 연결된 시각 명세

이 수준에서는 디자인이 개발과 협업하여 필요에 맞는 스타일, 레이아웃, UI 컴포넌트의 목록을 만들었다고 기대할 수 있습니다. 다시 말해, 디자인 시스템을 구축한 것입니다.

여기서 디자인 팀은 디자인 시스템을 반영하는 표준화된 UI 키트를 사용해 디자인을 제작합니다. UI 키트는 디자인 도구 자체(예: Sketch나 Figma)를 사용해 만들어진 재사용 가능한 시각 디자인 요소의 모음으로, 코드베이스의 컴포넌트와 일치합니다. 이는 이미 매칭되는 UI 컴포넌트가 존재하기 때문에 개발 팀이 디자인을 구현하기 더 쉽게 해줍니다.

이 접근 방식에서는 개발자가 여전히 앱의 뼈대를 만들고, 레이아웃을 생성하며, 명세에 맞춰 컴포넌트를 추가로 구성하기 위해 UI 코드를 작성해야 합니다. 구현이 합의된 디자인 시스템 컴포넌트를 사용하기 때문에 소통 오류의 가능성이 줄어듭니다. Storybook과 같은 솔루션은 UI 키트 컴포넌트를 개발자 컴포넌트 툴킷과 연결할 수 있게 해줍니다. 이러한 유형의 통합은 개발자 툴킷을 문서화하기 위해 소프트웨어 팀들 사이에서 인기를 얻고 있습니다.

그러나 더 큰 문제는 모든 조직이 디자인 시스템에 투자한 것은 아니라는 점입니다. 따라서 이 정도 수준의 협업은 대부분의 조직에게 있어 열망 사항입니다. 게다가 이러한 협업은 디자인 시스템 컴포넌트나 디자인 토큰을 재사용하는 데 초점을 맞춥니다. 개발자는 여전히 각 컴포넌트를 구성하고 UI를 구현해야 하며, 이는 이후 디자인 팀의 승인을 받아야 합니다.

레벨 3: UI 컴포넌트에 연결된 시각 명세

디자인 시스템은 디자인 및 개발 팀이 공통된 빌딩 블록 세트를 중심으로 표준화하는 데 도움을 줄 수 있습니다. 그러나 핸드오프의 일부로 만들어지는 산출물(즉, 디자인 산출물)은 비효율의 원천이 될 수 있습니다. 이전 섹션에서 설명했듯이, 낭비되는 노력은 개발 팀이 디자인을 구현해야 하는 데서 비롯됩니다. 더 구체적으로는 컴포넌트를 구성하고 레이아웃을 재생성하는 작업입니다.

일부 조직은 여전히 오래된 프레임워크를 사용하는 경향이 있으며, 결국 Blazor나 Angular로 마이그레이션해야 하는 시점에 이르게 됩니다. 하지만 그렇게 하면서 동시에 시장 출시 속도를 높이려 한다면 더 급진적인 솔루션이 필요합니다. 디자인 시스템을 기반으로 명세를 만들고 이를 핸드오프 산출물로 포함하는 것이 이를 처리하는 한 가지 방법입니다. 그러나 이러한 프로젝트는 다음을 포함하되 이에 국한되지 않는 다른 과제들도 극복해야 합니다.

• 디자인 시스템(즉, 합의된 빌딩 블록)을 조사하고 설계하기

• 디자인 시스템과 일치하는 컴포넌트 라이브러리를 구축하고 유지 관리하기

• 대상 플랫폼(예: Angular)에 익숙해지고 모범 사례를 반영하기

• 개발 중 도움이 될 필요한 개발자 문서 작성하기

• 애플리케이션이 시각 명세(레이아웃 + 테마)와 정확히 일치하는지 확인하기

App Builder와 같은 솔루션은 이전 섹션에서 설명한 전통적인 형태의 핸드오프(레벨 3 참조)를 대체하는 것을 목표로 합니다. 명세 문서나 목업을 공유하는 대신, 개발자는 이미 구현된 디자인 명세를 기반으로 한 앱을 받게 됩니다. 이는 명세의 일부를 검사하고 추출하여 디자인을 재구현할 필요성을 없애줍니다.

로우코드 접근 방식을 사용하여 디자이너는 Indigo.Design UI 키트를 사용해 목업을 제작합니다. 이 UI 키트는 디자인 도구(예: Figma나 Sketch)에 적합한 형식으로 디자인 시스템의 버전을 디자이너에게 제공합니다. 이를 통해 디자이너는 화면 레이아웃을 만들고 디자인 시스템이 허용하는 방식에 맞춰 컴포넌트를 구성할 수 있습니다.

목업이 완성되면 사용자는 플러그인을 사용하여 자신의 디자인을 앱으로 게시할 수 있습니다. 이 플러그인은 정적 디자인 파일을 클라우드 기반 WYSIWYG 에디터를 사용해 추가로 편집할 수 있는 앱으로 자동 변환합니다. 이 에디터는 개발자가 애플리케이션의 전체 소스 코드를 다운로드하기 전에 앱을 계속 편집할 수 있게 해줍니다.

대규모 디자인 스토리를 지원하는 App Builder의 주요 기능은 다음과 같습니다.

• Angular 및 Blazor 플랫폼용 앱 셸과 뷰 스캐폴딩

• 앱 라우팅 및 내비게이션

• 웹 레이아웃

• 글로벌 테마 및 토큰

• REST API 소스를 사용한 데이터 바인딩

• 개발을 계속하기 위한 GitHub 통합

디자인 시스템의 해부학

이제 디자인 시스템이 디자인-투-개발 스토리에서 어디에 위치하는지 더 잘 이해했으니, 이것이 어떻게 구조화되어 있는지 살펴보겠습니다.

디자인 시스템은 원자, 분자, 유기체로 가장 잘 설명할 수 있는 확장 가능한 요소를 구축하기 위한 접근 방식을 사용합니다. 이는 Brad Frost가 만든 아토믹 디자인 방법론(Atomic Design Methodology)이라고 불립니다. 이는 디자인 시스템의 구조를 설명하는 인기 있는 접근 방식이 되었습니다.

원자, 분자, 유기체의 비유로 돌아가서, 가장 작은 컴포넌트(예: 버튼, 아바타, 라벨, 헤딩 등)를 디자인하는 것부터 시작합니다. 이 가장 작은 컴포넌트를 원자라고 부릅니다.

한 단계 더 깊이 들어가면, 원자는 핵, 양성자, 중성자와 같은 입자로 구성됩니다. 디자인 시스템에서 이는 조직의 브랜드 아이덴티티를 정의하는 기본 색상 팔레트와 타이포그래피에 매핑될 수 있습니다.

원자에서 한 단계 위로 올라가면, 원자로 구성된 분자가 있습니다. 분자는 컴포넌트에 매핑될 수 있으며, 메뉴 항목, 리스트 항목, 드롭다운 항목과 같은 더 복잡한 구조를 나타냅니다.

그런 다음 레이아웃과 여러 컴포넌트를 결합하면 다음 계층 단위인 UX 패턴, 즉 생물학적 비유를 계속 사용하자면 유기체를 얻게 됩니다. 이는 “좋은” 디자인 원칙을 따름으로써 UX의 모범 사례를 캡슐화하며, 제품의 특정 요구 사항에 맞게 구축됩니다.

디자인 시스템을 원자, 분자, 유기체로 설명하는 요점은 살아있는 시스템과의 유사성을 그리기 위함입니다. 디자인 시스템은 정적이고 변하지 않는 것이 되어서는 안 됩니다 - 제품 UX 요구 사항을 반영하며 사용되는 제품 및 기술과 함께 끊임없이 진화해야 합니다. 새로운 디바이스 레이아웃 요구 사항, 새로운 제품 기능, 그리고 피할 수 없는 브랜드 아이덴티티 변화로 인해 새로운 요구 사항이 발생하며, 우리는 이러한 변화에 적응할 수 있도록 디자인 시스템이 유연하고 변화할 준비가 되어 있는지 확인해야 합니다.

디자인 시스템 사용의 이점

표준화된 UX

디자인 시스템의 가장 강력한 이점 중 하나는 다양한 디바이스, 제품, 하위 제품 전반에 걸쳐 일관성을 유지하고, 마케팅 및 브랜딩과 조율하는 것입니다.

불일치의 흔한 원인은 서로 다른 개발자와 디자이너가 제품 개발에 관여할 때입니다. 여기에 시간대를 넘나드는 업무의 점점 더 분산화되는 특성이 더해지면, 1대1 검토가 비용이 많이 들게 됩니다. 디자인 시스템이 갖춰져 있으면 디자이너와 개발자는 디자인 구현에 대한 저수준 점검 없이도 각자의 도구에서 독립적으로 작업할 수 있습니다. 대신 결과물을 둘러싼 고가치 상호작용에 집중할 수 있습니다.

순수한 고객 관점에서 보면, 동일한 조직이 제공하는 애플리케이션 전반에 걸친 의미 있는 일관성은 사용자가 앱과의 과거 상호작용에서 얻은 학습 내용을 재사용할 수 있게 해줍니다.

GitHub의 Diana Mounter는 다음과 같이 말합니다.

“디자인 시스템은 혼돈에 질서를 가져옵니다. 모든 사람이 같은 페이지를 유지하므로 전체 제품이 일관되고 세련된 상태를 유지합니다. 디자인 시스템은 익숙하고 검증된 패턴을 반복적으로 사용함으로써 사용자 경험을 개선합니다. 처음부터 무언가를 디자인하는 것은 오류의 여지를 남기므로, 이미 작동하는 것을 사용하려고 노력하세요. 디자인 시스템은 워크플로 효율성을 향상시킵니다 - 제품 팀은 새로운 기능의 컴포넌트가 어떻게 보여야 하는지, 그리고 어떻게 구현해야 하는지 정확히 알고 있습니다.”

디자인과 개발 간의 공유 어휘

일관성이 큰 이점이긴 하지만, 컴포넌트와 패턴에 대해 상호 합의된 명명 규칙과 같은 간단한 것도 큰 도움이 될 수 있습니다. 이는 디자인 시스템의 현재 사용자와 향후 합류할 구성원의 온보딩 모두에 도움이 됩니다. 명명 규칙을 명시적이고 공유되게 함으로써 개발자와 디자이너 모두 각자의 도구 환경에서 컴포넌트를 더 쉽게 찾을 수 있습니다.

시간이 지나면서 UX 패턴의 이름은 대화 속에서 나타나기 시작하며, 사용자 요구 사항의 대리 역할을 하게 됩니다. 예를 들어, 누군가 콤보 박스 컴포넌트를 사용해야 한다고 언급하면 디자이너와 개발자 모두에게 어떤 유형의 동작이 지원되고 이것이 경험 목표에 어떻게 부합하는지 명확해집니다. 디자인 시스템은 컴포넌트를 패턴으로 문서화하기 때문에, 일반적으로 특정 컴포넌트를 언제 사용해야 하는지, 그리고 예시와 함께 올바르게 사용하는 방법을 설명합니다. 그런 의미에서 디자인 시스템은 접근하기 쉬운 UX 가이드에 대한 필요를 충족시켜 디자인 관행을 전파할 수 있습니다.

디자인 프로세스와 개발 속도 향상

컴포넌트를 재사용함으로써 얻는 명시적인 이점은 전달 속도입니다. 디자인 관점에서 보면, 새로운 컴포넌트나 패턴을 만들 필요가 없다는 데서 효율성이 발생합니다. 이미 디자인 시스템 UI 키트의 일부이기 때문입니다. 새로운 복잡한 패턴을 만들어야 하는 상황에 직면하더라도, 디자이너는 디자인 시스템 가이드라인에 의존하여 이미 사용 가능한 “원자”나 “분자”를 사용해 무언가를 구축할 수 있습니다. 개발자의 관점에서는 이 컴포넌트나 패턴에 대한 코드를 생성할 수 있다는 것이 디자인 명세와 코드 간의 불일치를 피하는 데 도움이 됩니다.

학습 속도는 디자인 시스템 접근 방식을 사용함으로써 얻는 그다지 명확하지 않은 이점입니다. 이제 디자이너는 픽셀 작업에서 벗어나 진정한 디자인 프로세스로 돌아갈 수 있으며, 사용자 여정이나 흐름을 디자인하고 사용자와 함께 이를 평가하는 데 집중할 수 있습니다. 디자인 산출물을 만드는 데 사용되는 접근 방식은 [사용성 테스트](#)와 [이해관계자로부터 피드백 받기](#)를 위한 중간 프로토타입을 만드는 데도 사용될 수 있습니다.

변화하는 환경, 혹은 디자인 시스템의 미래는 자동화 및 로우코드 도구와 어떻게 얽혀 있는가?

어떤 디자인 도구를 사용하시나요?

디자인 프로세스는 때때로 필요 이상으로 복잡하고, 분산되어 있으며, 혼란스럽습니다. 이런 경우, 이는 전략적 기능이자 협업을 개선하기 위한 도구로서 디자인 시스템을 요구합니다. 앞서 논의했듯이, 디자인 시스템은 디자인과 개발을 조율하는 데 도움이 되는 일종의 지식 공유 공간(knowledge-commons) 역할을 합니다. 이는 팀이 (가능한 한) 모범 사례를 성문화할 수 있는 포럼입니다. 그리고 이는 살아있는 시스템이어야 하므로, 새로운 패턴, 요구 사항, 그리고 (프로세스 전반에 걸쳐 로우코드 앱 메이커를 사용하는 것과 같은) 코드 생성 솔루션까지도 논의되고 흡수될 기회를 제공합니다. 더 중요한 것은, 디자인 시스템은 단순한 저장소가 아니라 협업하는 방식이라는 점입니다. 이는 디자이너와 개발자가 협업할 때 직면하는 과제에 대한 만병통치약이 아닙니다. 또한 디자인 시스템이 존재한다고 해서 두 분야 간의 의미 있는 대화가 배제되는 것도 아닙니다.

많은 기업에게 가장 큰 과제는 자신들의 요구 사항과 진행 중인 디지털 전환 모두에 부합하는 관련성 있는 디자인 시스템 접근 방식으로 시작하는 것입니다. 이미 다양한 앱을 시장에 내놓은 일부 기업에게는 초기 단계가 지루한 작업입니다. 참고할 수 있는 여러 디자인 시스템이 있지만, 각각은 자신의 모기업을 위해 만들어진 것입니다. 동시에 이들은 UX 패턴과 모범 사례 측면에서 많은 공통점을 공유합니다. 따라서 조직이 맹목적으로 복사하는 대신 자신만의 디자인 시스템을 신속하게 만들 수 있도록 돕는 도구와 서비스가 필요합니다.

우리가 이야기하는 이러한 유형의 간소화된 프로세스와 일관성은 자동화를 통해, 그리고 예를 들어 디자인 라이브러리 전체에 한 번에 포괄적인 테마를 적용할 수 있게 해주는 플러그인을 통해 달성할 수 있습니다. 이는 또한 Sketch와 Figma 파일에는 보통 없는 아이디어를 설명하거나 애니메이션 및 마이크로 인터랙션을 정당화하려는 시간과 에너지를 절약하면서, 디자이너-개발자 핸드오프를 처리하는 혁신적이고 훨씬 더 효율적인 접근 방식을 가능하게 하는 것을 의미합니다.

이렇게 고도로 디지털화된 환경에서 App Builder와 같은 도구를 사용하는 것은 팀과 기업을 위한 기능적이고 효과적인 디자인 시스템의 근간이 됩니다. 이것이 디자인과 개발을 어떻게 긍정적으로 변화시키는지 더 잘 설명하기 위해, App Builder가 하는 일은 다음과 같습니다.

• Bootstrap, Fluent, Indigo용 UI 키트로 Material UI 키트를 보강합니다. 이는 디자인 팀이 어떤 인기 있는 디자인 시스템이든 타겟팅할 수 있게 해주며, 테마, 화면 부분, UI 패턴을 원활하게 App Builder로 핸드오프하여 픽셀 퍼펙트한 앱과 Angular용 코드 생성 또는 Blazor용 코드 생성을 위해 커스터마이징할 수 있습니다.

• 데이터 바인딩 및 내비게이션 컨트롤부터 Blazor 및 Angular 앱 모두를 위한 코드 생성에 이르기까지, 수많은 컨트롤 및 코드 생성 기능.

• 앱 템플릿 및 화면 레이아웃 - 앱 디자인을 빠르게 시작하고 클릭 한 번으로 반응형 페이지를 구축할 수 있도록 돕습니다. 이는 개발자에게 있어 앱 개발에서 가장 어려운 부분인 웹용 반응형 CSS를 손으로 코딩하고 실제 데이터에 바인딩된 실제 UI 컨트롤로 복잡한 인터랙티브 레이아웃을 만드는 작업을 완화해 줍니다.

디자인 시스템은 단순히 UX 모범 사례와 UI 키트에 그치지 않는다는 점에 유의해야 합니다. 개발 측면에서도 매칭되는 UI 컴포넌트가 필요합니다. 디자인 시스템 운동은 전통적으로 대규모 조직 내 디자인 팀이 주도해왔지만, 진정으로 성공하려면 개발 팀도 디자인 시스템의 공동 소유자/기여자가 되어야 합니다.

또한 원자-분자-유기체 구조는 디자인 시스템의 시작점일 뿐이며, 여기서 멈출 필요는 없습니다. 앱이 어떻게 동작해야 하는지에 대한 추가 정보를 포함할 수 있습니다. 다음은 디자인 시스템에 포함될 수 있는 잠재적 후보 목록이며, 결코 모든 것을 망라한 것은 아닙니다.

• 인터랙션 디자인 가이드는 사용자가 애플리케이션과 어떻게 상호작용할지, 제스처 기반인지 마우스 및 키보드 기반인지를 설명합니다. 해야 할 것과 하지 말아야 할 것을 개괄합니다. Google의 Material Design이 이를 매우 잘 수행합니다.

• 모션과 트랜지션은 앱을 사용할 때 역동성과 즐거움의 수준을 제공하기 위해 점점 더 흔해지고 있습니다. 하지만 개별적으로는 일부 트랜지션을 이해할 수 있더라도, 앱 전반에 걸쳐 이를 표준화하는 것이 좋습니다(예: 마스터-디테일 전환을 위한 슬라이드 트랜지션).

• 사용자 스토리는 일반적이거나 특화된 작업이 앱에서 어떻게 구현되었는지 문서화하는 데 도움이 될 수 있습니다. 새로운 디자인을 위한 영감으로 활용될 수 있습니다.

• 디자인 시스템의 서로 다른 요소들이 어떻게 함께 작동할 수 있는지 보여주는 레퍼런스 앱

따라서 디자인 시스템을 구축하고, 사용하고, 유지 관리하면 컴포넌트나 패턴을 다시 만들 필요가 없어지므로 더욱 일관된 경험으로 이어집니다. 대신, 디자이너와 개발자는 재사용을 촉진하고 유연한 디자인 자산을 제공하는 통합된 목록의 혜택을 받아 처음부터 디자인하는 데 드는 시간과 노력을 절약합니다. 디자인 시스템의 미래는 또한 일관된 타이포그래피, 색상, 보이스 앤 톤을 통해 명확한 표준과 실용적인 브랜드 준수를 지배하는 관행을 명령합니다.

하지만 그 이상의 것이 있습니다 - 오늘날의 성공적인 디자인 시스템은 다음과 같은 공통된 문화적 전환과 다른 사고방식도 필요로 합니다.

• 교차 기능성을 함양하여 디자이너와 개발자 모두가 아이디어와 결과를 더 잘 전달하고, 최종 제품의 품질을 향상시키며, 팀이 함께 만들어내는 영향력을 증대시킵니다.

• App Builder와 같은 도구, 시스템, 서비스를 이미 확립된 UI 및 UX 관행 주변에서 받아들여 로드맵을 다듬고, 사일로를 제거하고, 반복적인 작업을 줄이고, 단일 진실 공급원을 확립하는 데 도움을 주며, 디지털 제품 디자인 및 개발의 속도와 품질을 향상시킵니다.

왜 App Builder를 솔루션으로 선택해야 할까요?

App Builder는 팀이 디자인 시스템의 견고하고 미래에도 통하는 아키텍처를 구축하도록 돕는 것 외에도, 시간과 노력을 절약해주며 디자이너가 실제 디자인에 집중할 수 있게 해줍니다.

App Builder를 차별화하는 요소:

• 모든 기술에 대해 동일한 디자인 시스템을 따르는 서드파티 UI 키트를 보유하고 있어, 디자이너가 저희가 제공하는 특정 도구용 심볼로 디자인할 수 있으면서도 도구 선택을 자유롭게 전환할 수 있습니다.

• UI 키트 심볼 이면의 메타데이터를 활용하는 Sketch와 Figma용 네이티브 라이브러리를 나타내어, 디자인된 화면을 App Builder로 가져와 실제 컴포넌트의 관점에서 시각화할 수 있게 합니다.

• 상태를 가진 컴포넌트를 제공할 뿐만 아니라, 디자인 시스템 사용자가 컴포넌트의 구성을 변경할 때 자동으로 조정되는 템플릿과 변형도 제공합니다.

• App Builder와 함께 작동하여 웹에서 실제 컴포넌트를 생성합니다.

• 애플리케이션 구조, 뷰, 인터랙션을 정의하는 방식을 추상화합니다.

• 서로 다른 기술로 동일한 앱을 하나 가질 수 있게 해줍니다.

• 디자인을 받아 App Builder가 이해할 수 있도록 만들고, Angular나 Blazor를 위한 코드 미리보기 및 코드 생성을 가능하게 합니다(Web Components와 React는 곧 지원 예정).

• 기술 전반에 걸친 공통 패턴을 정의합니다.

• UI 키트, App Builder, 또는 기타 서드파티 플러그인 위에서 디자인 도구 파서에 의해 생성됩니다.

• 테마, 브랜딩, 그리고 추가 커스터마이징 옵션을 위한 강력한 메커니즘을 갖추고 있습니다.

• Material, Bootstrap, Fluent를 위한 뚜렷한 변형을 제공하여 이러한 프레임워크와 똑같은 느낌과 모양을 제공합니다.