UXer의 벤치마킹에는 나침반이 필요하다
UXUI 방법론에 대한 고찰
처음 벤치마킹 업무를 맡았을 때의 장면이 떠오른다.
몇 개의 경쟁 서비스를 설치하고, 기능을 하나씩 눌러본 뒤 스크린샷을 찍는다.
그리고 PPT에 정리한다.
화면 옆에는 이런 문장이 붙는다.
“○○ 서비스는 이런 기능이 있음”
“△△ 서비스는 이런 UI 구조”
문서는 빠르게 채워진다
그래서 우리는 무엇을 해야 할까?
많은 주니어 기획자들이 이 단계에서 길을 잃는다.
나는 이 상태를 종종 벤치마킹 홈쇼핑이라고 부른다.
문서는 있지만 방향은 없다.
왜 벤치마킹은 ‘복사 붙여넣기’가 되는가
특히 내비게이션 같은 성숙한 시장에서는 이 문제가 더 자주 나타난다.
이미 대부분의 서비스가 비슷한 기능을 갖추고 있기 때문이다.
목적지 검색, 실시간 교통, 경로 추천, 차선 안내, 도로 상황 안내등등.
어느 서비스를 열어봐도 큰 틀은 크게 다르지 않다.
그래서 벤치마킹이 쉽게 '기능 및 UXUI 수집'으로 변한다.
하지만 이 방식에는 중요한 질문이 빠져 있다.
왜 이 기능이 여기 있을까.
왜 이 UI 구조를 선택했을까.
경쟁사가 무엇(What)을 했는지만 보고 왜(Why) 그렇게 했는지를 놓치면,
그 기능은 우리 서비스에 들어오는 순간 맥락을 잃는다.
그리고 결과적으로 우리는 카피된 기능만 늘어난 서비스를 만들게 된다.
그래서 필요한 것: UX 나침반
벤치마킹이 길을 잃지 않으려면 지도보다 나침반이 필요하다.
이 나침반의 목적은 단순하다.
우리 서비스가 어디에 있는지 확인하고
경쟁사와의 격차를 측정하고
앞으로 어느 방향으로 가야 하는지 찾는 것
즉, 벤치마킹을 스크린샷 수집이 아니라 방향 탐색으로 바꾸는 것이다.
Step 1. 질문부터 정의한다
벤치마킹을 시작하기 전에 먼저 질문을 만든다.
질문 없는 리서치는 검색창에 아무 단어도 입력하지 않은 상태와 비슷하다.
예를 들어 이런 질문이다.
"ADAS View에서 지나가는 객체를 어떤 시각적 표현으로 보여줘야 운전자가 한눈에 이해할 수 있을까?"
질문이 정해지면 그다음에야 무엇을 비교해야 하는지 보이기 시작한다.
Step 2. 경쟁사를 넓게 본다
질문이 정해졌다면 다음은 무엇을 비교할 것인지 정하는 단계다.
주니어 기획자들이 가장 자주 하는 실수는 직접 경쟁 서비스만 보는 것이다.
예를 들어 ADAS View를 벤치마킹한다면 보통 이런 서비스부터 떠올린다.
테슬라, 메르세데스 벤츠, BMW, BYD, Geely 등등 (물론 중요한 비교 대상이다.)
하지만 이 범위 안에서만 보면 대부분 비슷한 답에 도달한다.
차량, 차선, 주변 객체를 3D 모델로 표현하고 위험 상황에서는 색상이나 애니메이션으로 경고를 주는 방식이다.
그래서 비교 대상을 조금 더 넓게 가져갈 필요가 있다.
예를 들어 이런 서비스들이다.
게임 UI-미니맵에서는 수많은 객체를 빠르게 인지할 수 있도록 단순화된 시각 언어를 사용한다.
로봇 / 자율주행 시각화 인터페이스-센서가 인식한 객체를 어떤 형태와 색으로 표현해야 직관적인지 다양한 실험이 이루어지고 있다.
지도 서비스-차량, 보행자, 교통 상황을 단순한 그래픽으로 표현하는 방식에서 참고할 점이 많다.
이렇게 비교 대상을 확장하면 질문도 조금 더 구체적으로 변한다.
“ADAS에서 어떻게 경고를 주고 있는가”->“어떤 시각 언어가 가장 빠른 상황 인지를 만드는가”
라는 질문으로 바뀌기 시작한다.
그리고 바로 이 지점에서 벤치마킹은 기능 수집이 아니라 UX 문제 해결 과정이 된다.
Step 3. 느낌 대신 숫자를 남긴다
“이 UI가 더 직관적인 것 같다.”
ADAS View를 보면서도 이런 말을 자주 하게 된다.
하지만 이런 표현은 팀 안에서 오래 버티지 못한다.
그래서 벤치마킹에는 측정 기준이 필요하다.
특히 ADAS View처럼 운전 중 짧은 시간 안에 정보를 이해해야 하는 UI에서는 ‘좋아 보인다’는 감각보다 인지 속도와 반응성이 더 중요한 기준이 된다.
예를 들어 이런 방식으로 측정할 수 있다.
1. 객체 인지 시간 (Object Recognition Time)
화면에 객체가 나타난 뒤 운전자가 그것을 인지하는 데 걸리는 시간.
2. 위험 상황 인지 시간 (Hazard Detection Time)
전방 차량 급감속이나 차선 위험 상황을 운전자가 알아차리는 데 걸리는 시간.
3. 시선 이동 횟수 (Eye Movement)
운전자가 ADAS View를 이해하기 위해 몇 번이나 시선을 이동해야 하는지.
4. 오인식 비율 (Misinterpretation Rate)
객체의 의미를 잘못 이해하는 경우가 얼마나 발생하는지.
그리고 이때 가장 중요한 기준이 하나 더 있다.
우리 서비스의 Baseline.
현재 ADAS View에서 운전자가 전방 위험을 인지하는 평균 시간이 얼마인지 모른다면 새로운 UI가 더 좋아졌는지 판단할 수 없다.
그래서 UX 벤치마킹은 항상 현재 상태를 먼저 측정하는 것부터 시작한다.
Step 4. 벤치마킹을 ‘결론’이 아니라 ‘제안’으로 만든다
벤치마킹의 마지막에는 항상 같은 순간이 온다.
여러 서비스를 비교하고 패턴을 정리하고 차이를 분석한 뒤 회의실에서 누군가가 묻는다.
“그래서 우리는 어떻게 해야 하죠?”
이 질문에 답하지 못하면 벤치마킹 문서는 그저 잘 정리된 스크린샷 모음으로 남는다.
그래서 마지막 단계에서는 항상 하나의 제안을 만들어야 한다.
1. 와이어프레임
벤치마킹에서 발견한 패턴을 바탕으로 우리 서비스에 적용했을 때의 화면을 간단히 설계해 본다.
2. 적용 시나리오
사용자가 어떤 상황에서 이 기능을 사용하게 되는지 흐름을 정리한다.
3. 기대 효과
이 변화가 실제로 어떤 경험을 개선할 수 있는지 설명한다. 예를 들어 위험 상황 인지 속도, 정보 이해도, 사용 편의성 같은 부분이다.
벤치마킹은 ‘관찰’이 아니라 ‘방향 찾기’다
경쟁 서비스를 보는 일은 어렵지 않다.
하지만 그 안에서 패턴을 읽고, 이유를 찾고, 방향을 정하는 일은 조금 다르다.
그래서 좋은 벤치마킹 문서는 “경쟁사가 무엇을 했다”로 끝나지 않는다.
대신 이런 문장으로 끝난다.
“그래서 우리는 이렇게 해볼 수 있다.”
그리고 그 순간 벤치마킹은 복사 붙여넣기 문서가 아니라 다음 디자인을 만드는 출발점이 된다.
Reference
Nielsen Norman Group – UX Benchmarking Metrics
https://www.nngroup.com/articles/benchmarking-ux/
Maze – How to run UX benchmarking
https://maze.co/collections/ux-ui-design/benchmarking/
UXDesign.cc – UX Benchmarking Metrics (Task success rate, time on task 등)
https://uxdesign.cc/benchmarking-in-ux-an-organizational-framework-bf64305d7270
UserTesting – UX Metrics Guide
https://www.usertesting.com/blog/user-experience-metrics-to-know?utm_source=chatgpt.com