대부분의 Web3 온보딩 조언은 같은 곳에서 시작합니다:

지갑 연결을 쉽게 만드세요.

그것은 유용하지만 불완전합니다. 지갑 연결은 오직 첫 번째 시각적 실패일 뿐입니다. 더 깊은 문제는 Web3가 사용자들에게 누구에게도 신뢰하지 말라고 반복적으로 말하는 시스템을 신뢰하게 요구한다는 점입니다.

그 모순은 설계하기 어렵습니다.

Web2에서는 온보딩이 주로 마찰을 줄이는 것이고, Web3에서는 위험을 숨기지 않으면서 불확실성을 줄이는 것이 온보딩입니다.

이것들은 같은 일이 아닙니다.

첫 번째 화면에는 이미 신뢰 문제가 있습니다

사용자가 지갑을 연결하기 전에 그들은 조용한 질문을 합니다.

• 이게 진짜입니까?
• 이게 안전입니까?
• 클릭하면 어떻게 될까요?
• 비싼 것에 서명할 준비가 되었나요?
• 무언가를 잃지 않고 떠날 수 있나요?
• 누가 이것을 만들었나요?
• 이 인터페이스를 왜 믿어야 하는 거죠?

대부분의 암호화폐 제품은 히로 헤드라인, 토큰 로고, 연결 지갑 버튼으로 그 질문에 답합니다.

그것은 충분하지 않습니다.

연결 지갑 버튼은 일반적인 SaaS의 의미에서 CTA가 아닙니다. 그것은 신뢰의 경계입니다. 사용자가 웹사이트를 읽는 것에서 주소를 노출하고 확장 프로그램을 엽니다. 그리고 그들이 완전히 이해하지 못할 수 있는 권한을 서명하기 위해 준비하는 지점입니다.

디자이너들은 그 순간을 은행 인증처럼, 뉴스레터 가입처럼 보지 말아야 합니다.

익숙한 UI는 자동으로 신뢰를 만들지 않습니다

일반적인 실수는 DeFi 앱을 금융기술처럼 보이게 하고 문제가 해결되었다고 가정하는 것입니다.

깔끔한 카드. 둥근 버튼. 좋은 차트. 현대적인 은행 앱처럼 보이는 대시보드.

그러나 이는 도움이 될 수 있지만, 잘못된 자신감을 만들 수도 있습니다.

사용자가 변경 불가능한 계약, 다리 위험, 슬리핑, 청산, 잠금 해제 기간, 또는 토큰 승인과 상호작용하고 있다면, 인터페이스는 그런 사항을 표시할 책임이 있습니다. 복잡성을 숨기는 것은 단기적으로 전환율을 개선할 수 있지만, 사용자가 숨겨진 비용을 나중에 발견하면 신뢰를 손상시킵니다.

목표는 Web3를 Web2처럼 느끼게 하는 것이 아닙니다.

목표는 Web3를 이해하기 쉽게 느끼게 하는 것입니다.

좋은 온보딩이 실제로 설명하는 것

강력한 Web3 온보딩 흐름은 약속을 요청하기 전에 네 가지 질문에 답해야 합니다.

1. 이 제품은 무엇인가?

카테고리가 아닙니다. 프로토콜 아키텍처가 아닙니다. 실제 사용자 결과입니다.

나쁨:

다음 세대 자산 원시형에 대한 분산된 유동성 조정 레이어.

더 나음:

안정적인 코인을 입금하고, 가변 수익을 얻으며, 풀(Pool)이 잠겨있지 않은 한 언제든지 인출할 수 있습니다.

간단한 언어는 덜 복잡합니다. 더 유용합니다.

2. 사용자가 필요한 것은 무엇인가요?

사용자가 지갑(Wallet), 특정 체인, 가스(Gas), 토큰 잔액(Token balance), 서명(Signature), 또는 다리(Bridge)가 필요하다면 이를 일찍 말하세요.

첫 번째 오류 메시지가 설명을 대신하지 않도록 하세요.

좋은 온보딩 화면은 다음과 같이 말할 수 있습니다:

• Base에서 작동합니다
• 가스비를 위해 ETH가 필요합니다
• 탐색을 위해 예금이 필요하지 않습니다
• 예금하기 전까지 지갑 연결은 읽기 전용입니다

이는 알 수 없는 요구 사항을 알려진 단계로 바꾸어 스트레스를 줄입니다.

3. 어떤 일이 잘못될 수 있나요?

여기서 많은 팀이 긴장을 느낍니다. 위험을 보여주면 전환율이 낮아질 것이라고 생각합니다.

하지만 정교한 사용자들은 이미 위험 존재를 가정하고 있습니다. 인터페이스가 그것을 숨기면 프로젝트는 더 신뢰할 만하지 않게 보이며, 더 신뢰할 만하게 보이지 않습니다.

위험은 극적인 것이 필요하지 않습니다. 구체적인 것이 필요합니다.

예시:

• 수익은 시간이 지남에 따라 변합니다.
• 철회는 최대 24시간 걸릴 수 있습니다.
• 연결은 두 번째 거래가 필요할 수 있습니다.
• 토큰 승인은 나중에 취소될 수 있습니다.
• 담보 가치가 떨어지면 청산이 발생할 수 있습니다.

