Phát triển ứng dụng Web3 được định hình theo người dùng của bạn

Một ứng dụng hữu ích bắt đầu từ một tác vụ người dùng thực tế

Một ứng dụng Web3 nên làm cho một tác vụ hữu ích trở nên dễ hiểu. Hãy tưởng tượng một studio sắp mở bản beta kín, vào buổi tối trước một AMA. Nhóm của studio muốn thành viên thử một luồng di động, vì vậy chúng tôi sẽ lập bản đồ bước wallet trước khi chọn màn hình.

Tác vụ đầu tiên đó có thể là kiểm tra số dư, sử dụng tính năng DeFi hoặc xem phần thưởng khách hàng thân thiết. Chúng tôi bắt đầu bằng cách hỏi một người cần làm gì. Chúng tôi hỏi họ cần thông tin gì và hành động nào yêu cầu kết nối wallet hoặc blockchain. Điều này mang lại cho nhóm một cách thực tế để tách biệt những thứ cần thiết khi ra mắt khỏi những ý tưởng có thể chờ đợi.

Công việc có thể phù hợp với một sản phẩm mới hoặc một phần di động của một dịch vụ Web3 rộng hơn. Chúng tôi kết nối kế hoạch ứng dụng với sản phẩm hiện có, thiết lập kỹ thuật và những người sẽ duy trì nó. Nếu cũng cần trải nghiệm dựa trên trình duyệt, công việc phát triển dApp của chúng tôi có thể giúp giữ cho hành trình di động và web nhất quán. Để xây dựng sản phẩm rộng hơn, hãy xem phát triển Web3.

Một tác vụ đầu tiên rõ ràng cũng mang lại cho thiết kế và kỹ thuật cùng một điểm khởi đầu. Nhóm của bạn có thể xem xét luồng trước khi đầu tư thời gian vào các màn hình hoặc tích hợp không phục vụ nó.

Trải nghiệm di động nào phù hợp với sản phẩm của bạn?

Định dạng ứng dụng phù hợp tuân theo hành trình người dùng của sản phẩm, nhu cầu nền tảng và kế hoạch bảo trì. Chúng tôi xem xét những nhu cầu đó trước khi chọn phát triển native iOS và Android hoặc phương pháp đa nền tảng.

Khi ứng dụng native phù hợp

Phát triển native có thể phù hợp khi trải nghiệm iOS và Android cần hành vi khác biệt hoặc thiết kế dành riêng cho nền tảng. Chúng tôi lập bản đồ những khác biệt đó với nhóm của bạn, sau đó ghi chú những gì mỗi phiên bản phải hỗ trợ. Điều đó mang lại cho bạn cái nhìn rõ ràng hơn về công việc trước khi phát triển bắt đầu.

Khi phát triển dùng chung phù hợp

Một bản build đa nền tảng có thể phù hợp với các sản phẩm có màn hình và hành động chính phần lớn được chia sẻ. Chúng tôi cùng nhau kiểm tra các tích hợp, nhu cầu giao diện và kế hoạch bảo trì trong tương lai. Quyết định nên phản ánh những gì nhóm của bạn cần để vận hành, không phải sở thích framework.

Ví dụ, hãy tưởng tượng một sản phẩm khách hàng thân thiết nơi thành viên xem phần thưởng trong ứng dụng, sau đó kết nối wallet cho một hành động cụ thể. Chúng tôi sẽ đánh dấu thông tin nào chỉ được hiển thị và hành động nào cần kết nối. Nếu sản phẩm cần trải nghiệm wallet riêng, hãy so sánh yêu cầu với phát triển wallet tiền mã hóa. Khi hành vi hợp đồng hiện có hoặc mới cần được chú ý, phát triển hợp đồng thông minh có thể là một luồng công việc liên quan.

Bốn quyết định chúng tôi giải quyết trước khi code

Trước khi phát triển bắt đầu, chúng tôi biến ý tưởng sản phẩm thành một kế hoạch ngắn gọn. Cả thiết kế và kỹ thuật đều có thể sử dụng kế hoạch đó. Một ghi chú khởi động gồm 3 phần nắm bắt mục tiêu người dùng, hành động ra mắt và các phụ thuộc kỹ thuật.

1. Đặt tên cho hành trình người dùng chính. Chúng tôi xác định tác vụ đầu tiên mà ứng dụng nên hỗ trợ. Sau đó, chúng tôi lập bản đồ các màn hình mà một người cần để hoàn thành nó.
2. Lập bản đồ các kết nối. Chúng tôi liệt kê công việc wallet, blockchain, backend và API cần thiết. Chúng tôi cũng ghi chú các dịch vụ hiện có hoặc tài liệu kỹ thuật mà nhóm có thể cung cấp.
3. Chọn các tính năng cho bản phát hành đầu tiên. Chúng tôi đánh dấu những gì phải có khi ra mắt và những gì có thể theo sau sau đó. Điều này giúp giữ cho bản build đầu tiên tập trung mà không mất đi tầm nhìn về sản phẩm rộng hơn.
4. Thống nhất về các kiểm tra. Chúng tôi xác định cách nhóm sẽ xem xét từng luồng chính. Các kiểm tra bao gồm xác nhận, trạng thái chờ và những gì một người thấy khi một hành động không hoàn thành.

