완성도 높은 화면 모형을 보여주면 사용자는 색과 문구를 평가하고 팀은 이미 많은 결정을 했다고 느낍니다. 하지만 실제 위험이 배송 약속을 운영팀이 지킬 수 있는지라면 화면 반응을 아무리 측정해도 답을 얻지 못합니다.

핵심 프로토타입의 충실도는 출시와 얼마나 비슷한지가 아니라 검증할 위험을 얼마나 정직하고 저렴하게 드러내는지로 결정해야 합니다.

먼저 보면 좋은 점

  • 먼저 바뀌면 제품이 무너지는 가정을 한 문장으로 씁니다.
  • 흐름, 이해, 운영, 기술 위험에 맞는 표현 방식을 고릅니다.
  • 배운 뒤 버릴 수 있을 만큼만 만들고 성공과 중단 기준을 둡니다.

위험 하나에 맞는 충실도와 종료선을 고른다

송금 앱에서 사용자가 수취인 확인 문구를 이해하는지가 위험이면 종이 흐름이나 클릭 모형이면 충분합니다. 상담원이 5분 안에 예외 송금을 복구할 수 있는지가 위험이면 역할극과 가짜 운영 도구가 필요합니다. 실제 송금 성공률을 보려는 단계에 이르기 전에는 시각 완성도에 시간을 쓰지 않습니다.

대상 사용자 5명 중 4명이 수취인과 금액을 정확히 설명하면 문구 가설은 다음 단계로 넘기되, 한 명이라도 잘못된 계좌로 진행할 위험이 있으면 중단합니다. 오늘 프로토타입 화면을 열기 전에 가장 비싼 오판, 필요한 행동 증거, 버릴 날짜를 적고 그 증거에 필요 없는 표현을 삭제하십시오. 배우지 못한 모형도 더 다듬지 않습니다.

위험을 쓰기 전에는 화면을 그리지 않는다

당일 세탁 수거 서비스의 위험은 고객이 시간대를 이해하는지, 기사 배정이 가능한지, 실시간 위치가 정확한지 서로 다릅니다. 하나의 고화질 앱 모형으로 세 질문에 답하려 하면 반응의 의미가 섞입니다.

“고객은 두 시간 범위의 방문을 기다릴 의사가 있다”처럼 가정과 실패 영향을 씁니다. 이미 확실한 부분은 모형에 시간을 쓰지 않습니다.

흐름과 언어는 낮은 충실도로 본다

화면 순서와 정보 이해가 위험하다면 종이 카드나 단순 클릭형 모형이면 충분합니다. 사용자가 수거 시간을 고르고 변경하는 과정을 말로 안내하지 않고 수행하는지 봅니다.

시각 완성도가 낮다는 사실을 설명하되 실제가 아닌 기능을 작동하는 척 속이지 않습니다. 버튼 색 선호보다 다음 행동을 예측하고 완료하는지를 기록합니다.

사람과 운영은 역할극으로 드러낸다

기사 지연과 고객 문의가 핵심이면 팀원이 기사와 상담원 역할을 맡아 알림, 재배정, 환불 흐름을 시뮬레이션합니다. 화면 뒤에서 누가 어떤 정보를 언제 받아야 하는지 발견할 수 있습니다.

역할극에는 정상 상황뿐 아니라 주소 오류, 연락 불가, 갑작스러운 취소를 넣습니다. 운영자가 별도 표를 만들거나 개인 메신저를 써야 한다면 제품 흐름이 백스테이지 부담을 숨긴 것입니다.

수요와 제공 가능성은 컨시어지로 시험한다

자동 배정 시스템을 만들기 전에 소수 고객의 요청을 사람이 직접 배정할 수 있습니다. 고객은 실제 가치에 가까운 경험을 하고 팀은 예외 종류와 처리 시간을 배웁니다.

수동 서비스라는 사실과 데이터 사용 범위를 공개합니다. 직원의 과도한 노력으로 약속 시간을 맞추고도 자동화 가능하다고 결론 내리지 않도록 건당 노동과 실패율을 측정합니다.

프로토타입의 종료 조건을 정한다

위험별 표에는 가정, 필요한 현실감, 참여자, 관찰 행동, 성공 기준, 버릴 산출물을 적습니다. 이해 위험이 해소되면 시각 장식을 더하지 않고 다음 위험으로 이동합니다.

참여자가 모형의 한계를 계속 오해하거나 실제 규정과 안전 조건을 재현할 수 없다면 시험을 중단합니다. 제작 비용이 커져 팀이 반대 증거를 받아들이지 못하게 되기 전에 더 낮은 방식으로 돌아갑니다.

충실도는 화면 완성도가 아니라 위험으로 정한다

송금 앱의 수취인 확인 문구가 이해되는지 볼 때는 종이 화면으로 5명이 다음 행동과 취소 방법을 설명하게 하면 됩니다. 반면 실제 이체 지연과 상담 인계를 시험하려면 테스트 계좌, 운영자 역할, 알림 시간을 포함한 서비스 모형이 필요합니다. 각각 4명 이상이 치명적 오해 없이 과업을 끝내는지 기준을 미리 둡니다.

시각 품질 때문에 호감만 측정되거나 모형인데도 실제 송금으로 오해할 위험이 있으면 중단합니다. 산출물은 시험할 위험, 필요한 현실감, 성공·중단 기준, 버릴 부분입니다. 오늘 만든 시안에서 검증 질문과 관계없는 디테일 하나를 제거해 보십시오.

메모

  • 현재 프로토타입이 답해야 할 위험한 가정은 하나로 좁혀졌는가?
  • 그 질문에 화면보다 역할극이나 수동 제공이 더 적합하지 않은가?
  • 반대 증거가 나와도 산출물을 버릴 수 있는 비용인가?