Figma 없이 진행하는 나의 AI 프로덕트 디자인 워크플로

Figma가 없는 제품 디자인은 제품이 이미 성숙한 디자인 시스템을 갖추고 있을 때 작동합니다. 내 AI 제품 디자인 워크플로는 세 가지 에이전트 기술을 사용합니다. ui-design는 9가지 방향을 탐색하고, ui-implement는 선택한 방향을 제품으로 바꾸고, ui-walkthrough는 내장된 Agent Browser를 통해 모든 상태를 검토합니다. 나는 여전히 결정을 내립니다. 반복적인 생산과 점검을 에이전트가 처리합니다.

대부분의 제품 기능은 빈 페이지에서 시작되지 않습니다. 제품이 출시된 지 꽤 지나면 기본 디자인 결정이 이미 코드에 존재합니다. 버튼, 입력, 카드, 탐색, 간격, 색상, 복사, 호버 상태 및 모바일 동작이 모두 정의되었습니다. Figma에서 해당 부분을 재구성하는 것은 동일한 구성 요소를 제품에서 다시 재구성하기 전에 다른 캔버스로 드래그하는 것을 의미하는 경우가 많습니다.

디자이너는 여전히 제품 결정을 내립니다. 에이전트는 반복적인 조립 및 확인 작업을 대부분 제거합니다. 이는 Zero가 이미 상당히 성숙한 설계 시스템을 갖추고 있기 때문에 작동합니다.

1. 설계 시스템을 통해 Figma 없이 제품 설계를 시작합니다.

Figma 없이 작업한다고 해서 설계 규칙 없이 작업한다는 의미는 아닙니다. 보다 명확한 규칙이 필요합니다.

Zero의 경우 에이전트는 다음을 검사할 수 있습니다.

• 버튼, 입력, 드롭다운, 카드, 대화 상자 및 탐색을 위한 기존 구성 요소
• 간격, 타이포그래피, 색상, 테두리 및 모서리 반경 설정
• 기존 마우스 오버, 선택됨, 비활성화됨, 비어 있음 및 모바일 상태
• 문장 케이스 및 짧은 사용자 표시 레이블과 같은 복사 규칙
• 이 조각들이 어떻게 결합되는지 보여주는 실제 화면

이러한 참고 자료는 일반적인 디자인 질문에 대한 답을 제공합니다. 새 입력은 이미 제공되는 입력과 같아야 합니다. 새 카드는 가장 가까운 기존 카드와 동일한 표면과 반경을 사용해야 합니다. 아이콘 버튼에는 다른 아이콘 버튼과 동일한 호버 피드백이 있어야 합니다.

이는 에이전트에게 경계를 제공합니다. 모든 화면에 대해 새로운 시각적 언어를 개발하지 않고도 기능의 구조를 탐색할 수 있습니다.

Figma는 팀이 새로운 브랜드, 새로운 구성 요소 시스템을 만들거나 긴밀한 제품 참조가 없는 상호 작용을 만들 때 여전히 유용합니다. 그러나 시스템이 성숙해지면 실행 중인 제품이 주요 디자인 표면이 될 수 있습니다. 이는 Zero를 재구축하는 데 사용한 코드형 디자인 워크플로의 기능 확장 버전입니다.

2. ui-design를 사용하여 9가지 제품 디자인 방향 탐색

모든 기능에는 여전히 탐색이 필요합니다. 나는 에이전트가 내 첫 문장을 받아 즉시 코드로 변환하는 것을 원하지 않습니다.

ui-design로 시작합니다. 에이전트에게 현재 화면, 사용자 문제, 목표, 주요 제약 사항을 제공합니다. 에이전트는 기존 제품 패턴을 읽고 권장 방향 1개와 대안 9개를 반환합니다.

일반 언어로 기술은 현재 화면을 캡처하고, 하나의 권장 방향을 만들고, 9개의 서로 다른 대안을 탐색하고, 절충점을 제시하고, 인간의 선택을 기다립니다.

이 지침에 포함된 디자인 사고

이 지침은 단순한 시각적 규칙 목록이 아닙니다. 이는 디자이너의 일반적인 프로세스를 반복 가능한 시퀀스로 바꿉니다.

1. 제안하기 전에 이해하세요. 현재 화면을 캡쳐하고 주변 제품을 읽어본 후 제작해 보세요.
2. 시스템을 생각해보세요. 기존 구성 요소, 템플릿 페이지, 상호 작용 패턴 및 복사 규칙을 시작 자료로 취급합니다.
3. 재발명을 방지합니다. AI는 프롬프트가 모호할 때 새로운 패턴을 만드는 경향이 있습니다. 이 명령은 가장 가까운 배송된 구성 요소나 페이지를 찾아서 메모리에서 근사하는 대신 재사용하도록 지시합니다.
4. 선택하기 전에 살펴보세요. After 앵커는 하나의 그럴듯한 방향을 제공합니다. 9가지 변형은 레이아웃, 계층 구조, 밀도, 진입점 및 공개에 대해 서로 다른 결정을 내립니다.
5. 탐색과 헌신은 별개입니다. 상담사는 옵션을 제시한 후 중지합니다. 인간은 코드가 시작되기 전에 장단점을 비교하고 선택합니다.
6. 전체 경험을 검토합니다. 복사, 마우스 오버 피드백, 상태, 모바일 동작 및 시각적 일관성은 구현 후 정리가 아닌 디자인의 일부입니다.

이것이 제가 스킬에서 원하는 시스템 사고입니다. 기존 제품을 이해하고 그 안에서 탐색한 다음 명시적인 선택을 하는 것입니다.

다음은 라이브 워크플로에서 그대로 재현된 전체 원본 지침입니다.

ui-design 원본 지침 전문

# vm0 / Zero UI 디자인 규칙

## 작업 흐름 — 시각적인 것부터, 코드는 나중에

**코드로 건너뛰지 마세요.** 이 기술이 호출되면 첫 번째 결과물은 항상 Ming이 볼 수 있는 렌더링된 모형 세트입니다. 구현은 방향이 선택된 후에만 발생합니다.

### 1단계 - "이전" 캡처

- 화면이 이미 존재하는 경우 현재 상태를 **이전** 이미지로 렌더링합니다(실행 중인 앱의 스크린샷을 찍거나 기존 구성 요소를 정적 미리 보기로 렌더링).
- 새로운 화면에 대한 요청인 경우 "이전"은 가장 가까운 기존 화면이거나 빈 상태입니다. 이를 캡션에 명시적으로 명시하세요.

### 2단계 — 단일 "이후" 앵커 생성

