디자인 시스템: 구성 요소, 토큰 및 문서화의 인공 지능

이득:

인공 지능을 사용하여 일관된 디자인 토큰, 구성 요소 명명 및 사용 규칙 초안을 작성하고 만드는 능력
구성 요소 문서를 신속하게 생성하고, 인공 지능을 사용하여 예제를 작성하고 사용하지 않는 기능
기존 디자인 시스템과의 충돌에 대한 인공지능 제안을 확인하고 특이점을 보존하는 기능

디자인 시스템은 재사용 가능한 구성요소(버튼, 카드, 양식 필드), 디자인 토큰(색상, 간격, 타이포그래피와 같은 값의 정의로 명명됨), 사용 방법을 설명하는 문서 등 제품군의 모양과 동작을 일관되게 만드는 공통 언어입니다. 좋은 디자인 시스템은 10명의 디자이너가 동일한 제품을 마치 단일 소스에서 생산된 것처럼 디자인할 수 있게 해줍니다. 이 시스템을 설치하고 유지 관리하는 것은 피곤하고 반복적이며 텍스트 집약적인 작업입니다. 인공지능이 빛을 발하는 곳이 바로 여기다. 그러나 시스템의 본질은 특이성과 일관성입니다. AI의 추천은 현재 시스템과의 충돌 여부를 확인하지 않고서는 받아들일 수 없습니다.

토큰 및 명명: 일관성의 기초

디자인 토큰은 디자인 결정의 재사용 가능한 명명된 값입니다(원색, 공백 중심, 텍스트 제목-대문자). 토큰 덕분에 한 곳에서 색상을 변경하고 전체 제품에 걸쳐 업데이트할 수 있습니다. 그러나 토큰의 힘은 명명의 일관성에 달려 있습니다. blue-1, main-blue,primaryBlue를 혼합하여 사용하면 시스템이 충돌합니다.

AI는 여기서 두 가지 일에 능숙합니다. 일관된 명명 체계에 대해 기존 토큰 세트를 검토하고 새 토큰에 대해 스키마를 준수하는 이름을 제안하는 것입니다. "이 토큰 목록을 의미론적(의미 기반) 명명으로 변환"과 같은 요청은 blue-500 대신 color-action-primary와 같이 의미를 전달하는 이름을 생성하는 데 도움이 됩니다. 그러나 최종 명명 결정은 팀의 계약입니다. 모델은 개요만 제공합니다.

팁: AI에 토큰 이름을 지정할 때 현재 구성표의 5~6가지 예를 제시하고 "동일한 패턴을 유지"라고 말합니다. 샘플 없는 요청은 시스템에 맞지 않는 이름을 생성합니다.

구성요소 문서화: AI의 가장 생산적인 영역

구성 요소의 문서에는 구성 요소의 기능, 사용 시기, 사용하지 않는 시기, 변형, 상태(기본값, 가리키기, 수동적, 오류), 접근성 참고 사항 및 "해야 할 일/하지 말아야 할 일" 예가 포함됩니다. 이러한 텍스트를 손으로 작성하는 데는 몇 시간이 걸리기 때문에 많은 팀에서 문서화를 무시합니다.

AI는 이러한 격차를 해소합니다. 구성 요소를 설명하면 초안 문서, 사용 규칙, 해야 할 일/하지 말아야 할 예가 일관된 형식으로 생성됩니다. 따라서 문서화는 "없음"에서 "초안이 있으므로 수정될 것"으로 바뀌는데, 이는 큰 이득입니다. 그러나 모델은 구성 요소의 실제 동작을 알지 못합니다. 그것이 생성하는 규칙을 시스템의 현실과 일치시키는 것이 당신의 임무입니다.

문서 조각

인공지능의 투고

인간의 검증

그것은 무엇을 합니까?

명확한 개요 정의

목적에 대한 진정한 적합성

언제 사용하나요?

일반 시나리오

제품별 규칙

해야 할 일/하지 말아야 할 일의 예

빠른 초안 쌍

실제 오용

접근성 참고 사항

표준 알림

실제 테스트로 확인됨

변형/사례 목록

가능한 목록

실제로 시스템에 존재하는 사람들

모순 검사: 특이점 보존

디자인 시스템의 가장 큰 적은 중복입니다. 동일한 작업을 수행하는 두 개의 버튼, 두 개의 서로 다른 공간 규모, 두 개의 상충되는 규칙입니다. AI가 새로운 구성 요소나 규칙을 제안하면 해당 제안은 기존 시스템과 충돌할 수 있습니다. 전체 모델 시스템을 염두에 두지는 않습니다. 그래서 나는 "이것이 이미 존재하는 것과 충돌합니까?"라고 질문하여 각 제안을 평가합니다. 질문으로 필터링합니다. 충돌 검색에 인공 지능을 사용할 수도 있습니다. 현재 시스템 요약과 새로운 권장 사항을 제공하고 충돌을 나열할 수 있습니다. 그러나 최종적인 "단일 올바른" 결정은 팀에 달려 있습니다.

세 개의 미니 케이스

사례 1 — 문서 부채가 청산되었습니다. 팀의 24개 구성 요소 중 6개에만 문서가 있었습니다. 나머지 18개 구성요소에 대해서는 인공지능을 이용해 초안 문서가 제작됐다. 팀은 각 문제를 10~15분 안에 해결했습니다. 몇 주 동안 미뤄졌던 작업이 이틀 만에 완료됐다.

