工作台模块杂谈

早年在设计中后台产品时，我的精力都模块本身的结构上，以模块的扩展性为目标而努力。但就算是内部或者底层产品也不是一味的模块罗列，我在扩展性的基础上也开始考虑实际人员的效率问题。

起初，主要是依靠一些关联的操作来减少模块间的跳转。后来就开始尝试主动引导相关人员的工作，开始搭建中后台最常见模块之一：工作台

工作台往往当作登录后的首页，下面是我随便从花瓣找的两张图

图1

图2

大家可以看到页面的组成区别还是比较大的，因为其承载的价值和展示会根据岗位属性不同有所区别，管理属性为主就会趋向于数据展示，执行层为主则会趋向于连接任务。下面就大概讲讲我个人的设计步骤：

1.制作任务清单

大多数模块都是以流程为中心设计，而工作台是以人为中心设计。与相关用户沟通并熟悉他们的一天的工作情况，沟通需要获取的信息有以下几个方面：

①用户都需要处理什么任务

②每种任务的时效要求、数量大小、具体流程（主要是看复杂程度）、关联任务

③用户处理任务的顺序习惯

（P.S 管理层看每日数据对于他来说其实也是一种任务）

然后大概获得这样一个任务清单表

如果不能与实际用户交流也可以尝试和竞品的销售交流，或者从运营数据中提取相关数据

2.连接任务相关设计

根据表中的角色和任务进行汇总，然后尝试根据同一角色建立一个每日工作模型

①先假想存在一个工作台模块，每完成一次任务都会回到这个模块，然后通过一个入口再进行下一次任务

②构建模块区域。根据任务关联性，把任务入口组织起来，比如订单处理放在一组，财务处理放在一组

③选择展示形式。作为入口一般都是需执行的数量合计数，偶尔需要快速处理的部分也会使用详情展示，直接在工作台处理

3.数据展示相关设计

我们都知道给管理者展示公司大盘数据，给财务主管展示现金流、负债等数据

数据展示并不是只是为了给一个数字，关键在于能不能说明数据的“问题”（这里的问题并不一定是坏事情），举几个例子：

①现金流低于财务设置警戒线是个问题

②日订单数量增长趋势增高或降低

③当前订单年完成比和预测值差异较大

想发现问题就需要有一个标准或者预期，只有建立了标准才能知道的偏差

4.组织已有模块

最后一步的目的是为了看模块间有没有通用性，可以关联账户权限系统一块进行设计，这样可以降低一些开发成本

P.S 如果你接手的是个内部系统，梳理各部门工作是件很有意思的事情，因为你可以看到整个公司内人、公司、系统三者间错综复杂的关系。如果你又恰好有兴趣梳理它，有可能会提高公司整体的运作效益