- 아래의 모든 규칙(구성 요소, 문장 케이스, 에이전트 세부 정보 입력/드롭다운, 채팅 작성기 카드 반경, 일정 추가 버튼, 아이콘 버튼 호버, 회색-50 표면)을 완전히 준수하는 요청에 대한 최선의 추측 해석을 나타내는 하나의 모형입니다.
- **이전**과 나란히 페어링하세요. 명확하게 라벨을 붙이십시오: `Before` / `After`.

### 3단계 - 9개의 변형 탐색 생성

이전/이후 쌍 뒤에는 동일한 화면에 대해 **9개의 고유한 변형 모형**을 생성합니다. 각 변형은 9가지 색상 조정이 아닌 의미 있게 다른 디자인 축을 탐색해야 합니다. 다음과 같은 스프레드를 커버하세요:

1. 레이아웃 — 단일 열 대 분할/사이드바/그리드
2. 밀도 - 컴팩트함 vs. 넓음
3. 계층 구조 — 시각적으로 이어지는 요소
4. 표면 처리 - 평면 vs. 카드 그룹 vs. 분할된 섹션
5. 진입점 - 인라인 액션 vs. 전용 CTA vs. 빈 상태 히어로
6. 카피 프레이밍 - 교훈적 vs. 최소한 vs. 대화적
7. 공개 - 보이는 모든 것 vs. 점진적 공개/아코디언
8. 구성 — 콘텐츠 주도 vs. 제어 주도
9. 한 번쯤 볼만한 가치가 있는 의도적인 파격/'와일드 카드' 연출

각 변형은 여전히 ​​협상할 수 없는 항목(문장 사례, 구성 요소 재사용, 에이전트 세부 정보 입력/드롭다운 스타일, 채팅 작성기 반경, 일정 추가 버튼, 아이콘 버튼 가리키기, 회색-50 중립)을 준수해야 합니다. 변형은 "디자인 시스템을 무시하면 어떨까"가 아니라 *레이아웃과 강조*를 탐구합니다.

### 4단계 - 발표 후 기다리기

- 하나의 메시지로 모든 이미지를 Ming에게 표시합니다. 먼저 `Before / After` 쌍을 표시한 다음 탐색 중인 축을 각각 설명하는 한 줄 캡션과 함께 1~9로 번호가 매겨진 9개의 변형을 표시합니다.
- 어떤 방향(또는 어떤 조합)을 추구할지 물어보세요.
- Ming이 방향을 선택할 때까지는 구현을 시작하지 마세요.

### 이미지 렌더링

- 선호하는 경로: `turbo/apps/platform`의 실제 Tailwind 토큰을 사용하는 정적 HTML/React 미리보기를 빌드하고 스크린샷을 찍은 후 `okou web upload-file`를 통해 업로드하세요.
- 빠른 탐색을 위해: `v0` 스킬은 프롬프트에서 변형 모형을 생성할 수 있습니다. 그러나 프롬프트는 v0이 일반 SaaS UI를 생성하지 않도록 아래 규칙(문장 사례, 에이전트 세부 정보 입력, 채팅 작성기 반경 등)을 명시적으로 열거해야 합니다.
- 세션에서 이미지 생성을 사용할 수 없는 경우 11개 프레임(전, 후, 9개 변형) 모두에 대해 명확하게 레이블이 지정된 ASCII/텍스트 와이어프레임으로 대체하고 이를 호출합니다. 시각적 단계를 자동으로 건너뛰지 마십시오.

---

# 설계 규칙

이는 vm0 플랫폼(`turbo/apps/platform`) 내부에 제공되는 새로운 UI에 대해 협상할 수 없는 디자인 규칙입니다. 구성 요소를 작성하기 전에 이를 적용하고 검토 중에 기존 PR을 감사합니다.

## 핵심 원칙

1. **재사용하고 재발명하지 마세요.** 새 구성 요소를 도입하기 전에 항상 `turbo/apps/platform/src/components/`의 기존 기본 요소와 `src/views/`의 뷰 수준 패턴을 확인하세요. 유사한 상호작용이 상담원 세부정보, 일정 또는 채팅 작성기에 이미 포함된 경우 병렬 패턴을 디자인하기보다는 해당 패턴을 복사하세요.
2. **Zero 디자인 언어와 일치합니다.** 부드러운 표면, 중성 회색, 넉넉한 반경, 미묘한 테두리, 거친 그림자 없음. 시각적 기준은 "차분하고 독선적이며 약간 편집적"입니다. 결코 SaaS 기본값이 아닙니다.
3. **사용자 자리에서 말하세요.** 문구는 시스템이 수행하는 작업이 아니라 *사용자*가 수행하거나 보려고 하는 작업을 설명해야 합니다. 짧게 유지하세요. 일반적으로 한 문장, 최대 두 문장입니다.

## 참조 패턴(직접 복사)

| 요소             | 참조 소스                                  | 왜 |
|---------------------|---------------------------------------------------|-----|
| 텍스트/텍스트 영역 입력 | 에이전트 세부정보 페이지 입력(`src/views/agent-detail/`) | 패딩, 테두리, 포커스 상태, 자리표시자 처리 설정 |
| 드롭다운/선택     | 상담원 세부정보 페이지 드롭다운                         | 트리거 스타일, 메뉴 반경, 항목 호버, 확인 표시 배치 설정 |
| 카드/패널 반경   | 채팅 작성기 카드(`composer` 구성 요소 찾기) | 앱 전체에서 표준 카드 반경과 표면 스타일을 설정합니다. |
| 기본 페이지 버튼   | 일정 페이지의 "일정 추가" 버튼          | 모달 *외부* 모든 곳에서 사용되는 중성-암색 원색 |
| 모달 기본 버튼  | 브랜드 기본 색상(대화상자/팝오버 내부에만 해당) | 모달은 브랜드 색상의 기본 색상을 유지합니다. 페이지는 그렇지 않습니다 |
| 아이콘 전용 버튼      | 호버 배경이 있는 기존 IconButton           | 클릭 가능한 모든 아이콘에는 눈에 보이는 호버 상태가 있어야 합니다. |

의심스러운 경우 코드베이스에서 참조 구성 요소를 열고 해당 props 및 클래스 이름을 읽고 미러링하세요. 기억에서 근사하지 마십시오.

## 카피 가이드라인

