☰ Categories

Document a component so it is used correctly

"What it is not for" prevents more misuse than "what it is for".

CategoryDesign › Design collaboration
TagsDraftingReformattingTemplate
Prompt
Document this component so someone else uses it correctly.

**Premise: components get misused because the rules live in the head of whoever made them.**

**Cover:**
1. **What it is for**, ***in one sentence.* **And what it is not for** — *the second line prevents more misuse than the first*
2. **When to use it, and when to use something else instead** — ***name the alternative***
3. **Variants** — ***what each is for, not just what each looks like.* **A variant with no stated purpose becomes a style choice**
4. **What can be changed** and ***what must not.* **Say which parts are the contract**
5. **Content rules** — ***length, what happens past it, tone, whether the label can be a question***
6. **Behaviour** — states, what it does on interaction, what it does when unavailable
7. **Accessibility requirements that come with it** — ***what the user of this component still has to do***

**Then:**
- ***The most likely misuse***, and what to write to prevent it
- **Where two existing components overlap** — ***if the answer to "which one" is unclear, document the rule or merge them***
- ***What this component does not solve***, so nobody bends it to fit

⚠️ ***Work only from what I gave you. Do not invent what they meant, and do not assume a design or a constraint I did not state.***
After pasting, fill in the fields at the bottom (The component · Where it is used)

What this prompt does

Components get misused because the rules live in one person's head. What actually prevents it is stating what it is not for and naming the alternative — this requires both.

Model comparison

ChatGPT best respects the no-assumption constraint. Gemini is detailed but invents many rules, while [C] was not provided.

ChatGPTTop overall
41/ 50

+ Documents clearly while respecting the supplied evidence.

- Repeats unknowns and still adds a few unsupported criteria.

Gemini
31/ 50

+ Covers every requested section with concrete detail.

- Invents unstated rules, such as one Primary per screen.

CriterionChatGPTGeminiLeader
Instruction following95ChatGPT +80%
Accuracy93ChatGPT +200%
Specificity88Tie
Structure89Gemini +13%
Right length76ChatGPT +17%

Scored 1–10 by gpt-5.6-sol with model names hidden (2026-09-25). This is an AI review, not a measurement.

Read full answers

We gave three models the same input and copied their answers unedited. Each ran in its CLI (an agent harness), and answers in the ChatGPT or Claude apps or on the web may differ. Outputs are in Korean.

Input used
The component: Button 컴포넌트 (Primary/Secondary/Ghost 변형, Small/Medium/Large 사이즈)

Where it is used: 결제 페이지 CTA, 설정 화면 저장 버튼, 모달 확인·취소 버튼 등 서비스 전반 약 40여 곳
gpt-5.6-luna (codex CLI · 에이전트 하네스) · Run on 2026-09-24

Button 컴포넌트 사용 가이드

1. 용도

Button은 사용자가 서비스의 다음 동작을 실행하도록 하는 인터랙션 컴포넌트다.

결제 페이지 CTA, 설정 화면의 저장 버튼, 모달의 확인·취소 버튼 등 서비스 전반의 약 40여 곳에서 사용된다.

Button은 용도에 따른 의미와 동작이 정의되지 않은 장식용 요소나, 단순한 텍스트·링크를 표현하기 위한 컴포넌트로 사용하지 않는다.

구체적인 동작, 우선순위, 접근성 동작은 제공된 정보만으로 정의할 수 없으므로 각 사용처에서 명시해야 한다.

2. 사용 여부

Button을 사용한다.

  • 사용자가 결제, 저장, 확인, 취소 등 특정 동작을 실행해야 할 때
  • 사용자가 클릭하거나 탭해서 서비스의 상태를 변경하거나 다음 단계로 이동할 때

다음과 같은 경우에는 다른 컴포넌트를 사용한다.

  • 단순히 다른 페이지나 위치로 이동하는 목적이라면: 링크 컴포넌트
  • 동작 없이 정보를 표시하는 목적이라면: 텍스트 또는 정보 표시 컴포넌트

단, 현재 제공된 정보에는 링크 컴포넌트와 정보 표시 컴포넌트의 실제 명칭이나 사용 규칙이 없으므로 프로젝트의 해당 컴포넌트명을 확인해 기재해야 한다.

3. 변형

Primary

가장 중요한 동작을 나타낼 때 사용한다.

현재 정보만으로 Primary가 항상 한 화면에 하나여야 하는지, 특정 동작에만 사용해야 하는지는 정의할 수 없다.

Secondary

Primary보다 우선순위가 낮은 동작을 나타낼 때 사용한다.

Primary와 Secondary의 우선순위 차이를 색상이나 시각적 강도 외에 어떻게 판단하는지는 추가 정의가 필요하다.

Ghost

Ghost를 사용해야 하는 상황은 제공된 정보에 정의되어 있지 않다. 장식적인 목적이나 임의의 스타일 선택으로 사용하지 않도록, 용도를 별도로 결정해야 한다.

변형은 외관이 아니라 동작의 우선순위를 표현하는 계약이다. 우선순위를 판단할 수 없으면 변형을 임의로 선택하지 않는다.

4. 사이즈

Small

Small을 사용해야 하는 상황은 제공된 정보에 정의되어 있지 않다.

Medium

Medium을 사용해야 하는 상황은 제공된 정보에 정의되어 있지 않다.

Large

Large를 사용해야 하는 상황은 제공된 정보에 정의되어 있지 않다.

사이즈별 사용처, 화면 밀도, 터치 영역, 모바일·데스크톱 기준이 정의되어 있지 않으므로 현재는 사이즈를 취향에 따라 선택하면 안 된다. 프로젝트에서 각 사이즈의 목적을 먼저 정해야 한다.

