⚠ PP — 잘못 정의된 문제

㊦ Poor Problem

UX 포트폴리오의 첫 관문

UX 포트폴리오의 구조는 보통 ‘문제 정의 → 가설 설정 → 조사 및 검증 → 솔루션 도출 → 결과 및 회고’의 흐름을 따른다. 얼핏 보면 당연한 이 구성에서, 사실상 가장 많은 오류가 발생하는 지점은 첫 단계인 ‘문제 정의’다.

문제는 모든 프로젝트의 시작이자, 이후 흐름을 통제하는 관문이다. 그러나 많은 지원자들은 이 관문을 지나치게 쉽게 넘기거나, 당연한 절차로 치부해 버린다. 어떤 이는 개인적인 불편을 곧바로 문제로 규정하기도 하고, 어떤 이는 조사 결과를 수집만 한 채 의미 있는 해석 없이 그냥 넘어가곤 한다. 또 어떤 이는 흥미로운 솔루션을 먼저 염두에 두고, 그 명분을 마련하기 위해 문제를 맞혀서 설정한 티를 내버리기도 한다.

하지만 문제 정의란 단지 어떤 사용자의 불만을 단지 말로 옮기는 행위가 아니다. 그것은 UXer가 세우는 일 전체의 방향성과 기준이기도 하다. 따라서 이 정의가 어긋나면, 이후 모든 흐름은 무조건 흔들린다. 아무리 결과물이 미려하고 정교해도, 그 설득력은 반감될 수밖에 없다. 첫 단추가 잘못 꿰어지면, 그 뒤의 단추가 아무리 반듯하게 이어져도 결국 틀어지게 마련이다.

---

UX 포트폴리오에서 자주 보이는 문제 정의 오류

지금까지 수년간 멘토링을 통해 본 반복적으로 발견한 대표적인 문제 정의의 오류를 나는 크게 세 가지 정도로 본다.

1. 문제가 아닌 것을 문제로 착각한 경우

감정적 불만이나 단편적 수치를 과도하게 해석해 문제로 오인하는 방식이다. 예를 들어, “이 기능 클릭률이 너무 낮아요. 사람들이 잘 못 보는 것 같아요”라는 팀 내부의 반응에 따라 곧장 해당 기능을 앱 상단이나 홈 배너에 배치하는 방식의 프로젝트로 이어지는 경우가 있다.

이때 진짜 문제는 '위치'가 아닐 수도 있다. 그 기능이 실제로 필요하지 않다거나, 사용자가 인지했음에도 의도적으로 사용하지 않은 것일 수 있다. 단순 노출 강화로 클릭률을 높이겠다는 시도는, “사용하지 않는다 = 못 본다”는 잘못된 인과관계를 전제로 한다. 이처럼 데이터를 곧장 문제로 연결지은 것은 좋으나 그 해석의 오류는, 오히려 기능의 본질적 필요성과 사용자 맥락을 흐리는 결과를 낳는다.

2. 존재하는 문제를 필터링해내지 못한 경우

조사 과정에서 분명 문제들이 드러났지만, 핵심 이슈를 선별하지 못한 채 피상적인 문제만 선택하는 경우도 흔하다. 이때 가장 큰 오류는 ‘리서치를 했으니 문제정의도 잘 되었다’고 착각하는 것이다. 예를 들어, 한 모빌리티 앱에서 사용자는 “GPS가 부정확하다”, “결제 등록이 어렵다”, “경로가 현실과 다르다”는 불편을 호소했다고 치자. 하지만 UXer는 “운전자 평가 화면이 갑자기 뜬다”는 피드백만 문제로 삼아, 전환 애니메이션 개선에 집중했다면, 프로젝트 외부자의 시각에서는 이 상황을 의아해할 수밖에 없다.

이처럼 손댈 수 있는 문제만 선택하고, 실제 불편이 집중된 문제는 외면하면, 리서치의 신뢰력은 무의미해진다. UX 문제 정의란 무엇을 선택하고 무엇을 버릴지를 판단하는 능력까지 포함된다. 눈에 띄는 것보다, 실제 사용자를 가장 힘들게 하는 문제를 중심에 두는 것. 그것이 진짜 실력이다.

3. 해결 불가하거나 검증이 어려운 문제에 무모한 도전을 한 경우

한 지원자는 “SNS 중독으로 인해 집중력과 정서가 악화되고 있다”는 문제의식에서 출발해, 이를 해결하기 위한 UX 프로젝트로 ‘SNS 중독을 벗어나게 도와주 새로운 SNS’를 제안했다. 좋아요를 없애고, 피드 자동 갱신을 막고, 사용 시간제한 기능도 적용했다. 언뜻 보면 디지털 웰빙을 고려한 UX처럼 보이지만, 정작 문제와 솔루션이 본질적으로 충돌한다.

SNS 중독을 문제 삼는다는 것은 디지털 서비스에 대한 본질적 도전에 가깝다. 그런데 오히려 또 다른 SNS를 만든다는 건, 아무리 중독을 예방하고 반대의 기획 의도를 품었다 해도 결국 또 다른 후보를 더 생산해 내는 셈이다. 문제를 정확히 봤더라도, 해결 수단을 자기 식대로 끌어다 쓰면 결국 아전인수에 불과하다.

사용자 중심? 정말로?

많은 UX 포트폴리오가 표면적으로 ‘사용자 중심’을 당연히 표방하지만, 실제 내용을 들여다보면 사용자가 중심이 아닌 경우가 정말로 많다. 대표적인 유형은 다음과 같다.

유형 A: UXer 주도형 문제 정의