5.2 UI 디자인과 디자인 시스템

개요와 동기

사용자 인터페이스(UI) 디자인은 사람들이 보고 만지는 것, 곧 레이아웃, 타이포그래피, 색, 간격, 컨트롤, 상태를 빚는 기술입니다. 디자인 시스템은 그 기술을 공유되고, 재사용 가능하고, 다스려지는 자산으로 바꿉니다. 모든 팀이 끌어 쓰는 문서화된 원칙, 컴포넌트, 패턴, 토큰의 집합으로, 제품 전체가 하나처럼 보이고 동작하게 합니다. UI 디자인은 한 화면이 어떻게 보여야 하는지 결정합니다. 디자인 시스템은 많은 팀에 걸친 만 개의 화면이 어떻게 일관되게 유지되는지 결정합니다.

대규모 조직에게 디자인 시스템은 UI 품질과 전달 속도에서 지렛대 효과가 가장 큰 단일 투자입니다. 하나가 없으면 모든 팀이 버튼, 양식, 모달, 오류 처리를 다시 발명하고, 각각 조금씩 다르고, 따로 유지되고, 따로 깨집니다. 사용자는 혼란과 불신으로 이 값을 치르고, 비즈니스는 중복된 노력과 고르지 않은 품질로 치릅니다. 디자인 시스템은 일회성 디자인 결정을 재사용 가능한 자본으로 바꿉니다. 접근성, 반응형, 브랜딩을 컴포넌트에서 한 번 해결하면 모든 팀이 결과를 상속합니다.

기업과 정부는 두 가지 구체적 압력을 더합니다. 첫째 규모입니다. 많은 것이 벤더가 만들었거나 합병으로 인수된 수백 개의 애플리케이션이 모두 한 조직처럼 느껴져야 합니다. 둘째 수명과 변화입니다. 브랜드는 갱신되고, 기관은 재편되고, 하나의 플랫폼이 하나의 코드베이스에서 여러 브랜드나 하위 기관을 섬겨야 할 수 있습니다. 적절한 테마화와 토큰화를 갖춘 잘 설계된 디자인 시스템은 이런 광범위한 변화를 파국이 아니라 다룰 만한 것으로 만듭니다.

핵심 원칙

일관성은 인지 부하를 낮춥니다. 버튼은 어디서나 같게 보이고 동작해야 합니다.
디자인 결정은 자산입니다. 재사용 가능한 컴포넌트와 토큰으로 한 번 포착하십시오.
토큰이 시각적 결정의 진실 원천입니다. 컴포넌트는 토큰을 소비하며, 하드코딩된 값은 절대 쓰지 않습니다.
접근성과 반응성은 화면마다 덧붙이는 것이 아니라 컴포넌트에 짜 넣습니다.
디자인 시스템은 일회성 산출물이 아니라 사용자(개발자와 디자이너)가 있는 제품입니다.
시각적 위계가 주의를 이끕니다. 글자, 색, 공간이 중요도를 분명하게 해야 합니다.
거버넌스가 시스템을 일관되게 유지하고, 기여가 시스템을 살아 있게 유지합니다.

권장 사항

시스템을 토큰, 컴포넌트, 패턴의 계층으로 구조화한다

디자인 토큰은 색, 간격, 타이포그래피, 반경, 고도, 모션에 대한 이름 붙은 플랫폼 중립적 값, 곧 원자적 결정입니다. 단계로 구축하십시오. 원시 팔레트(날것의 값), 의미를 지닌 시맨틱 토큰(color-action-primary, space-inset-md), 필요한 곳의 컴포넌트 수준 토큰입니다. 컴포넌트는 시맨틱 토큰을 소비하므로 단일 변경이 어디서나 전파됩니다. 컴포넌트 위에 패턴이 있습니다. 데이터 테이블, 다단계 양식, 빈 상태 같은 검증된 구성입니다. 세 계층 모두를 라이브 예시와 사용 지침과 함께 한 곳에 문서화하십시오.

시각적 기본기를 맞게 한다