- **사용자 관점 표현.** "받은편지함 연결"이 "받은편지함 연결 필요"를 능가합니다. "아직 에이전트가 없습니다"가 "에이전트 목록이 비어 있습니다"를 능가합니다.
- **완전성보다 간결함.** 짧은 줄이 완전한 문장보다 더 효과적입니다. 트림 필러("간단히", "제발", "하기 위해").
- **모든 것에 대한 문장 케이스.** 레이블, 제목, 버튼, 메뉴 항목, 테이블 열 — 모든 문장 케이스("모델 공급자", "API 키", "일정 추가"). 제목 케이스가 아닙니다. 섹션 헤더의 CSS를 통해 `uppercase`를 사용하지 마세요. Title-Case 또는 모두 대문자 라벨을 찾으면 수정하세요.
- **필드나 섹션 위에 캡션 대소문자 "장식" 라벨이 없습니다**. 형식적이고 날짜가 있는 것으로 읽혀집니다. 일반 레이블을 사용하거나 필드가 자명한 경우 레이블을 건너뜁니다.
- **독립형 라벨이나 버튼에는 후행 구두점이 없습니다**. 마침표는 본문 문구와 도움말 텍스트용입니다.
- 문자열 이름을 바꿀 때 이전 문자열에 대한 코드베이스를 grep하고 테스트하세요. 레이블은 테스트와 번역에서 참조됩니다.

## 구성 요소 및 구조

- 항상 기존 구성 요소(`Button`, `Input`, `Select`, `Card`, `IconButton`, 대화 상자 기본 형식 등)에서 페이지를 빌드하세요. 새로운 구성 요소는 최후의 수단이며 이유가 필요합니다.
- 기존 레이아웃/템플릿(설정 페이지, 목록 페이지, 세부 정보 페이지)을 찾고 해당 스캐폴딩을 상속합니다. 페이지 구조를 다시 파생하지 마세요.
- 설정 스타일 페이지에 추가할 때 섹션 간격, 구분선 처리 및 인접 섹션에서 사용되는 양식 행 너비를 일치시킵니다.

## 버튼

- **페이지 기본**(페이지의 기본 CTA) → 일정 페이지의 '일정 추가' 버튼과 일치합니다. 이는 앱 전체 외부 대화 상자에 사용되는 중간색의 어두운/단색 기본입니다.
- **모달 기본**(대화상자/팝오버 내부 확인 버튼) → 브랜드 기본 색상을 사용합니다. 페이지는 그렇지 않습니다.
- **보조/고스트 버튼** → 기존 변형을 재사용합니다. 새로운 것을 발명하지 마십시오.
- **아이콘 버튼** → 호버 배경이 있어야 합니다(일반적으로 `hover:bg-gray-50` 또는 설정된 IconButton 호버 토큰). 클릭 대상으로 hoverless 아이콘을 제공하지 마십시오.
- 모든 버튼은 기존 높이 토큰을 존중해야 합니다. 일회성 크기를 도입하지 마세요.

## 입력

- 에이전트 세부 정보 입력 미러링: 동일한 패딩, 동일한 테두리, 동일한 포커스 링(또는 부족 - 포커스 링을 추가하기 전에 참조 확인), 동일한 자리 표시자 색상.
- 여러 줄: 에이전트 세부 정보 텍스트 영역 패턴을 사용합니다(참조에서와 같이 자동 증가 또는 고정 행).
- 필드 레이블 끝에 콜론을 넣지 마십시오.
- 입력 아래에 음소거된 회색의 한 줄로 된 도우미 텍스트입니다.

## 드롭다운/선택

- 에이전트 세부 정보 드롭다운 미러링: 동일한 트리거 모양, 동일한 메뉴 반경, 동일한 항목 패딩, 동일한 마우스 오버/선택 상태.
- 콘텐츠에서 요구하지 않는 한 메뉴는 트리거보다 넓어서는 안 됩니다.
- 기존 드롭다운에서 이미 사용하지 않는 한 중첩된 하위 메뉴를 사용하지 마세요.

## 카드 및 표면

- 카드 반경과 표면 스타일은 채팅 작성기 카드와 일치합니다. 이유 없이 더 작거나 더 큰 반경을 도입하지 마십시오.
- 테두리가 미묘합니다(기존 테두리 토큰에 가는선이 하나임). 채팅 작성자가 그림자를 사용하지 않는 한 그림자는 없습니다.
- 모바일의 중립 표면/밝은 회색 채우기(활성 알약 배경, 아이콘 컨테이너 채우기 등) → `bg-gray-50`. `gray-100` 및 `gray-200`가 너무 어둡게 반복적으로 호출되었습니다. `gray-50`에서 시작하세요.

## 포커스와 인터랙션

- 탐색/마케팅 요소에 사용자 정의 `:focus-visible` 상자 그림자 또는 윤곽선을 추가하지 마십시오. 대신 호버 색상 전환을 재사용하십시오. (참조 구성 요소에 명시적인 초점 링이 없는 한 일반적으로 동일한 제한이 플랫폼 내부에 적용됩니다.)
- 모든 대화형 요소(버튼, 아이콘 버튼, 행, 링크)에는 눈에 보이는 마우스 오버 상태가 필요합니다. 완료된 디자인을 고려하기 전에 각 항목에 마우스를 올려 테스트해 보세요.
- 비활성화된 상태는 기존 비활성화된 토큰을 사용합니다. 바랜 색상을 손으로 굴리지 마십시오.

## 체크리스트 검토

UI 준비를 선언하기 전에 다음을 살펴보세요.

1. 새 구성 요소를 만드는 대신 기존 구성 요소를 재사용했습니까?
2. 기존 페이지 템플릿/레이아웃과 일치했나요?
3. 입력이 상담원 세부정보 입력과 시각적으로 동일합니까?
4. 드롭다운은 상담원 세부정보 드롭다운과 시각적으로 동일합니까?
5. 카드가 채팅 작성기 반경 및 표면과 일치합니까?
6. 모든 라벨 문장은 케이스인가요? 남은 타이틀 케이스나 대문자가 있나요?
7. 카피는 짧고 사용자 입장에서 작성되었는가?
8. 페이지가 기본적으로 '일정 추가' 스타일 버튼인가요? 기본 브랜드는 모달 내부에서만 사용됩니까?
9. 모든 아이콘 버튼에 호버 배경이 있나요?
10. 피드백을 확인하기 위해 모든 대화형 요소에 마우스를 올렸나요?

대답이 "아니요"인 경우 PR을 열기 전에 수정하십시오.

## 의심스러울 때

- 참조 구성 요소를 열고 해당 소스를 읽고 구조를 복사합니다.
- 두 참조 구성 요소가 일치하지 않으면 가장 최근에 출시된 구성 요소를 선호하세요(git log 확인).
- 디자인에 정말로 새로운 기본 요소가 필요한 경우 제작하기 전에 Ming과 함께 이를 제기하세요. 번들로 제공되는 재설계 작업은 Ming이 리뷰어인 하나의 PR에 속합니다.

9개의 옵션이 9개의 완성된 디자인일 필요는 없습니다. 그들의 임무는 나에게 문제를 다르게 보고 올바른 방향으로 나아갈 수 있도록 충분한 범위를 제공하는 것입니다. 개념이 현재 제품 외부에 있는 경우에도 독립형 React 프로토타입가 도움이 될 수 있습니다. 이 기능을 위해 저는 실제 제품 시스템 내부에 머물렀습니다.

