사용자 중심의 Web3 모바일 앱 개발

유용한 앱은 하나의 실제 사용자 작업에서 시작됩니다

Web3 앱은 하나의 유용한 작업을 이해하기 쉽게 만들어야 합니다. 클로즈드 베타를 열려는 스튜디오가 AMA 전날 저녁에 있다고 상상해보세요. 팀은 멤버들이 모바일 흐름을 시도하길 원하므로, 화면을 선택하기 전에 지갑 단계를 먼저 매핑할 것입니다.

그 첫 번째 작업은 잔액 확인, DeFi 기능 사용, 또는 로열티 보상 확인일 수 있습니다. 우리는 사람이 무엇을 해야 하는지 질문하는 것부터 시작합니다. 어떤 정보가 필요한지, 어떤 작업에 지갑 또는 블록체인 연결이 필요한지 묻습니다. 이렇게 하면 팀이 출시 필수 요소와 나중에 미룰 수 있는 아이디어를 실용적으로 구분할 수 있습니다.

작업은 신제품 또는 더 넓은 Web3 서비스의 모바일 부분에 적합할 수 있습니다. 앱 계획을 기존 제품, 기술 설정, 유지 관리할 사람들과 연결합니다. 브라우저 기반 경험도 필요하다면, dApp 개발 작업이 모바일과 웹 여정을 일관되게 유지하는 데 도움이 될 수 있습니다. 더 포괄적인 제품 구축은 Web3 개발을 참조하세요.

명확한 첫 번째 작업은 디자인과 엔지니어링에 동일한 출발점을 제공합니다. 팀은 이를 지원하지 않는 화면이나 통합에 시간을 투자하기 전에 흐름을 검토할 수 있습니다.

어떤 모바일 경험이 제품에 적합할까요?

올바른 앱 형식은 제품의 사용자 여정, 플랫폼 요구사항, 유지보수 계획에 따라 결정됩니다. 우리는 네이티브 iOS 및 Android 개발 또는 크로스 플랫폼 접근 방식을 선택하기 전에 이러한 요구사항을 검토합니다.

네이티브 앱이 적합한 경우

네이티브 개발은 iOS와 Android 경험이 서로 다른 동작이나 플랫폼별 디자인을 필요로 할 때 적합합니다. 우리는 이러한 차이점을 팀과 함께 매핑하고 각 버전이 지원해야 할 사항을 기록합니다. 이를 통해 개발 시작 전에 작업 범위를 더 명확히 파악할 수 있습니다.

공유 개발이 적합한 경우

크로스 플랫폼 구축은 화면과 주요 작업이 대부분 공유되는 제품에 적합할 수 있습니다. 우리는 통합, 인터페이스 요구사항, 향후 유지보수 계획을 함께 확인합니다. 결정은 프레임워크 선호도가 아닌 팀이 운영에 필요한 사항을 반영해야 합니다.

예를 들어, 멤버들이 앱에서 보상을 확인한 후 특정 작업을 위해 지갑을 연결하는 로열티 제품을 생각해보세요. 우리는 단순히 표시되는 정보와 연결이 필요한 작업을 구분할 것입니다. 제품에 자체 지갑 경험이 필요하다면, 요구사항을 암호화폐 지갑 개발과 비교하세요. 기존 또는 새로운 컨트랙트 동작에 주의가 필요하다면, 스마트 컨트랙트 개발이 관련 작업 스트림이 될 수 있습니다.

코드 작성 전에 결정할 네 가지 사항

개발을 시작하기 전에 제품 아이디어를 간단한 계획으로 전환합니다. 디자인과 엔지니어링 모두 이 계획을 사용할 수 있습니다. 3부분으로 구성된 킥오프 노트는 사용자 목표, 출시 작업, 기술적 종속성을 포함합니다.

1. 주요 사용자 여정을 명명합니다. 앱이 지원해야 할 첫 번째 작업을 식별합니다. 그런 다음 사용자가 이를 완료하는 데 필요한 화면을 매핑합니다.
2. 연결을 매핑합니다. 필요한 지갑, 블록체인, 백엔드 및 API 작업을 나열합니다. 또한 팀이 제공할 수 있는 기존 서비스나 기술 자료를 기록합니다.
3. 첫 번째 출시 기능을 선택합니다. 출시 시 반드시 있어야 할 것과 나중에 추가할 수 있는 것을 표시합니다. 이는 더 넓은 제품 시야를 잃지 않으면서 첫 번째 빌드에 집중하는 데 도움이 됩니다.
4. 확인 사항에 합의합니다. 팀이 각 핵심 흐름을 어떻게 검토할지 정의합니다. 확인 사항은 확인, 대기 상태, 작업이 완료되지 않았을 때 사용자가 보는 화면을 포함합니다.

