更新时间：2026年10月11日

成员邀请需要同时设计管理员和被邀请人的路径：管理员选对项目、对象和角色，收到逐人结果；被邀请人核对身份与加入范围，再接受邀请。邀请已发出不等于成员已加入，过期、撤回、重复邀请和登录账号不匹配也不能统一显示为“失败”。

下面以“北辰项目”的协作应用为例，通过Pixso原型设计连接两端页面。示例设有成员和查看者两种角色，用来讨论界面分工；真实项目的角色能力、有效期和加入条件应先由产品规则确定。

填写对象前，先让加入范围可见

邀请入口常出现在团队或项目设置中。用户打开面板时，标题应说明正在邀请加入哪个范围，例如“邀请加入北辰项目”，而不是只写“邀请成员”。在同时管理多个组织时，这条信息能避免把人加错地方。

角色名称旁边给出与任务有关的简短解释。本例查看者可以阅读项目资料并参与已允许的讨论，成员可以编辑项目内容；是否能再邀请别人不由名称猜测，另按权限定义说明。涉及多个层级的授权关系，可以先阅读设计协作权限的四层结构，再把已确定的规则落到邀请面板。

如果允许一次输入多个邮箱，需要让每个地址成为可单独修改和删除的对象。不要把一整行逗号分隔文本只标一个红框，让管理员不知道究竟哪个地址有问题。默认角色如果对全部人有效，也要保持可见，避免管理员以为是逐人设置。

一次邀请三个人，结果也要分三行

本例使用三条演示地址：li@example.com已经是项目成员，chen@example.com可以发送邀请，wu@格式不完整。点击发送后，每行反馈自己的结果，不用“部分失败”结束整个操作。

技术层收到请求不一定代表对方已经收到邮件，更不代表接受成功。界面应根据能够确认的事实措辞，例如“邀请已创建，等待接受”；只有服务能够提供送达结果时，才将送达作为一个确定状态。

重发邀请前，说明使用的仍是哪位对象、哪个项目和什么角色。如果重发会更新有效期或让旧链接失效，应让相关两端页面按同一规则响应；不要在旧链接中继续显示可接受，提交后才突然换成未知错误。

被邀请人打开链接后，需要知道邀请来自谁、加入哪个项目、将取得什么角色，以及当前使用哪个账号。如果账号与邀请对象不匹配，给出切换账号或按产品规则验证身份的路径，不要直接替对方选择一个账号加入。

在Pixso画布上，左侧放管理员的逐人邀请结果，右侧放被邀者的确认页面。两端都写“北辰项目”和同一个角色名称，再补一个当前账号不匹配的分支，就能发现是否有人在中途失去项目或身份上下文。

尚未登录或需要注册时，完成身份步骤后应回到这份邀请，继续显示原项目和角色。不要把用户送到通用首页，让他重新翻邮件寻找链接。接受完成后可以直接进入项目，并清楚表示已加入；管理员一侧的待接受状态也应更新。

管理员撤回待接受邀请，只影响尚未完成的邀请；移除已加入成员是另一项操作，需要不同的权限和后果说明。两者如果使用同一个“删除”图标，容易让管理员误以为撤回邀请就等于移除了已有成员。

邀请发出后，管理员也可能失去邀请权限，或目标角色被修改。接受时需要以实际有效的规则决定是否允许继续。设计不必暴露后台检查过程，但应有清楚的结果和可继续路径，不能让用户面对一张永远转圈的确认页。

评审可以由一人扮演管理员，另一人从收到链接开始操作。管理员先发送三条邀请，被邀者再用不匹配账号打开，切换后接受，最后管理员回到成员列表。每一段都核对项目名称、角色、账号和状态，尤其注意中断后是否还能回到原任务。

在Pixso中为这两条路径设置各自起点，把发送结果、待接受、账号不匹配和加入成功放在对应分支。画布负责表达业务应用的邀请体验，不替代真实账号系统。若用户是先遇到无权限页面，再主动申请进入，应该使用申请访问与审核反馈的流程，不要把两种起点混成一个万能邀请页面。