실제 예: Zero의 내비게이션

Zero에는 원래 제품 대상, 고정된 상담원 및 채팅 스레드가 포함된 300픽셀 사이드바가 하나 있었습니다. 동시에 세 가지 일을 하고 있었습니다. 대화 영역을 바꾸지 않고 그 업무들을 분리하고 싶었어요.

탐색을 위한 제품 개요는 다음과 같습니다.

/ui-design

실제 역사적 기반에서 Zero의 3개 지역 탐색에 대한 설계 단계를 재생해 보세요. 대화 영역을 변경하지 않고도 제품 대상, 에이전트 및 대화를 보다 명확한 영역으로 분리합니다. 실제 Zero 토큰, 아이콘 및 구성 요소를 사용하십시오. 소스에 충실한 Before, 하나의 강력한 After 및 9개의 완전히 다른 변형을 생성합니다. 제품 코드를 편집하거나 모형을 브라우저 증거로 제시하지 마십시오.

첫 번째 탐사는 너무 조심스러웠다. 여러 옵션에서 너비와 선택 스타일이 변경되었지만 여전히 동일한 사이드바처럼 보였습니다. 나는 그 세트를 거부하고 에이전트에게 정보 아키텍처 수준에서 차이점을 볼 수 있게 해달라고 요청했습니다.

두 번째 실행에서는 완전히 다른 9개의 방향이 반환되었습니다. 기사를 긴 이미지 스트립으로 바꾸지 않고도 쉽게 비교할 수 있도록 3×3 표로 그룹화했습니다. 모든 축소판은 블로그의 이미지 뷰어에서 열립니다.

1. 상단 탐색	2. 접이식 서랍	3. 스레드 우선
대화 위로 대상 이동	필요할 때까지 목적지 숨기기	대화를 기본 탐색 개체로 만들기
4. 상담원 우선	5. 대화 먼저	6. 명령 실행기
스레드보다 먼저 에이전트를 선택하세요	활성 대화 위에 고정된 상담원 배치	검색 가능한 메뉴에서 목적지 열기
7. 확장 가능한 레일	8. 대시보드 항목	9. 하단 도크
필요할 때만 좁은 레일을 확장하세요.	최근 작업부터 시작	목적지를 하단으로 이동

나는 이 프레임 중 하나를 그린 그대로 선택하지 않았습니다. 나는 그것들을 사용하여 무엇을 유지하고 무엇을 변경해야 하는지 결정했습니다. 최종 방향에서는 좁은 대상 레일, 별도의 채팅 레일, 눈에 보이는 고정된 5명의 에이전트, 기존 대화 영역을 사용했습니다.

ui-design의 중요한 출력은 이미지만이 아니었습니다. 짧은 결정 기록이었습니다.

• 68픽셀의 대상 레일과 300픽셀의 채팅 레일을 유지하세요.
• 고정된 에이전트 슬롯 5개 표시
• 선택 항목을 조용히 유지하되 읽을 수 있게 유지하세요.
• 드래그하는 동안에만 재주문 안내 표시
• 대화 내용과 기존 모바일 서랍을 그대로 유지

구현을 시작하기에 충분했습니다.

3. ui-implement를 사용하여 선택한 디자인을 코드로 변환

방향을 선택하고 제품 코드베이스를 연결하면 에이전트가 코드에서 직접 작업합니다. 먼저 Figma에서 선택한 프레임을 다시 그리지 않습니다.

일반 언어에서 ui-implement는 방향이 이미 선택되었기 때문에 탐색을 건너뜁니다. 가장 가까운 실제 구성 요소와 페이지 구조를 찾아 이를 기반으로 빌드하고 결과를 감사하고 브라우저에서 기능을 확인합니다.

이 명령이 보호하는 것

• 선택한 방향은 구현 중에 다시 설계되어서는 안 됩니다.
• 에이전트는 가장 가까운 기존 구성 요소 및 템플릿 페이지부터 시작해야 합니다.
• 제품에 실제 차이가 없는 한 재사용이 새 구성 요소보다 우선합니다.
• 자체 감사 및 브라우저 검사를 통해 일관되지 않은 사본, 상태 및 상호 작용을 포착합니다.
• 제품 결정이 아직 해결되지 않은 경우 작업은 ui-design로 돌아갑니다.

이것이 구현 중에 디자인 시스템이 활성 상태를 유지하는 방법입니다. 상담원이 한 번 읽어보는 문서가 아닙니다. 어떤 구성 요소를 선택하고 완성된 경험을 확인하는 방법을 결정합니다.

다음은 라이브 워크플로에서 그대로 재현된 전체 원본 지침입니다.

ui-implement 원본 지침 전문

# vm0 / Zero UI 구현 규칙

## 워크플로 — 직접 구현

이 스킬이 호출되면 **모형 및 변형 탐색 단계를 건너뜁니다**. 아래의 모든 설계 규칙을 적용하여 즉시 `turbo/apps/platform` 구현을 시작하세요.

### 1단계 - 참조 구성요소 찾기

줄을 작성하기 전에 미러링할 참조 구성 요소를 엽니다.

- 입력/텍스트 영역 → `src/views/agent-detail/` 입력
- 드롭다운/선택 → `src/views/agent-detail/` 드롭다운
- 카드/패널 반경 → 채팅 작성기 카드
- 페이지 기본버튼 → 일정페이지 내 "일정추가" 버튼
- 아이콘 전용 버튼 → 호버 배경이 있는 기존 `IconButton`

소품과 클래스 이름을 읽어보세요. 그것들을 미러링하십시오 - 기억에서 대략적으로 추정하지 마십시오.

### 2단계 - 가장 가까운 기존 페이지 템플릿 찾기

동일한 모양(설정, 목록, 세부정보)의 가장 가까운 기존 페이지를 열고 해당 스캐폴딩(섹션 간격, 구분선 처리, 양식 행 너비)을 상속합니다. 페이지 구조를 다시 파생하지 마세요.

### 3단계 - 구축 후 자체 감사

`turbo/apps/platform/src/components/`의 기존 기본 요소를 사용하여 화면을 구현합니다. 완료되었다고 생각되면 다시 보고하기 전에 이 기술의 맨 아래에 있는 **검토 체크리스트**를 살펴보세요. 작업 완료를 선언하기 전에 모든 "아니요" 대답을 수정하세요.

### 4단계 - 브라우저에서 확인

UI 작업의 경우 작업이 완료된 것으로 보고하기 전에 개발 서버를 시작하고 브라우저에서 기능을 실행해 보세요. 모든 대화형 요소에 마우스를 놓고 골든 경로와 엣지 케이스를 테스트하고 주변 화면의 회귀를 관찰하세요. 유형 확인 및 테스트는 기능의 정확성이 아니라 코드를 확인합니다. 브라우저를 열 수 없는 경우 명시적으로 알려주세요.