읽기 쉬움을 위한 분명한 위계와 넉넉한 줄 간격을 가진 타이포그래피 스케일을 설정하고, 제한된 크기와 굵기 집합을 지키십시오. UI 곳곳에 흩어진 날것의 색조가 아니라, 접근성을 위한 충분한 대비(접근성 장 참조)와 시맨틱 역할을 가진 시스템으로 색을 정의하십시오. 화면마다의 추측 없이 정렬과 리듬이 일관되게 유지되도록 간격 스케일과 레이아웃 그리드를 쓰십시오. 시각적 위계는 주된 행동과 가장 중요한 정보를 한눈에 분명하게 해야 합니다.

반응형과 모바일 우선으로 설계한다

합리적으로 가장 작은 뷰포트를 먼저 설계한 뒤 더 큰 화면을 위해 확장하십시오. 이는 필수 콘텐츠와 컨트롤의 우선순위를 정하게 합니다. 몇 개의 고정 중단점 사이를 딱딱 끊기는 대신 어떤 화면에도 인터페이스가 적응하도록 유동적 레이아웃과 상대 단위를 쓰십시오. 터치 대상을 충분히 크게 하고, 상호작용이 터치, 마우스, 키보드에서 동작하게 하십시오. 특히 정부에서는 사용자의 상당한 몫이 작거나, 오래되었거나, 저가 기기를 쓴다고 가정하십시오.

디자인-개발 인계와 동등성을 일급 관심사로 만든다

디자인 시스템은 출하된 UI가 의도한 디자인과 맞고 계속 맞을 때만 보답합니다. 단일 진실 원천을 목표로 하십시오. 디자인 도구에서 내보낸 토큰이 코드에 직접 공급되어 디자이너와 엔지니어가 같은 값을 참조합니다. 엔지니어가 실제로 쓸 코드 컴포넌트 라이브러리를 디자인 컴포넌트와 같은 이름과 props로 제공하십시오. 시각적 회귀 테스트(렌더링된 UI를 승인된 기준 이미지와 자동 비교)와 디자인 리뷰 검사로 표류를 잡으십시오. 그리고 “디자인-코드 동등성”을 명시적 건강 지표로 측정하십시오. 시스템 컴포넌트로 만든 UI와 일회성 코드의 비율입니다.

기업 규모에서 테마화와 화이트 라벨링을 지원한다

여러 브랜드가 필요할 가능성이 조금이라도 있다면 처음부터 그를 위해 아키텍처를 만드십시오. 컴포넌트가 시맨틱 토큰을 소비하므로 테마는 그저 다른 토큰 값 집합이며, 브랜드 갱신이나 새 하위 브랜드는 코드 재작성이 아니라 데이터 변경이 됩니다. 같은 메커니즘으로 라이트 및 다크 테마, 고대비 모드, 테넌트별 브랜딩을 지원하십시오. 브랜드 전용 로직은 컴포넌트에서 빼고 토큰 집합과 설정으로 밀어 넣으십시오.

시스템을 제품으로 다스린다

디자인 시스템에 전담 팀, 로드맵, 버전 관리, 변경 로그, 지원 채널을 주십시오. 팀이 새 컴포넌트를 기여하는 방법과 그것이 어떻게 리뷰되고 승격되는지 분명히 하십시오. 중앙 통제(일관성과 접근성 보존)와 기여 모델(시스템이 병목이 되지 않고 실제 필요에 따라 진화)의 균형을 잡으십시오. 폐기와 이전을 분명히 알리고, 사용하는 팀에게 충분한 리드 타임을 주십시오.

장단점

결정	장점	단점
디자인 시스템 구축	일관성, 속도, 접근성 한 번에, 더 쉬운 리브랜드	선행 및 지속 비용. 전담 팀 필요
기성 시스템 채택	빠른 시작. 검증된 패턴	일반적인 모양. 고유한 브랜드와 필요에 맞추기 더 어려움
엄격한 중앙 거버넌스	일관성, 품질, 접근성 보장	팀을 병목으로 만들 수 있음. 관료적으로 느껴짐
열린 기여 모델	실제 필요로 진화. 공유된 소유권	리뷰 없이는 표류와 일관성 없음 위험
무거운 토큰화와 테마화	싼 리브랜드와 다중 브랜드 지원	더 많은 추상화. 더 가파른 학습 곡선

