작가의 글을 더 이상 구독하지 않고,
새 글 알림도 받아볼 수 없습니다.
초보 PM, 디자이너가 피해야 할 UX 의사결정 1
1편
by
Feb 18. 2025
프로덕트 매니저와 프로덕트 디자이너의 업무 경계는 많은 부분 겹칩니다. 심지어 프로덕트 디자이너라는 잡 타이틀은 UI 디자이너, UX디자이너, UXUI 디자이너를 거쳐 진화된 또 다른 직무로써 나열된 직업명들과는 또 다른 아이덴티티를 가지고 있기도 하죠. 그만큼, 제품 제작에 있어 PM과 프로덕트 디자이너의 역할이 환경에 따라 다르게 정의되고 기술에 따라 요구 사항이 변화하고 있다는 의미이기도 합니다.
그러나 디지털 제품을 만드는 제품 메이커라는 관점에서 두 직업 군이 모두 함께 바라보아야 할 지점이 있습니다. 바로 UX에 대한 깊은 이해와 통찰입니다. 저는 업계의 멋진 선후배님들 만큼 노련하거나 다채로운 경험을 가진 프로덕트 디자이너는 아닙니다만, 그간 UX기획자와 리서처를 거치며 프로덕트를 만들어 온 메이커로서 UX 의사결정을 할 때 참고하면 좋을 점들을 써보려 합니다.
혹시나 PM 포지션에서 일하기를 원하시거나, 혹시나 사수 없이 프로덕트 매니저가 되셨거나, 이제 막 프로덕트 디자이너가 되어 UX 의사결정 앞에 고민하시는 분들이 계시다면, 조금이라도 도움이 되고 싶은 마음에 오랜만에 글을 적어 봅니다.
초보 PM, 초보 디자이너가 피해야 할 UX 의사결정
1. 발생 횟수로 판단하기
UX는 통계의 영역이 아닙니다. 사용자 경험이라는 것은 숫자로 설명되지 않는 부분도 많으니까요. 사용자 경험의 설계는 정량적 데이터와 정성적 데이터가 서로 보완적 관계를 가지고 가설을 세우고, 실험, 증명해 내는 영역에 더 가깝습니다. 그렇기 때문에 잘 못된 시선으로 데이터를 활용하고 근거로 삼는 순간, 유저의 사용 경험과 더 먼 의사 결정을 할 수도 있습니다.
❌ "VOC가 적으니까, 문제가 크지 않기 때문에 개선하지 않는다."
❌ "데이터를 추출해 보니 문제 발생 빈도가 낮으니 개선하지 않는다."
위와 같은 접근은 항상 참(True)이 아닐 수 있습니다. 문제를 제기하는 사람이 적으면, 문제의 중요도가 낮은 것이라는 판단에서 오는 것인데 앞서 말했듯 사용자 경험은 맥락적인 이해, 즉 정성적인 분석을 토대로 정량적 데이터가 보완되어 결정되어야 합니다.
아래의 예제를 생각해 보면, 프로덕트의 니즈와 원츠는 항상 숫자가 아님을 알 수 있습니다.
이용 빈도가 낮다고 하여 건물 내 장애인 전용 엘리베이터를 없앨 것인가?
도로에 과속 방지턱이 부족해 과속이 잦은데, 민원이 적으면 문제가 없는 걸까?
ATM에서 출금 오류가 발생, 고객 센터에 문의하는 사람이 없다면 문제가 없는 걸까?
오류나 어려움을 만났을 때 사람들이 항상 신고하는 것은 아닙니다. 몇 번이고 다시 시도하거나, 포기하거나, 서비스에 자기가 원하는 걸 어필하지 않거나(적극적으로 니즈를 알리는 분들은 정말 감사한 분들입니다..), 또는 앞으로 이용하지 않거나. 제품을 만들 때 가장 피하고 싶은 일이 있다면, 유저가 그 서비스를 떠나는 것일 겁니다. 불편이 자꾸 반복되어 신고할 애정도 남지 않을 만큼 나쁜 경험을 한 뒤 말이죠. (유저 절대 지켜..)
결국, 말하고자 하는 것은 어떻게 문제를 정의할 것인가입니다. UX에서의 문제 정의는 숫자가 아닙니다. 진짜 페인포인트, 유저가 원하고 있는 숨겨진 니즈를 파악하려면 단순한 숫자나 빈도를 넘어 "왜 이런 숫자가 나왔는가?" 하는 맥락을 해석하는 과정이 동반되어야 한다는 점입니다. 즉, 데이터를 사용자 맥락에서 분석하지 않으면 숨겨진 불편을 놓칠 위험이 있습니다. 바른 문제 정의가 있어야 바른 문제 해결을 할 수 있기에 매우 중요한 포인트입니다.
2. 남들이 하니까 우리도
여느 분야를 막론하고 리서치와 벤치마킹은 필수입니다. UX/UI도 마찬가지입니다. 이때의 리서치의 목적이 있다면 서비스 기획적인 레벨에서 타 서비스는 어떤 기능을 어떻게 제공하고 있는가, 일종의 트렌드 리서치, 정보 설계나 기획 리서치가 될 수 있겠고 UI적인 레벨에서는 우리가 해결하고자 하는 문제를 어떤 형태로 풀어내고 있는가 컴포넌트 단위의 리서치가 될 수 있겠습니다. 둘을 이분적으로 분리하는 것은 어렵겠지만요.
하지만, 이 단계에서 유의해야 할 점이 있습니다. 벤치마킹과 카피는 다르다는 점입니다. 사실, 의도하지 않더라도 무의식 중에 카피를 하게 되는 경우도 있습니다. UX/UI 디자인의 영역에서는 많은 부분 우수한 기업들이 업계의 표준적인 디자인과 설계를 구현해 두었고, 그것이 시장에서 일종의 템플릿화 되며 범용적으로 사용되는 케이스가 많습니다. 그래서 제품을 만들면서 어떤 게 카피이고 어떤 게 카피가 아닌지 고민될 지점이 많을 수밖에 없을 것 같습니다.
다만, 한 가지 확실한 기준이 있다면, 올바른 벤치마킹 방법은 리서치를 통해 얻어낸 인사이트를 제품에 녹여내는 것이지 단순히 똑같은 형태의 UI를 차용하는 것이 아니라는 것입니다.
❌ "다른 서비스도 이렇게 하니까, 우리도 그대로 하면 된다."
❌ "이 UI가 좋다고 하니까, 우리도 적용하자."
좋은 UI라고 해서 무조건 우리 서비스에도 적합한 것은 아닙니다. 중요한 것은 "왜 저렇게 설계했을까?"를 이해하고 그걸 우리 서비스에 맞게 적용하는 것입니다. 이 과정은 매우 고통스러운 분석과 고뇌를 요하긴 하지만, 이런 고민을 충분히 거치고 나면 프로덕트에 정말 필요한 문제 해결을 할 수 있을 것입니다.
아래 제가 생각하는 벤치마킹 방법에 대해 이야기해 보겠습니다.
<벤치마킹 하는 법>
1. 우리 제품에서 해결하고자 하는 문제가 무엇인지 명확히 알아야 함
UI를 먼저 보고 이를 문제 해결 방법으로, 혹은 기획으로 가져오지 않습니다. 우리 프로덕트에서 해결할 문제를 먼저 정의하고, 이를 풀어나가는 방법을 찾기 위해 타사의 UX 설계를 바라보고, 설계를 잘 구현하는 방법으로써 UI 래퍼런스를 수집해야 합니다.
2. UX/UI에서 무엇이 보편적, 관용적으로 소통되는지 이해해야 함
ex. 다운로드 아이콘, 좋아요 아이콘 등 어떤 의도 전달 및 액션에 있어 보편적으로 굳어진 관용적 사용
위의 예시 같은 경우, 똑같이 따라 한다고 하여 카피가 되는 것은 아닙니다. 오히려 유저의 기존 학습 경험을 고려해 암묵적인 룰처럼 따라야 하는 경우가 됩니다. 뒤로 가기 버튼에 화살표가 아닌 별이나 꽃 아이콘을 넣지 않는 것과 같습니다.
3. 다양한 사례를 수집, 패턴화 시키고 인사이트를 찾아야 함
프로덕트 디자인의 UX 리서치에서 가장 중요한 것이 있다면 패턴화 같습니다. 개별 사례를 그냥 바라보고 하나를 차용하는 것이 아니라, 여러 개의 사례에서 인사이트를 찾을 수 있는 분석력을 기르면 좋습니다. (결국 AI의 학습법이기도 하겠으나, 결국에는 인간의 학습법인..) 여하튼 이런 과정을 반복해 보시면 흩어져 있는 사례들에서 하나의 패턴을 찾아내 실 수 있을 겁니다. 그리고 그 패턴을 우리 서비스에서 우리만의 스타일로 녹여낼 때, 벤치마킹을 통한 문제 해결을 할 수 있을 것입니다.
사실 준비했던 두 가지가 더 있는데 글이 길어지는 것 같아 다음 편에 이어 써 보도록 하겠습니다. 읽어 주셔서 감사합니다.
더하여, UI 표절에 관해 더 궁금하신 분들을 위해 몇 가지 글들도 첨부해 봅니다.