### ui-design로 대체하는 경우

요청이 방향을 선택하지 않고 개방형("X에 대한 설정 페이지 디자인")인 경우 대신 `ui-design` 기술을 중지하고 실행하십시오. 정확히 해당 경우에 대해 이전/이후 + 9개 변형이 존재합니다. `ui-implement`는 방향이 이미 결정된 경우에 사용됩니다.

---

# 설계 규칙

이는 vm0 플랫폼(`turbo/apps/platform`) 내부에 제공되는 새로운 UI에 대해 협상할 수 없는 디자인 규칙입니다. 이를 구축하는 동안 적용하고 PR을 열기 전에 자신의 차이점을 감사하십시오.

## 핵심 원칙

1. **재사용하고 재발명하지 마세요.** 새 구성 요소를 도입하기 전에 항상 `turbo/apps/platform/src/components/`의 기존 기본 요소와 `src/views/`의 뷰 수준 패턴을 확인하세요. 유사한 상호작용이 상담원 세부정보, 일정 또는 채팅 작성기에 이미 포함된 경우 병렬 패턴을 디자인하기보다는 해당 패턴을 복사하세요.
2. **Zero 디자인 언어와 일치합니다.** 부드러운 표면, 중성 회색, 넉넉한 반경, 미묘한 테두리, 거친 그림자 없음. 시각적 기준은 "차분하고 독선적이며 약간 편집적"입니다. 결코 SaaS 기본값이 아닙니다.
3. **사용자 자리에서 말하세요.** 문구는 시스템이 수행하는 작업이 아니라 *사용자*가 수행하거나 보려고 하는 작업을 설명해야 합니다. 짧게 유지하세요. 일반적으로 한 문장, 최대 두 문장입니다.

## 참조 패턴(직접 복사)

| 요소             | 참조 소스                                  | 왜 |
|---------------------|---------------------------------------------------|-----|
| 텍스트/텍스트 영역 입력 | 에이전트 세부정보 페이지 입력(`src/views/agent-detail/`) | 패딩, 테두리, 포커스 상태, 자리표시자 처리 설정 |
| 드롭다운/선택     | 상담원 세부정보 페이지 드롭다운                         | 트리거 스타일, 메뉴 반경, 항목 호버, 확인 표시 배치 설정 |
| 카드/패널 반경   | 채팅 작성기 카드(`composer` 구성 요소 찾기) | 앱 전체에서 표준 카드 반경과 표면 스타일을 설정합니다. |
| 기본 페이지 버튼   | 일정 페이지의 "일정 추가" 버튼          | 모달 *외부* 모든 곳에서 사용되는 중성-암색 원색 |
| 모달 기본 버튼  | 브랜드 기본 색상(대화상자/팝오버 내부에만 해당) | 모달은 브랜드 색상의 기본 색상을 유지합니다. 페이지는 그렇지 않습니다 |
| 아이콘 전용 버튼      | 호버 배경이 있는 기존 IconButton           | 클릭 가능한 모든 아이콘에는 눈에 보이는 호버 상태가 있어야 합니다. |

의심스러운 경우 코드베이스에서 참조 구성 요소를 열고 해당 props 및 클래스 이름을 읽고 미러링하세요. 기억에서 근사하지 마십시오.

## 카피 가이드라인

- **사용자 관점 표현.** "받은편지함 연결"이 "받은편지함 연결 필요"를 능가합니다. "아직 에이전트가 없습니다"가 "에이전트 목록이 비어 있습니다"를 능가합니다.
- **완전성보다 간결함.** 짧은 줄이 완전한 문장보다 더 효과적입니다. 트림 필러("간단히", "제발", "하기 위해").
- **모든 것에 대한 문장 케이스.** 레이블, 제목, 버튼, 메뉴 항목, 테이블 열 — 모든 문장 케이스("모델 공급자", "API 키", "일정 추가"). 제목 케이스가 아닙니다. 섹션 헤더의 CSS를 통해 `uppercase`를 사용하지 마세요. Title-Case 또는 모두 대문자 라벨을 찾으면 수정하세요.
- **필드나 섹션 위에 캡션 대소문자 "장식" 라벨이 없습니다**. 형식적이고 날짜가 있는 것으로 읽혀집니다. 일반 레이블을 사용하거나 필드가 자명한 경우 레이블을 건너뜁니다.
- **독립형 라벨이나 버튼에는 후행 구두점이 없습니다**. 마침표는 본문 문구와 도움말 텍스트용입니다.
- 문자열 이름을 바꿀 때 이전 문자열에 대한 코드베이스를 grep하고 테스트하세요. 레이블은 테스트와 번역에서 참조됩니다.

## 구성 요소 및 구조

- 항상 기존 구성 요소(`Button`, `Input`, `Select`, `Card`, `IconButton`, 대화 상자 기본 형식 등)에서 페이지를 빌드하세요. 새로운 구성 요소는 최후의 수단이며 이유가 필요합니다.
- 기존 레이아웃/템플릿(설정 페이지, 목록 페이지, 세부 정보 페이지)을 찾고 해당 스캐폴딩을 상속합니다. 페이지 구조를 다시 파생하지 마세요.
- 설정 스타일 페이지에 추가할 때 섹션 간격, 구분선 처리 및 인접 섹션에서 사용되는 양식 행 너비를 일치시킵니다.

## 버튼

- **페이지 기본**(페이지의 기본 CTA) → 일정 페이지의 '일정 추가' 버튼과 일치합니다. 이는 앱 전체 외부 대화 상자에 사용되는 중간색의 어두운/단색 기본입니다.
- **모달 기본**(대화상자/팝오버 내부 확인 버튼) → 브랜드 기본 색상을 사용합니다. 페이지는 그렇지 않습니다.
- **보조/고스트 버튼** → 기존 변형을 재사용합니다. 새로운 것을 발명하지 마십시오.
- **아이콘 버튼** → 호버 배경이 있어야 합니다(일반적으로 `hover:bg-gray-50` 또는 설정된 IconButton 호버 토큰). 클릭 대상으로 hoverless 아이콘을 제공하지 마십시오.
- 모든 버튼은 기존 높이 토큰을 존중해야 합니다. 일회성 크기를 도입하지 마세요.

## 입력

- 에이전트 세부 정보 입력 미러링: 동일한 패딩, 동일한 테두리, 동일한 포커스 링(또는 부족 - 포커스 링을 추가하기 전에 참조 확인), 동일한 자리 표시자 색상.
- 여러 줄: 에이전트 세부 정보 텍스트 영역 패턴을 사용합니다(참조에서와 같이 자동 증가 또는 고정 행).
- 필드 레이블 끝에 콜론을 넣지 마십시오.
- 입력 아래에 음소거된 회색의 한 줄로 된 도우미 텍스트입니다.

