按角色设计移动端 Workflow
02 / 08多角色移动端 Workflow 体验设计
New Flow 如何在共用的移动端 App 中,为 Coordinator 和 Assignee 设计按角色区分的入口与视图
项目一览
问题 随着 New Flow 在现有 App 中承载更多 Workflow 能力,同一个 Workspace 开始服务不同职责的用户。每个角色都需要从最需要的信息开始工作。
应对 根据权限和 Workspace 角色显示对应视图:Coordinator、Spotlight 或 Gallery。
已上线 团队上线了 Coordinator 和 Assignee 体验,并让三种视图共用一套 Action 内容与操作模式。
背景与问题
一个共用的 App 开始服务不同职责的 Workflow 用户
随着 New Flow 在现有 App 中承载更多 Workflow 能力,同一个 Workspace 开始服务不同职责的用户。问题不再只是如何把流程适配到移动端,而是如何让每个角色从最需要的信息开始工作。
V10 与 New Flow 共用同一个移动端 App。两个版本都以 Workspace 表示完整流程,Action 是其中的一项任务。在 New Flow 中,Coordinator 要查看整个 Workspace,Assignee 则要处理分配给自己的 Action。
因此,设计需要保留共用的 App 以及现有的 Workspace、Action 模型,同时改变用户进入后首先看到的内容。
研究与协作
移动端设计从已经在 Web 实现的权限模型开始
角色权限规则由产品团队提出,并由产品、设计、工程共同评审。Web 端已经实现了这套模型,因此移动端设计不需要重新定义底层角色和权限。
在开始移动端设计前,Marketing 团队先试用了 Web 端体验。我们以现有的 Web 模型为基础,把按角色进入的规则转译到移动端 App。
设计策略
把权限模型转成移动端的角色化入口
所有用户都以相同方式进入 Workspace。进入后,Coordinator 看到 Workspace 总览;Assignee 则根据 Workflow Template 权限看到 Spotlight 或 Gallery。
这次调整改变的是用户进入 Workspace 后看到的内容,而不是进入位置。
判断 01
根据权限和角色决定首屏
账户分为 Internal Portal 和 Client Portal。Internal Portal 用户在 Workspace 内可以是 Coordinator 或 Assignee,Client Portal 用户则是 Assignee。
进入 Workspace 后,Coordinator 看到 Coordinator 视图。Assignee 看到的任务视图由 Workflow Template 权限决定:线性任务显示 Spotlight;需要查看顺序和上下文时,则显示 Gallery。
判断 02
先弄清每个角色最需要什么
Coordinator 要掌握整个 Workspace 的进度,并知道何时需要介入。Assignee 要看懂当前任务,也要清楚下一步如何完成。
Workspace 角色决定用户进入后看到的视图。每个视图都会把任务状态和当前可执行的操作放在一起。
最终体验
Coordinator 和 Assignee 进入 Workspace 后会看到什么
最终方案包含一个 Coordinator 视图和两个 Assignee 视图。三种视图使用相同的 Workspace 和 Action 数据,只是根据角色的任务重新安排信息。
Coordinator
Coordinator 先查看 Workspace,再打开单个 Action
Coordinator 视图展示 Workspace 总览。用户可以先查看整体进度和需要关注的任务,再打开单个 Action。
Assignee · Spotlight
专注当前 Action
Spotlight 把当前 Action、状态和可用操作放在同一个页面。Assignee 不需要查看整个 Workspace 时,可以直接在这里完成任务。
Assignee · Gallery
先查看 Workspace,再选择 Action
Gallery 展示所有 Action 的顺序和状态。Assignee 可以先确认自己的任务处在流程中的什么位置,再打开需要处理的 Action。
复用模式与协作
三种视图共用一套 Action 结构
我为 Action 的内容、状态、负责人和操作定义了统一结构。Coordinator、Spotlight 和 Gallery 只是调整这些内容的排列方式,不需要各做一套组件。
Product 和 Mobile Engineering 一起检查了权限规则、Action 状态和实现限制。设计时也预留了扩展方式,之后 Automation 等 Workflow 对象可以继续使用。
结果与复盘
共用一个 App,在工作入口区分角色视图
最终设计基于现有权限模型完成评审,并落地到 Coordinator 和 Assignee 视图。New Flow 继续与 V10 共用同一个 App,三种视图共用一套 Action 模式。
证据边界
由于没有任务完成情况或任务耗时数据,本案例不宣称改版提升了效率。
我的复盘
最难的移动端决策,是判断用户进入 Workspace 后,每个角色必须先看到什么。删掉哪些 Web 功能反而是次要的。
按角色显示视图后,Assignee 可以在需要时专注当前任务,也可以回到完整 Workspace 查看上下文。
下一个项目