“리서치 결과 정리됐는데요.” “아, 그 기능 이미 디자인 확정됐어요. 다음 버전에 반영할게요.”
이 말을 들었을 때의 허탈함을 아는 분이 많을 것 같습니다. 열심히 인터뷰하고 분석했는데, 결과물이 나왔을 때 열차는 이미 떠난 뒤입니다. 역에 도착했는데 전광판에 “출발”이 떠 있는 느낌이랄까요.
이건 리서치의 질 문제가 아닙니다. 타이밍 문제입니다.
리서치를 요청받는 순간의 대화를 바꿔야 합니다
시행착오 끝에 찾은 방법은 리서치를 요청받는 순간의 대화를 바꾸는 것이었습니다. PM이 “사용성 테스트 해줄 수 있어요?”라고 하면, 바로 설계에 들어가지 않고 먼저 세 가지를 확인합니다.
“이 결과로 어떤 결정을 내리려고 해요?” 답이 없으면 리서치를 시작하지 않습니다. “언제까지 필요해요? 그 기한의 이유는?” “빠를수록 좋아요”는 기한이 아닙니다. 기한에는 이유가 있어야 합니다. “이미 알고 있는 것과 모르는 것을 나눠주세요.” PM이 가진 데이터를 먼저 파악해야 리서치가 채울 빈칸이 명확해집니다.
처음 30분이 이후 2주의 방향을 결정합니다
이 30분이 이후 2주의 방향을 결정합니다. 그리고 리서치 질문 초안을 PM에게 보여주고 같이 수정합니다. PM이 직접 질문을 추가하면 “우리의 리서치”가 됩니다. 혼자 설계한 리서치에는 오너십이 없지만, 같이 만든 리서치에는 책임이 따라요.
리서치의 가치는 인사이트의 날카로움만이 아니라, 의사결정 직전에 도착하는 타이밍에서 만들어진다.
개인 실무 경험을 바탕으로 한 정리
디자이너와의 타이밍은 더 조심스럽습니다
디자이너와의 타이밍은 더 조심스럽습니다. 리서치 결과가 디자인을 뒤집으면, 디자이너 입장에서는 자기 작업을 부정당한 것처럼 느낄 수 있거든요. 핵심은 “이건 틀렸다”가 아니라 “여기에 리스크가 보인다”로 전달하는 것. 그리고 방향이 열려 있는 단계에서 이야기하는 것입니다.
결과를 던지는 시점이 늦으면, 좋은 인사이트도 방어를 부르게 됩니다.
좋은 우산도 비가 그친 뒤에 펼치면 늦습니다
리서치의 가치는 인사이트의 날카로움이 아니라, 의사결정 직전에 도착하는 타이밍에서 만들어지는 것 같습니다. 아무리 좋은 우산도 비가 그친 뒤에 펼치면 소용이 없으니까요.
리서치가 늦는 이유는 종종 팀의 대화가 늦게 시작되기 때문입니다.