## 드롭다운/선택

- 에이전트 세부 정보 드롭다운 미러링: 동일한 트리거 모양, 동일한 메뉴 반경, 동일한 항목 패딩, 동일한 마우스 오버/선택 상태.
- 콘텐츠에서 요구하지 않는 한 메뉴는 트리거보다 넓어서는 안 됩니다.
- 기존 드롭다운에서 이미 사용하지 않는 한 중첩된 하위 메뉴를 사용하지 마세요.

## 카드 및 표면

- 카드 반경과 표면 스타일은 채팅 작성기 카드와 일치합니다. 이유 없이 더 작거나 더 큰 반경을 도입하지 마십시오.
- 테두리가 미묘합니다(기존 테두리 토큰에 가는선이 하나임). 채팅 작성자가 그림자를 사용하지 않는 한 그림자는 없습니다.
- 모바일의 중립 표면/밝은 회색 채우기(활성 알약 배경, 아이콘 컨테이너 채우기 등) → `bg-gray-50`. `gray-100` 및 `gray-200`가 너무 어둡게 반복적으로 호출되었습니다. `gray-50`에서 시작하세요.

## 포커스와 인터랙션

- 탐색/마케팅 요소에 사용자 정의 `:focus-visible` 상자 그림자 또는 윤곽선을 추가하지 마십시오. 대신 호버 색상 전환을 재사용하십시오. (참조 구성 요소에 명시적인 초점 링이 없는 한 일반적으로 동일한 제한이 플랫폼 내부에 적용됩니다.)
- 모든 대화형 요소(버튼, 아이콘 버튼, 행, 링크)에는 눈에 보이는 마우스 오버 상태가 필요합니다. 완료된 디자인을 고려하기 전에 각 항목에 마우스를 올려 테스트해 보세요.
- 비활성화된 상태는 기존 비활성화된 토큰을 사용합니다. 바랜 색상을 손으로 굴리지 마십시오.

## 체크리스트 검토

UI 준비를 선언하기 전에 다음을 살펴보세요.

1. 새 구성 요소를 만드는 대신 기존 구성 요소를 재사용했습니까?
2. 기존 페이지 템플릿/레이아웃과 일치했나요?
3. 입력이 상담원 세부정보 입력과 시각적으로 동일합니까?
4. 드롭다운은 상담원 세부정보 드롭다운과 시각적으로 동일합니까?
5. 카드가 채팅 작성기 반경 및 표면과 일치합니까?
6. 모든 라벨 문장은 케이스인가요? 남은 타이틀 케이스나 대문자가 있나요?
7. 카피는 짧고 사용자 입장에서 작성되었는가?
8. 페이지가 기본적으로 '일정 추가' 스타일 버튼인가요? 기본 브랜드는 모달 내부에서만 사용됩니까?
9. 모든 아이콘 버튼에 호버 배경이 있나요?
10. 피드백을 확인하기 위해 브라우저의 모든 대화형 요소에 마우스를 올렸나요?

대답이 "아니요"인 경우 PR을 열기 전에 수정하십시오.

## 의심스러울 때

- 참조 구성 요소를 열고 해당 소스를 읽고 구조를 복사합니다.
- 두 참조 구성 요소가 일치하지 않으면 가장 최근에 출시된 구성 요소를 선호하세요(git log 확인).
- 디자인에 정말로 새로운 기본 요소가 필요한 경우 제작하기 전에 Ming과 함께 이를 제기하세요. 번들로 제공되는 재설계 작업은 Ming이 리뷰어인 하나의 PR에 속합니다.

다음은 기능별 구현 프롬프트였습니다.

/ui-implement

개정판 04d642bb에서 시작합니다. 68px 대상 레일, 300px 채팅 레일 및 변경되지 않은 대화가 포함된 기본 데스크톱 분할을 추가합니다. 스위치가 꺼져 있고 모바일에서는 기존 300px 사이드바를 유지하세요. 5개의 고정된 슬롯을 렌더링하고, 사용자 정의 순서를 유지하고, 활성 드래그 중에만 재정렬 어포던스를 표시합니다. 독립적인 패치, 테스트 및 브라우저 증거가 고정될 때까지 과거 기능이나 이후 개선 사항을 검사하지 마십시오.

탐색 기능의 경우 기능이 꺼져 있을 때 이전 사이드바를 유지하고, 켜져 있을 때 새로운 3부분 레이아웃을 표시하고, 기존 모바일 서랍을 유지하고, 사람들이 고정된 에이전트를 재정렬할 수 있도록 허용하도록 상담원에게 요청했습니다.

구현 중에 에이전트는 한 가지 중요한 문제를 발견했습니다. 이전 제품은 어떤 상담원이 고정되어 있는지 기억했지만 해당 상담원의 순서는 기억하지 못했습니다. 드래그 상호 작용이 올바르게 표시되었다가 새로 고침 후에 재설정될 수 있습니다.

따라서 에이전트는 드래그 상태를 그리는 것 이상의 작업을 수행했습니다. 새 주문을 유지하고 페이지를 새로 고치고 주문이 유지되었는지 확인했습니다. 또한 재정렬 핸들은 드래그 중에만 나타났다가 이후에는 사라지는 것을 확인했습니다.

구현 제공에는 검토해야 할 두 가지 데스크톱 상태가 표시되었습니다. 인터페이스를 계속 읽을 수 있도록 전체 너비로 표시합니다. 모바일 동작은 나중에 연습에서 고밀도 전화 캡처로 나타납니다.

데스크탑 휴지 상태

활성 재정렬

이 시점에는 다른 디자인 파일이 아닌 작업 기능이 있었습니다. 하지만 구현이 아직 끝이 아니었습니다. 배포된 미리보기에서 실제로 무엇이 실행되고 있는지 확인해야 했습니다.

4. ui-walkthrough를 사용하여 실제 제품을 검토하십시오.

예전에는 제품 둘러보기가 지루했습니다. 배포된 미리 보기를 열고, 올바른 계정을 준비하고, 기능을 켜고 끄고, 모든 컨트롤을 클릭하고, 브라우저 크기를 조정하고, 스크린샷을 찍고, 각 이미지가 어떤 상태를 나타내는지 기억하려고 노력했습니다.

에이전트에는 Agent Browser가 내장되어 있으므로 해당 작업을 에이전트에 전달할 수 있습니다.

워크플로우에는 두 가지 주요 단계가 있습니다.

