관찰의 시작
지난 1년간 10개 Web3 서비스의 온보딩부터 핵심 기능까지 전수 분석했다. 서비스마다 다른 비전을 가지고 있었지만, UX 문제는 놀랍도록 비슷했다.
5가지 패턴으로 정리한다.
1. 기술 설명형 카피
패턴: 랜딩 페이지의 첫 문장이 기술 스택 설명이다.
"Decentralized, permissionless, non-custodial liquidity protocol"
사용자가 묻는 건 "이게 나한테 왜 좋아?"인데, 답은 "이게 어떻게 작동해"다.
원인: 기술을 만든 팀이 직접 카피를 쓴다. 그들에게 기술 설명은 자연스러운 출발점이다.
처방: 사용자의 현재 문제(Pain)에서 시작하고, 기술은 그 해결 수단으로 후반부에 등장시킨다.
2. 지갑 연결 먼저, 가치 설명 나중
패턴: 서비스 진입과 동시에 지갑 연결을 요구한다. 서비스가 무엇인지 보여주기 전에.
이는 처음 만나는 사람에게 악수 대신 계약서에 서명을 요구하는 것과 같다.
원인: 개발 중심 사고. 지갑 연결 없이는 데이터를 불러올 수 없으니, 기술적으로 첫 단계가 된다.
처방: 지갑 없이도 서비스의 핵심 가치를 탐색할 수 있는 "Guest Mode"를 설계한다.
3. 에러는 있고, 설명은 없다
패턴: 트랜잭션 실패 시 "Transaction Failed"만 표시된다.
Web3 트랜잭션 실패 원인은 다양하다. 잔액 부족, 슬리피지 초과, 네트워크 혼잡, 스마트 컨트랙트 오류. 하지만 사용자가 보는 건 항상 같은 메시지다.
원인: 에러 핸들링은 개발 일정에서 가장 마지막 항목이 된다.
처방: 에러 타입별 메시지 설계를 기획 단계에서 정의한다. "무엇이 잘못됐는지"와 "어떻게 하면 되는지"를 함께 제공한다.
4. 숫자는 많고, 맥락은 없다
패턴: 대시보드는 숫자로 가득하다. APY 38.2%, TVL $2.4B, 24H Volume $180M.
이 숫자들이 나에게 무엇을 의미하는지 알 수 없다. 38.2%가 좋은 건지, 평균인지, 위험한 건지.
원인: 데이터를 보여주는 것과 인사이트를 제공하는 것은 다른 설계 문제다.
처방: 숫자에 기준선과 방향성을 추가한다. "시장 평균 대비 +12%", "지난 주 대비 ↑2.3%".
5. 모바일은 항상 나중
패턴: 서비스의 주요 기능이 데스크톱에서만 완전히 작동한다.
그러나 실제 Web3 사용자의 트랜잭션 60% 이상은 모바일에서 발생한다.
원인: 개발팀이 데스크톱에서 개발하고, QA도 데스크톱에서 한다.
처방: Mobile-First 설계 원칙을 프로토타이핑 단계에서 강제한다. 모바일에서 불가능한 기능은 출시하지 않는다.
공통 구조
5가지 패턴의 뿌리는 하나다. 만드는 사람의 관점에서 설계된 서비스.
Web3 UX가 개선되려면 사용자 관점이 설계의 출발점이 되어야 한다. 기술이 훌륭해도, 사용자가 문을 열고 들어오지 못하면 의미가 없다.