사례 2 - 토큰 이름 지정이 일관되게 되었습니다. 한 시스템에서는 색상이 blue1, mainBlue, Brand-blue처럼 혼합되었습니다. AI는 기존 40개의 토큰을 의미 체계로 변환했습니다. 팀은 이를 개정하여 단일 표준으로 전환했습니다. 후속 디자인에서는 색상 오류가 눈에 띄게 감소했습니다.

사례 3 - 충돌하는 구성 요소가 거부되었습니다. AI는 '보조 액션 버튼'이라는 새로운 구성요소를 제안했습니다. 팀이 모순점을 검색했을 때 기존 "고스트 버튼"과 동일한 작업을 수행한다는 사실을 발견하고 제안을 거부했습니다. 교훈: 모든 제안이 시스템에 새로운 구성 요소를 추가하는 것은 아닙니다. 때로는 사용 가능한 것을 사용하는 것이 옳습니다.

복사 가능한 프롬프트

이 토큰 목록을 의미론적(의미 기반) 명명 체계로 변환합니다. 내 현재 스키마 예: <<5-6 예>>. 같은 패턴으로 계속하세요. 각 토큰에 대해 이전 이름 -> 새 이름 -> 정당화 테이블을 제공합니다. 목록: <<토큰>>

모순 검색: 현재 설계 시스템 요약: <<summary>>. 새로 제안된 구성 요소/규칙: <<제안>>. 이 제안이 기존 시스템(동일한 작업을 수행하는 구성 요소, 충돌하는 규칙, 중복 토큰)과 충돌합니까? 갈등과 제안 사항을 나열하십시오.

이 구성요소에 대해 "해야 할 일/하지 말아야 할 일" 예제 쌍을 생성합니다(현실적으로 올바른 사용 및 현실적으로 잘못된 사용 시나리오). 각 쌍에 대해 그것이 참/거짓인 이유를 한 문장으로 설명하십시오. 구성요소: <<이름 및 목적>>

약한 프롬프트 / 강한 프롬프트

약함: "이 버튼에 대한 문서를 작성하세요."

결과: 시스템과 연결되지 않은 일반 형식의 텍스트입니다.

Strong: "이 버튼을 다음 형식으로 문서화하세요(기능/사용하지 않는 경우/변형/사례/접근성/하지 말아야 할 일). 모르는 동작을 구성하고 '팀이 작성해야 함'이라고 작성하세요."

결과: 일관된 형식, 적절한 간격, 편집 가능한 원고.

차이점: 강력한 프롬프트 형식 + 제작 금지 + 프롬프트 수행/하지 않음.

일반적인 실수

예시 없이 토큰 이름 지정을 요청합니다. 모델은 시스템에 낯선 이름을 생성합니다. 일관성이 깨졌습니다.
모순을 검사하지 않고 구성 요소를 추가합니다. 복제는 시스템의 최대의 적입니다.
모델이 고안한 동작이 정확하다고 가정합니다. AI는 구성요소의 실제 동작을 알지 못합니다.
테스트 없이 접근성 등급을 수락합니다. 표준 알림은 실제 테스트를 대체할 수 없습니다.
문서를 한 번 작성하고 업데이트하지 않습니다. 시스템이 변경되면 문서를 업데이트해야 합니다.

요약하면

디자인 시스템은 일관성과 확장성의 인프라입니다. 그러나 텍스트 집약적이고 반복적이기 때문에 유지 관리가 종종 무시됩니다. AI는 구성 요소 문서, 해야 할 일/하지 말아야 할 예, 사용 스크립트 및 토큰 명명 초안을 신속하게 생성하여 이러한 부채를 해결합니다. 그러나 시스템의 본질은 특이성과 일관성입니다. 모든 토큰 이름은 샘플 스키마에 대해 확인되어야 하고, 모든 구성 요소 제안은 모순된 내용을 검사해야 하며, 동작에 대한 모든 설명은 현실과 비교하여 확인되어야 합니다. 모델을 효율적인 제도자로 사용하십시오. 팀은 개인의 올바른 결정을 내립니다.

응용과제

문서가 누락된 구성 요소를 선택하고 첫 번째 프롬프트가 포함된 초안 문서를 생성합니다.
실제 동작으로 "팀이 작성해야 함"이라고 표시된 필드를 완성합니다.
두 번째 프롬프트에서는 8-10 토큰을 의미 체계로 변환하고 이전/새 이름 테이블을 만듭니다.
새로운 구성 요소 아이디어를 얻으려면 세 번째 프롬프트에서 모순을 검색하세요.
네 번째 프롬프트를 사용하여 구성 요소에 대한 예제 쌍을 생성하고 시스템에 추가합니다.

체크리스트

[ ] 토큰 이름 지정을 예제 스키마에 연결했습니다.
[ ] 충돌이 있는지 새 구성 요소를 검사했습니다.
[ ] 모델이 만든 행동을 현실과 검증했습니다.
[ ] 접근성 주의사항은 실제 테스트를 통해 확인해 볼 계획이었습니다.
[ ] 나는 문서를 일관된 형식으로 유지했습니다.
[ ] 특이점을 유지하고 중복을 방지했습니다.