44/ 50
＋ 주어진 정보 안에서 관찰·진단·처방을 충실히 분리했다.
－ 모바일 점검과 요청 간 충돌 가능성은 근거가 다소 약하다.
모호한 디자인 피드백을 해석하는 프롬프트
반응은 대개 맞고 처방은 대개 틀립니다. 관찰을 역산합니다.
| 분류 | 디자인 › 디자인 협업 |
|---|---|
| 태그 | 분석질문생성검토 |
Turn this feedback into something I can act on. **Premise: "make it pop", "it feels off", "can you make it cleaner" are real signals badly expressed. ***The reaction is usually right; the proposed fix usually is not.*** 1. **Separate what they said into:** - ***An observation*** — something they noticed - ***A diagnosis*** — their theory about why - ***A prescription*** — the change they asked for **Most feedback arrives as a prescription with the observation missing. That observation is what I need** 2. **For each prescription, work backwards:** ***what would they have had to notice to say this?*** **List the possibilities** 3. **Which of those possibilities I can check**, and how 4. ***What to ask them*** — **one question per unclear item, phrased so it does not sound like pushback** 5. **Where the feedback is out of scope** — ***a decision already made, or something not mine.* **Say which, and who owns it** **Then:** - ***What to do before asking anything*** — sometimes the observation is obvious once separated - **Feedback that contradicts other feedback I received** — ***surface it rather than trying to satisfy both*** - ***What not to change.* **Feedback given once by one person is a data point, not a mandate** ⚠️ ***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.***
붙여 넣으면 맨 아래에 채울 칸(받은 피드백 · 준 사람)이 나옵니다
어떤 프롬프트인가
"좀 더 시원하게" 같은 피드백은 관찰이 빠진 채 처방만 도착한 것이다. 그리고 반응 자체는 대개 맞고 제안한 수정이 틀린 경우가 많다. 이 프롬프트는 관찰·진단·처방을 가른 뒤 "이렇게 말하려면 무엇을 봤어야 하나"를 역산하고, 되묻기 어려운 질문을 되묻기 쉬운 형태로 만든다.
모델 비교
ChatGPT는 근거를 지키며 가장 충실하다. Gemini는 체계적이지만 추측이 많고, [C]는 답이 없어 평가 불가다.
33/ 50
＋ 검증 방법과 질문을 단계별로 읽기 쉽게 구성했다.
－ 디자인 시스템·전환 목표·뷰포트 등 미제공 사실을 가정했다.
| 기준 | ChatGPT | Gemini | 앞선 모델 |
|---|---|---|---|
| 지시 준수 | 9 | 6 | ChatGPT +50% |
| 정확성 | 9 | 5 | ChatGPT +80% |
| 구체성 | 9 | 7 | ChatGPT +29% |
| 구성·가독성 | 9 | 9 | 동점 |
| 분량 적정성 | 8 | 6 | ChatGPT +33% |
gpt-5.6-sol가 모델 이름을 가린 채 1~10점으로 채점했습니다 (2026-09-25). 측정값이 아니라 AI 심사 결과입니다.
답 전문 보기
같은 입력을 세 모델에 넣어 받은 답을 그대로 옮겼습니다. 각 CLI(에이전트 하네스)에서 실행했습니다. ChatGPT·Claude 앱이나 웹에서는 답이 다를 수 있습니다.
받은 피드백: 이 화면 뭔가 좀 답답해 보여요. 여백도 더 주고 구매 버튼도 좀 더 눈에 띄게 키워주시겠어요? 준 사람: 김도윤 PM (주간 디자인 리뷰 미팅에서 구두로 전달, 별도 기록 없음)
피드백을 분해하면
| 원문 | 관찰 | 진단 | 처방 |
|---|---|---|---|
| “이 화면 뭔가 좀 답답해 보여요” | 화면이 답답하게 느껴짐 | 원인은 불명확함 | — |
| “여백도 더 주고” | 명시된 관찰은 없음 | 여백 부족이 답답함의 원인이라는 추정 | 여백 확대 |
| “구매 버튼도 좀 더 눈에 띄게 키워주시겠어요?” | 구매 버튼이 충분히 눈에 띄지 않음 | 크기가 작아 주목도가 낮다는 추정 | 구매 버튼 확대 |
처방에서 거꾸로 추정할 수 있는 관찰
1. 여백을 더 달라는 요청
가능한 관찰은 다음과 같습니다.
- 요소 사이의 간격이 좁아 보였을 수 있음
- 화면 가장자리와 콘텐츠 사이가 좁아 보였을 수 있음
- 텍스트나 이미지가 밀집되어 보였을 수 있음
- 정보량에 비해 화면의 호흡이 부족해 보였을 수 있음
- 특정 영역만 유독 빽빽해 보였을 수 있음
확인 방법:
- 현재 화면에서 요소 간 간격과 가장자리 여백을 실제로 측정
- 같은 화면 안에서 간격이 일관적인지 비교
- 주요 영역과 보조 영역의 밀도가 다른지 확인
- 지정된 화면 크기에서 콘텐츠가 실제로 밀려 보이는지 확인
2. 구매 버튼을 키워 달라는 요청
가능한 관찰은 다음과 같습니다.
- 구매 버튼의 면적이 작아 보였을 수 있음
- 주변 요소에 비해 시각적 우선순위가 낮아 보였을 수 있음
- 버튼을 찾는 데 시간이 걸렸을 수 있음
- 버튼의 클릭 영역이 작아 보였을 수 있음
- “눈에 띄게”가 크기보다 색상, 대비, 위치 또는 주변 여백을 의미했을 수 있음
확인 방법:
- 화면에서 구매 버튼의 크기와 위치를 측정
- 주변 요소와 비교해 버튼의 시각적 대비와 우선순위 확인
- 구매 버튼을 처음 봤을 때 바로 식별되는지 점검
- 실제 클릭 영역이 시각적 버튼 크기와 일치하는지 확인
- 모바일 등 다른 화면 크기에서도 충분히 보이고 눌리는지 확인
먼저 할 일
질문하기 전에 현재 화면을 다음 관점으로 점검합니다.
- 실제로 가장 빽빽해 보이는 영역이 어디인지 표시합니다.
- 여백 부족이 전체 문제인지, 특정 구간의 문제인지 구분합니다.
- 구매 버튼이 작아서 문제인지, 대비·위치·주변 정보 때문에 묻히는지 확인합니다.
- 명백한 간격 불균형이나 버튼의 낮은 우선순위가 보이면 해당 부분만 우선 조정 후보로 잡습니다.
확인이 필요한 질문
“화면에서 특히 답답하게 느껴진 부분이 콘텐츠 사이 간격인지, 화면 가장자리 여백인지, 아니면 특정 영역인지 알려주실 수 있을까요?”
“구매 버튼은 크기 자체를 키우는 방향을 원하시는지, 아니면 색상·대비·위치까지 포함해 더 눈에 띄게 보이길 원하시는지 궁금합니다.”
범위 밖인 부분
현재 제공된 내용만으로는 이미 확정된 디자인 결정이나 다른 담당자의 소유 영역은 확인되지 않습니다. 따라서 범위 밖이라고 단정할 항목은 없습니다.
김도윤 PM이 피드백을 전달한 사람이라는 사실은 확인되지만, 최종 결정권자 또는 해당 화면의 소유자라는 점까지는 주어진 정보만으로 판단할 수 없습니다.
다른 피드백과의 충돌
제공된 피드백 안에는 서로 충돌하는 요구가 없습니다. 다만 “여백을 늘리기”와 “구매 버튼을 키우기”는 화면 공간을 더 사용할 수 있으므로, 실제 적용 시 콘텐츠 밀도나 다른 요소의 배치와 충돌할 가능성은 확인해야 합니다.
바꾸지 말아야 할 것
- 피드백에 없는 색상 변경
- 카피나 정보 구조 변경
- 구매 버튼의 위치 변경
- 전체 화면의 여백 체계 전면 수정
- 다른 요소의 크기나 우선순위 변경
한 사람에게 한 번 구두로 전달된 피드백이므로, 우선은 관찰 가능한 문제를 확인한 뒤 최소 범위로 조정할 데이터 포인트로 취급합니다.
같은 분류의 프롬프트
| UI 디자인 브리프 프롬프트 | |
| 변경 요청의 실제 비용을 따지는 프롬프트 | |
| 경쟁 화면에서 결정을 읽어내는 프롬프트 | |
| 디자인 핸드오프 노트 작성 프롬프트 | |
| 개발 인계 명세 쓰는 프롬프트 |