B端业务系统设计：HR绩效管理模块原型设计全过程分享

你有没有了解过，该怎么样去针对一套彻头彻尾陌生的业务场景，去设计出一套能够投入使用的管理系统呢？这个从无到有设计《绩效考核管理系统》的一整个过程，将会给你展现出B端产品设计的实际存在的挑战以及思考出路。

从调研到迷茫的起点

在三月刚开始的时候，项目正式开启。身为主要负责这个项目的产品经理，面对HR绩效管理这个全然陌生的领域范畴，内心满是不安。在前期的时候，已经跟各子公司的HRBP开展了十多场访谈，收集到了厚厚的一摞绩效考核表格，可是当真正坐下来准备开始设计时，仍然感觉毫无头绪，不知从何处着手。

最令人焦虑之时，发生于同集团里负责人事掌管薪资的同事开完需求沟通会后，她们诚挚告知，集团属下七个子公司，每个公司绩效考核方式全然不同，有的运用KPI，有的采用OKR，还有的采取完全自定义考核方式，此言令先前所有准备皆显得苍白无力。

原型设计的第一个纠结

当拿起画笔着手开始绘制原型之际，首先要面对的是产品内容组织架构的选择。最开始的想法极为简单，那便是依据员工列表的形式，直接逐个罗列每位员工所提交的绩效数据。然而当思考到集团有着超过2000名员工之时，这种单纯的列表管理模式明显会造成灾难性的用户体验。

尝试围绕着绩效模板来开展组织工作，而后发觉始终没办法去搞定海量数据的管理难题。最终历经三轮方案的推翻重新构建，于是决定依照组织架构作为立足点，依据被考核员工所属部门来实施绩效表单管理。此项决定致使系统于面对大规模员工数据之际，依旧维持着清晰的层次架构。

表格到产品的艰难转化

运营业务人员给出了一份标准的绩效考核模板，然而该表格自身并非简易。员工基本信息部分纳入了姓名、部门、岗位这三个字段，绩效指标内容更是涉及到评估时间、考核指标、指标说明、评估依据、指标权重、完成情况、指标得分等七个维度。

简便至极的做法乃是把表格径直复制至系统里，然而这明确并非产品经理的价值之所在。所要思索的是怎样把静态的表格转变为动态的、能够交互的产品形态。此过程耗用了整整两天的时间，最终抉择采用信息架构的思路，把内容重新架构为员工信息、绩效结果、其他事项这三个通用信息模块。

平衡一般与特殊的难题

集团各个子公司考核方式存在不一致的状况，这个问题一直盘旋在脑海里。要是彻底满足每个子公司的个性化需求，那么系统就会变成一堆没办法维护的定制化代码。然而要是强行统一标准，又肯定会遭到业务部门的抵制。

其解决方案是，于保持核心流程标准化情况之下，引入绩效考核模板这一概念。系统准许HR人员依据不同岗位以及层级，去创建多种绩效考核模板。该模板里含有通用考核项，还预留了可自定义指标的接口。如此设计，既保障了数据的规范性，又兼顾到了业务的灵活性。

业务流程到产品流程的转身

在历经周末的那两天里，依靠休息的闲余时间对整个绩效管理的业务流程再来重新进行梳理操作了。察觉到公司的考核流程真就非同一般，举例而言，存在着有些部门开展实施季度考核这项措施，有些部门所执行的是月度考核这个方式，另外一部分部门采取使用项目制考核样式，全然是不受固定周期的约束限制的。

历经了一整天的时间，好不容易才完成了从原本的业务流程向产品流程的转变，把繁杂的业务规则提炼成了产品逻辑 ，于系统里设定了具备灵活性的考核周期配置功能，此环节是项目之中极具价值的部分 ，还是产品经理核心能力的一种展现。

核心页面框架的确立

顺着思路渐渐清晰起来，着手打造那种产品的核心页面框架。绩效考核模块主要涵盖考核模板配置页，还有考核任务分配页，以及员工自评页，另外还有上级评价页，再者是考核结果确认页，最后是绩效数据看板等六个核心页面。

有这样的情况，每个页面都历经了起码三次迭代，拿考核模板配置页来说，起始的设计仅有单纯的字段增减这种功能而已，再后来增添了指标库的相关概念，这使得HR能够把常用的考核指标存至库内，在后续配置的时候能够直接拿来调用，就是这样一个细节方面的优化，促使模板配置的效率提高了至少50%。

眼看着项目就要交付了，回头去看这二十多天的设计过程，深切地感受到B端产品的设计比预想的复杂得多。每一个看起来挺简单的功能背后，说不定都是对业务规则深入的理解以及反复地权衡。你认为在设计这种企业级管理系统的时候，是应该先为业务部门的个性化需求考虑，还是坚持产品的标准化设计呢？欢迎在评论区讲讲你的看法，给本文点赞并分享，好让更多产品同行能看到这段实实在在的设计历程。