工作这几年，年限不长，但可能是缘分太巧，经验比较多。鄙人做过前端APP，做过运营工具，做过后台管理系统，做过toC，做过toB，甚至交互设计也顺带做过。但总体来说，还是偏后台的经验更多一些。正好整理一下前端后台的工作经验对比。
1、中后台用户与用户行为
先做一个用户分类：
- 互联网发展到现在，企业内部一般有很多的中后台系统，用来管理各项业务线与用户信息，这类系统的用户是企业内部职能部门。
- toB售卖的后台管理系统，它的用户是外部企业员工和老板。
toC的产品有个逻辑——把用户当成傻子。相比之下，我们没法对中后台的用户做这样的假设，因为他们在业务的专业领域，比产品懂得更多，产品要对他们的专业领域有足够尊敬。但与此同时，他们大部分还是不那么理解系统或者产品背后的逻辑，这时候你最好也把他们当成“傻子”，这样可以激励产品把逻辑做得更易懂、更高效。
中后台产品有个好处，是可以直接接触到你的用户，直接向用户搜集需求。但也对沟通提出更进一步的要求。在搜集需求过程中，产品要完整思考整个产品的逻辑，仔细追溯需求背后的动因和本质目的。在沟通过程中，每个人的表达逻辑不同，产品要认真了解，他说的和你听的是不是同一回事。
如果你要做的需求是一个全新的系统或者业务，那你可能是得到的信息最多、最了解这个业务的人，这个时候，务必把用户当成“傻子”，去做更多功课。中后台产品经理的系统设计，其实也是对业务的解构与重定义，而不是单纯地堆砌功能。
后台产品用户人数不会太多，一般很少在内部系统做埋点监控。关于用户行为，只能产品上线后可以隔三差五去了解一下线上效果，去看看跟设想是不是一致，然后主动尝试规划迭代和优化。很多时候你的用户没有问题反馈，不代表你的功能非常好用，可能是你的用户没有反馈的动力。
2、产品逻辑与可拓展性
中后台系统，有很强的逻辑要求。主要从两个角度考虑：1) 业务逻辑，2) 系统逻辑。符合业务逻辑会让产品体验更好，符合系统逻辑会让研发工作更顺利。
我在优化一个旧的系统时，偶尔会翻出一些陈旧的问题：为什么这个功能，当时做得这么难用？一般答案是，这样做更符合系统结构，对研发来说简单，可以尽快上线。
我记得14年左右互联网上升阶段，一般说产品不需要考虑研发的系统逻辑。但现在，除非你只做原型交互，否则无法避免地要把后台系统逻辑考虑进去。所以不妨多与研发沟通一些，多了解一下系统的功能结构与数据库，很多时候可以同时满足业务逻辑，同时符合系统设计。至少，不要搞出违背现有系统逻辑的优化方案，那样的需求过不了评审。
在业务的角度看，产品可以在需求搜集和分析阶段多做一些功课，了解更多业务方面的知识，多与用户沟通，多了解一下他们的工作，了解现阶段的需求的同时也了解一些未来的拓展方向，去学习这项业务的底层结构，最终目标。这样可以更好地设计系统结构，规划今后的拓展性，也让你的近期优化更有方向，减少弯路。
总的来说，产品需求最终目的是为了解决业务诉求，所以先从从业务角度下手，首先出业务逻辑流程图（脑图或者角色流程），然后再在此基础上，从系统角度检查是否有优化点，再出更细化的系统流程图（状态图或者功能流程）。如果是比较大的需求，在产品需求处理完成后，还可以进一步与研发沟通，从系统角度看这个需求是否有优化空间。 为什么要这样？因为这样你的需求会有更好的可行性，更便于落地。
另外，后台产品经常有一个常见的纠结点：未来的拓展方向是A，但没有那么多资源，而现在急需解决一个问题，快速优化的方向却是B……这种情况大多数时候…只好妥协一下。
3、中后台需求规划
我在刚开始做产品的时候，耗时最多的工作是原型和交互的产出。这是前端产品工作重心之一，也是产品最容易获得成就感的地方。前端与后台在这方面有完全不同的切入点。
中后台产品有一个极强的目的是：完成相对全局性的管理功能。比如：这个业务模块的完整流程管理、功能的全局性设置、全量数据的统计分析评估等。所以它有更强烈的功能闭环要求，产品要尽量在第一个版本里提供一个完整的功能链条，来解决全部的核心问题。功能可以不够好用，页面可以丑一点，但一定要有。得给用户足够的信息和数据，才能支撑他们完成管理和决策。
那么，怎么找到第一版的MVP需求？后台管理系统的用户往往是公司的职能部门，首先考虑参与这个业务的职能部门有哪些、每个部门的角色和工作内容是什么。逐一与他们沟通讨论，搜集需求，罗列整理。
举个例子，比如我们要新建一个系统来做运营渠道的管理：
- 渠道对接前，APP的市场会跟很多个渠道沟通引流事宜，所以 1) 它要能够支持多个渠道的接入、渠道基础信息管理。
- 接入中期，每个渠道合作周期会根据市场签订的合约来调整，所以需要 2) 提供渠道的配置功能，用于上架或下架某些渠道，并配置渠道的有关参数。
- 接入后，运营同事会对各个渠道质量做监控，计算引流数据，观察哪个渠道性价比更高，考虑是否调整引流策略，他们需要 3) 实时监控统计渠道流量数据，及核心转化率。
- 财务需要定期与渠道结算费用，我们一般APP不会完全信任渠道的数据，所以会 4) 为每个渠道统计我们自己的流量报表，一方面用来核对账单，一方面为市场运营同事绩效评估提供依据。
- 如果你的APP是个金融理财类产品，那么还要问一下，合规有没有要求。
上面列的这5条，结合各个企业自身后台属性，继续细化下去，会衍生出很多子功能，变成一套非常非常复杂的系统。但一般第一个版本不会有那么长的周期、那么多的资源，所以要挑出最核心最必要的功能，降低需求复杂度，控制版本边界。
那，什么是最必要的功能？满足下面任意一个条件的就是必须做的：
- 业务基点：没了它这个业务不能推进（而且必须系统执行、人工无法处理的）
- 影响范围广：影响前端转化率 (或用户体验)的，对其他模块有强影响的
- 营收：能大幅节约公司成本、或增加公司收入的。
- 合规：法律法规要求必须做的。
这些非常容易理解，但还是有取舍和变通的空间，实际的结论也要有变通。比如：老板说我们的APP急需新增流量。那就不要关心什么流量监控了，先把渠道接入做进来，尽快上线，监控方面先请研发在代码中或者数据库中留下痕迹，方便后期取数和功能拓展。你知道这样在初期线上运维运营可能不得不让研发参与，用户和研发都会痛苦，但这些痛苦总还是会在下一个版本解决。
但如果合规说，这个功能必须在线上增加一项声明才符合监管规定，那你只能争取上线前把这个问题解决掉。
而关于人工工作量这一点，如果不是实在没办法，系统能处理的尽量系统处理，不要增加人工的工作量。中后台本质就是为了提高效率，如果研发做出来的系统还需要依赖很多人工，就太鸡肋了。鸡肋的功能不会有用处。
4、中后台交互体验
众所周知，中后台可以做丑一点，逻辑比原型重要。系统功能的逻辑设计完成以后，展示逻辑框架基本也就出了。但还是聊一下交互体验。
C端的交互逻辑在后台一样适用，但除此之外，中后台页面的一个核心任务：管理和展示大量的业务数据。后台会有大量的表格、统计数字、表单、流程管理。这是与前端产品是完全不同的方向和诉求。这里涉及一门独立的学问——信息架构，今后有机会可以单独聊。但产品在工作中却把它归在交互和原型部分去处理，那我们也按这样的逻辑讨论。
我总结出下面几点，大概是仅适用于后台的：
- 逻辑自洽：交互逻辑服从功能逻辑
- 简洁有力：提供有效的页面交互结构，省去花哨的展示干扰
- 信息结构：信息归纳的结构，服从信息本身的属性和结构，使之更容易理解
- 内容充分：用户在一个功能或一个场景下需要的信息，一个模块给够，避免用户需要到不同页面搜集
- 数据高效：同一组数据可以不用重复处理太多次。否则你每次迭代都要迭代所有位置
- 足够的引导：易出错位置强提示，易混淆位置提供充分解释，可以丑陋但务必有用。
交互比较简单，只补充说明其中两个有取舍需要的点：内容充分，数据高效。
后台管理系统为了提高业务人员的工作效率，通常在一个模块里要提供足够的数据，方便他们做管理的决策。例如，哔哩哔哩的内容审核，当前待审核视频的有关数据一定会一次性提供到位，审核员才能工作。但我想某些时候也会参考上传视频这个用户的账户信息、历史违规记录、历史投诉消息等。在内容模块里，也应该能方便地查到这个用户的这些资料。
与此同时，在一个业务链条里，一组数据会被重复用到。这种时候如果一个接口可以解决所有位置的展示，那么就可以随便你展示多少次。如果这一组数据在不同位置要用不同接口提供给前端，那么要慎重。有可能考虑换个方式，或在展示方面做一些折中。当然这些即使没处理也没关系，研发那边只是麻烦一点也没有麻烦太多，而且研发的接口结构，也不是产品在需求阶段能预判的事情。但你了解这些，会在与研发沟通过程中更流畅。
当然，如果你的后台是要卖出去的，交互要做得更好一点。
作者：Conan Sze，微信公众号：Conan产品研习社，我的产品笔记，走过的路，踩过的坑，遇到的朋友们。