1. 먼저 시나리오를 나열합니다. 상담원은 설계 및 구현 요구 사항을 체크리스트로 바꿉니다.
2. 체크리스트를 실행하고 증거를 첨부합니다. 배포된 미리 보기의 모든 시나리오를 수행하고 각 의미 있는 상태에 대한 스크린샷과 함께 PASS, FAIL 또는 BLOCKED를 반환합니다.

이 지침으로 인해 검토와 관련하여 변경되는 사항

• 에이전트는 클릭을 시작하기 전에 시나리오를 나열합니다.
• 내장된 Agent Browser를 통해 실제 배포된 구성 요소를 사용합니다.
• 각 의미 있는 상태에 대해 하나의 스크린샷을 캡처합니다.
• 모든 체크포인트 PASS, FAIL 또는 BLOCKED를 표시합니다.
• 모의 증거 뒤에 사용할 수 없는 상태를 숨기지 않습니다.

이렇게 하면 수동 클릭이 체계적인 검토 패키지로 전환됩니다. 의도한 행동과 결과, 증거를 함께 살펴볼 수 있습니다.

전체 지침은 다음과 같습니다. 독자가 명확하게 볼 수 있도록 내부 종속성 이름을 "built-in Agent Browser"로 번역했습니다. 그 외에는 워크플로 논리가 변경되지 않습니다.

ui-walkthrough 원본 지침 전문

# UI 연습

실제 PR별 미리보기에서 vm0/Zero 프런트엔드 기능의 엔드투엔드 시각적 QA입니다. 이 워크플로우는 검증할 내용과 결과 보고 방법을 정의합니다. UI 작업 도구를 정의하지 않습니다.

## 필수 종속성: 내장 Agent Browser

다음을 포함하여 모든 UI 상호 작용에 대한 단일 진실 소스로 내장된 Agent Browser를 사용하세요.

- PR별 미리보기를 검색하고 엽니다.
- 미리보기 보호 처리 및 세션 설정.
- 가입, OTP, 온보딩, Stripe 테스트 체크아웃 및 라이브 앱 접속.
- 기능 스위치를 활성화합니다.
- 탐색, 컨트롤과 상호 작용, 테스트 또는 모의 데이터 제공, 스크린샷 캡처, 아티팩트 업로드, 문제 해결 및 정리.

UI 작업을 수행하기 전에 현재 내장된 Agent Browser 지침을 읽고 따르십시오. 이 워크플로우에서 런타임 관련 명령, 엔진 설정, 선택기 메커니즘, 페이지 컨텍스트 스크립트, 세션 관리 또는 프로세스 정리 방법을 복제하지 마십시오. 내장된 Agent Browser가 변경되면 현재 지침이 우선 적용됩니다.

## 언제 사용하나요?

- 배포된 미리보기에서 vm0 풀 요청의 UI를 살펴보세요.
- 인증, 온보딩, 청구, 기능 전환 또는 실제 채팅 스레드가 필요한 인앱 기능을 확인하세요.
- 라이브 애플리케이션에서 작동하는 기능에 대한 충실한 스크린샷이나 짧은 연습 비디오를 캡처하세요.

## 연습 워크플로우

### 1. 목표와 범위를 설정한다

- PR, 헤드 커밋, 변경된 사용자 표시 동작 및 예상 미리보기를 식별합니다.
- 테스트하기 전에 배포된 미리보기가 PR 헤드와 일치하는지 확인하세요.
- PR 차이점과 설명을 읽고 변경 사항을 보여주는 주요 경로와 상태를 알아보세요.
- 사용자가 별도로 구현을 요청하지 않는 한 연습 중에 코드를 수정하거나 충돌을 해결하거나 제품 동작을 변경하지 마세요.

### 2. 기능에 도달

내장된 Agent Browser를 사용하여 미리보기에 들어가 라이브 기능 상태에 도달합니다. 인증, 온보딩, 청구, 기능 전환 및 미리보기 전용 우회에 대한 현재 규칙을 따르십시오.

우회를 사용하는 경우 최종 보고서에 이를 공개합니다. 온보딩 자체가 테스트 중인 경우에는 온보딩 우회를 사용하지 마십시오.

### 3. 시각적 상태 매트릭스 정의

상호 작용하기 전에 기능이 작동함을 증명하는 가장 작은 상태 집합을 나열하세요. 해당 항목을 포함하십시오:

- 초기/기본 상태.
- 열기, 마우스 오버, 포커스, 선택, 확장 또는 활성 상태.
- 비어 있고 채워진 상태.
- 활성화 및 비활성화 상태.
- 성공, 유효성 검사, 로드 및 오류 상태.
- 배치, 충돌, 뒤집기, 자르기 및 반응 동작.
- 기능이 대화형인 경우 제출 또는 다운스트림 작업입니다.

일반적인 연기 테스트보다 실제 변경된 동작을 연습하는 것을 선호합니다.

### 4. 라이브 구성요소 구동

모든 상호 작용 및 테스트 데이터 기술에 내장된 Agent Browser를 사용하세요.

모의 또는 주입된 콘텐츠는 실제 애플리케이션 구성 요소를 결정적인 시각적 상태에 배치하는 데에만 사용될 수 있습니다. 평가되는 구성 요소, 스타일 및 상호 작용은 PR 미리 보기의 실시간 구현으로 유지되어야 합니다.

모든 조롱된 상태에 대해:

- 어떤 내용이나 필수 구성 요소가 조롱되었는지 기록합니다.
- 실제 애플리케이션 동작과 모의된 콘텐츠를 구별합니다.
- 조롱된 텍스트나 데이터가 모델이나 프로덕션 소스에서 나온 것이라고 암시하지 마십시오.
- 환경이 허용하는 모든 곳에서 실제 제어 및 다운스트림 배선을 실행하십시오.

### 5. 증거 확보

내장된 Agent Browser를 사용하여 주요 체크포인트에 대한 증거를 캡처하고 업로드하세요. 각 이미지는 동일한 보기를 반복하기보다는 하나의 의미 있는 상태를 증명해야 합니다.

사용자가 비디오를 요청하면 확인된 체크포인트에서 짧은 캡션이 포함된 연습을 구성합니다. 캡션은 UI를 가리지 않고 사용자 작업과 예상 결과를 식별해야 합니다.

### 6. 전달 및 보고

보고서:

- PR 링크, 정확한 미리보기 URL, 가능한 경우 테스트된 커밋.
- 정확한 사용자 흐름이 실행되었습니다.
- 계정이 생성되었을 때의 테스트 계정입니다.
- 각 체크포인트에 대해 `PASS`, `FAIL` 또는 `BLOCKED`입니다.
- 스크린샷 링크와 간단한 설명이 포함된 선택적 비디오 링크.
- 기능 스위치, 바이패스, 모의 데이터 및 기타 테스트 전용 설정이 사용됩니다.
- 실패한 검사, 환경 방해 요소 또는 검증 공백.

