UX 리서처는 어떻게 문제를 해결할까?
UX 리서처가 연구 또는 문제를 해결하는 프로세스
UX연구 또는 디자인, 기획 시 활용가능한 다양한 프로세스들이 존재합니다. 그리고 이 프로세스들은 프로젝트의 성격과 상황에 따라 융통성있게 사용할 필요가 있습니다. 하지만 어떤 프로젝트던지 변수와 문제가 발생하기 마련입니다. 예산문제, 인력문제, 조직의 목표 변경 등.. 제 경험상 이런 상황에서 진짜 고수들은 - '문제를 해결하려고 하는 사람'은 상황에 휩쓸리지 않고 자신의 논리를 꾸준하게 유지했던 것 같습니다. 과연 어떻게 그럴 수 있었을까요? 제가 내린 답은 '그들만의 논리 체계(Logic system)를 가지고 있기 때문아닐까' 입니다.
나만의 논리 과정을 통해 오류 가능성을 줄이는 것
결과만 보면 아름답지만 그 과정은 얼마나 치열했을까..아름다운 프로젝트는 없다
모든 프로젝트의 진행 과정은 아름다울 수 없습니다. 위에서 언급했듯이 작은 사건, 사고가 없는 프로젝트는 없으니까요. 우리가 보는 케이스 스터디와 논문 등은 모든 과정들을 잘 정제된 단어를 통해서 정리한 '결과물'입니다. 즉, '과정의 치열함'까지는 볼 수가 없는 것이죠. 저는 당연히 지금도 프로젝트가 잘 풀리지 않으면 스트레스를 받고, 걱정을 합니다. 하지만 서두에서 언급했듯이 '흔들림 없는 그들'에서 배운 모습을 내 것으로 만들려는 시도를 했습니다. 바로 저만의 논리 구조 / 프로세스를 만드는 것입니다.
당연 이 논리 구조 역시 완벽할 수 없고, 상황에 맞게 변경되기는 하지만 제 개인적인 경험과 여러 연구 프로세스를 결합하여 만들었습니다. 굉장히 뻔한 프로세스처럼 보일 수 있습니다만..(사실 팩트) 여러분 각자만의 흔들리지 않는 논리 구조를 만드는 것을 도울 수 있지 않을까하는 마음에 공유합니다. 저는 논문을 쓸때나 팀 단위 프로젝트를 할 때 등등.. 아래에서 작성할 로직 내지는 프로세스를 늘 염두에 두고 진행을 합니다.
나만의 문제해결 Logic
1. 문제점 발견
문제점을 발견하게 되거나, 팀 목표를 위해 해결해야하는 현상을 디테일하게 연구해봐야 할 때를 일컫습니다. 중요한 것은 이게 진짜 문제점일까? 니즈가 존재할까? 등을 잘 확인해 볼 필요가 있습니다. 비바리퍼블리카 팀이 창업한 8번째 아이디어까지 빛을 보지 못하고 서비스를 종료했을 때 창업멤버들은 서울 각지로 떠나 진짜 고객들이 원하는 것을 찾기 시작했다는 이야기는 이미 유명하죠. [출처 : 연합인포맥스 / '데카콘' 꿈꾸는 창업자에 전한 이승건 토스 대표의 성공전략…'생즉사 사즉생']
이처럼 우리가 해결하려는 문제가 단순 현상인지, 아니면 극복 가능한 문제인지를 구별하는 것이 중요합니다.
2. RQ(Research Question) 수립
명확한 목적이 있는 리서치를 위해 연구 질문을 문장으로 만들어봅니다. 예컨대 '어떻게 하면 기존 사용자들이 OO 기능도 사용하게 만들까?' 따위가 될 것 같습니다. 물론 더 디테일할수록 좋습니다. 여기서는 모호한 표현을 삼가고, RQ 문장의 논리 검토, 현재 예산 / 인력 내에서 진행 가능한 프로젝트인지 등을 면밀히 검토할 필요가 있습니다.
의학 연구에 자주사용된 RQ 작성 프레임워크* 3. 직접 눈으로 관찰
많은 연구자들 / 실무자들이 놓치는 부분입니다. 대부분이 케이스 스터디에 매몰되거나 임의의로 짐작하여 문제를 해결하려고 합니다. 그러나 사용자 경험 문제를 해결하기 위해서는 직접 '눈'으로 확인하고 경험하는 것이 중요합니다. 이를 위해서 흔히 쓰이는 연구는 WoZ / 유저 스토리 맵 작성 / 인터뷰 등 있겠네요.
개인적으로는 정말 여러번 강조하고 싶은 부분입니다. 지레짐작하지 마시고, 직접 확인하는 걸 추천합니다.
Wizard of OZ 방법론4. 인사이트 도출 / 가설수립
위에서 도출한 문제점, 인사이트들을 정리해야합니다. 중요한 점은 '사용자'의 말이나 행동을 '해석'해야한다는 점입니다. 이를 통해 단순한 현상을 극복 가능한 문제로 치환시킬 수 있고 떠다니는 정보를 인사이트로 바꿀 수 있을 것입니다. 그리고 이러한 인사이트를 토대로 가설을 수립합니다. 가설 수립은 여러가지 포인트가 있지만 반드시 연구를 통해 확인 가능한 표현을 써야한다는 점입니다.
예를 들어 "고객의 출,입이 많은 입구 쪽에 정수기를 두면 고객들이 행복할꺼야"가 아니라 "정수기를 두면 고객의 재입장이 늘어날꺼야"와 같은 구체적 표현으로 변환해야합니다. 이를 조작적 정의라고 합니다.
5. 권위자(책, 논문) + 동료 연구원의 의견, 피드백
여러 의견을 수립하고, 피드백을 반드시 받아야 합니다. 이를 통해 오류를 줄이고, 쓸모 없는 리소스 낭비를 줄일 수 있습니다. 논문을 참고하거나 책을 읽거나, 케이스 스터디를 하거나 여러가지 좋은 방법이 있을 것 같습니다.
거인의 어깨에 올라서서 더 넓은 세상을 바라보라6. 실험설계
실험을 설계하고 진행할 때 반드시 파일럿 테스트(모의실험)을 해야 합니다. 이는 위와 같이 오류를 잡기 위함입니다. 요즘 흔히 하는 프리토타이핑 역시 팀원 / 직장동료들을 대상으로 사전 테스트를 하고 실험을 진행하는 것이 좋습니다.
7. 실험진행 (연구윤리와 피험자 학습)
실험은 참 변수가 많고, 어렵습니다. 또한 저도 한참 부족한 수준이고 다른 중요한 게 너무 많지만, 가장 강조하고 싶은 내용을 하나만 꼽자면 - 사람은 '학습을 하는 동물'이라는 부분입니다. 즉, 한 번 실험을 진행한 사람은 이미 조금의 학습을 한 상황이므로 재실험 또는 다른 실험에 투입시키지 말아야 합니다. 이 점을 잘 고려한다면 A/B 테스트, 사용성 테스트 등에서 피실험자들에게 효과적인 결과물을 얻어낼 수 있을 것입니다.
8. 실험 데이터 확인 - 가설 검증
이제 실험 결과를 확인하면서 데이터를 검증하고 내가 세운 가설이 얼마나 타당한가를 확인하는 단계입니다. 이 지점에서 중요한 점은 데이터를 여러 각도로 바라본다면 생각치도 못한 훌륭한 인사이트가 도출될 수 있다는 것입니다. 정보를 나열하고 정리하지마시고, 다양한 생각을 첨부해보세요.
저희는 단순히 정보를 정리하는 사람이 아닌, 문제를 해결하려고
노력하는 사람이니까요.
9. 글로 정리
마지막으로 가장 고통스러운 과정이 남았습니다. 바로 글로 정리하는 것입니다. 누군가에게 공유해도 좋고, 공유하지 않아도 좋습니다. 진행했던 과정들을 한 번 정리를 해보며 본인만의 논리를 만들어 보시거나 포트폴리오를 만들어보시는 걸 추천합니다. 물론, 저도 가장 귀찮은 과정이라고 생각하지만 - 글을 쓰는 것만큼 효과적인 정리가 없다고 '감히' 생각합니다.
지금까지 간단히 제 프로세스 / 논리 구조를 정리해봤는데 평소 여러분은 어떻게 프로젝트를 진행하시는지 또는 본인만의 어떤 논리구조를 가지고 계신지 궁금합니다. 참고로 여기 [주인장의 인사이트 블로그]에는 UX 관련 이외에도 제가 생각하는 다양한 생각을 올려 볼 예정입니다. 재미있게 봐주시면 감사하겠습니다.
다시 한 번 감사합니다.