변경 가능한 부분

각 사용처에서 변경 가능한 항목은 다음 정보가 정의된 뒤에만 판단한다.

  • 변형
  • 사이즈
  • 라벨
  • 실행할 동작
  • 상태

반드시 유지해야 하는 계약

다음은 Button 사용자가 임의로 바꾸면 안 되는 계약으로 문서화해야 한다.

  • Button이라는 컴포넌트의 인터랙션 역할
  • Primary, Secondary, Ghost의 의미
  • Small, Medium, Large의 의미
  • 상태별 동작
  • 비활성 상태의 동작
  • 접근성 요구사항

현재 제공된 정보만으로는 위 계약의 구체적인 값과 구현 기준은 확인할 수 없다.

5. 콘텐츠 규칙

현재 제공된 정보에는 다음 콘텐츠 규칙이 없다.

  • 라벨의 최대 길이
  • 최대 길이를 넘었을 때의 처리
  • 라벨의 문체와 어조
  • 라벨에 질문형 문장을 허용하는지
  • 아이콘과 라벨의 사용 규칙
  • 동작을 설명하는 동사 사용 여부

따라서 사용자는 라벨 길이와 문체를 임의로 정하지 말고, 별도의 콘텐츠 규칙이 정의될 때까지 사용처별로 검토해야 한다.

문서에는 최소한 다음을 명시해야 한다.

라벨은 버튼을 눌렀을 때 실행되는 동작을 명확하게 표현한다. 라벨의 길이 제한, 초과 시 처리, 어조, 질문형 허용 여부는 서비스 콘텐츠 규칙을 따른다.

6. 동작과 상태

Button에 필요한 상태와 동작은 다음과 같다.

  • 기본 상태
  • 사용자가 상호작용할 때의 상태
  • 비활성 상태
  • 동작 처리 중 상태가 있다면 해당 상태

그러나 제공된 정보에는 상태 목록과 각 상태의 구체적인 동작이 정의되어 있지 않다.

특히 다음을 별도로 정해야 한다.

  • 클릭·탭 시 어떤 동작을 실행하는가
  • 중복 클릭·탭을 허용하는가
  • 처리 중 다시 누르면 어떻게 되는가
  • 사용할 수 없을 때 숨기는가, 비활성화하는가
  • 비활성 상태에서 클릭·탭 이벤트가 발생하는가
  • 오류가 발생하면 사용자에게 어떻게 알리는가

“사용할 수 없음”을 단순히 스타일로만 표현하지 않는다. 비활성 상태의 동작과 사용자 안내 방식을 함께 정의해야 한다.

7. 접근성 요구사항

Button을 사용하는 쪽에서 최소한 다음을 확인해야 한다.

  • 라벨만 보고 실행될 동작을 이해할 수 있는가
  • 키보드 등 비마우스 입력으로도 사용할 수 있는가
  • 현재 상태가 사용자에게 전달되는가
  • 비활성 상태가 시각적으로만 구분되지 않는가
  • 라벨이 아이콘이나 색상에만 의존하지 않는가
  • 모달 안에서 사용될 경우 확인·취소 동작이 명확히 구분되는가

구체적인 접근성 기준, 키보드 동작, 포커스 처리, 상태 전달 방식은 제공된 정보에 없으므로 Button 사용자가 별도로 확인해야 한다.

가장 likely한 misuse

가장 가능성이 높은 오용은 Primary/Secondary/Ghost와 Small/Medium/Large를 의미가 아니라 화면에 어울리는 스타일로 선택하는 것이다.

다음 문구를 문서에 명시한다.

변형과 사이즈를 시각적 취향으로 선택하지 않는다. 변형은 동작의 우선순위, 사이즈는 정의된 사용 목적에 따라 선택한다. 목적을 판단할 수 없으면 임의로 선택하지 말고 컴포넌트 담당자에게 확인한다.

또 다른 오용은 Button이 필요한지 판단하지 않고 모든 클릭 가능한 요소에 Button을 사용하는 것이다.

페이지나 위치로 이동하는 요소는 링크를 사용하고, 동작을 실행하는 요소만 Button을 사용한다.

기존 컴포넌트와의 겹침

제공된 정보에는 Button과 겹치는 다른 컴포넌트가 제시되지 않았다. 따라서 어떤 컴포넌트를 선택해야 하는지, 두 컴포넌트를 합쳐야 하는지는 판단할 수 없다.

최소한 다음 비교 규칙은 추가로 문서화해야 한다.

  • Button과 링크의 구분
  • Button과 텍스트 링크의 구분
  • Button과 아이콘 전용 컨트롤의 구분
  • Button과 모달 전용 액션 컴포넌트의 구분

Button이 해결하지 않는 것

Button은 다음 문제를 자체적으로 해결하지 않는다.

  • 어떤 동작을 실행해야 하는지 결정하는 일
  • 여러 동작의 우선순위를 정하는 일
  • 라벨의 문구를 작성하는 일
  • 결제·저장·확인·취소 동작의 비즈니스 규칙을 정의하는 일
  • 처리 중, 성공, 실패 결과를 사용자에게 안내하는 일
  • 모달의 구조와 포커스 흐름을 설계하는 일
  • 링크와 Button 중 무엇을 사용할지 결정하는 일
  • 접근성 요구사항을 사용처에서 확인하는 일

Button은 실행 컨트롤을 제공할 뿐이다. 각 사용처는 동작, 우선순위, 콘텐츠, 상태, 접근성 요구사항을 함께 정의해야 한다.

More in this category

Design Brief
Work out what a change request actually costs
Read the decisions behind a competitor's screen
Decode vague design feedback
Design Handoff Notes - AI First, Human Readable