문제 정의와 문제 해결에 대한 단상

"사실 고객의 문제가 무엇인지 알고 있다면, 그 문제를 해결하는 것은 쉬운 일이다."

— 실전 웹사이트 분석 A to Z (Web Analytics : An Hour a Day) - p. 57

제품을 개발하는데 있어 ‘문제 정의’의 중요성을 강조하는 시각이 많다. 위 인용 문구도 그것을 강조한 것이며, 린 스타트업 방법론에서도 전체 과정 중 가장 중요한 것으로 ‘문제 정의’를 꼽고 있다. (스타트업의 가장 큰 위험은 ‘아무도 원하지 않는 제품’을 만드는 것이다 - 라는 문장으로 대표되는)

문제 정의의 중요성을 강조하는 글이나 발표에서는 우리에게 항상 이런 주문을 한다.

당신에게 주어진 문제를 그대로 받아들이지 말고, 문제를 새로운 관점에서 바라보고 ‘진짜 문제’를 찾아라!

그리고 이를 증명하기 위해 수많은 성공 사례들을 나열한다.

OOO한 문제가 있어서 의뢰가 들어왔는데, 우리는 리서치 결과 XXX하다는 것을 발견하였고, 진정한 문제가 ***라는 것을 깨달았습니다. 그래서 우리는 ###를 하였고, 그 결과 @@성과가 00% 상승하였습니다!

이건 정말 명확해보이고, 우리는 발표가 끝난 후, 그동안 제대로 성과를 내지 못한 자신을 원망하게 된다. 그런데, 뭔가 이상하다.

이 세상엔 똑똑한 사람들이 많고, 이들은 진정한 문제 해결을 위해 문제를 다른 관점에서 해석해야한다는 사실을 알고 있고, 또 그렇게 하려고 노력한다. 그런데 왜 진짜 문제를 해결하고 큰 수확을 거두는 경우는 여전히 많지 않은 걸까? (그리고 왜 난 문제 정의부터 다시 하는데도 성과를 거두지 못하는 걸까?)

성공적인 문제 해결책은 괜찮은 문제 정의에 기초하는 것은 맞지만, 모든 기막힌 문제 정의가 성공적인 해결책을 보장하는 것은 아니다. 그럼 그 사이엔 어떤 것이 있는걸까?

그래서 성공 사례의 주인공을 향해 이런 질문을 해본다.

"그 새롭고 창의적인 문제 정의가 옳다는 것을 언제 확신하게 되었습니까?"

과연 그 시점이 ‘리서치 결과를 보았을 때’ 였을까? 요즘엔 문제 정의를 위한 기반 리서치도 엄청 많이 하지만, 탄탄하고 방대한 리서치 역시 성공을 보장하진 못한다. 문제 정의가 옳다는 것을 증명할 수 있는 때는 ‘해결책이 성공을 거두었을 때’ 뿐이라는 것이 나의 생각이다.

이것은 다시 말해, ‘문제 정의’와 ‘해결’을 명확히 나눌 수 없다는 것을 뜻한다.

해결책을 만들어보는 과정 자체가 ‘문제 정의가 옳았는지 검증하는 과정’이며, 따라서 ‘문제 정의는 끝났고 해결책에 집중하자’라는 말은 무척 위험하다.

'문제 정의'에 대한 강조는 자칫, '뭔가 일단 만들어보는 것'의 가치를 필요 이상으로 평가절하하는 결과를 불러올 수 있다. 앞으로 나아가지 못하고 지루한 말꼬투리 잡기에 머무르게 될 수도 있다.

'뭔가 일단 만들어보는 것'의 가치는 특히 디지털 서비스 제작 영역에서 더욱 크다. 다른 분야에 비해 '해결책을 만들어보는' 가격을 극적으로 낮출 수 있는 방법이 많기 때문이다. 컴퓨터가 할 일을 사람이 한동안 직접 해본다든가, 아직 구현되지 않은 기능이지만 마치 되는 것 처럼 데모 비디오를 만들어본다는가 하는 것들이 바로 그것이다.

작게나마 문제 정의를 해보았다면 일단 뭔가를 만들어보는 실행력과 용기를 가져보자. 유관 부서를 죄다 모아놓은 회의에서 쏟아지는 질문 공세 속에서도 내 논리를 무사히 방어한다고 문제 정의에 대한 검증이 끝나는 것은 아니다.

Tags: essay 문제

큰 회사에서 하는 일

1.
프로세스 정립 프로세스를 수립하기 위한 위원회를 구성하고자 전체 담당자 회의를 가지고자 하오니 가능하신 시간과 아젠다를 적어 본 메일에 회신주시기 바랍니다

2.
본 건에 대한 상세 내용을 수합하고자 수합 담당자를 수합하고자 하오니 이를 진행할 담당자를 지정하는 협조전을 작성하여 보내주시기 바랍니다

예상치 못한 문제

예상치 못한 문제를 발견하는 방법
-> 예상하는대로 실행하고 문제가 발생할 때 까지 진행한다.

