业务数字化平台项目总结
这是最近完成的一个B端项目，总结一下其中遇到了一些难题是如何解决，复杂需求是如何进行方案设计的以及设计方法原则的提炼。
前言
最近共负责了两个B端项目的交互设计，一个是滴滴的管理平台，一个是软通的业务数字化平台，大致比较相似，就对其中一个进行了总结。也是对B端项目设计方法的总结和提炼。B端项目需要设计师深刻的了解业务需求，用户习惯，以及真实的业务场景，这点很重要。从而提炼需求，总结分类，知道设计的目的，形成设计方案。一般而言B端项目角色众多，设计时稍有不慎会考虑不全面，导致各角色之间页面或流程造成冲突，而且设计时有很多的制约条件，局限性，所以要真正的了解业务才能在众多制约条件中设计出最佳的方案。
HTS业务数字化平台主要是为了解决公司复杂的线下业务流程，造成工作效率不高的问题，也是对业务数据的统计分析，使管理者能够更清晰快速的了解公司情况。下面是对该项目的一些个别问题进行的总结和分享。
一、首页
目前HTS业务数字化平台角色有8种：系统管理员，实施，销售，招聘顾问，招聘负责人，销售负责人，部门负责人，商务。首页设计统一中加定制，共有的部分为统一设计的，不同的部分为角色定制的。
这样的设计也有问题：因为在刚开始做这个平台的时候，需求收集的很少，当时只有需求管理，和面试管理这一部分，主要为招聘模块的，领导希望能够为每位角色专门设计首页。但是在后期，一个一个需求增加，角色也开始增加，而且角色的权限范围总是会做调整，导致首页改动较多。
建议：首页统一做成共有模板，都一样。如果想要看一些角色关注的数据可以新建工作台将定制每个角色的模块，可以不断增加。
|
实施销售首页 |
二、需求管理
实施销售申请需求——招聘负责人接收需求——招聘负责人分配需求——招聘顾问上传简历进行跟踪
2.1需求申请的字段太多，怎么提高填写效率？
（1）首先将字段分类，分为需求信息，基本要求，面试官信息，岗位信息，任职要求，几个部分，可以清晰的了解大概内容；
（2）其次建立模板如下图，可以将重复性高的需求建立模板，比如招聘Java开发，某个公司的模板每次都差不多，就可以建立一个模板，每次需要的时候使用模板修改一下就可以了。
需求模板
（3）凡是可以选择的不要填写，凡是可以自动获取的就获取，凡是可以给出默认项的就给默认项，怎么减少操作怎么来。
表单填写页面一切为了节省时间提高填写效率而努力，相似表单分类，需选择的默认一般选项；
点击项目带出客户名称与部门，减少选择项，填写工作地点带出面试地点，对于填写过的面试官等信息下次填写可以给出之前的填写内容供选择。
2.2需求申请中招聘团队的选择问题
在需求申请的时候选择招聘团队是一个比较麻烦的事，这个需求进行了多次改动。
一个问题是招聘团队在最初的没有细分区域的，也就是说你可以选择一个华南的招聘也可以选择华北的招聘组成一个团队，这样会有一个问题的，招聘负责人没法界定，因为选择了招聘后是要招聘负责人来接收需求的，然后可以多次分配给不同的招聘顾问。所以在实际实施时会非常麻烦。
解决方法：我们单独创建一个团队管理的功能，在这里招聘负责人可以创建招聘小组和招聘团队，招聘小组是专门针对某个客户的，在创建的时候一个客户会匹配一个招聘小组，而团队是不指定客户的。这样以来，在需求创建的时候如果确定了是某个客户那么就会默认某个招聘小组，不用选择，如果某个客户没有指定小组，那么他可以在众多团队中选择一个作为本次招聘负责的团队。如下图：
招聘团队创建
2.3需求接收与分配
需求接收是招聘负责人的功能，招聘负责人主要先接收来着各个实施销售发来的需求，接收后分配给他的下属，同时也要关注每个需求的进度问题，以便做出调整
交互细节：（1）当点击需求接收按钮自动弹出需求接收成功，您可以分配需求了，引导用户去进行需求分配，点击“去分配需求”按钮则弹出招聘顾问名单，以及每个招聘顾问目前手里有多少个需求，以便招聘负责人可以知道谁现在需求少，可以把这个需求给他，进行一个判断。
接收成功
进行需求分配
三、面试管理
3.1面试管理流程
面试管理是包括了面试到到岗的所有过程。如下图所示：从简历上传——面试安排——面试预约——面试反馈——报价申请——报价确认——到岗反馈。
面试流程图
3.2怎样衔接简历筛选和面试安排达到简化的目的？
这两个部分是实施或销售来操作的，实施在筛选了简历后就要填写面试安排的时间，但是这两步其实的分开为两个菜单的。第一版是简历通过后再去面试安排里面填写过于繁琐，所以，要在中间做一个衔接，面试安排的肯定是简历通过的，那么可以当简历通过的时候直接给出面试安排的弹框进行面试安排。
简历通过弹框
如果想去面试安排，就点击面试安排则弹出面试安排弹框，可直接安排。便可以省去专门到面试安排页面再去找到这个候选人进行安排。
3.3怎样减少操作？
（1）在面试管理里面，把所有的操作按钮在列表页也放置了一份，可以在列表上直接操作，无需点击进入详情页。
简历筛选列表
（2）面试安排弹框里，面试时间的填写，由最初的选择三个时间段，直接改为下拉选项：尽快安排，本周，下周，这样的字样。
最开始是选择几点到几点这样的时间段，但是面试官这里的选择其实并没有太大作用，因为发给招聘顾问后招聘顾问还要跟候选人预约，预约后会和面试官联系，最后确定一个具体的时间写在上面，这样就走下一个流程。
所以在面试官这里的面试时间选择改为简单的选择一个大致时间即可。
面试安排
3.4简历进展怎么展示？
简历进展是记录该候选人的简历走向的所有信息。
这个设计要灵活，而且再屏幕大小改变的情况下能够完美的自适应，所以采取时间轴的方式，既美观又直观。比起表格一行一行展示的好。
简历进展
四、入离场管理
4.1入场步骤
招聘顾问发起入场申请——销售补充人员费用部门信息——实施填写入场通知人员邮箱并发送通知
（华北地区）招聘顾问发起入场申请——销售补充人员费用部门信息——销售填写入场通知人员邮箱并发送通知
4.2针对一个申请三个人填写如何设计？
需求是华北地区的销售完成后两步的操作，其他地区则分三步走，但是当开发实现的过程中发现销售并没有地区的标识，他们销售只是在私下分配每个人去负责某个地区的业务。解决：所以在实际操作的部分第二步和第三步就只能放开销售是可以都操作的，可以可以选择实施交由实施完成第三步。
虽然一个入场通知需要走三个人的步骤，但是后面操作的又可以修改之前填写的内容，这样的流程填写页面交互要怎么设计。
解决方式：申请页面做成3个tab页面，按顺序排列，可以点击tab显示出不同角色填写的字段，但是不同于以往步骤条显示的页面，步骤条显示页面说填第二步就是第二步，其他的两步是点击不了的。我们则要做的更灵活性。但是在不同的角色提交的时候会选择下级填写人。
入场填写表单
4.3入离场通知怎样能够更简便？
1、目的
入离场通知只要是方便业务人员发送通知，减少工作量。在设计的时候要考虑到如何能让他们更简便。
2、方法
（1）第一在发送通知的地方我们可以获取发送通知必须主送和抄送的邮箱，其他邮箱如果填写过一次，下次过来则可直接选择；
（2）第二检测发送状态，如果发送失败了则可以重新发送；
（3）第三下载附件，保留每个员工的附件信息因为在发送通知的时候是需要直接携带这几个附件的，发送人也可以下载；
（4）第四设置自测功能，这是为了发送人在发送之前可以先发送给直接看一下是否错误，再发送
五、福利管理
5.1角色多问题
参与福利流程的太多角色参与到这些流程里面：招聘顾问，招聘负责人，实施，BU商务，BU OM，BU Head，BD OM,BD商务，BD OM负责人，BD Head。
5.2审批流程多样
每个福利的审批流程又有差别所以又不能完全复用
5.3线下业务放到线上出现问题
福利的审批之前都是线下进行，业务人员用Excel统计每个部门的数据，一级一级提交，到BD OM福利团队后进行汇总。
汇总也是把所有的数据合并到一张Excel里面，所以就会造成每级合并的时候有数据遗漏，需求反复确认，而且每个人都可以修改，但是线上的话提交的时是什么样子如果不驳回修改，是不会变的
5.4流程中有并行流程
流程到BU OM时就会同时进行三个流程并行，其中有一个分支驳回就回到起点，全部通过再汇总到一个点进行接下来的审批
5.5流程变动多次
审批流程多次变动，因为之前的灵活性过大，也没有统一的规则，再加上华北东北，华南华东，地区审批流程又不太一样，造成了这块需求变动较大
举例说明：
以加班奖金为例，最早的流程过于复杂，多个角色在流程中审批两次，但是修改了流程后，依然有角色需要审批两次，
比如BU OM和实施最后需要他们再次确认，在线下来说因为是Excel复制的所以可能会造成遗漏错填的情况，但是线上来说提交后是不会修改的，所以不能有这个问题，但是业务还是坚持要保留这两个的确认，去掉了一些多次操作的流程。
福利流程变更多次，下图是之前的流程.后来简化为5步就可以了。
最初流程
5.6福利申请的时候到底以什么维度？
最初实施在申请一个员工的福利就会生成一条，但是线上来说申请一条点了提交就会到下级审批人那里，这样会造成数据量过多，而且部门负责人那里根本不会关注是哪个员工用了多少钱，所以考虑的这里可以每次以某种维度提交：这里有两种方式
（1）实施维度
实施每次申请后生成一条数据，显示申请人，福利金额，申请人数，等
（2）项目维度
实施申请的时候按照项目来添加需要申请的员工，提交后在其他人那里显示一个项目申请的情况，点击进去可以看到每个员工的具体详情
最后决定采取第二种方案：项目维度
原因：考虑到软通的业务场景，在软通每个实施不止有一个项目的，所以如果实施申请的时候并不能锁定到他申请的是什么项目，如果所有项目混在一起对于后面福利部门的统计也不方便。
5.7 BU 层面BD层面的汇总不一样，BD里面包含多个BU，BU里面包含多个实施
BU层面每个BU OM都会收到来自本BU的实施发来的不同项目的福利申请，当审核通过后，我们的系统需要自动按照不同的BU整合成一条数据发送到BD层面，BD层的领导需要关注的是每个BU需要多少钱。
5.8审批的时候以什么维度为单位的审批？
（1）首先排除以员工为单位的审批，因为人数众多，不可能只打回去一两个人再等，实施提交的也是以项目为单位的，所以在BU层面如果某个员工有问题会将整个项目打回去
（2）到了BD层面是以BU为维度的，将整个BU打回去的话会有很多项目都重新回到实施那里，又有重新走流程，所以会造成不必要的麻烦，所以在BD层面可以以项目为单位驳回。
5.9线下线上业务场景不一样
1、业务场景
一般的业务场景是BU OM会将整个BU的项目都汇集后才会递交到BU head那里去审批，但是我们线上如果你对某个项目审批通过就会自动到下级审批人那里，而且有些项目还没有提交的情况，就会造成领导多次审批。
2、解决这个问题的方法
在每个审批人这里设置一个节点，因为每次申请福利都是有一定的时间来提交的，所以首先在BUOM这里是需要所有的项目都到齐了进行统一审批的，如果对其中某个项目进行驳回，那么则需要等该项目修改后再次提交到这里，最后统一审批通过，不能针对单独的项目进行审批通过。
以此类推，所有的审批人都是可以批量进行审批通过，单个驳回后需要等到再次提交到这里才可以一起审批通过。这样的话就可以以完整的数据进行推进。
六、发现与改进
做原型的时候考虑的不是太全面，总结发现有以下几种原因：
6.1需求不清晰问题
项目需求一直不太完善，改动较多，前期需求很简单，导致在分析需求做原型的时候有些问题根本没想到。
这些在项目初期很容易遇到，本身对业务的不熟悉造成对问题的考虑也不全面。
6.2方案局限性问题
对于复杂的需求，有时候可以有多种方案，但是有些方案是对前后端技术实现有局限的。所以，有可能在不知的情况下设计出过于复杂技术的原型。
总结方法：在以后的设计中对于复杂的需求，要跟前后台讨论一下实现的方式，怎样可以用最简单的方式，设计出最优的交互设计。当然有些方案如果体验好，技术复杂，就要另当别论，这个需要看项目进度情况，以及实现优先级来考虑。
6.3业务不熟练问题
业务场景了解不深刻，对于过多繁琐的操作，很多都来源于对业务场景不熟悉，或者自以为的都需要，最后发现其实并不在乎一些数据，也就没有必要设计成这样。
比如实施在配置员工工时的时候，因为一个员工可能一个参与到多个项目中，工资则是需要根据在每个项目的工时来计算工资的。
最初按照常规的方式：实施进来选择员工——选择项目——弹出日历表——选择几号——新增一条——重复选择项目。。。以此类推，如下图（时间配置）。
这样的我们系统就会算出这个员工在各个项目具体哪天的工时，以及使用成本，但是按照这样做下去会有一个不方便的操作，就是要修改时间的时候，因为日历是如果选择过的日期，到下一个项目是选不了的。
所以如果你想添加几天在某个项目的时候必须要保证这几天还没选，如果被其他项目选了就要先去这个项目删掉这几天才行。这对操作者而言会很麻烦，在我们询问了实施后了解到他们在配置工时的时候这种情况是很多的，而且他们并不关注这个员工具体几月几号在哪个项目，他们关注的时候使用成本，是几天，其他都无所谓。
最初的项目时间选择
改进：
所以针对这一需求，我们将日历去掉，在配置的时候系统会算出这个月需要配置的天数总和，然后让实施自己输入某个项目工时是多少，最终只要保证工时不能超过本应配置的天数就行。在修改的时候也会方便很多。
针对这个想法，对这个页面再进行优化，发现其实可以直接配置项目然后点添加，增加一条项目后，直接在表格里输入天数，点击完成即可，这样，页面看上去也没有那么拥挤。
所以在B端的设计上，特别是我们这种CRM系统，就要了解业务场景，以及理解全链路业务，你才能发现痛点，才能分清主次，最终目的都是让使用者工作效率更高，更快，更方便。
6.4多部门多角色的合并问题
针对一个人拥有多个部门，或者多重角色的的情况，项目开始定位可切换部门，切换角色，这样菜单内容数据都是按照部门和角色来展示的，但是在项目已经做了一年了的时候老板觉得要合并起来，就是这个人的的页面把他所有可以操作的数据都展示出来，这样就造成了，很多有重合的数据展示不是在好，还有每个角色都有的菜单一样但是内容是不同角色的内容，就出现问题。
比如需求管理，销售，实施，招聘负责人，招聘，都有我的需求菜单，但是招聘负责人我的需求主要是接收需求的，招聘顾问我的需求是分配给自己的需要进行简历上传的，实施销售是需求申请的。
后来有几个招聘负责人需要给他招聘顾问的功能，又要给他销售的功能，，，，合并后就会有三个我的需求，但是内容不一样，所以合并后这些菜单要改名字，比如改成需求申请，需求接收，需求上传简历，这样就可以共存
单独分开做的时候就设计范围较大，当全部合并在一起就是适合，匹配，不冲突，需要更多的不干扰，设计局限性更大。
6.5部门负责人与下属数据混合问题
有些部门负责人，既可以操作自己的数据，又可以查看其它人的数据，所以在他的列表里面数据很多，有自己的又有其它人的，比如需求申请里面，但是能操作的只能是自己的，这样会造成不好识别
所以要把自己的和别人的要分开展示，即我可操作的待办的放在一起，查询的放在一起，单独做一个需求查询页面，让每个角色都可以查询，只不过查询范围因人而异。
部分页面展示
七、设计原则提炼
在设计b端项目更多是提供基于用户需求的解决方案。用设计的方式，运用视觉的效果和交互的原则来达到解决实际问题的目的。
7.1遵循简约设计四原则“删除，组织，隐藏，转移”
B项目的信息呈现较为复杂，信息有主次，层级的划分，如果毫无规则摆放会让用户找不到重点，眼神来回的跳。所以在拿到需求的情况下要注意以下几点；
1、首先要将信息组织起来，分类，分块，要考虑用户想要做什么，如何设计流程展开方案
2、把不必要的信息删除，必要但不重要的信息隐藏，少用强调，或者重复强调，要减少视觉混乱，注重分层概念有一个清晰的对比
7.2组件化设计和一致性设计
相同的逻辑设计操作流程要一致性，比如按钮的操作，弹出方式等一致性，这样的目的是可以减少用户的学习成本，更方便更高效。我们的组件全部采用的是elment ui组件，这样会更统一开发更快。
7.3共性与特性设计
对于多种角色的设计，进行用户研究，分析业务逻辑后，进行分类共同点，做通用设计方案，再分析每个角色的特性，做定制化设计，这样可以避免多种角色页面差异过大，也避免给开发造成麻烦。
7.4提高效率，简化操作流程
对网站的优化部分，要确保80%的业务操作过程不能超过3个步骤，要将过程简化更简化，提高效率。
7.5视觉效果
视觉设计也是用户体验的一大重要因素，有些解决方案是可以利用视觉设计来解决问题的。颜色主色调搭配辅色，布局合理，页面设计遵循设计规范，比如靠近原则，对比原则，网格原则，对齐原则等这样设计出来的页面更有观赏性也可以帮助用户理解。
八、总结
8.1 UI与UX的配合
好的UX，UI设计相辅相成，缺一不可，才能提升用户体验的愉悦感。怎样用最简单的流程，最少的步骤，最优的方式解决问题，提高用户的使用感，这是UX设计要考虑的问题；怎样用好点线面颜色，设计出更加友好的界面，这是UI设计的问题。
但是一切都是围绕着能有一个好的用户体验为目标，让用户在使用网站的时候能够更快找到自己的需求点，更快完成自己的业务流程，同时又能够开心愉悦的使用网站。这是设计的目标和原则。
8.2 B端产品要深入的了解业务，做全链路设计
TO B产品大多专业门槛高，客户少但角色众多，没有成熟的方法论指导，竞品少没有足够的数据支撑，这些都导致产品的设计难度加大。特别是有些需求，局限性大，操作流程复杂，更加大了设计的难度。
在项目初期需求只是一个概念的时候接触项目，到目前的项目上线，中间需求变动不知多少次，很多需求都是一起边收集边设计，再补充，再修改。我也学到了很多经验和方法。
对于B端产品一定要深入的了解业务，了解业务场景，如果对业务没有系统的认知，在和产品，开发等工作伙伴对接会增加成本，在需求的讨论上也会花费很多的时间，所以在设计的时候就要多问，多想，多看，多总结。你会发现不同的业务场景，所适合的设计方案也是不一样的，关注点也是不一样的。
8.3对于用户的调研，永远都不嫌多
在做设计的时候，我发现永远了解的都不够全面。对于用户的调研不是一蹴而就的，需要长期慢慢的挖掘才行。
在项目一开始需求的功能点是老板提出，说想要做一款业务平台，将能处理集团的大部分业务，简化工作流程。最初了解的是招聘这一模块，了解到平时招聘团队的工作业绩是每个人要用Excel记录后发给领导的，每周一发，但是作为部门负责人来说，每天看一堆Excel是很费时间的事，而且没有直观的统计结果。所以我们在一开始就是从需求，招聘入手，统计各类数据，将线下业务操作，放到线上，实时更新。
中间项目开发时间，我们对产品的使用角色都进行了需求收集，但是这些收集大多是，很笼统的，他们只会告诉你我需要什么，或者工作中遇到的不方便的业务是什么。比如他会告诉你我想要一个项目人员配置，但是他们不会说这个项目人员配置主要是为了让客户发工资的时候好计算，还得可以修改，而且他们并不关注具体配置哪几天，只关注这个月在某个项目出勤了几天。
当你设计原型的时候，你会想为什么要这样做？为了解决什么问题，用户在什么场景下需要这个操作，为了达到什么样的目的。这很关键，你会发现你对用户的了解永远不够，在沟通和表达中有些信息就会被误会。
所以，在什么时候都要问what（是什么），why（为什么），who（谁），when（何时） ，where（何地），how（怎么做），how much（多少）！这样才能趋近于完美。
8.4想清楚再动手
做设计的时候，一定要想清楚再动手，这样会事半功倍。
我一般在接到一个新的需求的时候，如果逻辑比较复杂的，我会先在xmind里先做好信息导航架构分析，把需求梳理清楚，菜单有多少，交互页面需要哪些，每个页面做什么都整理清楚后，你会发现什么是共同的，什么的差异的，一目了然，这对你在设计原型的时候有很大的帮助。
学会在本子上会将初步原型画出，简单即可，选择最佳方案，在软件里设计原型，这样速度很快，重要的前面90%的思考，最后的动手也只有10%。
结语
没有什么是有捷径的，也不要总想着不要出现问题，因为问题会再任何一个地方不定时的出现，重要的是解决问题的能力。在问题出现的时候要想出多种应对方式，提供有效的解决方案这是根本。
一个项目的上线，不是工作的结束，后期的优化也是关键，任何一个好的产品都是不断的在打磨，在了解用户，才能做到人人夸赞的产品。
当然，一个产品也不是一定要迎合所有人的需求，因为用户也分为一般用户和技术性用户，我们要做的就是在大多数一般用户都可以操作方便，帮助解决问题就可以了。针对这个项目而言更多的是根据公司业务情况而设计，这跟一个公司的公司制度，工作流程有极大的关系。
最后，这个项目也收获了很多，得到了锻炼，积累的不只是经验，更多的是思考问题的方向，对事物的认知的改变。