좋은 위험 설계는 경고벽이 아닙니다. 그것은 맥락적 진실입니다.

4. 다음은 무엇이 일어납니다?

각 서명에는 명확한 전후 상황이 있어야 합니다.

서명 전:

• 이 계약을 통해 최대 X만큼 지출할 수 있습니다.
• 이렇게 하면 아직 자금이 이동하지 않습니다.
• 이후에 이를 취소할 수 있습니다.

서명 후:

• 승인이 확인되었습니다.
• 이제 입금할 수 있습니다.
• 예상 가스비는 X입니다.

사용자는 절대로 지갑 팝업을 혼자 디코딩할 필요가 없습니다.

지갑 팝업은 제품의 일부입니다

많은 팀들이 지갑 상호작용까지 설계하고, 그 다음에 MetaMask, Phantom, Rabby, WalletConnect, 혹은 사용자가 선택한 다른 지갑에게 책임을 정신적으로 이양합니다.

그것은 오류입니다.

지갑 팝업은 제어하지 않더라도 사용자 여정의 일부입니다.

이것이 나타나기 전에 사용자를 준비시키고 닫은 후에 무엇이 일어났는지 확인하여 그것을 설계할 수 있습니다.

만약 앱이 "메시지 서명"이라고 하고 지갑이 비밀스러운 말을 한다면, 사용자는 앱이 명확하지 않다고 경험합니다.

인터페이스는 지갑 작업을 인간의 언어로 설명해야 합니다:

• "지갑 소유권을 확인합니다."
• "USDC 지출을 승인합니다."
• "ETH 풀에 입금하세요."
• "보상을 수령하세요."

기술적인 거래는 사용자 의도가 아닙니다. 의도에 맞게 설계하세요.

점진적 공개는 복잡성을 숨기는 것이 아닙니다

일부 건설자들은 "온보딩을 단순화한다"고 들으면 중요한 세부 사항을 제거한다고 가정합니다.

그렇지 않습니다.

점진적 공개는 적절한 순간에 적절한 세부 정보를 보여주는 것을 의미합니다.

첫 번째 화면에서 사용자는 안내가 필요합니다.

연결하기 전에 사용자는 요구 사항과 안심이 필요합니다.

서명하기 전에 사용자는 결과에 대한 이해가 필요합니다.

서명한 후에 사용자는 확인 및 복구 경로가 필요합니다.

고급 사용자도 거래 해시, 계약 주소, 문서, 검토, 탐색 링크에 접근할 수 있습니다. 하지만 그 세부 정보는 여정을 지원해야 하고, 첫 화면을 과대하면 안 됩니다.

더 나은 Web3 온보딩 체크리스트

배송 전에 질문하세요:

• 지갑을 연결하지 않고도 누가 제품을 이해할 수 있나요?
• 지갑 연결 버튼이 요청되는 접근이 무엇인지 설명하나요?
• 연쇄, 가스, 및 토큰 요구 사항이 실패 전에 표시됩니까?
• 지갑이 열리기 전에 위험한 작업이 설명됩니까?
• 모든 서명에 명확한 인간 레이블이 있습니까?
• 앱이 서명 후 변경 사항을 확인하나요?
• 사용자가 문서, 감사, 계약 주소 및 지원 경로를 찾을 수 있나요?
• 읽기 전용 또는 미리보기 모드가 있습니까?
• 비어 있는 상태가 유용한가요, 아니면 그냥 '지갑을 연결하세요'라고 말하는 것뿐인가요?

만약 그 대부분의 답변이 '아니오'라면, 문제는 지갑이 아니에요.

문제는 신뢰 설계입니다.

인터페이스는 신뢰 레이어입니다

스마트 계약은 기술적 신뢰를 만듭니다.

인터페이스는 인간적 신뢰를 만듭니다.

프로토콜이 안전할 수도 있지만 의심스러울 수 있습니다. 제품이 강력할 수도 있지만 첫 서명에서 사용자를 잃을 수 있습니다. 대시보드가 정확할 수도 있지만 아무도 무엇을 요청받고 있는지 몰라서 실패할 수 있습니다.

Web3 온보딩은 팀들이 UX를 프로토콜의 래퍼로 취급하기를 멈추고 프로토콜의 신뢰 시스템의 일부로 취급하기 시작할 때 개선될 것입니다.

그러면 의문의 버튼이 줄어들 것입니다.

해결되지 않은 서명이 적습니다.

사용자가 이미 위험 모델을 이해한다고 가정하는 대시보드가 적습니다.

그리고 사용자가 신뢰를 가지고 행동할 수 있도록 진실을 명확하게 전달하는 인터페이스가 더 많습니다.

저는 Web3 창의 디렉터로서, 복잡한 제품을 사람들이 실제로 신뢰하고 사용할 수 있는 인터페이스로 바꾸는 데 코인팀을 도와줍니다. 이 공간에서 개발을 하고 있다면, somaryuu.xyz.