如何为具有用户账户的Web应用编写自由职业者简报

如何为具有用户账户的Web应用编写自由职业者简报

一个好的简报在第一天节省时间。一个弱的简报在自由职业者甚至打开线框文件之前就会产生10个后续问题。如果你正在考虑如何为一个具有用户账户的网络应用编写自由职业简报，请从商业问题开始，而不是菜单标签。一个明确的结果胜过三个模糊的愿望。

1. 定义网络应用的目的和商业目标

用一段简单的文字说明网络应用的功能。自由职业者需要知道这是一个客户门户、预订系统、学习仪表板还是订阅产品。目的应该明确用户和结果：“客户登录以跟踪订单”比“一个现代的参与平台”更好。

给出一个具有可衡量终点的商业目标。如果目标是获取潜在客户，就这样说。如果目标是付费注册，也要这样说。这个区别很重要，因为自由职业者会围绕这个目标来设计账户流程、主页和行动号召。

说明成功在实践中是什么样子。例如：“用户可以在3分钟内创建账户、验证电子邮件并完成第一个任务。”这一行告诉自由职业者的信息比一页的普遍热情要多。它还将工作与真实结果联系起来，而不是幻想产品演示。

2. 描述用户类型和账户需求

列出您在第一天预期的每个用户角色。如果可能，保持列表简短：访客、注册用户、管理员、支持代理。如果只有两个角色，就写出这两个。如果有五个，解释原因。每个角色都应该有工作要做和权限边界。

明确注册和登录规则的具体步骤。使用电子邮件和密码？社交登录？魔法链接？双因素认证？说明哪个是必需的，哪个是可选的。如果在访问之前必须进行电子邮件验证，请写明。

权限是许多简报模糊的地方。不要让这种情况发生。自由职业者需要知道一个用户是否可以编辑另一个用户的数据，管理员是否可以暂停账户，以及支持人员是否可以查看账单详情。像“管理员可以编辑所有记录，但支持人员只能查看个人资料状态和最近的工单”这样的句子可以快速消除猜测。

如果您的应用有多种账户类型，请添加一个简单的表格。这使得简报更容易浏览，也更难以误解。

3. 概述核心功能和用户流程

首先列出前5个功能，而不是15个。一个网络应用的第一个版本通常依赖于少数几个操作，因此要清楚地命名这些操作。如果用户必须注册、确认电子邮件、完成个人资料并提交请求，请按顺序写出该序列。自由职业者可以将其转化为屏幕和状态。

描述从第一次访问到重要成功时刻的主要用户流程。例如：登录页面，注册，验证电子邮件，仪表板，创建项目，审核项目，提交项目。如果有密码重置、计划取消或账户删除的特殊路径，请将其作为单独的流程添加。这些“小”流程可能会消耗比主页更多的时间。

不要忘记空状态和失败状态。如果登录失败5次会发生什么？在用户添加任何数据之前，仪表板显示什么？当支付方式被拒绝时会出现什么消息？一个列出这些情况的简要说明将产生更好的网络应用，因为自由职业者不会在尴尬时刻猜测。

一个实用的技巧：把流程写得像是在和一个真实的人在桌子上交谈。“玛丽亚注册，检查她的收件箱，确认她的电子邮件，登录，并上传她的第一个文件。”这一行比“入职旅程”要有用得多。它还迫使你注意到缺失的步骤。

4. 指定设计、内容和品牌要求

设计说明应该具体，而不是诗意的。如果你想要一个宁静的界面，带有大量的空白，请直接说明。如果你想要密集的表格和企业风格的导航，也请说明。包括你已经拥有的任何品牌颜色、字体、徽标文件或视觉规则，并提到哪些内容必须在页面之间保持一致。

列出自由职业者应该设计的页面。一个简单的应用可能需要6或7个页面：登录页面、注册、登录、仪表板、个人资料、设置、管理面板。如果你有法律页面、帮助页面或入职屏幕，请将它们包括在内。否则它们会在最后一周消失，而通常那一周是错误的时间。

内容比许多客户预期的更重要。说明谁来撰写文案，谁提供产品截图，谁提供法律文本。如果自由职业者必须先放置占位文本，请注意最终内容会在稍后到达。如果你已经有3个屏幕的内容，请命名它们。这可以防止意外的重写。

