함부로 넘겨짚지 않기
Observation과 Problem Statement
사용자와의 인터뷰가 끝난 후, 디자이너는 필연적으로 어떤 걸 먼저 개선해야 할지 고민에 빠지게 마련입니다. 사실 디자이너 입장에서는 모두 다! 요리조리 씹고.. 뜯고.. 맛보고.. 즐겨서 개선하고 싶지만 시간과 리소스는 한정돼 있는 걸요. 필연적으로 선택해야만 합니다. 이때, 명확한 Define을 위해 사용할 수 있는 ✨아주 멋진 방법✨이 있어 소개해보고자 합니다.
고양이는 세상을 구함니다 암튼 맞음Observation & Problem Statement
바로 정리해 둔 유저 인터뷰를 바탕으로 도출한 Observation과 Problem Statement입니다! Defining 과정에서 다양한 방법을 사용할 수 있겠지만, 이 방법을 활용해서 더 뾰족하게 문제를 정의할 수 있습니다.
우선 간단히 개념을 알아볼까요? 한 줄로 정리하면 아래와 같습니다.
* Observation: 사용자가 문제를 겪는 상황 관찰
* Problem Statement: 그 문제에 대한 순수한 정의(가설, 비약, 추론 X)
예제로 이해하기
윗 문장 그대로 사용자가 문제를 겪는 상황을 관찰하고, 문제 또는 상황에 대해 순수하게 정의하는 것이 바로 이 방법의 핵심입니다. 하지만 이렇게만 보면 정말 어쩔티비 아니겠어요?
백문이불여일견, 이해를 돕기 위해 지금부터 이커머스 서비스 D에서 일하고 있는 PD에 빙의해 봅시다. IT 카테고리를 개선하고자 하고 있는 우리는 사용자 A 씨와 인터뷰를 진행했습니다.
"요즘 재택근무가 가능해져서 집에 사무환경을 좀 구축하고 싶었어요. 근데 또 제가 완전 컴맹이고.. 주변에 컴퓨터를 잘 아는 사람도 없어서 막막했는데 다들 D를 추천하길래 사용해보게 됐어요. 확실히 신세계던데요. 원래 이런 IT 제품들 사양이나.. 뭐 그런 것들을 보면 검은 건 글씨고 하얀 건 백지인데 너무 이해하기 쉬웠어요. 일단 제품 구매 온보딩 과정이 획기적이었어요. 다짜고짜 상품들을 나열하는 게 아니라, 용도/직무/금액대/공간/설명 난이도 등 정말 자세하게 정해서 비교해볼 수 있더라고요. 일단 그렇게 정해서 다음 스텝으로 넘어가면 4개 정도의 제품을 동시에 비교해볼 수 있는데, 제 눈높이에 맞춰서 비교해주니 너무 수월했어요. 아, 근데 그 비교창에서 바로 상품을 장바구니에 담고 싶어서 장바구니 버튼을 찾았는데 진짜 한참 걸렸어요. 너무 찾기가 어렵더라고요. 맞다! 키보드랑 마우스도 그런 식으로 해서 동시에 구매하고 싶었는데.. 기타 주변기기도 구매과정에 포함돼 있었으면 더 좋았을 것 같아요."
위 인터뷰에서 어떤 Observation을 찾아낼 수 있을까요?
사용자 A는 비교창에서 장바구니 버튼을 찾기 힘들다.
사용자 A는 컴퓨터뿐만 아니라 기타 주변기기도 한 번에 구매하고 싶다.
인터뷰다 보니 이런저런 사족이 붙지만, 사용자가 겪은 문제의 핵심은 이 두 가지로 관찰할 수 있겠습니다. 이렇게 Observation을 찾았다면 Problem Statement도 도출해낼 수 있겠죠?
D 서비스 비교창의 장바구니 버튼 어포던스가 낮다.
D 서비스는 구매과정에서 컴퓨터 외 기타 주변기기를 함께 구매할 수 없다.
이렇게 가설/비약/추론 없이 정리된 Problem Statement는 사용자가 어떤 문제를 왜 겪고 있는지, 어떤 부분에서 허들이 생기는지를 4k로 선명하게 볼 수 있도록 도와줍니다. 뉴트럴 하게 정의됐기 때문에 편향 없이 무수한 갈래의 가설이 생길 수 있는 여지도 있고요.
이렇게 정의하면 안 돼요
반면 이 Problem Statement에 내 뇌피셜을 한가득 담아버리면 어떤 일이 벌어질까요? 한 번 살펴볼까요?
위에서 나온 두 번째 Observation(사용자 A는 컴퓨터뿐만 아니라 기타 주변기기도 한 번에 구매하고 싶다)에 졘피셜을 담아 Problem Statement를 재정의 해 보겠습니다.
컴퓨터 외 기타 주변기기를 함께 구매하고자 하는 사용자 A는 완벽주의자적 성향이 있다.
비교를 위해 다소 극단적으로 정의했지만.. 효과는 확실한 것 같네요. 위에서 뉴트럴 하게 정의했던 Problem Statement와 비교하면 이미 안에 가설이 있다는 게 확연히 드러나죠?
이걸 쓴 사람의 머릿속에는 이미 "사용자 A는 완벽주의자적 성향이 있기 때문에 컴퓨터 구매 시 모든 것을 한 번에 완벽하게 세팅해서 구매하고 싶을 것이다"라는 가설이 담겨 있습니다. 이렇게 뉴트럴 하지 않은 statement로 Define 하게 되면 내재된 가설에 매몰되거나 편향되기 십상일뿐더러, 뉴트럴 한 상태에서 나올 수 있는 무수한 갈래의 가설을 원천 봉쇄하는 작용을 하기도 합니다.
막상 실제 인터뷰를 진행하고 Define 하는 과정에서 이 작업을 진행해 보면 가설/비약/추론을 담지 않고 담백하게 Statement만 적는 게 생각보다 어렵다는 걸 깨닫게 됩니다. 우리 뇌는 너무 고기능(?)이라, 자꾸만 모든 것을 직관적으로 연결 짓고자 하기 때문이죠!
그 후
이렇게 Observation과 Problem Statement를 진행한 후에는, 개선 우선순위를 논의하기 위해 각각의 항목들을 (예컨대) 유저 니즈가 많은 순 / 디자이너가 중요하다고 생각하는 순 / 빠른 개선 및 도입이 필요한 순("이것"으로 인해 크리티컬 한 허들이 생기는 것)과 같이 카테고리화 하여 나눠볼 수 있습니다. 이렇게 필요에 따라 카테고리를 나누고, Observation과 Problem Statement를 재분류하면 다양한 필요와 상황에 따른 우선순위를 선정하는 작업이 훨-씬 수월해진답니다!
TIP 실제 인터뷰에서는 공통된 의견을 내는 사람들이 여러 명일 겁니다! 그 사람들의 숫자를 카운트하여 Observation 시 함께 체크해 두면, 나중에 유저 니즈별 우선순위를 정하는 데 도움이 돼요.
사족
이쯤되면 생각나는 갓-곡, 장기하와 얼굴들: 그건 니 생각이고Problem Statement를 Define 해 나가는 과정은 사람을 대할 때 취해야 할 태도와도 닿아있는 것 같아요.
함부로 넘겨짚지 않고, 감히 단언하지 않고, 내 생각 강요하지 않기.
