场景中台化助力提升上下游协作效率

—— 大企业工作台场景中台化的思考与实践
文章by UED郭岚馨(澜莘)

一、项目背景 Situation/Task
1 大企业工作台项目体量庞大,业务逻辑十分复杂
阿里巴巴大企业采购简言之是为大企业提供专业的SAAS工具生态+服务生态+市场生态的专业采购平台。其中采购SAAS工具服务,即大企业采购软件,包括但不限于电子询报价、电子竞价、电子招投标、物料管理、请购、审批系统、内部商城、供应商管理、主子账号管理、协议采购、交易金融等采购所需的电子信息化工具。具有专业壁垒高,业务逻辑复杂,工具生态体量庞大,协作角色众多等特点。

而目前我们平台对应的采购工具相对单薄,平台服务大企业的底层工具建设薄弱,远不能满足大企业采购的需要。因此在2017-2018财年,我们将构建全新的互联网采购生态系统,期间将会有几十个甚至成百上千个庞大的、业务逻辑十分复杂的专业工具系统从0到1的孵化并上线。

2 设计、前端、测试资源十分有限
面对业务产品规划蓝图, 成百上千个复杂工具系统将在两年内全新上线,目前大企业工作台的资源配置:需求输入方14人,设计1人,前端13人,后端32人,测试4人,远远不够。其中后台产品交互视觉UX设计师1人对接上下游63人,更是十分紧张。在产品、设计、开发、测试资源都十分有限的情况下,如何高质且高效地快速支撑业务发展需要,让众多复杂专业的后台工具型产品快速孵化,将成为项目组面临的迫在眉睫的命题和挑战。

3 团队倡导中台化思维思考问题和解决问题
各协作方遇到的问题:资源有限,时间紧迫,重复性的工作较多。

1)需求输入方:终于理顺复杂的业务逻辑,却在原型输出细节上耗费大量时间,相似的任务场景输出五花八门,思考时间多,与设计师沟通成本高;

2)设计师:人少活多,业务流程复杂,好不容易消化产品,相似的任务场景却每次要从0到1抠像素地重新绘制;

3)前端:相似的任务场景总重复开发,项目周期长,成就感不大,劳民伤财;

4)测试:相同的逻辑反复测测测,资源消耗大;

二、解决方案 Action—场景中台抽象规范及新协作方式的展开
面对业务的快速发展需要,各协作方的重复工作可通过流程优化提高效率。

因大企业后台80%任务场景具有强规律性、可规范性、高复用性等特点,ued与前端共建,进行了规范约定,将常用的任务场景进行框架层的抽象,包括但不限于其布局、内容、交互、实现,框架下的需求内容可灵活定制,不仅大大减少各协作方对相同场景进行重复性的思考及工程投入,缩短了项目开发时间,而且保证项目有高质量和一致性的产出。

场景中台化后,ued重点则更加聚焦在需求及体验本身,帮助产品把用户体验打磨的更好。

具体开展步骤:STEP1场景分类(识别并归拢);STEP2场景细化;STEP3场景实现;

STEP1:场景分类(识别并归拢)
我们通过大企业云工作台中表单的数据流向,归纳出3种任务场景:

1 数据输入型表单 包括:单表表单,配置表单,头行表单,树状表单,分步表单,导入…

2 数据管理型表单 包括:管理列表—行,管理列表—卡片…

3 数据展示型表单 包括:detail单表结构,detail头行结构,导出,结果展示,错误…

STEP2:场景细化(举例说明)
1 数据输入型表单
单表/配置型表单数据输入
For 前端:页面宽1200px标准尺寸的基础上自适应,横向两端预留20px,纵向标题距顶10px,标题高30px,与Tab区域间距20px,内容行项数(按需定制),标题列120px;若需配置,右侧配置操作区域160px(可选)。

For 需求方:提供案例和模版,需求方可直接基于框架内更换内容,重点关注内容,无需care像素细节。

2 头行输入型
For前端:页面宽1200px标准尺寸的基础上自适应,横向两端预留20px,纵向标题距顶10px,标题30px(内容与左导航保持一致),tab/页面级操作30px,头公共基础信息可一栏或两栏布局,标题列120px,内容列440px。行项列表单行时,高度40px,两行内容时60px,10行,翻页区高度30px, 翻页区域以下为自定义附属信息,各功能模块纵向间距10px。

For 需求方:提供案例和模版,需求方可直接基于框架进行内容更换,重点关注内容,无需care像素细节。

3 数据管理型
For 前端:页面宽1200px标准尺寸的基础上自适应,横向两端预留20px,其他详见规范标注。

For 需求方:提供案例和模版,需求方可直接基于框架内更换内容,重点关注内容,无需care像素细节。

除此之外,为了保证前端顺利代码化,我们根据现有后台内容盘点归纳了常用的表单列宽尺寸,提供了50,80,100,120,180,250px宽可供选择,同时,每一列可设定一栏为主维度信息,主维度信息的列宽自适应(flex),不受以上几种尺寸约束。列宽数量以不激活横向滑动为原则,需要需求侧需求输入时能够有所取舍,将重点项进行展示。

4 树状表单
For 前端:页面宽1200px标准尺寸的基础上自适应,横向两端预留20px。其他详见标注。

For 需求方:提供案例和模版,需求方可直接基于框架内更换内容,重点关注内容,无需care像素细节。