분명히 ‘해봐야 발견하는 문제’가 많은데
문제가 발견되면 ‘왜 예상하지 못했나’를 따지고 들게 된다.

Data-driven에 대한 단상

요즘은 데이터 드리븐이 어디서나 화제다.
A/B테스트, MAB, 코호트 분석, 퍼널 분석, 세그멘테이션, 전환율, 이탈율…

숫자를 보는 건 중요하다. 무척 중요하다.
하지만 숫자만 보는 건 무척 위험하다.

모든 결정을 철저히 숫자의 ‘크기’에 따라 내리다보면, 누구도 선뜻 ‘직관’을 내세우기 어려운 분위기가 조성된다. 그리고 타인의 직관에 대해 기계적으로 숫자에 기반한 근거를 요구하게 된다.

기계적이라는 것은, 어떤 의견을 들었을 때 그 의견이 ‘좋은가 아닌가’가 아닌 ‘근거의 유무’에 집중한다는 뜻이다. 근거가 있는 그저 그런 의견이 근거는 부족하지만 멋진 아이디어보다 높이 평가받게 되는 것이다.

이러한 상황은 숫자가 주는 명확성과 안도감에 매몰되면서 발생한다.  아주 중요한 사실 하나를 잊게 되는 것이다. 숫자는 어쨌든 ‘결과’이고, 숫자를 읽는 것 그 자체는 ‘생산’이 아니라는 것.

이런 상황에 빠진 조직의 목표는 변질된다. ‘멋진 것을 만들어내는 것’에서 ‘높은 숫자를 얻어내는 것’으로.

궁극적으로는 중요한 것은 숫자를 읽어내는 것 자체가 아니라, 숫자를 통해 알아낸 새로운 사실을 바탕으로 무언가를 만들어내는 것이다. 그걸 만들어내는 순간엔 반짝이는 직관이 필요하다. 그건 숫자가 아닌 사람에게서 나온다.

'높은 숫자를 얻어내는 것'이 목표인 조직의 문제는, 이 조직이 더 이상 즐겁거나 흥분되지 않는다는 것이다. 멋진 걸 만드는데 온 신경을 집중하는 사람들은 더 즐거운 곳을 향해 떠나고, 조직 안에는 숫자 높낮이 비교와 숫자 해석에 대한 끝없는 회의만 남게 될 것이다.

A/B테스트에서 가장 중요한 것은 A와 B중 무엇이 더 높은 숫자를 기록하는가가 아니라, 무엇하나 선뜻 선택하기 어려울 정도로 멋진 A/B안을 만드는 것이다.

디자인 어워드 수상에 관한 기사를 볼 때마다 드는 한 가지 의문.

'왜 진짜 세상을 바꾸고 사람들이 살아가는 방식에 영향을 준 것들은 수상자 리스트에서 볼 수 없는걸까?'

UX책 좀 추천해줘

참 미천한 경력이지만, ‘UX’라는 단어가 들어간 팀에서 일하다보니 종종 ‘UX책 좀 추천해줘’라는 부탁을 받는다. 듣자마자 머리가 좀 깜깜해지는 부탁이다.

일단 나도 UX가 당췌 뭔지 별로 확신이 없는 것이 첫 번째 문제. 더 큰 문제는, UX라는 말이 붙은 (혹은 연관된) 책들 중 상당수가 대책없이 지루하다는 것이다.

그래서 저런 질문을 받으면 난 반사적으로 이런 저런 질문을 던진다.

"왜요?"

리스트를 팍 던지면 대여섯권 한 번에 산 후, 가장 제너럴한 제목을 가진 책을 100페이지 이하 읽고 나머지 읽기도 포기할 것 같아서이다. (내가 그랬다) 그래서 나름, 상황에 맞게 적절한 책을 던져보려고 노력한다. (결국 늘 실패하지만) 생각 정리도 할 겸, 나름의 기준에 따른 책을 정리해본다.

상황 1. 느긋하게 UX 디자인의 전체 과정을 훑어보고 싶다.
그렇다면 : UX 디자인 프로젝트 가이드

  • 장점 : 소위 ‘UX’한다는 것에 대한 가장 일반적인 프로세스 전체를 교과서적으로 정리
  • 단점 : ‘교과서적’이라는 것에 주목. 1. 교과서는 지루하다. 2. 세상은 교과서처럼 돌아가지 않는다.

