Double Diamond: 올바른 일을 먼저 하고, 그 일을 제대로 하기
본 장 안내
최소 SOP
목적: 읽고 나면 제품을 만들 때 언제 먼저 문제를 생각해야 하고, 언제부터 솔루션과 프로토타입을 생각해야 하는지 더 명확해집니다. 처음부터 잘못된 방향을 매우 성실하게 만드는 일을 피합니다.
행동 항목: Discover → Define → Develop → Deliver 네 단계를 따라 내려가며, 각 단계에서는 현재 단계에서 해야 할 일만 합니다.
결과: 더 명확한 문제 정의, 비교 가능한 몇 가지 솔루션, 검증 가능한 최소 버전을 얻게 됩니다.
키워드 이동: Double Diamond란 무엇인가 · 첫 번째 다이아몬드 · AI는 어떻게 도와줄 수 있나
다음 내용을 배우게 됩니다
- Double Diamond가 무엇이고, 제로 베이스로 제품을 만들 때 왜 적합한지
- Discover, Define, Develop, Deliver 네 단계가 각각 무엇을 하는지
- "지금은 계속 발산해야 하는가"와 "지금은 수렴을 시작해야 하는가"를 구분하는 법
- Double Diamond를 AI 제품, 프로토타입 설계, 요구사항 검증에 적용하는 법
1. Double Diamond란 정확히 무엇인가
Double Diamond는 영국 Design Council이 널리 알린 고전적인 디자인 프로세스 프레임워크입니다. 하나의 완전한 디자인과 혁신 과정을 연속된 두 개의 다이아몬드 모양으로 그립니다.
"다이아몬드"인 이유는 각 다이아몬드가 서로 반대지만 모두 중요한 두 가지 동작을 포함하기 때문입니다.
- 발산: 먼저 시야를 열고 더 많은 가능성을 본다.
- 수렴: 다시 범위를 좁혀 판단하고 취사선택한다.
전체 과정은 네 단계입니다.
- Discover: 사용자, 문제, 환경, 시장을 넓게 이해한다.
- Define: 많은 정보 속에서 진짜 해결할 가치가 있는 핵심 문제를 추출한다.
- Develop: 핵심 문제를 둘러싸고 여러 해결책을 발산한다.
- Deliver: 더 적합한 해결책을 선별하고, 프로토타입을 만들고, 테스트하고 전달한다.
이 네 단계를 가장 기억하기 쉬운 한 문장으로 압축하면 이렇습니다.
- 첫 번째 다이아몬드: 정확히 어떤 문제를 해결해야 하는지 먼저 파악한다.
- 두 번째 다이아몬드: 그다음 어떤 방법으로 해결할지 결정한다.
이것이 방금 말한 아주 정확한 문장입니다.
- 첫 번째 다이아몬드: 올바른 일을 하기
- 두 번째 다이아몬드: 그 일을 제대로 하기
2. 왜 Double Diamond는 초보자에게 특히 적합한가
초보자가 제품을 만들 때 가장 흔한 리듬은 보통 이렇습니다.
- 아이디어가 떠오른다.
- 이 방향이 멋지다고 느낀다.
- 바로 프로토타입을 그리기 시작한다.
- 만들다 보니 기능이 점점 많아진다.
- 마지막에는 자신이 정확히 어떤 문제를 해결하는지 모르게 된다.
Double Diamond의 가치는 프로세스를 복잡하게 만드는 데 있지 않습니다. "문제 이해"와 "솔루션 설계"를 강제로 분리하게 하는 데 있습니다.
이 말은 평범하게 들리지만 실제로는 매우 중요합니다. 실패한 제품의 상당수는 실행이 성실하지 않아서가 아니라 다음 이유 때문입니다.
- 문제를 잘못 골랐다.
- 사용자를 오해했다.
- 해결책을 너무 일찍 고정했다.
- 방향 검증 없이 세부 다듬기에 많은 시간을 썼다.
Double Diamond는 계속해서 이렇게 상기시킵니다.
- 생각이 잘 이어진다고 해서 문제가 성립했다고 기본 가정하지 마세요.
- 해결책을 만들 수 있다고 해서 그것이 만들 가치가 있다고 기본 가정하지 마세요.
- 프로토타입이 완성되어 보인다고 해서 사용자가 정말 필요로 할 것이라고 기본 가정하지 마세요.
3. 첫 번째 다이아몬드: 올바른 일을 하기
첫 번째 다이아몬드는 문제 자체에 집중하며, 해결책에 집중하지 않습니다.
한 문장으로 이해하면 이렇습니다. 서둘러 만들지 말고, 정말 만들 가치가 있는지 먼저 파악하세요.
3.1 Discover: 먼저 문제 공간을 열기
Discover 단계의 핵심 과제는 넓게 조사하는 것이지, 빠르게 결론을 내리는 것이 아닙니다.
이 단계에서 보통 하는 일은 다음과 같습니다.
- 사용자가 실제 장면에서 어떻게 행동하는지 보기
- 잠재 사용자를 인터뷰해 최근 언제 문제를 만났는지 이해하기
- 지금은 어떻게 임시로 해결하고 있는지 관찰하기
- 경쟁 제품과 대체 방안이 어떻게 처리하는지 보기
- 시장, 프로세스, 제약, 상하류 정보를 수집하기
많은 사람이 Discover를 "자료를 좀 더 많이 보는 것"으로 오해합니다. 사실 더 중요한 것은 사람과 장면을 이해하는 것이지, 정보만 잔뜩 검색하는 것이 아닙니다.
예를 들어 "AI가 회의록 정리를 도와주는 도구"를 만들고 싶다면, Discover 단계에서 더 집중해야 할 것은 다음입니다.
- 사용자가 회의 후 정확히 어느 부분에서 가장 고통스러워하는지
- 기록이 어려운지, 정리가 어려운지, 동기화가 어려운지
- 지금은 직접 쓰는지, 인턴에게 시키는지, 녹음을 다시 듣는지, 아예 정리하지 않는지
- 어떤 회의 장면에서 회의록이 가장 필요하고, 어떤 장면에서는 전혀 필요 없는지
이 단계에서 가장 중요한 목표는 답을 내는 것이 아니라, 너무 일찍 자신이 이미 답을 알고 있다고 착각하지 않는 것입니다.
3.2 Define: 많은 정보 속에서 핵심 문제 추출하기
Discover가 시야를 여는 것이라면, Define은 수렴을 시작하는 것입니다.
Define 단계에서 해야 할 일은 모든 관찰을 그대로 보존하는 것이 아니라, 다음을 묻는 것입니다.
- 진짜로 가장 우선 해결할 가치가 있는 문제는 무엇인가?
- 어떤 문제가 가장 자주 나타나고, 가장 아프고, 가장 가치 있는가?
- 첫 번째 버전은 정확히 어떤 장면 하나만 겨냥할 것인가?
이 단계의 핵심은 넓은 주제를 명확한 문제 정의로 수렴하는 것입니다.
처음에는 이렇게 말할 수 있습니다.
회의 효율을 높이는 AI 도구를 만들고 싶다.
Define 단계에 이르면 더 좋은 표현은 이렇게 바뀔 수 있습니다.
우리는 먼저 프로젝트형 팀이 30~60분짜리 협업 회의가 끝난 뒤, 10분 안에 할 일, 담당자, 마감일이 포함된 회의록을 만들지 못하는 문제를 해결한다.
이제 문제가 명확해지기 시작합니다.
- 사용자는 누구인가
- 장면은 무엇인가
- 막히는 지점은 무엇인가
- 성공 기준은 무엇인가
Define의 본질은 "문제가 많다"에서 "이번에는 어떤 문제 하나를 먼저 해결할 것인가"로 수렴하는 것입니다.
4. 두 번째 다이아몬드: 그 일을 제대로 하기
첫 번째 다이아몬드를 완료한 뒤에야 진정으로 두 번째 다이아몬드에 들어가기에 적합합니다. 이때 해결하려는 것은 더 이상 모호한 방향이 아니라 수렴된 구체적인 문제이기 때문입니다.
4.1 Develop: 핵심 문제를 중심으로 솔루션 발산하기
Develop 단계의 핵심은 같은 문제를 중심으로 여러 가능한 솔루션을 탐색하는 것입니다.
주의할 점은 여기서의 발산은 Discover 단계와 다릅니다.
- Discover의 발산은 문제 공간을 탐색하는 것입니다.
- Develop의 발산은 해결책 공간을 탐색하는 것입니다.
회의록 예시를 계속 쓰면, Develop 단계에서는 다음을 생각할 수 있습니다.
- 웹 도구를 만들 것인가, 회의 플러그인을 만들 것인가
- 녹음 업로드 후 처리할 것인가, 실시간 기록할 것인가
- 요약만 할 것인가, 할 일 추출에 집중할 것인가
- 개인 효율을 강조할 것인가, 팀 동기화를 강조할 것인가
- 사용자가 자유롭게 편집하게 할 것인가, 구조화된 템플릿을 바로 출력할 것인가
이 단계는 브레인스토밍에 매우 적합하고, 팀과 함께 솔루션을 넓히기에도 좋습니다.
하지만 전제가 있습니다. 모든 솔루션은 이미 정의된 같은 문제를 섬겨야 합니다.
문제가 명확히 정의되지 않았다면 Develop은 쉽게 다시 기능이 난무하는 상태가 됩니다.
4.2 Deliver: 솔루션 선택, 프로토타입, 테스트, 전달
Deliver 단계는 두 번째 다이아몬드 안의 수렴 단계입니다.
이때 해야 할 일은 더 많이 상상하는 것이 아니라 판단을 시작하는 것입니다.
- 어떤 솔루션이 현재 단계에 가장 적합한가
- 어떤 버전이 가장 작지만 가장 유용한가
- 어떤 기능은 반드시 먼저 해야 하고, 어떤 기능은 나중으로 미뤄도 되는가
- 어떻게 프로토타입을 만들고, 테스트하고, 작은 범위에서 검증할 것인가
많은 사람이 Deliver를 "출시"와 같다고 생각합니다. 사실 더 정확한 뜻은 하나의 솔루션을 테스트 가능하고, 검증 가능하며, 반복 개선 가능한 것으로 바꾸는 것입니다.
그것은 다음일 수 있습니다.
- 저충실도 흐름도 한 장
- Figma 프로토타입
- 실행 가능한 MVP
- 소규모 사용자 테스트
- 실제 피드백 이후의 반복 개선 버전
Deliver의 핵심은 "완벽한 전달"이 아니라 가능한 한 빨리 솔루션을 실제 환경에 넣어 검증하는 것입니다.
5. 가장 기억하기 쉬운 대조표
네 단계를 자꾸 헷갈린다면 아래 버전을 그대로 기억하세요.
| 단계 | 무엇을 하는가 | 키워드 | 흔한 산출물 |
|---|---|---|---|
| Discover | 문제 이해 | 조사, 관찰, 인터뷰, 정보 수집 | 사용자 인사이트, 장면 메모, 문제 목록 |
| Define | 문제 정의 | 추출, 집중, 취사선택, 문제 다시 쓰기 | 문제 정의, 우선순위, MVP 진입점 |
| Develop | 솔루션 탐색 | 브레인스토밍, 비교, 공동 창작, 프로토타입 구상 | 솔루션 목록, 흐름 스케치, 프로토타입 방향 |
| Deliver | 솔루션 검증 | 프로토타입, 테스트, 반복 개선, 전달 | 프로토타입, 테스트 피드백, 최적화 버전 |
더 압축하면 이렇습니다.
- Discover / Define: "올바른 일을 하기"를 해결한다.
- Develop / Deliver: "그 일을 제대로 하기"를 해결한다.
6. Double Diamond의 가장 흔한 오해
6.1 Discover도 하지 않고 바로 Deliver하기
가장 흔한 경우입니다. 많은 사람이 아이디어가 생기자마자 프로토타입을 그리고, PRD를 쓰고, 모델을 붙이고, 페이지를 만듭니다.
문제는 당신이 성실하지 않다는 것이 아니라, 해결할 가치가 있는 문제인지 아직 확인하지 않았을 수 있다는 점입니다.
6.2 Discover는 오래 하지만 끝내 Define하지 않기
또 다른 극단은 계속 조사하고, 계속 자료를 보고, 계속 인터뷰하지만 좀처럼 수렴하지 못하는 것입니다.
Double Diamond는 무한 발산을 하라는 뜻이 아닙니다. 발산 후에는 반드시 판단과 취사선택으로 들어가야 한다고 알려 주는 것입니다.
6.3 Define 이후 몰래 문제를 바꾸기
많은 팀은 Develop 단계에서 어떤 솔루션이 더 쉽게 만들 수 있다는 이유로, 기존 솔루션에 맞도록 문제 정의를 거꾸로 수정합니다.
이것은 위험합니다. 문제를 해결하는 것이 아니라 자신이 선호하는 솔루션을 정당화하고 있을 수 있기 때문입니다.
6.4 Deliver를 "크고 완전한 출시"로 오해하기
Deliver는 완전한 제품을 모두 만들어야 끝난다는 뜻이 아닙니다. 많은 경우 테스트 가능한 프로토타입 하나, 실제 사용자 테스트 한 번이면 이미 좋은 deliver입니다.
7. AI 제품에서 Double Diamond는 어떻게 쓰나
AI 제품은 특히 "능력 우선" 함정에 빠지기 쉽습니다. 모델 능력이 너무 매력적으로 보이기 때문입니다. 당신은 곧장 이런 생각을 하고 싶어질 수 있습니다.
- 멀티모달을 붙일까
- Agent를 만들까
- 워크플로우를 넣을까
- 음성, 이미지, 웹 검색을 연결할까
하지만 Double Diamond는 먼저 이렇게 묻게 합니다.
- 사용자는 정확히 어느 단계에서 정말 막혀 있는가
- 이 막힘은 반드시 AI가 있어야 해결되는가
- AI를 쓰지 않는다면 기존 방법은 정확히 어디가 가장 나쁜가
- AI가 들어간 뒤 가장 핵심적인 진전은 무엇인가
이것은 흔한 상황을 피하게 해 줍니다. 능력은 강한데 가치는 약한 상황입니다.
실용적인 순서는 다음과 같습니다.
- Discover 단계에서 사용자가 지금 어떻게 과제를 처리하는지 관찰한다.
- Define 단계에서 가장 아픈 장면 하나를 명확한 문제 정의 한 문장으로 쓴다.
- Develop 단계에서 어떤 AI 기능이 이 문제를 가장 잘 섬기는지 비교한다.
- Deliver 단계에서 최소 버전을 만들고 실제 사용자에게 테스트하게 한다.
8. 바로 적용할 수 있는 Double Diamond 템플릿
자기 제품을 만들고 있다면 이 순서대로 먼저 써 보세요.
Discover
- 내가 관찰한 사용자는 누구인가?
- 그들이 최근 이 문제를 만난 것은 언제인가?
- 지금은 어떻게 해결하고 있는가?
- 가장 짜증 나고, 느리고, 불안한 지점은 무엇인가?
Define
- 이 문제들 중 가장 우선 해결할 가치가 있는 것은 무엇인가?
- 어떤 장면이 가장 빈번하거나 가장 핵심적인가?
- 첫 번째 버전은 누구만, 무엇만 섬길 것인가?
- 성공적으로 해결되면 사용자의 상태는 어떻게 변하는가?
Develop
- 이 문제에 대해 어떤 가능한 솔루션이 있는가?
- 어떤 솔루션이 가장 가볍고, 빠르고, 검증하기 쉬운가?
- 반드시 해야 할 것은 무엇이고, 나중으로 미룰 것은 무엇인가?
Deliver
- 이 방향을 검증하기 위해 가장 작게 무엇을 전달할 수 있는가?
- 흐름도인가, 프로토타입인가, MVP인가?
- 누구에게 테스트해야 하는가?
- 테스트 후 계속할지, 수정할지, 포기할지는 어떻게 판단할 것인가?
9. 제로 베이스도 이해할 수 있는 예시
"대학생의 취업 이력서 준비를 돕는 AI 도구"를 만들고 싶다고 가정해 봅시다.
많은 사람은 처음부터 두 번째 다이아몬드로 들어가 이런 생각을 시작합니다.
- 원클릭 미화를 넣을까
- 지능형 문장 개선을 넣을까
- JD 자동 매칭을 할까
- 자기소개서를 생성할까
하지만 Double Diamond를 따르면 더 좋은 과정은 이렇습니다.
첫 번째 다이아몬드
Discover
- 취업 준비생에게 최근 이력서를 고친 것이 언제인지 묻는다.
- 그들이 이전 이력서를 어떻게 새 버전으로 바꾸는지 본다.
- 가장 어려운 것이 "쓸 줄 모름"인지, "고칠 줄 모름"인지, "좋은지 판단할 줄 모름"인지 이해한다.
Define
- 마지막에는 더 구체적인 문제로 수렴한다.
- "대학생은 이력서를 만들 줄 모른다"가 아니다.
- "처음 인턴십에 지원하는 학생은 기존 경험을 직무에 맞는 표현으로 바꾸기 어려워 지원을 미룬다"이다.
두 번째 다이아몬드
Develop
- 몇 가지 솔루션을 생각한다. 템플릿 라이브러리, AI 문장 개선, 직무 대조, 이력서 점수화, 사례 참고.
Deliver
- 첫 버전은 "직무 설명에 따라 경험 bullet point를 바꿔 쓰기"만 만든다.
- 학생 5명에게 써 보게 하고, 더 빨리 첫 버전의 이력서를 제출하게 되는지 본다.
첫 번째 다이아몬드를 탄탄하게 하면 두 번째 다이아몬드가 훨씬 명확해진다는 것을 알 수 있습니다.
10. 정리
Double Diamond의 가장 강한 힘은 혼란스러운 덩어리를 네 개의 더 명확한 동작으로 나눠 준다는 데 있습니다.
- 먼저 발산해 문제를 이해한다.
- 다시 수렴해 문제를 정의한다.
- 다시 발산해 솔루션을 탐색한다.
- 마지막으로 수렴해 솔루션을 전달한다.
이 모델은 당신을 느리게 만들기 위한 것이 아닙니다. 바빠 보이지만 사실 방향이 틀린 수많은 우회로를 줄이기 위한 것입니다.
특히 AI 시대에는 만드는 속도가 점점 빨라지기 때문에 Double Diamond가 오히려 더 중요해집니다. "만드는 것"이 점점 쉬워질수록 진짜 희소한 능력은 이렇게 바뀌기 때문입니다. 해결할 가치가 있는 문제를 풀고 있는가, 그리고 그것을 적합한 방식으로 풀고 있는가.
이 한 문장만 기억하면 됩니다.
올바른 일을 먼저 하고, 그 일을 제대로 하세요.
11. AI로 Double Diamond 흐름을 실행하는 방법
Double Diamond 자체는 AI 도구가 아니지만, AI는 네 단계에서 "가속기" 역할을 하기에 매우 적합합니다. 핵심은 AI가 대신 결정하게 하는 것이 아니라, 시야 확장, 정보 정리, 솔루션 비교, 검증 자료 생성을 돕게 하는 것입니다.
11.1 Discover 단계에서 AI로 정보 밑작업 한 번 하기
정식 인터뷰와 조사를 시작하기 전에 AI에게 가벼운 문제 스캔을 맡길 수 있습니다. 예를 들면 다음입니다.
- 시장에서 흔한 대체 방안은 무엇인가
- 사용자가 공개 커뮤니티에서 가장 자주 불평하는 것은 무엇인가
- 이 문제는 어떤 장면과 사람군에서 자주 나타나는가
- 기존 제품은 보통 무엇을 놓치고 있는가
이 단계는 실제 조사를 대체할 수 없지만, 문제 지도를 빠르게 만드는 데 매우 적합합니다.
아주 간단한 초보자 입력은 이렇게 쓸 수 있습니다.
대학생 이력서 수정을 도와주는 도구를 만들고 싶어.
기능을 생각해 주지 말고, 이 문제에서 사람들이 가장 자주 겪는 어려움이 무엇인지 먼저 봐 줘.AI는 이렇게 출력할 수 있습니다.
초기 문제 지도:
1. 어떤 경험을 써야 할지 모름
2. 직무에 맞게 어떻게 수정해야 할지 모름
3. 여러 번 고쳤는데도 충분히 좋은지 확신하지 못함
4. 다른 사람에게 봐 달라고 해야 하지만 매번 부탁하기 불편함
5. 확신이 없어서 계속 지원을 미룸이 출력의 역할은 결론을 대신 내려 주는 것이 아니라, Discover에 더 빨리 들어가게 해 주는 것입니다.
11.2 Define 단계에서 AI에게 문제 정의 수렴을 돕게 하기
많은 사람이 자료를 한가득 모은 뒤 가장 어려워하는 것은 문제를 진짜 명확한 한 문장으로 줄이는 일입니다. 조사 메모를 AI에게 주고 몇 가지 후보 문제 정의로 압축하게 할 수 있습니다.
아래는 Discover 단계에서 모은 사용자 피드백과 조사 메모야.
[내용 붙여넣기]
다음 세 가지를 도와줘.
1. 가장 자주 나타나는 문제 패턴을 요약
2. 문제 빈도, 고통감, 검증 가능성을 기준으로 우선 해결할 가치가 있는 문제 3개 정리
3. 각 문제를 구체적인 문제 정의 한 문장으로 작성이렇게 하면 "문제가 너무 많다"에 머무르지 않고 Define으로 들어가기 쉬워집니다.
입력을 아주 간단하게 써도 됩니다.
지금 모은 문제는 이거야.
1. 다들 이력서에 무엇을 써야 할지 모름
2. 다들 어떻게 고쳐야 할지 모름
3. 다들 잘 고친 건지 확신하지 못해 지원을 망설임
첫 버전에서 어떤 문제를 먼저 해결하는 게 가장 적합한지 봐 줘.AI는 이렇게 출력할 수 있습니다.
우선 해결을 추천하는 문제:
"처음 인턴십에 지원하는 학생은 이력서가 이미 지원 가능한 수준인지 확신하지 못해 반복 수정하고 지원을 미룬다."
이유:
1. 문제가 더 구체적이다.
2. 지연 행동을 설명할 수 있다.
3. 작은 버전을 설계해 검증하기 쉽다.이런 출력은 유용합니다. 흐릿한 문제들 속에서 MVP 출발점에 가까운 정의 하나를 수렴하게 해 주기 때문입니다.
11.3 Develop 단계에서 AI로 여러 솔루션 발산하기
많은 사람은 문제를 정의하자마자 머릿속에 처음 떠오른 솔루션만 바라봅니다. 이 단계에서 AI는 강제로 발산시키는 데 매우 적합합니다.
핵심 문제를 이렇게 정의했어: [문제 정의]
최종 답을 하나만 주지 말고, 아래 각도에서 2~3가지 해결 방향을 제안해 줘.
1. 가장 가벼운 MVP
2. 수요 검증에 가장 적합한 방안
3. 경험 개선에 가장 적합한 방안
4. AI에 의존하지 않는 방안
5. AI에 의존하는 방안
마지막에는 각 방안의 장점, 위험, 검증 비용을 비교해 줘.이렇게 하면 너무 일찍 하나의 솔루션에 묶이지 않게 됩니다.
간단한 입력은 이렇게 쓸 수 있습니다.
현재 문제 정의는 이거야.
"대학생은 이력서가 이미 지원 가능한지 확신하지 못해 계속 미루고 있다."
서로 다른 해결책 4가지를 생각해 줘. 하나만 주지 마.AI는 이렇게 출력할 수 있습니다.
방안 1: 이력서 지원 가능 체크리스트
방안 2: 직무 설명에 맞춘 맞춤형 문장 개선
방안 3: 사용자가 이력서를 업로드하면 위험 알림 제공
방안 4: 우수 사례 대조를 제공해 사용자가 차이를 판단하도록 도움이때부터 "솔루션 비교"로 들어가기 쉬워지고, 처음부터 AI 문장 개선 하나만 바라보지 않게 됩니다.
11.4 Deliver 단계에서 AI로 프로토타입 문구와 테스트 자료 생성하기
Deliver 단계에 들어가면 AI는 다음 작업을 빠르게 처리하는 데 매우 적합합니다.
- 저충실도 프로토타입의 페이지 문구 생성
- 사용자 테스트 스크립트 정리
- 비교 가능한 여러 버전의 제목, 버튼, 설명문 생성
- 테스트 후 피드백과 문제 목록 정리
예를 들어 AI에게 20분 사용자 테스트 스크립트를 만들게 하거나, 사용자 5명의 피드백을 "계속 진행 / 방향 수정 / 중단" 판단 근거로 정리하게 할 수 있습니다.
가장 작은 입력 예시는 다음입니다.
아주 간단한 프로토타입을 만들었어.
사용자가 이력서를 업로드하면, 시스템이 어떤 부분이 아직 지원하기에 적합하지 않은지 알려 줘.
15분짜리 사용자 테스트 스크립트를 만들어 줘.AI는 이렇게 출력할 수 있습니다.
15분 테스트 스크립트:
1. 먼저 사용자에게 최근 이력서 지원 경험을 설명하게 한다.
2. 사용자가 독립적으로 이력서 업로드를 완료하게 한다.
3. 피드백 결과를 이해하는지 관찰한다.
4. 질문: 이 안내 중 어떤 것이 가장 도움이 되고, 어떤 것이 헷갈렸나요?
5. 질문: 다음 지원 전에 다시 쓰고 싶나요?이 출력은 실용적입니다. "프로토타입을 만들었다"에서 "다음에는 어떻게 테스트할까"로 넘어가게 해 주기 때문입니다.
11.5 AI에게 "단계 문지기" 역할을 맡기기
Double Diamond에서 가장 흔한 문제는 사람이 단계를 건너뛰는 것입니다. AI에게 직접 문지기 역할을 맡겨 현재 어느 단계에 있는지 알려 달라고 할 수 있습니다.
제품 프로세스 코치 역할을 해 줘.
아래는 현재 내 프로젝트 상태야: [설명]
내가 지금 Discover, Define, Develop, Deliver 중 어디에 더 가까운지 판단해 줘.
그리고 알려 줘.
1. 내가 너무 일찍 다음 단계로 넘어갔는지
2. 현재 단계에서 가장 보충해야 할 행동은 무엇인지
3. 지금은 먼저 하지 말아야 할 일은 무엇인지초보자에게 특히 유용합니다. "문제를 아직 명확히 생각하지 않았는데 프로토타입을 그리기 시작하는" 일이 매우 쉽게 일어나기 때문입니다.
📚 Assignments
위 내용을 바탕으로 다음 과제를 완료하세요.
- 최근 만들고 싶은 제품 아이디어 하나를 고르고, Discover, Define, Develop, Deliver 네 단계 초안을 작성하세요.
- Define 단계에서 문제를 구체적인 한 문장으로 강제로 줄이세요.
- Develop 단계에서 처음 떠오른 방법 하나만 바라보지 말고, 최소 3가지 다른 방안을 나열하세요.
- Deliver 단계에서 일주일 안에 전달 가능한 최소 검증 버전을 작성하세요.
더 읽어 보기
이 글은 주로 Design Council의 Double Diamond 공식 자료를 참고했습니다. 이어서 보기 좋습니다.