디자인 시스템은 선행 및 거버넌스 비용을 장기적 일관성과 속도와 맞바꿉니다. 한 팀의 작은 제품에서는 오버헤드가 본전을 뽑지 못할 수 있습니다. 많은 팀과 오래 사는 제품을 가진 대규모 조직에서 질문은 시스템을 가질지가 아니라 얼마를 투자하고 어떻게 다스릴지입니다. 가장 흔한 후회는 거버넌스와 동등성 도구에 투자를 덜 한 것입니다. 시스템은 서류상으로 존재하지만 팀이 조용히 그것에서 멀어집니다.

팀과 논의할 질문

토큰 아키텍처는 어떻게 계층화되어 있으며, 컴포넌트가 하드코딩된 값을 쓰는 것이 금지되어 있습니까? 디자인 시스템의 모든 수익(싼 리브랜드, 다중 브랜드 테마화, 한 번에 해결되는 접근성)은 컴포넌트가 코드 곳곳에 흩어진 날것의 색조와 픽셀 값이 아니라 color-action-primary 같은 시맨틱 토큰을 소비하는 데 달려 있습니다. 지금 단계를 결정하십시오. 원시 팔레트, 의미를 지닌 시맨틱 토큰, 정말 필요한 곳에만 컴포넌트 수준 토큰입니다. 과도한 추상화는 실제 위험이므로, 몇 계층이 너무 많은지, 개발자가 알맞은 토큰을 어떻게 빨리 찾는지 합의하십시오. 표류의 증거로 코드베이스 전반의 하드코딩된 색과 간격을 grep한 결과를 가져오십시오. 브랜드 로직이 컴포넌트에 구워져 있으면 리브랜드는 설정 변경이 아니라 코드 재작성이 되며, 이것이 토큰화가 막으려고 존재하는 바로 그 재앙입니다.
디자인-코드 동등성을 어떻게 측정하고 방어하며, 어떤 도구가 표류를 자동으로 잡습니까? 디자인 파일로만 존재하는 디자인 시스템은 스티커 시트입니다. 엔지니어는 어차피 모든 것을 다시 만들고 출하된 UI는 의도에서 서서히 갈라집니다. 명시적 동등성 지표(시스템 컴포넌트로 만든 UI와 일회성 코드의 비율)에 합의하고, 렌더링된 화면이 승인된 기준과 비교되도록 시각적 회귀 테스트를 CI에 연결하십시오. 기업과 정부 규모에서 이것이 중요한 이유는, 벤더가 만들었거나 합병으로 물려받은 경우가 많은 수백 개의 애플리케이션이 모두 한 조직처럼 느껴져야 하기 때문입니다. 현재 동등성 수치와 팀이 계속 다시 만드는 상위 맞춤 컴포넌트 목록을 가져오십시오. 아무도 지표나 회귀 스위트를 소유하지 않는다면 표류가 이미 조용히 이기고 있습니다.
시스템이 팀을 병목으로 만들지도 쪼개지지도 않도록 기여, 폐기, 이전을 어떻게 다스립니까? 엄격한 중앙 통제는 일관성과 접근성을 보장하지만 디자인 시스템 팀을 팀이 우회하는 병목으로 만들 수 있고, 열린 기여는 시스템을 살려 두지만 리뷰 없는 갈라진 변형의 위험이 있습니다. 기여 경로를 결정하십시오. 팀이 새 컴포넌트를 어떻게 제안하고, 누가 리뷰하고, 어떻게 승격되는가. 마찬가지로, 호환 파괴 변경을 어떻게 알릴지 합의하십시오. 이전 지원과 리드 타임 없는 폐기는 사용하는 팀이 멈추거나 포크하게 만듭니다. 팀이 시스템 밖에서 만든 컴포넌트의 예를 가져와 왜 되돌려 기여하지 않았는지 물으십시오. 답은 대개 거버넌스가 서비스인지 장애물인지 드러냅니다.
접근성이 컴포넌트 안에서 한 번에 해결됨을 어떻게 보장하며, 팀이 접근할 수 없는 일회성 컴포넌트를 출하하는 것을 무엇이 막습니까? 디자인 시스템에 대한 가장 강한 논거는 색 대비, 포커스 상태, 키보드 조작, 스크린 리더 의미가 한 번 해결되어 어디서나 상속된다는 것이지만, 그 약속은 팀이 자체 컨트롤을 손으로 만드는 순간 무너집니다. 대규모 조직에서 가장 큰 법적, 평판 위험이 있는 곳이 여기입니다. 접근할 수 없는 결제 양식이나 날짜 선택기 하나가 실제 사용자를 막고 그것을 복사한 모든 제품에 걸친 불만을 촉발할 수 있기 때문입니다. 중앙 시행(접근 가능한 컴포넌트에 날것의 마크업을 거부하는 린터나 리뷰 관문)과 팀 자율을 저울질하고, 단단한 선이 어디인지 결정하십시오. 접근성 감사 결과, 적합성 상태가 있는 컴포넌트 목록, 팀이 시스템 밖에서 다시 만든 맞춤 컨트롤의 수를 가져오십시오. 기업과 정부 환경에서 이는 호의가 아닙니다. WCAG, Section 508, EN 301 549 같은 의무가 적합성을 조달과 감사 요건으로 만들므로, 문서화된 적합성을 갖춘 컴포넌트 라이브러리는 그 자체로 컴플라이언스 자산입니다.
이 시스템이 섬겨야 하는 브랜드, 테넌트, 테마는 몇 개이며, 나중에 사후 보강하는 대신 지금 토큰 계층을 그에 맞춰 설계했습니까? 테마화는 그를 위해 설계했다면 싸고 그러지 않았다면 잔혹합니다. 예상하지 못한 브랜드나 테넌트는 브랜드 로직을 컴포넌트로 되돌려 보내 토큰화의 요점 전체를 무효로 하기 때문입니다. 큰 팀에서 이 결정은 여러 해의 작업을 형성합니다. 여러 브랜드, 라이트 및 다크 테마, 고대비 모드, 테넌트별 브랜딩을 섬겨야 하는 플랫폼에는 테마가 그저 다른 값 집합이 될 만큼 깨끗한 시맨틱 토큰 계층이 필요합니다. 그 유연성을 과도한 추상화와 균형 잡으십시오. 아무도 탐색할 수 없는 토큰 트리는 그 자체로 실패입니다. 예상할 수 있는 브랜드와 테넌트의 로드맵, 오늘 쓰이는 테마 수, 이미 브랜드 전용 로직이 새는 컴포넌트를 가져오십시오. 기업과 정부 맥락에서 합병, 인수, 기관 재편이 계획하지 않은 브랜드를 일상적으로 더하므로, 처음부터 다중 브랜드를 위한 아키텍처를 만드는 것이 데이터 변경과 다년간 재작성의 차이입니다.
레거시와 벤더가 만든 애플리케이션을 어떻게 시스템으로 이전하며, 디자인 시스템 팀은 다음 예산 주기를 어떻게 견디도록 재원을 대나요? 디자인 시스템은 실제 제품이 채택할 때만 수익을 주지만, 변환하기 가장 어려운 애플리케이션이 그것이 가장 필요한 오래되고 외주된 것이며, 시스템을 유지하는 팀은 예산이 빠듯해질 때 가장 먼저 잘리는 경우가 많습니다. 대규모 조직에서는 빅뱅 이전과 점진적 이전 중 어느 것을 택할지, 벤더가 여러분의 컴포넌트를 우회하지 않고 그 위에 만들게 하려면 어떻게 할지 결정해야 합니다. 현재 동등성 점수가 있는 애플리케이션 목록, 애플리케이션별 이전 노력 추정, 벤더에 대해 쥔 계약상 지렛대를 가져오십시오. 기업과 정부 환경에서는 디자인 시스템 적합성을 조달 조건에 써서 새 벤더 작업이 기본으로 시스템 위에 올라가게 하고, 유지 팀을 내구성 있는 공유 인프라로 재원을 대십시오. 재편에서 관리자를 잃은 시스템은 1년 안에 파편화로 되돌아가 표류하기 때문입니다.

