dApp开发，从第一次点击就清晰明了

从使用dApp的人开始

一个dApp应在其钱包或合约操作出现之前，就让主要任务易于理解。我们首先梳理用户的目标，然后将每一步连接到应用所需的界面和数据。

初次沟通可以很简单。告诉我们产品面向谁、用户应能做什么、以及已有哪些内容。粗略的草图或几条笔记就足以开始。我们将它们转化为首个版本的共同蓝图，包括需要技术决策的部分。

例如，一个NFT项目可能希望用户浏览藏品并执行链上操作。我们可以将需要连接钱包的部分与对所有人开放的部分分开。如果产品还需要新合约，我们可以将应用计划与智能合约开发协调。关于更广泛的技术图景，Web3开发涵盖了单个dApp之外的相关产品工作。

通过三个清晰的步骤规划构建

一个实用的dApp计划将想法贯穿用户任务、集成和首个版本决策。这三个步骤在开发开始前就让重要选择清晰可见。

1. 描述旅程。 我们列出用户应执行的操作，从打开应用到完成主要任务。我们记录界面需要解释选择或显示响应的位置。
2. 收集连接。 我们审视产品必须与之交互的合约、钱包、网络和现有服务。我们还记录每个界面需要显示的信息。
3. 选择首个版本。 我们商定哪些界面和集成属于初始构建。其他想法可以保留在后续列表中，而不是中途悄悄加入工作。

假设您的团队已有产品草图和合约，但数据视图仍不确定。我们可以标记已确认的部分，列出未解决的问题，并商定哪些必须在实施前得到解答。如果产品需要独立的公开网站，Web3网站和落地页开发可以覆盖该部分，而不会混入应用计划。

钱包和链上数据应在何处交汇？

钱包流程和数据视图应服务于同一用户任务。我们一同规划它们，使用户能理解应用显示的内容以及为何需要连接。

钱包步骤

我们标记需要钱包地址或用户授权操作的时刻。界面应考虑3种基本状态：未连接、已连接和返回应用。我们还商定应用如何解释下一步，而不是让用户在没有上下文的情况下解读钱包提示。

用户可用的数据

当用户需要查找或组织链上记录时，索引值得考虑。我们从界面必须回答的问题开始，然后确定该信息的来源和呈现方式。单个账户视图可能需要与可搜索的活动历史不同的数据处理。

假设一位收藏者回来查看之前的操作。我们可以追溯界面需要哪些信息，并决定现有来源是否足够。请提供您想展示的记录或视图示例。当钱包功能本身是一个更广泛的产品时，加密钱包开发是一个独立选项。

将静默时刻融入设计

想象一位粉丝不多的NFT艺术家，恰逢唯一能回答问题的人休假。一位新成员带着关于藏品的问题和dApp中的操作到来。我们会让下一步在界面中可见，这样产品就不必依赖有人在线来解释。

这种时刻应属于产品审查的一部分，而不仅仅是支持计划。我们审视新用户看到的内容、信息缺失时会发生什么、以及应用在操作后如何响应。然后我们商定哪些状态需要设计和测试。

在构建工作开始前，我们检查：

• 新用户应完成的主要任务。
• 无需连接钱包即可探索的内容。
• 数据仍在加载或不可用时显示的消息。
• 用户提交操作后看到的内容。

这种审查使界面立足于实际使用。它还能帮助您决定哪些内容属于首个版本，哪些可以等待更多反馈。

让工作全程可见直至交付

良好的交付展示了构建的内容、商定的用户流程如何被验证、以及哪些依赖项仍然存在。我们设置两个审查点：一个在实施前，一个在交付前。实施前，我们确认商定的功能。交付前，我们与您一同走查已完成的工作。

在构建过程中，我们对照用户旅程检查计划的前端状态和集成。我们保持未解决问题的可见性，并在新请求改变商定工作之前进行讨论。交付时，我们走查应用、分享实施说明，并确定您的团队可能希望考虑的后续任务。

钱包提供商、网络、合约和数据服务不在我们的控制范围内。它们的可用性、交易处理、更新和兼容性可能发生变化，因此我们验证商定的应用行为，但不保证这些外部系统将如何运行。

要开始，请将您的产品说明、界面草稿、可用的合约详情以及用户需要的数据示例发送给我们。Brand Community将与您一同审视它们，澄清未解决的问题，并制定一个您可以明确决策的首个版本计划。

如何操作

1. 分享产品图景告诉我们dApp服务于谁、用户需要做什么、以及您已有哪些内容。
2. 梳理连接我们审视支持这些任务的钱包、合约、网络和数据需求。
3. 商定首个版本我们决定哪些功能属于构建范围，以及交付应涵盖哪些内容。
4. 构建并验证流程我们实施商定的工作，并对照用户旅程进行审查。
5. 走查交付我们向您展示已完成的工作、分享说明并确定剩余的依赖项。