시간을 되돌리면 무엇을 바꾸었을 것 같은지, 그래서 무엇이 lesson이었는지 define하기 1. Key question의 오류. <3~5년 뒤 미래의 라이프스타일에 적합한 모바일 기기의 진화 방향은 무엇인가?>...? 위 문제를 풀면 (1) 3~5년 뒤 미래의 라이프스타일의 정의, (2) 그것을 support 하는 기기 진화 방향 제안. 이다. 목표는 1)과 2)를 논리적으로 연결하는 것이었는데, 최종 보고서에 1)은 못 넣고, 2)만 넣었다. 우리의 역량과 일정으로 볼 때 1)은 무리였던 것 같다.
 모바일 프로젝트 In-depth Interview protocol Frame 다시 보니 이 프레임 정말 완벽하다. 모든 행태를 다 볼 수 있다. 그런데 왜 스르륵 기억에서 사라지고 말았을까? 보고서 쓸 때도 이 프레임을 다시 보지 않았다. 왜냐하면 이 프레임은 인터뷰 프로토콜의 질문들을 구조적으로 생각해본 프레임이기 때문이다. Lesson: 보고서의 스토리를 프로젝트 초반에 잡아야 한다. 어렵지만 해야 한다. 스토리 잡는 법 정리 中 (정리해보려 했는데 잘 안 되네요.ㅠㅠ) 스토리는 '결'은 Answer '전'은 Answer 의 근거가 되는 Insight를 주장. '승'은 Insight가 뽑아지는 a,b,c,d... 영역에서 중요한 내용을 전달. '기'는 Key question을 Redefine해서 답을 내리기 위해 알아봐야 하는 a,b,c,d... 영역과 그것이 종합되는 Frame을 제시 결국.. 1) Key question > Redefine > 여러 개의 하위 질문 만들기 (미래의 경험은? /현재의 경험은? / 미래의 기술은? / 과거-현재의 기술진화는? / 인간경험과 기술의 상관관계는? 등) 2) 하위 질문들의 Frame 만들기 (미래의 경험(=현재 needs의 충족) + 미래의 기술(=현재 개발중인 기술의 완성단계) = 미래의 디바이스) 3) Frame 빈칸들을 채우기 위한 리서치 방법론 개발 (현재 needs를 알아내기 위한 사용자 인터뷰 / 미래의 기술을 예측하기 위한 전문가 인터뷰) 4) Frame에서 나올 Insight 예시를 생각해보고, 그것이 Key question의 근거로 적절한지 점검해봄. 이를 위해 지루하고 힘든 토론이 필요함. 박지호 1. 클라이언트와의 커뮤니케이션 오류 Kick-off부터 그들이 원하는 것이 무엇인지, 우리가 하려는 것이 무엇인지에 대한 커뮤니케이션이 되지 않았다. 그 이후에 Insight, Direction 등의 용어에 대한 level, definition 차이가 굉장히 달랐으며, 같이 define해가며 할 필요가 있었다. 이런 definition 차이 때문에 methodology와 problem solving에 접근 방식이 틀어졌다. 인터뷰 프로토콜부터 잘못 짜였다고 볼 수 있다. 클라이언트와의 커뮤니케이션 방식 차이를 인정하고 그들을 이해하려고 해야 한다. 킥오프가 가장 중요하고 그 중간에 커뮤니케이션을 지속적으로 해야 한다. 2. Desk Research의 부재 모바일이나 UI/UX에 대한 데스크 리서치가 없었기 때문에 나중에 insight와 direction을 따는데 한계가 있었다. 특히 나중에는 클라이언트의 요구가 UI/UX에 치중되었다는 것을 알았을 때 그에 대한 direction을 내는 것이 무척 어려웠다. 3. 클라이언트 측에 보내는 자료에 대한 professionalism 스크립트나 번역 작업이 내부용도라면 알바를 써도 괜찮지만, 클라이언트에게 보내는 것이라면 좀 더 전문적인 인력을 써야 한다. 전문적인 인력을 쓰는 것이 관리하기도 쉽고, 퀄리티도 보장이 된다. 랜덤한 알바를 쓰면 더 에너지 소비가 많다. 4. 보내는 자료에 대한 계약 조건 어떤 자료를 프로젝트 중간에 넘기고 안넘기고를 확실하게 해야 할 것 같다. |