분야별 관점

스타트업. 엔지니어 두세 명과 여유 없는 런웨이로는 다스려지는 시스템을 만들지 마십시오. 하루나 이틀을 들여 색, 간격, 글자에 대한 소수의 시맨틱 토큰과 열두 개쯤의 공유 컴포넌트를 팀 전체가 참조하는 하나의 파일에 정의하십시오. 어려운 부분은 기성 프리미티브 라이브러리에 기대고, 아무것도 하드코딩하지 않아 첫 진짜 리브랜드가 재작성이 아니라 토큰 변경이 되게 하십시오.

소기업. 전담 디자이너도 빠듯한 예산도 없으니 만들지 말고 사십시오. 검증된 컴포넌트 라이브러리나 UI 키트를 채택해 브랜드에 가볍게 테마를 입히십시오. 목표는 디자인 시스템 팀에 인력을 대지 않고도 일관되고 접근 가능한 제품이므로, 접근성과 반응성을 기본으로 출하하는 시스템을 선호하십시오. 포크하고 싶은 충동에 저항하십시오. 유지할 수 없는 맞춤 사본은 상류 프로젝트가 움직이는 순간 부채가 되기 때문입니다.

대기업. 문제는 많은 팀과 오래 사는 제품에 걸친 일관성이므로, 디자인 시스템을 전담 팀, 버전 관리, 로드맵이 있는 다스려지는 공유 인프라로 다루십시오. 디자인-코드 동등성을 진짜 지표로 추적하고, 시각적 회귀 테스트를 CI에 연결하고, 처음부터 여러 브랜드와 테마를 위해 토큰 계층을 설계하십시오. 거버넌스와 이전 비용을 명시적으로 예산에 넣고, 팀이 저절로 시스템으로 표류하리라 가정하지 말고 채택을 포트폴리오로 관리하십시오.