Một bản đồ luồng 1 trang có thể giúp các quyết định này dễ xem xét hơn. Nó giúp trưởng bộ phận sản phẩm và kỹ thuật phát hiện sớm các chi tiết còn thiếu, đồng thời mang lại cho công việc giao diện một con đường rõ ràng. Nếu ứng dụng phụ thuộc vào một token mới, chúng tôi có thể kết nối việc lập kế hoạch với tạo và triển khai token để các giả định của ứng dụng được rõ ràng.

Từ màn hình đầu tiên đến bản build sẵn sàng phát hành

Bản build mang các hành trình người dùng đã thống nhất vào một ứng dụng hoạt động. Sau đó, nó kiểm tra các hành trình đó trước khi chuẩn bị nộp. Đây là cách các phần chính kết hợp với nhau:

Chúng tôi giữ cho thiết kế và kỹ thuật kết nối khi ứng dụng hình thành. Điều đó bao gồm lời nhắc, xác nhận, khoảnh khắc chờ và thông báo lỗi. Mọi người gặp những chi tiết này trong các hành động quan trọng. Nhóm kiểm tra bản phát hành ứng viên dựa trên hành vi đã thống nhất, thay vì chỉ dựa vào đánh giá trực quan vào phút cuối.

Chúng tôi cũng làm rõ ai cung cấp quyền truy cập tài khoản nhà phát triển, văn bản sản phẩm, ảnh chụp màn hình và các đầu vào phát hành khác. Một tính năng dựa trên Telegram có thể phù hợp hơn như một mini app hơn là một ứng dụng di động độc lập. Chúng tôi có thể so sánh nhu cầu đó với phát triển bot Telegram và mini app trước khi nhóm của bạn cam kết với định dạng sai.

Giữ kế hoạch phát hành dựa trên quy tắc cửa hàng

Một kế hoạch phát hành tốt làm cho trách nhiệm và câu hỏi mở trở nên rõ ràng trước bản build cuối cùng. Chúng tôi xem xét các chính sách ứng dụng tiền mã hóa trước khi phát triển. Sau đó, chúng tôi kết nối đánh giá sớm đó với các tính năng, thiết kế và công việc nộp mà nhóm của bạn cần. Nó mang lại cho mọi người cơ hội để đặt câu hỏi trong khi vẫn còn chỗ để thảo luận về luồng sản phẩm.

Chúng tôi cũng thống nhất ai sở hữu tài khoản cửa hàng ứng dụng và quyết định nộp. Chúng tôi làm rõ ai cung cấp chi tiết sản phẩm và ai sẽ xử lý các bước tiếp theo. Trong danh sách kiểm tra khởi động của chúng tôi, Brand Community ghi lại các mục tiêu nền tảng, ưu tiên ra mắt, tài liệu kỹ thuật hiện có và những người có thể phê duyệt công việc. Trong suốt dự án, chúng tôi kiểm tra giao diện và hành trình chính trước khi triển khai tiến triển. Sau đó, chúng tôi xem xét bản build dựa trên cùng hành vi đã thống nhất.

Apple và Google đặt ra các chính sách ứng dụng tiền mã hóa và đưa ra quyết định xem xét; không kết quả nào nằm trong tầm kiểm soát của chúng tôi. Chúng tôi chuẩn bị công việc nộp đã thống nhất, nhưng không thể hứa hẹn phê duyệt.

Để bắt đầu, hãy gửi cho chúng tôi một bản tóm tắt sản phẩm ngắn, nền tảng dự định của bạn và bất kỳ thiết kế hoặc ghi chú kỹ thuật hiện có nào. Hãy cho chúng tôi biết hành động người dùng nào quan trọng nhất khi ra mắt. Chúng tôi sẽ xem xét các tài liệu đó, xác định các quyết định đầu tiên và phác thảo một kế hoạch build thực tế với bạn.

Cách hoạt động

1. Chia sẻ ghi chú sản phẩmGửi mục tiêu, người dùng dự định, kế hoạch nền tảng và bất kỳ thiết kế hoặc tài liệu kỹ thuật hiện có nào. Chỉ ra các hành động quan trọng khi ra mắt.
2. Lập bản đồ ứng dụng và các kết nối của nóChúng tôi phác thảo các hành trình chính, liên kết wallet và blockchain cần thiết, công việc backend hoặc API và các câu hỏi mở.
3. Xem xét giao diệnChúng tôi cùng nhau xem xét các màn hình chính và trạng thái tương tác trước khi phát triển bắt đầu.
4. Xây dựng và kiểm tra các luồng chínhChúng tôi phát triển ứng dụng đã thống nhất và kiểm tra các hành trình chính cũng như tích hợp của nó so với các yêu cầu.
5. Chuẩn bị bàn giao phát hànhChúng tôi tổ chức công việc nộp trong kế hoạch, làm rõ ai cung cấp từng mục và thống nhất về bất kỳ hỗ trợ sau ra mắt nào.