官网售后入口由负责人审批，市场部改文案，开发人员做表单。上线后，合作服务点却说自己收不到请求，资料维护者也不知道新说明由谁更新。审批名单齐全，参与服务的人仍然漏了。
利益相关者分析图把与项目有关的人、组织和关系画出来，帮助团队安排研究与沟通。初稿可以来自现有知识和推测，真实关系要继续核实，项目变化后也要更新。
每张角色卡，都写一个与项目有关的理由
以设备企业改造在线售后入口为假设示例。客户想知道怎样获得支持，现场技术人员需要足够资料，合作网点承担线下处理，内容人员维护说明，系统管理员管理访问，负责人决定范围和资源。
不要只照职位表抄名字。让团队成员先独立列角色，并写“为什么与此项目有关”，再共同补充使用者、受益者、执行维护者、有决定权的人，以及可能受不利影响或形成阻力的人。
同一部门也可能有不同角色。销售主管看资源，一线销售接咨询；客户组织里，采购与实际使用者的目标也不同。合并之前检查任务，别让一个部门名称覆盖这些差别。
低频客户、使用辅助技术的人或可能被新入口排除的人，同样值得检查。识别受到影响的群体，是为了理解影响，不是给人贴“难配合”的标签。
线条要告诉大家，谁向谁提供什么
中心与外围、关系网络、分组图都可以采用，没有固定画法。先确定图例，说明距离、颜色和线条的含义。例如靠近中心表示直接参与，不能一会儿又代表权力更大。
把“客户—服务人员”之间的关系写成提交问题、补充资料、收到回复。合作网点与平台之间写清谁分配、怎样接收、处理后如何回传。只有一条线，无法让团队决定要找谁核实。
| 关系 | 本例要确认的事情 |
|---|---|
| 客户提交问题给平台 | 提供哪些信息，怎样知道已被接收 |
| 平台将请求交给网点 | 当前渠道、责任人与交接条件 |
| 技术人员使用产品资料 | 谁维护，哪些内容需要核验 |
| 负责人批准新入口 | 范围、资源与未决定的业务规则 |
地图内部保存必要信息并按约定共享。公开展示用角色称呼即可，无需暴露真实姓名、联系方式或敏感关系。
把不确定的线，变成要问的问题
“网点能直接收到官网请求”可能只是理想流程。把这条线标为待核实，找实际网点人员说明当前做法，或沿一条授权请求记录走一次。
如果发现平台目前用电话转达，地图就应体现电话交接与遗漏风险。若准备增加系统通知，再标成候选关系，让技术和业务评估。当前事实和未来设计混画，会让页面提前承诺尚不存在的能力。
核实也可能带来新角色。例如请求需要经销商确认范围，就补上经销商，并调整沟通计划。图形不够整齐没有关系，漏掉真实接手的人才会影响方案。
保留版本、日期和适用范围。渠道改变、职责调整、产品扩展，都可能使原来的关系失效。地图应跟着这些变化更新。
按问题邀请人，不让所有人参加所有会议
角色识别完成后，为每位主要参与者写清要了解什么、何时参与。例如客户核对支持任务，技术人员检查输入资料，维护者确定更新方式，网点确认交接渠道。
负责人希望表单尽量短，技术人员可能认为某份资料不可少。地图帮助找到双方和关系，真正的取舍仍要检查任务与工作要求。也许资料可稍后补，也许首次提交必须有，不能仅按职位高低解决。
若信息交换难以想象，可以用商业折纸摆出一次交接。角色图说明谁有关，实体模拟让团队看到请求怎样走过这些人。
成功标志是地图使团队发现此前遗漏的关键角色，并安排了具体核实或参与任务。后来加入的人也能通过图例和关系说明，知道为什么要向这个人了解这件事。
地图给出了入口，需求还要继续听
交付角色说明、图例、已核实关系、未知项和行动计划。“保持联系”太泛，改成“向网点核对请求接收和回传方式”，才有可执行的沟通目的。
图不能证明每个人的需求，也不能让冲突自动消失。还要听真实意见、观察任务、评估方案影响。影响力较弱的使用者若遇到严重困难，同样值得纳入设计。
售后入口改版因此能从“谁签字”走向“谁使用、谁接手、谁维护”。这几类关系清楚，团队才更容易判断页面应承诺什么。
把参与关系落实到官网与界面
58UI提供企业官网设计开发、UI/UX与品牌视觉设计，可在需求梳理中将角色任务、内容责任和交接关系转成页面结构与原型。实际组织职责和服务规则，需要项目团队共同确认。
你可以从设计与开发服务和官网与界面案例了解相关范围。通过沟通具体设计问题提供使用者、维护者和关键交接，能帮助设计讨论找到应当参与的人。
相关服务