상황 2. 인터페이스 설계의 개론을 보고싶다. (시간이 많다)
그렇다면 : 퍼소나로 완성하는 인터랙션 디자인 (About Face 3)

  • 장점 : 인터페이스의 수많은 컴포넌트들에 대한 상세한 분석. 이 책의 3장은 처음 설계 업무를 할 때 정말 많이 참고하게 된다. (사실 그 후에도 계속) ‘사용자 중심 디자인’이라는 말이 넘쳐나면서 들게된 의문 - 그럼 사용자 중심 디자인이 아닌건 뭔데? -에 대한 약간의 답을 얻게 된다. 그걸 여기선 ‘구현 모델’이라는 말로 설명한다. 사람 중심이 아니라 컴퓨터가 돌아가는 구조를 그대로 드러낸 것. 그래서 사람이 쓰기엔 뭔가 부자연스러운 것.
  • 단점 : 책을 딱 잡는 순간 읽기를 포기하게 된다. 한국어판의 번역이 좀 거칠다. (하지만 그 양을 보면 이해는 간다…) 이 책에 대해 두 가지 유형의 사람을 만나기 쉽지 않다. 1. 이 책을 모르는 사람 2. 이 책을 다 읽은 사람

상황 3. 상상력과 창의력 터지는, 멋진 과정을 원한다. (현실이 어떻든 간에)
그렇다면 : 사용자 경험 스케치 by 빌 벅스턴

  • 장점 : 가끔 UX라는 것이 긴긴 프로세스와 남의 불평을 묵묵히 듣고만 있어야 하는 답답한 무언가로 느껴질 때가 있는데, 여기서 잠시 벗어나서 ‘발산’의 즐거움을 느낄 방법을 얻을 수 있다. 또 ‘경험’을 디자인한다는게 정적인 시각적 결과물을 만들어 내는 것과 무엇이 다른지 살짝 느껴볼 수 있다.
  • 단점 : 당신이 꽉 막히고 딱 굳어진 조직 안에 있다면, 여기서 제시하는 방법을 처음 시도하는데 굉장한 용기가 필요할 것이다.

상황 4. 당장 설계서를 그려야 한다. (시간이 촉박하다)
그렇다면 : 웹 폼 디자인 by 루크 로블르스키

  • 장점 : 인터페이스 설계에서 가장 많은 사용성 문제를 일으키는 Form에 집중된 책. 집중되어있다는 뜻은 이 책이 별로 안두껍다는 뜻이다.
  • 단점 : 당신에게 일을 맡긴 사람이 ‘거 포인트가 딱~ 될만한 트렌디한 인터랙션으로 부탁합니다~’라는 식이라면 별 도움은 안될지도… + 모바일에 대한 내용이 좀 부족하다고 느낄 수도 있다.

상황 5. 준비도 없이 프로젝트 매니저가 되어버렸다.
그렇다면 : 마음을 움직이는 프로젝트 관리

  • 장점 : 이 책 자체에 마음이 움직인다.
  • 단점 : 사람을 상대하는 일을 글로만 배울 순 없다. 결국 시행착오가 필요.

상황 6. 개발자의 마인드를 이해하고 싶다.
그렇다면 : 조엘 온 소프트웨어

  • 장점 : 개발자가 무엇을 소중하게 여기는지, 어떻게 일하고 싶어하는지 간접적으로나마 알 수 있다.
  • 단점 : 개발자가 아니라면 분명히 전혀 이해할 수 없는 부분이 있다. (이런 부분은 알아서 적당히 넘어가야…)

상황 7. 시간은 촉박한데 뭔가 UX스러운 프로세스가 필요하다.
그렇다면 : 린 스타트업 (Running Lean)

  • 장점 : 별로 안두껍다. 당장 따라할 수 있을만큼 잘 정리되어있다. 실제로도 상당히 효과적이다. 프로세스가 아닌, 비즈니스 목표를 정조준한다.
  • 단점 : 일을 시킨 사람이 체계적인 과정이나 숫자를 중시한다면 이 방식을 싫어할 수도 있다. 실제로 이 책 그대로 하려면 진짜 몸이 힘들 것이다. (그래서 포기하고 싶을 듯…)

상황 8. 이리 치이고 저리 치이고 이게 다 무슨짓인가 싶다.
그렇다면 : 대체 뭐가 문제야? (Are Your Lights On?)

  • 장점 : 별로 안두껍고 엄청 재밌다. 그러면서도 뒤통수를 탁 때리는듯한 시원한 인사이트가 담겨있다. 뭔가 탁- 놓을 수 있는 기분을 선사한다.
  • 단점 : 이 책은 ‘문제의 해결에 대한 책’이 아니다. 문제 그 자체에 대한 책이므로 가벼운 마음가짐이 필요.

상황 9. 한국의 UX 상황 전반을 알고 싶다.
그렇다면 : 전략적 UX 디자인으로 성장하라.

  • 장점 : 해외 번역서들에는 담겨있지 않은 한국의 상황이 잘 들어있다.
  • 단점 : 상황을 안다고 해결책이 보이는 것 만은 아니다.

상황 10. 우린 기술력이 없어서 안될거야 아마…
그렇다면 : 피플 웨어

  • 장점 : 일은 기술이 아니라 사람이 한다는 것을 알려준다.
  • 단점 : 글쎄…

이상, 지극히 주관적인 리스트 정리.

*베스트 책들을 뽑았다기 보다는, 얼마 안되는 ‘읽은 책’들을 정리한 것에 불과한 것 같다.

Tags: UX books