요청자는 자신이 원하는 것을 정확하게 표현하지 못한다. 그들이 생각하기에 해답이라고 생각하는 것을 요청한다.
요청자가 원하는 형태가 아무리 구체적이어도 실제로 해결하고 싶은 ‘니즈'는 다를 수 있다고 말한다.
‘여기에 배너 하나 넣어주세요'라는 말은 사실은 ‘이 화면에서 발생한 트래픽을 이용해서 매출을 높이고 싶어요'라는 말로 치환할 수 있다는 것이다. 이 부분을 놓치게 되면 우리가 해결해야 하는 문제는 ‘여기에 배너를 어떻게 넣느냐’에 집중하게 된다. 정말 집중해야 하는 문제는 ‘이 화면의 트래픽을 이용해서 매출을 높일 수 있는 방법'이 되느냐인데 말이다. 이것이 ‘진짜 문제'를 정의한다는 의미라고 생각한다.
누군가 ‘2006년으로 돌아가게 해주세요'라고 요청했다고 생각해보자.
‘왜' 2006년으로 돌아가고 싶은지 물어보면 이런 대답이 나온다. “2006년이 가장 행복했던 시기여서 그때로 돌아가고 싶어요”
여기까지 들어보면 애초에 이유까지도 우리가 해결해줄 수 없는 니즈라고 판단할 수 있다. 문제를 요목조목 뜯어 정의해봐야 한다.
•
1) 2006년은 어떤 이유에서 가장 행복했던 시간인가?
•
2) 그 시간으로 돌아갔을 때 얻을 수 있는 것은 무엇인가?
•
1)의 답변: 2006년에 가족이 모두 함께 했고, 가장 성적이 좋은 시기였다.
•
2)의 답변: 살아있는 가족, 자기만족감
•
전제조건 1: 시간은 미래로만 이동 가능하다.
•
전제조건 2: 이미 죽은 사람을 되살릴 수 없다.
•
해결가능한 문제로 재정의: 미래에 새로운 가족을 만들고, 자기만족감을 높여서 2006년보다 더 행복한 시간을 만든다.
불편함만을 찾아내는 것은 VOC에 지나지 않는다.
가장 불편한 진실은 우리가 아무리 사용자의 입장에서 서려고 해도, 우리는 사용자가 아니라는 점이다. 사용자의 문제를 세분화해서 프로젝트화시키고 기술적으로 해결가능한 문제로 치환하는 것이 우리가 말하는 문제 정의 역량이다.