정부. 조달 규칙, 투명성, 공적 책임성이 모든 선택을 형성합니다. WCAG, Section 508, EN 301 549 같은 표준에 대한 접근성 적합성은 선호가 아닌 법적 요건이므로, 문서화된 적합성을 갖춘 컴포넌트 라이브러리가 컴플라이언스 자산이 됩니다. 시민이 서비스 전반에서 같은 패턴을 만나도록 공유 공공 디자인 시스템을 선호하거나 확장하고, 디자인 시스템 사용을 벤더 계약에 쓰고, 기관과 그 공급자가 채택하고 책임질 수 있도록 컴포넌트와 지침을 공개하십시오.

사례

스타트업. 두 엔지니어의 스타트업은 새 화면마다 버튼과 양식 필드를 조금씩 다르게 다시 만들었고, 제품이 이어 붙인 것처럼 보이기 시작했습니다. 무거운 시스템 대신 이틀을 들여 색, 간격, 글자에 대한 소수의 시맨틱 디자인 토큰과 열두 개쯤의 공유 컴포넌트를 팀 전체가 참조하는 하나의 파일에 정의했습니다. 아무것도 하드코딩되지 않았으므로, 디자인 감각이 있는 첫 신규 채용자가 더 깔끔한 팔레트를 제안했을 때 갱신은 화면마다 힘겹게 하는 일이 아니라 앱 전체에 한나절 만에 닿는 토큰 변경이었습니다.

대기업. 수십 개 제품 팀을 가진 한 글로벌 소프트웨어 회사가 공유 코드 컴포넌트 라이브러리를 갖춘 토큰화된 디자인 시스템을 구축했습니다. 시맨틱 토큰 덕에 수천 개의 하드코딩된 색 편집이 아니라 새 토큰 집합이라는 변경이었기에, 팀마다 여러 해가 걸렸을 전체 브랜드 갱신을 모든 제품에 걸쳐 몇 주 만에 출하할 수 있었습니다. 대시보드 지표로 추적한 디자인-코드 동등성은 팀이 맞춤 컴포넌트를 대체하면서 올랐고, 중복된 UI 유지보수를 줄였습니다.

