← 返回作品

按角色设计移动端 Workflow

02 / 08

多角色移动端 Workflow 体验设计

New Flow 如何在共用的移动端 App 中,为 Coordinator 和 Assignee 设计按角色区分的入口与视图

项目一览

问题 随着 New Flow 在现有 App 中承载更多 Workflow 能力,同一个 Workspace 开始服务不同职责的用户。每个角色都需要从最需要的信息开始工作。

应对 根据权限和 Workspace 角色显示对应视图:Coordinator、Spotlight 或 Gallery。

已上线 团队上线了 Coordinator 和 Assignee 体验,并让三种视图共用一套 Action 内容与操作模式。

按角色设计的移动端 Workflow 体验。
Coordinator 可以查看完整 Workspace,Assignee 则会看到适合当前任务的视图。

背景与问题

一个共用的 App 开始服务不同职责的 Workflow 用户

随着 New Flow 在现有 App 中承载更多 Workflow 能力,同一个 Workspace 开始服务不同职责的用户。问题不再只是如何把流程适配到移动端,而是如何让每个角色从最需要的信息开始工作。

V10 与 New Flow 共用同一个移动端 App。两个版本都以 Workspace 表示完整流程,Action 是其中的一项任务。在 New Flow 中,Coordinator 要查看整个 Workspace,Assignee 则要处理分配给自己的 Action。

因此,设计需要保留共用的 App 以及现有的 Workspace、Action 模型,同时改变用户进入后首先看到的内容。

V10 与 New Flow 的移动端结构对比:共用一个 App,从单一任务路径转向按角色显示不同的 Workspace 视图。
V10 与 New Flow 使用同一个 App,也使用相同的 Workspace 和 Action 概念。New Flow 会根据角色显示不同视图。

研究与协作

移动端设计从已经在 Web 实现的权限模型开始

角色权限规则由产品团队提出,并由产品、设计、工程共同评审。Web 端已经实现了这套模型,因此移动端设计不需要重新定义底层角色和权限。

在开始移动端设计前,Marketing 团队先试用了 Web 端体验。我们以现有的 Web 模型为基础,把按角色进入的规则转译到移动端 App。

已有的 Web 权限模型从 Portal 访问进入 Workspace 列表,再进入 Coordinator 或 Assignee 视图。
现有权限模型把 Portal 访问、Workspace 列表和进入后的角色视图连接起来。

设计策略

把权限模型转成移动端的角色化入口

所有用户都以相同方式进入 Workspace。进入后,Coordinator 看到 Workspace 总览;Assignee 则根据 Workflow Template 权限看到 Spotlight 或 Gallery。

这次调整改变的是用户进入 Workspace 后看到的内容,而不是进入位置。

从以 Workflow 浏览为中心,转向按 Coordinator 和 Assignee 角色组织移动端视图的前后对比。
改版把用户的第一步从浏览 Workflow,转为进入与自身角色匹配的信息和操作路径。

判断 01

根据权限和角色决定首屏

账户分为 Internal Portal 和 Client Portal。Internal Portal 用户在 Workspace 内可以是 Coordinator 或 Assignee,Client Portal 用户则是 Assignee。

进入 Workspace 后,Coordinator 看到 Coordinator 视图。Assignee 看到的任务视图由 Workflow Template 权限决定:线性任务显示 Spotlight;需要查看顺序和上下文时,则显示 Gallery。

Template 权限将线性任务映射到 Spotlight,将复杂 Workflow 映射到 Gallery。
现有 Template 权限决定 Assignee 进入 Spotlight 还是 Gallery,但不会改变 Action 本身。

判断 02

先弄清每个角色最需要什么

Coordinator 要掌握整个 Workspace 的进度,并知道何时需要介入。Assignee 要看懂当前任务,也要清楚下一步如何完成。

Workspace 角色决定用户进入后看到的视图。每个视图都会把任务状态和当前可执行的操作放在一起。

Coordinator 与 Assignee 的目标对应不同的移动端界面优先级。
Coordinator 需要看到全局,才能及时介入。Assignee 需要聚焦当前任务。

最终体验

Coordinator 和 Assignee 进入 Workspace 后会看到什么

最终方案包含一个 Coordinator 视图和两个 Assignee 视图。三种视图使用相同的 Workspace 和 Action 数据,只是根据角色的任务重新安排信息。

Coordinator

Coordinator 先查看 Workspace,再打开单个 Action

Coordinator 视图展示 Workspace 总览。用户可以先查看整体进度和需要关注的任务,再打开单个 Action。

Coordinator 移动端 Workspace 状态总览。
Coordinator 视图展示完整 Workspace,以及其中每个 Action 的状态。
Coordinator Action 卡片展示 Workspace 状态、负责人、依赖、进度和可用操作。
每张 Action 卡片都会显示状态、负责人、依赖、进度和当前可用的操作。

Assignee · Spotlight

专注当前 Action

Spotlight 把当前 Action、状态和可用操作放在同一个页面。Assignee 不需要查看整个 Workspace 时,可以直接在这里完成任务。

Action 状态变化后,Spotlight 会同步更新 Assignee 可以执行的操作。

Assignee · Gallery

先查看 Workspace,再选择 Action

Gallery 展示所有 Action 的顺序和状态。Assignee 可以先确认自己的任务处在流程中的什么位置,再打开需要处理的 Action。

Assignee 可以先查看 Workspace,再打开需要处理的 Action。

复用模式与协作

三种视图共用一套 Action 结构

我为 Action 的内容、状态、负责人和操作定义了统一结构。Coordinator、Spotlight 和 Gallery 只是调整这些内容的排列方式,不需要各做一套组件。

Product 和 Mobile Engineering 一起检查了权限规则、Action 状态和实现限制。设计时也预留了扩展方式,之后 Automation 等 Workflow 对象可以继续使用。

可复用的移动端 Action 模式,展示跨 Workflow 对象共享的组件结构。
这套结构可以用于 Action,也可以继续支持 Automation 等 Workflow 对象。

结果与复盘

共用一个 App,在工作入口区分角色视图

最终设计基于现有权限模型完成评审,并落地到 Coordinator 和 Assignee 视图。New Flow 继续与 V10 共用同一个 App,三种视图共用一套 Action 模式。

证据边界

由于没有任务完成情况或任务耗时数据,本案例不宣称改版提升了效率。

我的复盘

最难的移动端决策,是判断用户进入 Workspace 后,每个角色必须先看到什么。删掉哪些 Web 功能反而是次要的。

按角色显示视图后,Assignee 可以在需要时专注当前任务,也可以回到完整 Workspace 查看上下文。

下一个项目

可扩展的 Automation 系统设计

从句子式规则改为结构化 Automation 配置

查看项目 03 →