세상에 변화를 가져올 무언가를 만들고자 한다면, 그 고객을 이해하는 것에서 출발 해야 한다. 그래서 우리는 고객과 대화 한다. 여기서 고객에게 무엇을 물어야 할까? 구체적인 서비스나 제품이 출시되기 전에는 고객의 니즈를 어떻게 탐구할 수 있을까? 고객의 진정한 니즈를 파악하려면 어떤 접근법이 필요할까?
고객 스스로 니즈가 명확히 정리되어 있는 경우는 드물다. 고객의 니즈를 그대로 받아들이기보다는, 이를 해석하고 구체화하는 작업이 필요하다. 표현되지 못한 니즈를 발견하고, 그것을 현실적인 솔루션으로 연결하는 과정은 창의적인 과정이다. 특히 흔히 하는 실수는 솔루션을 이야기하는 것이다. 그러나 니즈에서 출발하는 사고가 진정한 고객 중심 사고임을 이 책은 강조한다.
책을 읽고 함께 이야기를 나누는 과정에서 “이런 게 있으면 어떨 것 같아요/ 사용하실 것 같아요?” 같은 질문에 대해 이야기를 나눴다. 질문자가 상상하고 있는 "이런 것"과 답변자가 상상하는 것의 "이런 것"은 크게 다를 수 있다. 무의미한 대화를 하게 될 수 있다. 그 대신 사람과 환경, 목적, 그리고 그들이 겪는 문제를 이해하는 질문을 던져야 한다. 이런 지점은 단순하면서도 깊이 있는 교훈이었다.
리서치를 정리할 때에는 사실과 의견을 구분하고, 관찰과 해석도 구분해야 한다. 사용자가 겪고 있는 문제나 그들이 행하는 행동을 관찰하는 것과, 이를 바탕으로 해석을 덧붙이는 것은 분명히 다르다. 관찰은 객관적 토대가 되고, 해석은 이를 기반으로 사용자 니즈를 파악하기 위한 행위다. 이 두가지를 혼동할 경우 방향은 쉽게 흐려질 수 있다.
리서치 방법론 보다는, 그 기저에 어떻게 질문해야 하는지, 그것을 어떻게 이해하고 전달해야 하는 지에 대한 생각들을 해봤다.
인상깊었던 부분
1장 준비하기
- 사람들은 자신의 정신 작용에 대해 신뢰할 만한 인사이트를 가지고 있지 않기 때문에 그들에게 무엇을 원하는지 묻는 것은 무의미하다. 사람들에게 무엇을 좋아하거나, 싫어하는지 물어보거나, 앞으로 무엇을 할 거라고 생각하는 지 등을 말해달라고 요청하는 것은 아무 소용이 없다
- UX 연구는 종종 팀에서 한 사람에게 할당된다. 그 사람은 사용자 니즈의 대변인이 되며, 사용자에 관해서 팀의 "전문가" 역할을 맡게 된다. 이러한 접근법은 리서치 진행에 좋지 않은 방법이다. UX 연구 원이 모든 답을 알지 못하기 때문만은 아니다. 실패하는 이유는 개발 팀이 사용자 이해에 대한 모든 책임을 한 사람에게 위임하도록 장려 하기 때문이다. 이러한 죄악을 프로젝트에서 방지할 수 있는 한 가지 방법은 모든 팀원이 "노출 시간"을 갖도록 장려하는 것이다. 연구에 따르면 가장 효과적인 개발팀은 6주마다 최소 2시간을 사용자 관찰에 보낸다고 한다. (예: 현장 방문이나 사용성 테스트).
- 퍼소나를 꼭 사용자 중심 으로 만들 필요는 없다. 사용자 중심 디자인은 퍼소나에 관한 것이 아니 다. 사실, 퍼소나는 크게 중요치 않다. 퍼소나를 창조하는 것이 목표가 돼서는 안 된다. 사용자의 니즈, 목표, 동기를 이해하는 것을 목표로 해야 한다.
- 미국 운전자의 93%는 자신 이 평균보다 뛰어난 운전자라고 말하며 88%는 평균 이상으로 안전한 운전자라고 말한다. 오늘날 거의 모든 회사가 사용자 경험에 대해 말만 앞세우고 있지 만, 그들 중 다수는 동떨어져 있는 것이 사실이다.
- 대략 8%에 해당한 가장 성숙한 회사는 다른 첨근법을 취한다. 이 회사들은 비판을 요구한다. 개인적인 진술을 요구하는 것이 아니라, 경험을 관찰함으로써 이것을 달성한다.
2장. 사용자 경험 리서치 계획 세우기
- "문제 해결에 20일이 주어진다면 문제 정의에 19일을 쓰곘네"
- "추축은 좋지만, 찾아내는 것이 더 좋다."
- 솔루션에서 벗어나기 위해 아래와 같은 질문들 던져봐라
- X 가 어떤 이슈를 해결하길 원하나요? 없다면 어떤 어려움을 겪게 되나요?
- 상상할 수 있는 최고의 X를 설계한다면 어떤 문제가 해결될까요?
- 이해관계자의 약점을 공격하지 마라. 그들의 허를 찌르지 마라. 목적은 정보를 얻는 것이지 그들이 일을 허술하게 해왔다는 것을 폭로하는 것이 아니다.
- 디지털 기술 수준이 높고 낮음을 구별하고 싶다면, 직접적으로 물어보지 말고. 올나인에서 무엇을 하는지, 누군가의 도움을 받는지 등을 물어봐라.
- 인구 통계가 아닌 행동에 기초해 모집해라. 인구통계별로 어떠하다는 가정은 틀릴 수 있다. 추가적으로 각 인구통계에 대한 대표성을 얻으려면 모집단이 커진다. 이는 오히려 각 인구통계의 대표성을 갖지 못할 수 있다.
- 5명의 참가자로 사용자의 30%에게 영항을 미치는 문제를 찾아낼 확률은 85%이다.
- 오히려 반복해서 리서치해라. 리서치의 목표는 대표 표본을 전달하는 게 아니라 리서치를 전달하는 것이다.
- 사용자 문제를 발견할 확률을 높히려면
- 표본에 오히려 문제가 될 사람을 포함하거나
- 단일 참가자에게 더 많은 태스크를 요청하거나
- 관찰자를 늘려라. (관찰하는 사람이 놓칠 확률도 꽤나 크다)
- 써보라고 하는것이 아니라 특정 테스크를 요청해야 한다.
3장. 사용자 경험 리서치 수행하기
- 사용자가 달성하고자 하는 목표는 무엇인가? 현재 어떻게 하고 있고, 어려움이나 좋아하는 부분은 무엇인가? 임시로 해결방안은 무엇을 사용하는가?
- 사용성 테스크에 있어서는, 보물찾기 테스크(해외여행에 가는데 가방을 찾아봐라) 등의 테스크를 주어야 한다.
- "내가 여기 없었다면 했을 행동을 하세요" 라는 식의 말을 하면서, 리서치 과정에서 참가자에 질문에 대답하는 함정에 맹목적으로 빠지지 않아야 한다.
4장. 사용자 경험 리서치 분석하기
- 대부분의 아이디어는 실패하게 되는데, 게다가 회사 임직원이 이미 실패의 이유를 대체로 알고 있다. 마케팅,타겟그룹, 포지셔닝 등이 잘못되었다 부터 캠페인의 인지도, 가격전략 등 다양한 요소들이 존재한다. 과정에서 "집단적 믿음"이 작용하기 때문이다.
- 사실과 증거를 요구하고, 이에 개인적인 의견이나 선호 보다는 증거를 가지고 논의해야한다. 권위자도 틀릴 수 있으며, 여러 대안적 아이디어를 발전시켜야한다. 열린 마음으로 임하며, 이러한 대안들에 대해 수치로 표현하며 의논해야 한다. 증거와 의견은 다르다.
- 솔루션을 도출하는 과정에서 "오컴의 면도날"을 기억하라. 2가지 가설을 마주한다면 더 단순한 것을 골라라. 그리고 이 가설을 테스트하기 위한 실험을 실시해라.
- 리서치보고서는 "왜 당신의 주장을 믿어야 하는가? 이 증거는 얼마나 타당하며 신뢰할 수 있는가?" 로부터 시작되라.
- 퍼소나를 생성할 때에는 사실, 행동, 니즈를 나누어서 사고해보라. 그리고 여기에 본인의 세련된 관점을 과도하게 넣지 않아야 한다.
- 사용성 문제의 우선순위 - 완료율에 치명적인가? 많은 사람들이 영향을 받는가? 문제의 빈도가 높은가? 로 나누어 사고할 수 있다.
- 사용성 테스트는 사용성을 향상할 수 없다. - 근본적인 문제에 대해서 생각해해봐야 한다.
- 리서치는 삼각 측량할 때 가장 효과적이다. 정량 데이터는 사람이 무엇을 하는지 알려준다. 정성 데이터는 사람들이 왜 하는지 말해준다.
5장. 사용자 경험 리서치 결과에 대한 조치를 취하도록 사람들을 설득하기
- 사용성과 사용자경험의 차이를 설명하면 사용자 여정 지도를 소개하라. 사용자 여정 지도는 사용자가 성취하고자 하는 것이 웹/앱/서비스 보다 더 훨씬 크다는 점을 분명히한다.
- 디자인 아이디어는, 무언가 대체하거나, 결합하거나, 수정,확대,최소화 하거나 용도를 바꾸거나 제거하거나, 재배치하는 것을 고려해보면 좋다.
6장. 사용자 경험 분야에서 경력 찾기
- 사용자 경험 실무자에게는, 니즈 리서치, 사용성 평가, 인포메이션 아키텍쳐, 인터렉션/시각 디자인, 기술문서 작성, 프로토타이핑 등의 역량이 필요하다.
- 단순 실무적 역량 뿐만아니라, 프로젝트 관리(프로세스 관점) 나아가 세일즈(리서치는 결국 제안서) 역량이 필요하다.
- 팀이 사용자를 이해할 수 있도록 도아라. 팀이 사용자의 태스크를 이해하도록 도와라. 이에 사용성 테스트 실행은 조직을 참여를 독려하는 관점에서 실용적이다.