[현장실습 #3] 신사업 프로젝트 - 콘셉 브리프 도출하기

퍼소나 작업이 끝나고 다음은 매핑과 콘셉 브리프였다.

 

콘셉 브리프는 정의 단계의 최종 결과물이다. 책에서는 통찰에서 한 단계 더 나아가 다양한 기회 영역을 포착하고, 그중에 집중하고자 하는 기회나 해결하고자 하는 문제를 선별하는 것이라고 설명한다. 그 아이디어를 모아 하나의 콘셉트로 만들고, 이를 개략적으로 설명한 것이 콘셉 브리프다.

 

순서로 보면 발상 단계에서 HMW를 던져 아이디어를 구체화하고, 추려진 기회 영역 중 가장 중요하고 실현 가능한 데서 아이디어를 모아 하나의 콘셉트를 만드는 흐름이다.

 

회의에서 받은 기준은 명확했다.

 

"콘셉 브리프는 왜 하고 싶은가다. 이 콘셉트를 들었을 때 사고 싶어야 한다. 그만큼 꽂히고 끌려야 한다. 그런 걸 보고 콘셉 브리프라고 한다."

 

예시도 하나 들어주셨는데, 듣고 나서야 알았다. 콘셉 브리프는 기능 설명이 아니었다.

고객이 가장 아파하는 지점을 정확히 건드리고, 그걸 어떻게 뒤집어줄지를 한 문장으로 말하는 것이었다.

 

이번에는 대상을 넷으로 나누고 팀원 4명이 각자 하나씩 맡기로 했다.

우리는 같은 서비스라도 판매 될 대상이 다르기 때문에 각자 다른 컨셉 브리핑으로 나뉘어졌다.

 

내가 맡았던 퍼소나와 다른 팀원이 맡은 퍼소나는 같은 서비스를 사더라도 사는 이유가 완전히 달랐다. 누구는 시간이 없어서 사고, 누구는 혼자서는 안 돼서 사고, 누구는 기존 방법이 막혀서 산다.

 

사는 이유가 다르면 꽂히는 문장도 다르다. 그래서 대상별로 콘셉 브리프가 따로 나와야 했다.

 

그런데 내가 맡은 건 퍼소나 때 맡았던 대상이 아니었다.

나와는 성별도 상황도 전혀 다른, 솔직히 말하면 공감이 하나도 안 되는 대상이었다.

처음 배정받고 좀 막막했다. 퍼소나 때는 인터뷰를 직접 7명 하면서 그 사람들 말투까지 머릿속에 남아 있었는데, 이번 대상은 내가 겪어본 적도 없고 주변에서 들어본 적도 거의 없는 입장이었다. 뭐가 힘든지, 뭐가 아쉬운지 상상이 안 됐다.

 

근데 생각해보니 퍼소나 때 제일 크게 틀렸던 이유가 내가 그럴듯하다고 혼자 판단한 것이었다. 완벽해 보이는 답을 먼저 정해놓고 근거를 모으러 갔다가 인터뷰에서 바로 깨졌다.공감이 안 되는 대상이면 애초에 혼자 판단할 수가 없다. 자료를 보는 수밖에 없다. 그렇게 생각하니 오히려 나은 조건일지도 모르겠다 싶었다.

 

다행히 이번엔 자료가 있었다. 퍼소나 때와 반대 상황이었다. 퍼소나 때 내가 맡은 대상은 기존 조사 30명에 한 명도 없어서 인터뷰부터 새로 해야 했는데, 이번 대상은 그 30명 안에 들어 있었다. 추가 조사 없이 기존 자료로 시작할 수 있었다.

 

그래서 퍼소나 때 썼던 방식을 그대로 가져왔다. 해당하는 응답자만 추려서 같은 질문에 뭐라고 답했는지 가로로 늘어놓았다. 혼자 읽을 때는 각자 사정으로 보이는데 나란히 놓으면 반복되는 게 보인다.

 

여기서 하나 조심한 게 있다. 공감이 안 된다고 해서 자료를 내 식으로 번역하지 않는 것이었다.

인터뷰 때 배운 것과 같은 문제였다. 사람들이 쓰는 애매한 단어를 내가 해석해버리면 그 순간 내 생각이 된다. 응답에 쓰인 표현을 그대로 두고, 그 표현이 몇 번 반복되는지를 봤다.

 

그 다음은 발상이었다. HMW는 "우리가 어떻게 하면 ~할 수 있을까"로 질문을 바꾸는 방식이다. 문제를 문제인 채로 두면 답이 안 나오는데, 질문으로 바꾸면 아이디어가 붙을 자리가 생긴다. 여기서 제일 어려웠던 건 가치와 요구를 구분하는 것이었다.

 

책에 나온 예시가 명확했다. "정비소에서 세차까지 한꺼번에 하고 싶다"는 요구지 가치가 아니다. 가치로 쓰려면 "정비와 세차를 한 곳에서 함으로써 고객에게 편리함을 준다"가 된다.

 

실행 계획도 마찬가지다. "예약 시스템과 발레 주차를 통해 빠르고 간편한 서비스를 제공한다"는 실행 계획이고, 가치로 쓰면 "효율적인 서비스를 제공함으로써 고객의 시간 관리를 돕는다"가 된다.

 

조사에서 나온 불편 사항을 그대로 옮기면 그건 요구 목록이지 콘셉트가 아니었다. 한 단계 위로 올려야 했다.

그리고 반대로 너무 올려버리면 아무 서비스에나 해당되는 말이 된다. 적당한 높이를 찾는 게 계속 어려웠다.

아이디어를 추리면서는 세 가지를 확인했다.

• 무결성. 콘셉트가 서비스의 특징을 조화롭게 설명하는가.
• 차별성. 기존 서비스와 무엇이 다르고 그걸 얼마나 부각시키는가.
• 집중성. 제공하려는 것이 사용자의 욕구에 집중되어 있는가.

차별성에서 많이 걸렸다.

기존에 있는 방법들로도 어느 정도 해결이 되는 부분이 있었는데, 그러면 "그래서 왜 우리 걸 사야 하는데"에 답이 안 됐다.

퍼소나 때 썼던 질문이 여기서도 똑같이 쓰였다. 기존 방법으로 해결되는데 그 방법을 쓸 수 없는 지점이 어디인가. 그 지점이 차별성이 될 수 있는 자리였다. 콘셉트를 쓰면서는 충실도도 신경 썼다.

 

책에서는 정의 단계에서 무리하게 자세히 쓰면 개발 단계에서 역효과가 난다고 한다. 검증 전에 프로토타입까지 만들어버리면 유용성이 떨어질 수 있으니 조금 모호하게 남기고 다음에 발전시키라는 것이다.

 

처음엔 자세할수록 좋은 줄 알았는데 아니었다. 아직 검증 안 된 걸 확정된 것처럼 써놓으면 나중에 바꾸기 어려워진다.

그래서 어떤 기능을 어떻게 만들겠다까지는 안 쓰고, 무엇을 해결해주는 서비스인가까지만 썼다.

이번에 배운 걸 정리하면 이렇다.

 

공감이 안 되는 게 꼭 불리한 건 아니었다. 오히려 자료를 볼 수밖에 없게 만들었다. 퍼소나 때는 내가 공감한다고 착각해서 틀렸다.

콘셉 브리프의 목표는 "사고 싶은가"였다. 퍼소나의 목표가 "누가 돈을 내는가"였다면 콘셉 브리프는 그 사람이 들었을 때 끌리느냐다. 기준이 있으면 쓰다가 길을 잃어도 돌아올 데가 있다.

 

요구를 그대로 옮기면 콘셉트가 안 된다. 불편 사항 목록과 가치는 다른 층위의 말이었다.

산출물을 만들 때 그 산출물의 목표가 뭔지부터 보는 습관이 이번에도 똑같이 쓰였다.

 

세 번째 과제든 네 번째 과제든 결국 같은 방식이었다.