5 大企业工作场景常用关系组件
1)输入input,常用的有Simple Input,Relationship Input,Autocomplete Input,即简单输入,关系联想输入,自动填充输入;

2)选择Select,常用的有Static select,Search select,Dynamic select,即静态选择,带搜索的选择,动态联想选择;

3)日期选择器Date picker,常用的有Single picker,Range picker,单日期选择,区间日期选择等等,诸如此常用的场景化组件,进行归纳规范;

STEP3:场景实现
通过以上任务细化并定义规范后,前端进行代码化的实现。当有相似需求产生时,可复用抽象的框架进行内容替换。

三、效果 Result
原始流程:需求方根据业务发展需要,规划产品,与用户及业务方多轮共建,多轮需求打磨之后进行需求评审;UED接到需求,消化需求,从体验侧进行重新梳理,然后从0绘制,开发从0开发,测试从0写测试用例进行测试,UED进行设计验收。

场景中台化后初步阶段:中台将元件、组件进行标准化,各方约定的组件元件不需要重新定义,反复造轮子。

场景中台化后进阶阶段:当任务场景规范化后,UED在需求阶段“往前站”与业务共创,聚焦体验规划,协助pd产出用户体验佳的产品需求,各方评审,其中可用场景规范的需求,只需根据已代码化的框架进行在线文字内容替换,即可上线。

最初的协作流程优化后各方的投入时间表:

原先的协作流程:假设总共20张页面,总项目时间100小时,每个页面理逻辑加绘制需要消耗5个小时,需求逻辑和体验视角的逻辑关注精力被极大的分散,核心体验链路和页面在均分精力下体验得分可能只有60分。

优化后的协作流程:可复用场景规范化的页面无需再重复耗费人力投入,还是20张页面,其中80%的页面可用规范的场景进行输出,那么总项目时间100小时不变的情况下,只需要核心聚焦在4张核心体验页面上,那么设计师在每张页面的关注时间由5小时变为25小时,有充足的时间挖掘每个页面的体验痛点和创新方案,核心体验链路和页面在聚焦精力下体验得分可上升到90分。

场景中台各方共识开始应用后,UED从画图为主的工作者变成真正的体验思考者,相同时间内,核心体验问题得到更充分的关注,项目整体质量和设计师成就感都会增加。

四、当前进展及未来畅想
1 当前实施情况
我们对目前大企业工作台中场景进行了抽象和归类,优先规范并代码化了单表结构、头行结构、管理结构的表单,规范后的内容对上下游伙伴进行讲解,并在若干项目中进行实践。在初步实践过程中,协作伙伴们遇到的疑虑:

1)需求输入者最大的担忧:会不会增加工作成本?
答:不会。场景中台前期实施时,我们会对目前已有规范进行提前讲解,协助业务伙伴在输入需求前了解规范,并提供提供案例sketch/axure的模版,当需求方有此类结构需求时,直接基于模版进行内容替换,这样绘制demo的环节更加便捷准确。并且设计师在接到需求后,会对需求进一步进行规范上的归拢。 长远来看,当业务伙伴了解并熟悉了模版,有相似需求时直接进行内容替换,减少了需求输入时相似任务场景再思考的成本,也减少了不必要的沟通和设计师归拢再设计的成本。

2)UED:当前需要抽象场景组件,进行规范产出,协助前端代码化,协助需求输入规范化;长远来看,已规范化的场景无需重复设计。

3)前端:当前需要抽象场景组件,进行代码化。长远来看,已规范化的场景无需重复架构开发。

4)测试:设计师还会不会出稿件?
答:会。当前设计师会基于需求稿的基础上进行规范修正,进行最终的统一交付。长远来看,已规范化的场景部分达成共识后,需求输出无需重复测试。

2 接下来场景将会结合业务发展进行丰富和扩展
会继续丰富场景组件,将会新增:管理表单卡片式,步骤渐进式表单,树状表单等。

3 未来畅想
将场景规范代码化后,搭建一个在线需求生成工具,业务方有相似需求时,直接在线进行内容录入,再进行需求评审,根据各方建议进行需求微调,后端开发完成后即可上线。

五、价值总结及反思
场景中台化的协作方法适用于具有强规律性、可规范性、高复用性的业务,通过设计师和前端共建将相似的任务场景(布局、组件、内容等)进行框架抽象,并代码化。然后将规范后的框架在项目组进行讲解,多方达成共识。需求输出时,将变得有章可循,无需浪费相同布局组件重新思考的时间,设计师面对相同的场景无需重新设计,前端无需重新开发,测试无需重复测试。使项目组各个协作成员的效率最大化,将精力回归到需求本身,帮助业务伙伴在相同时间内,将需求打磨的更加合理,体验更加优良,缩短项目整体开发时间,并且有效解决了资源少,重复性可归纳性强的需求体量过于庞大且逻辑十分复杂的客观问题。

场景中台规范化实施后,工作台具有“流水式”统一高效且高质的输出,节约了各方不必要的投入时间,使项目整体提效。但对设计师而言,要始终带着思辨的视角看问题,当遇到新的业务场景时,我们需要反思当前的规范是否合理,有没有更好的体验方式,不断对场景规范进行升级和重塑,以保持思辨和创新的核心竞争力。在项目中,不怕产生问题,办法总比困难多!希望本篇能对面临相同“困境”的同行产生帮助作用。

文章来源:

Author:岚馨(澜莘)
link:http://www.aliued.cn/2018/03/07/场景中台化助力提升上下游协作效率-2.html