1페이지 흐름 맵은 이러한 결정을 검토하기 쉽게 만듭니다. 제품 및 기술 리더가 초기에 누락된 세부 사항을 발견하는 데 도움이 되며, 인터페이스 작업에 명확한 진행 경로를 제공합니다. 앱이 새 토큰에 의존하는 경우, 토큰 생성 및 배포와 계획을 연결하여 앱의 가정이 명확해지도록 할 수 있습니다.

첫 화면에서 출시 준비 빌드까지

빌드는 합의된 사용자 여정을 작동하는 앱으로 구현합니다. 그런 다음 제출 준비 전에 이러한 여정을 확인합니다. 주요 부분이 어떻게 구성되는지는 다음과 같습니다:

앱이 구체화됨에 따라 디자인과 엔지니어링을 연결 상태로 유지합니다. 여기에는 프롬프트, 확인, 대기 순간 및 오류 메시지가 포함됩니다. 사용자는 중요한 작업 중에 이러한 세부 사항을 접하게 됩니다. 팀은 마지막 순간의 시각적 검토에만 의존하지 않고 합의된 동작에 대해 출시 후보를 확인합니다.

또한 개발자 계정 액세스, 제품 텍스트, 스크린샷 및 기타 출시 입력물을 누가 제공할지 명확히 합니다. Telegram 기반 기능은 독립형 모바일 앱보다 미니 앱으로 더 적합할 수 있습니다. 팀이 잘못된 형식을 선택하기 전에 Telegram 봇 및 미니 앱 개발과 해당 필요성을 비교할 수 있습니다.

출시 계획을 스토어 규칙에 기반하여 수립

좋은 출시 계획은 최종 빌드 전에 책임과 미해결 질문을 명확히 합니다. 개발 전에 암호화폐 앱 정책을 검토합니다. 그런 다음 초기 검토를 팀이 필요한 기능, 디자인 및 제출 작업과 연결합니다. 이를 통해 제품 흐름에 대해 논의할 여유가 있을 때 모든 사람이 질문을 제기할 기회를 얻습니다.

또한 앱 스토어 계정과 제출 결정을 누가 소유할지 합의합니다. 제품 세부 정보를 누가 제공하고, 후속 작업을 누가 처리할지 명확히 합니다. 킥오프 체크리스트에서 Brand Community는 플랫폼 대상, 출시 우선순위, 기존 기술 자료 및 작업을 승인할 수 있는 사람을 기록합니다. 프로젝트 중에는 구현이 진행되기 전에 인터페이스와 핵심 여정을 확인합니다. 그런 다음 동일한 합의된 동작에 대해 빌드를 검토합니다.

Apple과 Google은 암호화폐 앱 정책을 설정하고 검토 결정을 내리며, 그 결과는 저희가 통제할 수 없습니다. 합의된 제출 작업을 준비하지만, 승인을 약속할 수는 없습니다.

시작하려면 간단한 제품 요약, 의도한 플랫폼, 기존 디자인이나 기술 노트를 보내주세요. 출시 시 가장 중요한 사용자 작업을 알려주세요. 해당 자료를 검토하고 첫 번째 결정을 식별하며 실용적인 빌드 계획을 함께 개요를 설명하겠습니다.

이용 방법

1. 제품 노트 공유목표, 의도한 사용자, 플랫폼 계획 및 기존 디자인이나 기술 자료를 보내주세요. 출시 시 중요한 작업을 알려주세요.
2. 앱 및 연결 매핑주요 여정, 필요한 지갑 및 블록체인 링크, 백엔드 또는 API 작업, 미해결 질문을 개요로 설명합니다.
3. 인터페이스 검토개발 시작 전에 주요 화면과 상호작용 상태를 함께 검토합니다.
4. 핵심 흐름 구축 및 확인합의된 앱을 개발하고 요구사항에 따라 주요 여정과 통합을 테스트합니다.
5. 출시 인계 준비계획에서 제출 작업을 정리하고, 각 항목을 누가 제공할지 명확히 하며, 출시 후 지원에 합의합니다.