실시간 미리 보기 흐름이 실행되고 증거가 캡처되지 않은 한 기능이 확인되었다고 주장하지 마십시오. 미리보기를 사용할 수 없는 경우 로컬 또는 정적 복제본을 대체하는 대신 배포 증거와 함께 `BLOCKED`를 보고하세요.

다음은 기능별 연습 프롬프트입니다.

/ui-walkthrough

내장된 Agent Browser를 통해 배포된 미리보기를 유일한 브라우저 진실로 사용하세요. 기능이 꺼진 사이드바, 68px 및 300px 분할, 대상 순서, 마우스 오버 상태, 고정된 슬롯 5개, 드래그 전용 핸들, 지속적인 재정렬, 스레드 선택, 스크롤 및 전체 iPhone 서랍을 입증하세요. 모든 체크포인트에 대해 PASS, FAIL 또는 BLOCKED를 반환합니다. 연결할 수 없는 상태를 복제본으로 바꾸지 마세요.

이 기능의 경우 상담원은 다음 질문을 중심으로 둘러보기를 구성했습니다.

• 기능이 꺼져 있어도 기존 사이드바가 계속 작동하나요?
• 켜져 있으면 새 데스크탑 구조가 나타납니까?
• 호버 및 선택 상태가 표시되지만 조용합니까?
• 고정된 에이전트 5개를 읽을 수 있나요?
• 드래그가 시작될 때까지 재정렬 컨트롤이 숨겨져 있습니까?
• 새로 고침 후에도 새 주문이 유지됩니까?
• 실제 스레드를 선택하고 스크롤할 수 있나요?
• 기존 모바일 서랍이 여전히 작동하나요?
• 모든 내비게이션 목적지가 있고 올바른 순서로 되어 있나요?

그런 다음 에이전트는 새 사용자로 배포된 미리 보기를 열고 온보딩을 완료하고 기능을 활성화하고 목록을 살펴보았습니다. 휴지 상태, 마우스 오버 상태, 드래그 상태, 새로 고침 동작, 스레드 선택, 스크롤 및 휴대폰 레이아웃을 테스트했습니다.

결과는 11 PASS, 1 FAIL였습니다.

실패는 유익했습니다. 레이아웃과 상호 작용은 작동했지만 배포된 미리 보기에는 제품 대상이 6개만 표시되었습니다. Activity 및 Insights가 누락되어 주문이 선택한 디자인과 일치하지 않았습니다.

대본	결과
기능이 꺼진 기존 사이드바	PASS
새로운 3부분 데스크탑 레이아웃	PASS
마우스오버 및 선택 상태	PASS
고정된 에이전트 5명	PASS
드래그 전용 재주문 안내	PASS
새로고침 후 저장된 순서	PASS
스레드 선택 및 스크롤	PASS
기존 이동식 서랍	PASS
대상 내용 및 순서	FAIL

최종 전달은 레이블이 지정되지 않은 이미지 폴더가 아닌 정리된 스크린샷 세트였습니다. 데스크톱 캡처는 1440×900픽셀이고 휴대폰 캡처는 1170×2532픽셀입니다. 아래에는 한 번에 하나씩 표시되므로 인터페이스를 계속 읽을 수 있습니다. 기사를 떠나지 않고 이미지를 확대하려면 이미지를 클릭하세요.

기능 꺼짐

기능 활성화됨

데스크탑 레이아웃

목적지 호버

고정된 에이전트 호버

활성 드래그

저장된 주문

모바일 서랍

이를 통해 구조화된 방식으로 기능을 검토할 수 있습니다. 의도한 시나리오와 실제 배포된 결과, 증거물을 함께 볼 수 있습니다. 어떤 일이 실패하면 작업이 어디로 반환되어야 하는지 정확히 알고 있습니다.

팀이 이 AI 제품 디자인 워크플로를 채택하는 방법

전체 과정은 짧습니다. 팀원은 메모리에서 프로세스를 다시 구축하는 대신 각 단계를 공유 Zero 워크플로우로 저장할 수 있습니다.

단계	입력	산출
ui-design	현재 화면, 문제, 목표, 제약사항	1가지 권장방향, 9가지 대안, 선정된 설계기록
ui-implement	선택된 디자인 기록	검토 가능한 코드 변경 및 주요 상태의 스크린샷
ui-walkthrough	배포된 기능과 예상되는 동작	PASS, FAIL 또는 BLOCKED 스크린샷으로 구성된 시나리오 목록

팀원이 내 디자인 취향을 그대로 재현할 필요는 없습니다. 좋은 맥락을 제공하고, 공유 제품 시스템을 사용하고, 탐색 후 명시적인 선택을 하고, 브라우저 증거를 검토해야 합니다. 동일한 세 가지 인간 체크포인트(문제, 방향, 수용)가 AI 에이전트를 팀처럼 관리하세요 방식을 형성합니다.

이 워크플로우는 디자인 관행이나 디자인 사고를 제거하지 않습니다. 문제 정의, 제약 조건 설정, 방향 비교, 절충점 선택, 실행 중인 제품 판단 등 가장 중요한 부분으로 사용자를 이동시킵니다.

구성요소 시스템이 성숙해지면 더 이상 Figma에서 모든 기능을 드래그 가능한 블록으로 다시 구축할 필요가 없습니다. 디자인 시스템은 출력을 일관되게 유지하고 연습은 결과를 정직하게 유지하는 동시에 제품에서 에이전트와 직접 작업할 수 있습니다.

자주 묻는 질문

AI 제품 디자인 워크플로를 어떻게 구축합니까?

빈 프롬프트가 아닌 기존 제품 시스템으로 시작하세요. 작업을 탐색, 구현, 검토로 분리합니다. 에이전트가 옵션을 생성하고 반복 가능한 검사를 수행하도록 하되 문제, 선택한 방향 및 최종 승인에 대한 책임은 제품 디자이너에게 두십시오.

제품 디자이너가 Figma 없이 작업할 수 있나요?

예, 제품에 이미 안정적인 구성 요소, 페이지 템플릿 및 상호 작용 패턴이 있는 경우 가능합니다. Figma는 새로운 시각적 언어나 익숙하지 않은 상호작용에 여전히 유용합니다. 요점은 Figma를 금지하는 것이 아닙니다. 두 번째 캔버스에서 알려진 제품 결정을 다시 작성하지 않는 것입니다.

AI가 제품 디자이너를 대체하고 있나요?

이 워크플로에는 없습니다. 에이전트는 옵션을 조합하고, 코드를 편집하고, 시나리오를 확인합니다. 디자이너는 여전히 문제의 틀을 잡고, 제약 조건을 설정하고, 장단점을 비교하고, 방향을 선택하고, 실행 중인 제품이 출시하기에 충분한지 여부를 결정합니다.