정부. 한 국가 정부가 기관 전반에 의무화된 공공 서비스 공통 디자인 시스템(공유 컴포넌트, 패턴, 내장된 접근성)을 만들었습니다. 세금 서비스, 건강 서비스, 면허 서비스 사이를 옮겨 다니는 시민은 같은 헤더, 양식 컨트롤, 오류 패턴을 만나 신뢰를 쌓고 학습 곡선을 줄입니다. 기관과 그 벤더는 어려운 문제가 중앙에서 해결되므로 더 빠르고 더 접근 가능하게 출하하며, 정부는 지침이나 접근성 수정을 한 번 갱신하면 어디서나 전파되게 할 수 있습니다.

비즈니스 사례: 동기, ROI, TCO

디자인 시스템의 ROI는 중복을 없애고 전달을 빠르게 하는 데서 옵니다. 모든 팀이 같은 컴포넌트를 설계하고 만드는 대신 공유 라이브러리에서 조합하므로 전달이 측정 가능하게 빨라지고, 디자이너와 엔지니어가 제품 고유의 작업에 쓰일 수 있습니다. 컴포넌트에서 한 번 해결한 접근성과 반응성은 프로젝트별 시정 비용을 아껴 줍니다. 한때 여러 해 걸리던 리브랜드와 테마화가 이제 몇 주 걸립니다.

TCO에서 도입 비용은 전담 팀, 도구, 기존 제품이 시스템으로 이전하는 노력입니다. 도입하지 않는 비용은 지속적으로 치러집니다. 팀 전반의 중복된 구축과 유지보수, 지원과 법적 위험을 만드는 일관성 없고 접근할 수 없는 UI, 느리고 비싼 리브랜드입니다. 중복이 많은 팀의 예산에 퍼져 있으므로 간과하기 쉽습니다. 디자인 시스템은 그 숨은 비용을 보이게 하고 한 곳에 담습니다.

리더십을 설득하려면 팀 전반의 중복된 컴포넌트 작업, 조합이 주는 출시 시간 이득, 마지막 리브랜드의 비용과 기간 대 토큰화된 시스템이 허용할 것을 정량화하십시오. 시스템을 측정 가능한 채택 지표(동등성 비율)를 가진 공유 인프라로 구성해, 가치가 단지 주장되는 대신 시간에 따라 추적되게 하십시오.

안티패턴과 함정

스티커 시트로서의 디자인 시스템: 코드 컴포넌트가 없는 정적 디자인 파일로, 엔지니어가 어차피 모든 것을 다시 만드는 것.
어디서나 하드코딩된 값: 코드 곳곳에 흩어진 색과 간격으로, 테마화와 리브랜드를 불가능하게 하는 것.
거버넌스 없음: 팀이 갈라진 변형을 추가함에 따라 시스템이 쪼개지고 일관성이 침식되는 것.
기여 없는 거버넌스: 중앙 팀이 병목이 되어 팀들이 우회하는 것.
동등성 무시: 코딩된 UI가 디자인 의도에서 표류하는데 아무도 간극을 측정하지 않는 것.
과도한 추상화: 아무도 알맞은 것을 찾거나 쓸 수 없을 만큼 많은 토큰과 계층.
컴포넌트에 구워진 브랜드 로직: 다중 브랜드와 테마화를 설정 변경이 아닌 코드 재작성으로 만드는 것.
이전 지원 없는 호환 파괴 변경: 사용하는 팀이 멈추거나 시스템을 포크하는 것.

성숙도 모델

1단계: 시작. 각 팀이 UI를 즉흥적이고 반응적으로 만듭니다. 공유 컴포넌트가 없고, 모양과 동작이 일관되지 않으며, 색과 간격이 화면마다 하드코딩되어 있습니다. 모든 리브랜드는 화면마다 수동으로 힘겹게 하는 일입니다.