包括你喜欢的2到3个应用示例和1个你不喜欢的示例，并给出每个示例的理由。“我喜欢应用A的仪表板，因为它一目了然地显示状态”是有用的。“我不喜欢应用B，因为它将账户设置隐藏在太多点击之后”也是有用的。自由职业者可以根据这些信息工作。情绪词则不行。

5. 设置技术要求和集成

技术要求应该说明技术栈，如果你有的话。如果你已经需要React、Django、Laravel或其他框架，请说明。如果自由职业者可以选择，请说明选择是开放的，但必须符合你的托管和维护计划。这是模糊简报变得昂贵的地方之一。

列出托管、数据库、文件存储和第三方服务。如果应用必须连接到Stripe、SendGrid、Google Maps、Slack或CRM，请逐一写出每个服务的名称。如果API已经存在，请注明文档链接和版本。如果需要webhooks，请说明什么应该触发它们。自由职业者无法猜测集成的形状并仍然给出准确的估算。

安全期望应该明确。说明你是否需要哈希密码、基于角色的访问、速率限制、审计日志或双因素认证。如果应用处理个人数据，请提及你已知的任何合规要求。有关平台选择和基础设施术语的深入阅读，请参见我们的指南云计算技术，这可以帮助你在不含糊其辞的情况下命名技术栈的各个部分。

兼容性需求也属于这里。说明应用程序是否必须在最新的 2 个版本的 Chrome、Safari 和 Firefox 上运行，或者仅在桌面上，或者也在移动浏览器上。如果可访问性很重要，请说明您期望的级别。这些细节会影响测试时间，而测试时间又会改变报价。

6. 定义交付物、里程碑和审查过程

将工作分成几个阶段。自由职业者应该知道每个步骤交付的内容：发现笔记、线框图、UI 模型、开发版本、测试版本、最终交接。如果您希望在下一个阶段开始之前批准每个阶段，请说明这一点。一个简短的审批链比一堆未完成的资产更容易管理。

给每个里程碑一个具体的输出。例如：“里程碑 1：8 个屏幕的用户流程图和线框图。” “里程碑 2：可点击的原型。” “里程碑 3：登录、仪表板和个人资料的开发版本。” 即使数字稍后发生变化，这种结构也有帮助。像“设计阶段”这样的模糊里程碑会引发争论。

告诉自由职业者反馈是如何工作的。您会将 2 个利益相关者的评论整合到一个文档中吗？修订会在 Figma、项目板还是电子邮件中进行？包含多少轮修订？如果没有人拥有最终批准，项目可能会在按钮颜色或标题标签上停滞数周。

这也是定义交接项目的地方。请求源文件、文档、管理员凭据、部署说明和简短的设置指南。如果你希望自由职业者录制演示，请现在说明。晚了就来不及了。如果你在招聘时也在检查声誉，关于的文章在你签署任何文件之前值得一看。如何安全地雇佣自由职业者在您签署任何文件之前，值得一看。

7. 添加预算、时间表和沟通细节

预算应该是一个范围，而不是秘密。如果你可以花费 $3,000 到 $5,000，就这样说。如果预算是固定的，也要说明。了解范围的自由职业者可以提出合适的工作范围，而不是将太多内容塞入一个狭窄的数字。这可以避免双方的尴尬惊喜。

时间表应包括一个目标发布日期和几个检查点。写下你希望获得初稿的日期、希望开始测试的日期和希望最终交付的日期。如果任何日期依赖于你自己的批准或内容交付，请注明依赖关系。项目可能会因一个简单的原因错过截止日期：有人等待了 9 天以获取品牌文案。

选择一个主要的沟通渠道并坚持使用。Slack、电子邮件或项目板都可以，但混合使用这三者通常会减慢进度。说明你希望多频繁更新：每天、每周两次或在每个里程碑结束时。如果你希望在 24 小时内得到回复，请明确写出，以便没有人需要猜测。

用决策规则结束简报。说明谁可以批准范围变更，谁签署付款，谁拥有最终产品账户。提到如果工作开始后简报发生变化会发生什么。即使一句话也有帮助：“里程碑2之后的任何新功能将单独估算。”这句话保护预算，并保持网络应用朝一个方向发展。

如果您想在发送简报之前进行快速质量检查，请将其与 自由职业市场上的所有标签 进行比较，以查看您的项目描述在自由职业者浏览选项时的样子。然后再读一遍，就像您是自由职业者，而不是买家。如果简报仍然回答了谁、什么、何时和多少钱，那么您就接近了。