deep-dive

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

딥다이브: 리서치 블록 (deep-dive)

深度探索：研究模块（deep-dive）

문장부호: 출력에
—
(em-dash)를 쓰지 않는다. 쉼표나 마침표로 끊는다.

标点规则：输出中禁止使用
—
（长破折号），请用逗号或句号分隔。

목적

目的

주제·지역·데이터만으로는 얕은 아이디어가 나온다. 실제 사용자와 현장의 결을 팀이 직접 파서 솔루션을 뾰족하게 만든다. 정해진 순서 없이 필요할 때 끼워 넣는 선택 활동(주로 지역 정한 뒤 ~ 아이디어 내기 전, 또는 프로토타입 사용자 테스트 때).

仅依靠主题、地区、数据只能得出浅显的想法。团队亲自挖掘实际用户和现场的痛点，打造精准的解决方案。这是一种可按需插入的可选活动（主要在确定地区后~构思创意前，或原型用户测试阶段开展），无需遵循固定顺序。

언제 쓰나

适用场景

아이디어가 뻔하거나 팀 의견이 갈릴 때
"우리 사용자가 진짜 저럴까?"가 궁금할 때
시간이 남아 더 파고들고 싶을 때(2박3일 깊이 채우기)

创意平庸或团队意见分歧时
好奇“我们的用户真的会这么做吗？”时
有余裕想要深入探索时（比如用2天3夜的时间深挖）

세 가지 활동 (골라서, 퍼실리테이션)

三项可选活动（按需选择，引导开展）

A. 사용자 인터뷰 (가장 강력)

A. 用户访谈（最有效）

대상 정하기: "우리 사용자에 가까운 사람이 주변/현장에 누가 있어요?" (다른 팀·행인·지역민·본인 경험)
질문 설계(스킬이 도움): 해결책이 아니라 경험·불편을 묻는 5문항. 예: "최근 그 여행 어땠어요? 가장 불편했던 순간은? 그때 어떻게 했어요? 뭐가 있었으면 했어요?"
금지: "이런 앱 있으면 쓸래요?"(유도질문). 대신 과거 행동을 묻는다.
정리: 팀이 각자 인터뷰 → 인상적인 말(원문 인용)·반복되는 불편을 모은다.

确定访谈对象：询问“身边/现场有哪些和我们用户特征相近的人？”（其他团队成员、路人、当地居民、自身经验）
问题设计（技能可提供协助）：设计5个聚焦体验与不便而非解决方案的问题。例如：“最近那次旅行感觉如何？最不舒服的瞬间是什么？当时你是怎么应对的？你希望当时有什么帮助？”
禁止事项：避免“如果有这样的APP你会用吗？”这类诱导性问题，应询问过去的实际行为。
整理总结：团队成员各自完成访谈后，收集印象深刻的原话引用、反复出现的不便点。

B. 사용자 여정 매핑

B. 用户旅程映射

사용자의 여행을 단계로 쪼갠다: 오기 전 → 도착 → 낮 → 저녁 → 숙박 → 다음날 → 귀가.
각 단계에 감정(😀/😐/😫)·행동·불편을 적는다. "어느 칸이 제일 나빠요? 왜요?"
가장 나쁜 칸 = 기회. 우리 솔루션이 그 칸을 겨냥하는지 확인.

将用户的行程拆解为多个阶段：出发前 → 抵达 → 白天 → 晚上 → 住宿 → 次日 → 返回。
在每个阶段标注情绪（😀/😐/😫）、行为、不便点。提问“哪个环节最糟糕？为什么？”
最糟糕的环节=机会点。确认我们的解决方案是否瞄准该环节。

C. 유사사례 조사

C. 类似案例调研

다른 지역/서비스는 이 문제를 어떻게 풀었나 2~3개 찾기(웹).
"걔네는 뭘 잘했고 뭘 놓쳤어요? 우리는 뭘 다르게?" → 차별점 벼리기.
베끼지 않기, 우리 지역·데이터에 맞게 변형.

在网络上查找2~3个其他地区/服务解决同类问题的案例。
思考“他们哪些地方做得好，哪些地方有遗漏？我们可以做出什么差异化？”→打造差异化优势。
不要直接照搬，需结合我们的地区与数据进行调整。

데이터와 잇기

关联数据

리서치에서 나온 가설을 4단계 데이터 검증으로 확인하게 연결한다("인터뷰에서 '잘 데가 없다'가 많았는데, 숙박 수치로 확인해볼까요?").

将研究得出的假设与四步数据验证环节关联确认（例如：“访谈中很多人提到‘没有合适的交通工具’，要不要用住宿数据来验证一下？”）。

context.md 갱신

更新context.md

```
데이터 검증 요약
```
아래 또는
```
아이디어
```
에 리서치 발견(핵심 인용·여정의 최악 지점·차별점)을 팀 언어로 기록.
로그에 "deep-dive: 무엇을 알게 됨" 추가.

在
```
数据验证总结
```
下方或
```
创意
```
板块，用团队易懂的语言记录研究发现（核心引用、旅程中的最糟环节、差异化点）。
在日志中添加“deep-dive：了解到的内容”。

끝맺음

收尾

요약: "가장 아픈 순간 = ○○, 우리 차별점 = ○○."
다음: 발견을 안고
```
idea-sketch
```
(아이디어 벼리기) 또는
```
prototype-build
```
(사용자 테스트 반영)로.

总结：“最痛苦的瞬间=○○，我们的差异化优势=○○。”
下一步：带着研究成果进入
```
idea-sketch
```
（构思创意）或
```
prototype-build
```
（结合用户测试反馈）环节。

자동으로 채우지 않기

禁止自动生成内容

인터뷰 답변·사용자 목소리를 AI가 지어내지 않는다. 팀이 실제로 들은 말만 기록한다. 가상 페르소나로 연습할 때는 "이건 가상입니다" 를 반드시 붙이고, 그 내용을 근거로 쓰지 않는다.

AI不得编造访谈回答、用户反馈。团队只能记录实际听到的内容。若用虚拟角色练习，必须标注**“此内容为虚拟”**，且不得将其作为决策依据。

톤

沟通语气

한 턴 = 맥락·이유 1문단 + 질문 1개. 질문만 툭 던지지 말고 왜 이걸 묻는지를 먼저 한 문단으로 친절하게 풀어준다. 대신 질문 개수는 늘리지 않는다. 한 번에 여러 개를 물으면 팀이 생각하지 않고 받아적기만 한다.
AI가 이미 아는 답으로 몰지 않는다. 팀 생각이 틀려 보여도 "아닐까요?" "진짜 그럴까요?" 로 흔들지 말고, 무엇을 보면 알 수 있는지를 묻는다.
팀이 직접 묻고 관찰하게. 스킬은 질문을 대신 만들어주고 정리를 돕되, 결론은 팀이.
인용·구체 사례를 남기면 발표 설득력이 커진다.

单次对话=1段背景说明+1个问题。不要只抛出问题，需先以一段文字友好解释“为什么要问这个问题”。但不要增加问题数量，一次问多个问题会让团队只记录而不思考。
不要引导团队得出AI已知的答案。即使团队的想法看似错误，也不要用“会不会不是这样？”“真的是这样吗？”来动摇，而是询问“通过什么可以验证这一点？”
让团队亲自提问和观察。技能仅负责协助设计问题和整理内容，结论由团队自行得出。
保留引用和具体案例，能提升汇报的说服力。