2단계: 발전. 공유 스타일 가이드나 컴포넌트 라이브러리가 있지만 부분적이고, 선택적이고, 디자인과 코드 사이에서 어긋나는 경우가 많습니다. 일부 팀은 쓰고 다른 팀은 쓰지 않으며, 기본 실천이 팀마다 크게 다릅니다.

3단계: 표준화. 유지되는 코드 라이브러리, 문서, 거버넌스를 갖춘 토큰화된 디자인 시스템이 문서화되어 조직 전체에서 시행됩니다. 컴포넌트가 시맨틱 토큰을 소비하고, 테마화가 지원되며, 접근성과 반응성이 화면마다 덧붙이는 것이 아니라 짜 넣어져 있습니다.

4단계: 관리. 시스템이 기준선에 대한 데이터로 측정되고 통제됩니다. 디자인-코드 동등성이 제품별 목표와 함께 명시적 지표로 추적되고, 표류를 잡도록 시각적 회귀 테스트가 CI에서 돌며, 접근성 적합성이 가정이 아니라 표준에 대해 측정됩니다. 채택 대시보드가 팀별 컴포넌트 커버리지를 보여 주고, 리브랜드의 비용과 기간이 기록되어 개선이 시간에 따라 보입니다.

5단계: 오케스트레이션. 디자인 시스템이 조직 전체에 통합되고 변화에 적응하는, 지속적으로 개선되는 제품입니다. 버전 관리, 로드맵, 동작하는 기여 모델이 있어 실제 필요와 함께 진화합니다. 리브랜드와 새 테마는 일상적인 토큰 변경이고, 다중 브랜드와 다중 테넌트 테마화가 일반적이며, 팀은 사용 데이터의 증거로 패턴을 퇴역시키고, 범위를 다시 정하고, 승격시키며, 단일 진실 원천에서 디자인 도구와 전달 파이프라인에 공급합니다.

논의를 위한 아이디어

쪼개지거나 병목이 되지 않으면서 중앙 거버넌스와 팀 자율의 균형을 어떻게 잡습니까?
“디자인-코드 동등성”의 알맞은 지표는 무엇이며, 어떻게 정직하게 유지합니까?
팀이 시스템을 쓰는 대신 일회성 컴포넌트를 만들어도 되는 때는 언제입니까?
예산 주기와 재편을 견디도록 디자인 시스템에 어떻게 재원을 대고 인력을 구성합니까?
추가된 추상화 비용만큼 값을 하는 테마화 유연성은 얼마입니까?
레거시와 벤더가 만든 애플리케이션을 공유 시스템으로 어떻게 이전합니까?

핵심 요점

디자인 시스템은 일회성 디자인 결정을 재사용 가능하고 다스려지는 자본으로 바꿉니다.
컴포넌트가 시맨틱 토큰을 소비하는 계층(토큰, 컴포넌트, 패턴)으로 구조화하십시오.
모든 팀이 상속하도록 접근성과 반응성을 컴포넌트에 짜 넣으십시오.
디자인-코드 동등성을 가정이 아니라 측정 가능한 건강 지표로 다루십시오.
토큰화는 리브랜드와 다중 브랜드 테마화를 재작성이 아닌 데이터 변경으로 만듭니다.
로드맵, 버전 관리, 기여 모델을 갖춘 제품으로 시스템을 다스리십시오.
기업과 정부 규모에서 공유 시스템은 이용 가능한 지렛대 효과가 가장 큰 UI 투자입니다.

참고 문헌과 더 읽을거리

Brad Frost, Atomic Design
Alla Kholmatova, Design Systems: A Practical Guide to Creating Design Languages
Josef Müller-Brockmann, Grid Systems in Graphic Design
Robert Bringhurst, The Elements of Typographic Style
Ellen Lupton, Thinking with Type
Luke Wroblewski, Mobile First
Ethan Marcotte, Responsive Web Design
Nathan Curtis, writings on design tokens and design system governance
W3C Design Tokens Community Group, format specification
Government design systems (e.g., UK Government Design System, U.S. Web Design System) as reference implementations