通常，我们称规律背后的解决方法叫做方法论，提炼出方法论的前提是理解事情的“底层逻辑”，底层逻辑在面临变化的时候，总能应用到新的变化里，产生出新的方法论。
背景
每一款产品，在不断迭代和创新的过程中，都是以满足用户需求，解决用户痛点以及创造用户价值为目标的。业界共识的产品分类方法有许多，例如：根据服务的对象可分为toC和toB；按客户端可分为wap、app、web；按需求类型可分为社交、交易、内容、工具、游戏等等；在每个大的类别下，又会出现非常多的领域细分，非常复杂。
网易严选作为一个新消费品牌，兼具了消费品牌和电商的特性，产品上首先必须满足交易类购物的toC属性，同时由于背后整个商品、营销、供应链以及数据体系的支撑，也建设了一套toB的产品矩阵。ToB的需求相较于ToC，通常是相对明确的，根据客户诉求进行迭代即可。但是当业务和系统都复杂到一定程度时，设计阶段缺乏足够的把控和思考量，就容易埋下隐形的坑。
以产品视角出发，通常我们会把产品设计过程分成4个阶段，即，产品定义、产品设计、产品研发和产品运营，这4个部分不断迭代演进，就是整个产品设计的过程。
- 产品定义需要明确用户、场景和价值这三件事。
- 产品设计是基于场景拆分用户的使用任务以及路径，在此之上建立的架构、功能、内容以及交互。
- 产品研发是把设计落地实践并检验的过程。
- 产品运营是指上线后针对市场和用户所做的营销、推广及双向反馈。
其中，设计环节是重中之重，其质量的好坏基本奠定了产品之后的走向，无论是产品、研发、测试还是交互的同学都有机会重度参与到设计的每个环节中。
今天，我们先就toB产品体系，针对产品设计阶段，总结一些通用的产品设计原则。有了整体原则，才能保证我们日常交流中有一致的认知共识和沟通语言。
一些设计的原则
1、系统要有明确的边界，服务要有明确的归属
当产品矩阵有限时，系统边界通常是明确的。但是，在业务领域多形态及交互复杂的情况下，往往会伴随很多边界和协同的问题，相同或类似的功能没有归属，就会导致重复开发并且推高维护的成本。
比如供应链系统中需要记录商品与仓库之间的绑仓关系，指定一个商品只能放在哪个仓库里（由于存储和配送条件的限制，商品无法任意放）。起初，绑仓关系只用于采购送货，入口开放在商品中心。随着业务复杂度提高，出现了仓间调拨和履约等场景，继而出现了五花八门的绑仓用法，长在了仓配工作台，库存中控台等各个业务系统上。
系统缺乏边界感，对“绑仓关系”缺乏明确的定义和归属，导致了采购、调拨和发货环节，对这份信息反复存储迭代修改，引起了很多不必要的误会。“绑仓”到底归属于哪一个系统边界，这是在设计系统和增加服务之初就应该严格确定好的内容。
2、交互的系统达到一定数量问题频发时，就要警觉秩序的重要性
系统建设的初期，我们常常会以“走通”和“够用”为前提，不做过多设计。但随着业务体量和复杂度的升级，单点的问题会被放大或衍生出新问题，这个时候，建立一套通用规则来约束系统间的交互，并且，针对不同程度的“违约”，配合不同等级的管控措施就非常必要。
一个典型的例子就是库存系统，消费者在严选主站的购物行为会触发一系列的库存状态，最简单的场景是消费者对某商品下了一个订单，随着订单的状态从下单，到支付，再到出库，对应商品库存也会经历连续性的状态变化。可是当场景变复杂了呢？考虑逆向取消和售后场景呢，商品在主站外的其他渠道售卖的场景呢? 当上游一堆服务同时对同一个商品库存状态发起密集的调用指令，但是这些调用指令又没有很好的规范（如单状态重复调用，连续状态跳跃式调用，调用未完结等等），就会引起一连串的库存“事故”。
此时，在上游与库存状态的交互中建立一套完整的调用规范就非常有必要。如何定义调用是合规的，如何确定调用动作的完结？针对不同的异常，如何建立违规等级，不同的等级给予不同的防御规范，这些问题又可以衍生成如何监控，帮助用户快速定位问题的工具，自动修复等等，都是产品功能设计需要考虑的内容。
中后台系统，特别是符合中台属性的底层服务，跟其他产品交互的概率很大，都需要认真思考规范和秩序的问题。
3、基于对象抽象规则，远比端到端的流程线上化重要
前文提到toB相对于toC，有一个显著的特点就是，通常都有比较明确的用户需求，把明确的客户流程搬到线上是重要的一环。那么问题来了，是不是条理或逻辑清晰就是一个优秀的产品了呢？答案当然不是，这是个必要而非充分条件。
许多情况下，仅仅对流程做清晰的梳理，然后一步一步搬到线上，做到了搬砖，但并不是个好的实现方式。对于一条比较通用的功能，在设计时，对规则和能力做必要的抽象，能将一个单点的功能转化成一个拓展性良好的通用能力。
再来看一个案例，比如疫情期间武汉封城，除了医疗物资外其他所有日用商品一律不能配送，业务提前知道了这个风险，就希望严选系统针对武汉地区把除了防疫物资以外的商品订单卡住，不要下发给仓库和快递公司，只把防疫物资正常下发。听起来是个非常简单的功能，按既定规则订单打标并卡住即可。
但仔细想想，卡单是一个特殊还是通用功能呢？其实是比较通用的，仓库或者快递承运商出了故障，前台配置错误导致订单需紧急召回，直播等等情景都可能触发“系统卡单”这个功能。想到了这一层，产品设计就不应该简单的只针对单一场景做线上化，而是将系统卡单抽象成，第一条件设置（订单、用户、商品、地址等等维度）、第二规则引擎（条件组合及优先级的拼装）、第三业务决策（是否拆包、卡单、定时推单），这三个通用步骤来组装以满足更多的场景。
流程抽象=前置条件+规则引擎+决策动作
以上，我们谈到了产品设计的三个通用原则，基于篇幅的限制，其他原则就先不一一说明了。很多原则其实也不仅仅适用于B端或者产品端，做运营做系统做数据，最基础的底层原则其实是相通的。
写在最后
很多优秀和聪明的同学经常问，我的工作能力不错呀，领导交代的任务都办好了，不知道下一步如何提高了。答案很多，其中一条简单且质朴的是，通过办好一件事，是否认真地思考过，为什么要这么做而不是那么做？几件事情之间有什么内在联系和规律？你能精准而独到的提炼么？易于被别人理解和记住么？
通常，我们称规律背后的解决方法叫做方法论，提炼出方法论的前提是理解事情的“底层逻辑”，底层逻辑在面临变化的时候，总能应用到新的变化里，产生出新的方法论。无论是方法论还是底层逻辑，都需要首先经过大量的实践，充分的内化和提炼。我们每天都在经历很多实践，但是，请不要忘记了找规律和方法。
