端产品设计上的冲突与权衡

　　B端产品设计，如何权衡这些问题？本文作者将以一款企业移动办公软件为背景，讲述B端产品设计上的冲突与权衡。enjoy
　　做一款B端产品，可能会面临很多挑战。B端产品本身就具有一定的复杂性，你可能要梳理庞杂的业务流程，要考虑不同角色的协作与冲突，协调不同企业的特异性需求在习惯了2C的用户视角后，要如何理解B端的客户和用户？做一款B端产品，在设计过程中会遇到哪些挑战呢？
　　本文以一款企业移动办公软件为背景，讲述B端产品设计上的冲突与权衡。
　　冲突一：老板的需求和员工的需求
　　B端产品既然是给企业用的，自然会涉及到企业中的多种不同角色，满足不同角色的需求、促进他们的高效协作，是B端产品的基本要求。而在所有角色中，有两种身份最为典型：一是老板，二是员工。老板是企业的所有者、高层管理者，员工则是接受雇佣为企业创造价值的人。
　　作为企业的管理者，老板想要的是强管控。他希望知道员工在工作时间内的投入度，希望通过管控手段杜绝员工偷懒和损害公司利益。比如说，对于签到的功能，老板希望更精确地掌控员工实际办公的时间，他可能会提出这样的要求：
　　要确保员工到办公室后才能打上卡，不希望未到公司就能打卡；
　　避免代打卡现象，一个员工必须只用一台手机打卡；
　　员工外勤时，希望知道员工外出的路线、在外访地点的实际时长。
　　而员工的诉求相反，他们希望公司在考勤方面的要求可以更弹性，即使是在工作时间也希望自己有一定的自由度。因此他们对签到功能的期待可能是：
　　希望在距离公司一定范围内就可以打卡，希望有自动打卡避免忘记；
　　不希望限制手机设备，有些员工本身就用两部手机，若有急事提前走也不希望老板知道；
　　不想要老板知道自己的确切位置，感觉没有自由。
　　从签到这个例子就可看出，老板和员工往往有不同甚至相反的需求。对于一个B端产品来说，老板是购买者，是买单的人；而员工是使用者，老板买了软件后主要是给员工用。从商业价值考虑，老板的要求似乎应该是第一位的：毕竟只有老板愿意买单，我们的产品才会有市场，而员工几乎对产品购买没有决策权，满足他们的个体需求价值似乎并不大。
　　但是，我们并不能不考虑员工，而完全以老板为典型用户去设计产品。员工是实际使用者，如果产品设计对他们来说很难用、不能产生价值，甚至在某些方面使他们感到抵触（比如为了满足老板要求而侵犯他们的隐私），就会导致高层在内部推广产品时遇到较大阻碍，如果产品本身的价值体现不突出、老板也愿意考虑员工意见的话，就很可能会转而使用其他替代产品。
　　因此，对于老板与员工的冲突，我的看法是：以老板的需求为主、员工的需求为辅；除此之外，产品整体设计上应该保持易用性和情感化，这是为了让员工容易上手并且喜欢这个产品，降低高层对内推动的难度。情感化之所以重要，是因为员工们在使用B端产品时往往没有主动权，只是在上级的要求下使用，加之它是一个管理工具，员工会很容易对产品产生不良情绪，通过情感化设计，可以让员工意识到这不仅是一个满足高层的管理工具，它还很有温度，能让自己在某些时候产生共鸣，从而也会渐渐喜欢上这个产品。
　　冲突二：功能和体验
　　功能和体验的冲突不是B端产品的专属，C端产品也会面临这样的问题：增加功能可以使产品更有用，满足更多用户的需求；但是不断增加新功能会导致产品变得复杂难用，影响体验。而对于B端产品来说，这个冲突可能更加严重。这是因为：对于B端产品来说，功能实在是太重要了。
　　为企业做软件，需要考虑的业务场景和角色非常多，即使是满足一家或者一类企业的业务需求，工作量都非常大。更何况我们面向的企业来自不同行业、不同规模，很多都具有特异性的要求。于是尽管产品功能已经非常丰富，企业用起来还是感觉不够合适。
　　另一方面，企业使用管理软件是为了提升效率，提升效率也是为企业创造经济价值的方式之一。所以选择软件时，功能能不能满足需要就非常重要了。如果A软件有企业迫切需要的某功能，而B软件没有，那么即使B的体验更好，企业还是会选择A。功能覆盖的业务和场景、与企业的匹配程度，几乎成了企业选购产品的第一要素。
　　功能如此重要，那么体验呢？管理软件不像C端的产品，企业在选择产品时，即使有些难用，也会硬着头皮去探索功能，希望在综合对比几个不同产品后作出最优的决定。那么为了功能丰富而牺牲一些体验，是否可行呢？
　　体验并不是不重要，相反，B端产品的特殊性对体验设计提出了更多的要求。我认为B端产品体验设计有两大挑战。一是如何传达产品价值。由于产品是为多角色设计，当一个独立用户前来试用时，往往只能看到很简单的界面，而不知道不同角色在不同流程节点上会看到不同的功能和内容，因此也很难了解产品能为团队协作带来怎样的价值。第二个挑战是如何简化复杂的业务流程。功能越复杂，就越难学习，如果无法把复杂的系统设计得简单易用，用户也容易望而生畏，因为实在搞不懂而放弃该产品。
　　冲突三：短期利益和长期利益
　　如果只考虑短期利益，我们可能会做这些事：
　　用C端常用的方法拉新促活，短期内提高活跃用户数和新增用户数；
　　听从客户尤其是VIP客户的要求，添加一些特异性的小众的功能；
　　以功能为王，不断叠加新功能，忽视体验和稳定性。
　　这些事情往往只能满足短期利益，长期来说却并不合适。
　　我们可能会做一些C端常用的运营活动，通过热点、让利或者有趣味的活动来吸引个体用户，提高活动期间的用户活跃度。从短期来说，确实能够提高日活，让我们的数据看上去更漂亮；但是长期下来却并无用处。这是因为用户是否使用云之家，一般来说是一个企业级的行为如果我所在的公司不用，老板不用，我就不会去用，即使参加了这些促活活动也很难有所改变。所以B端的运营也许应该有更强的目的性，比如精准地面向决策层，传达出产品价值和品牌形象，找对了着力点或许就能吸引更多企业使用。
　　B端产品不免有很多付费客户，也会有一些重点维护的VIP客户，他们往往是一些比较大型的企业。客户不止经常向我们提bug、提体验问题，也常常要求加上某个功能这些功能往往是出于企业内部的实际需求，因此客户也总是比较着急，希望我们尽快上线这些功能。如果可以做，要给用户承诺排期；如果不做，也需要向客户提出合理解释。满足客户的要求可以提高这家客户的满意度和稳定性，但是客户所提的功能有时满足的是很特异性的场景，如果所有重要客户的需求都要加上，产品很快就会变得非常臃肿。
　　快速迭代，小步试错。也许正是这样的理念，让我们敢于在功能还未完善时就上线即使并未充分设计和测试过。原本这并没有问题，但如果迭代速度非常快，功能需求非常多，每个迭代都有做不完的新需求，那么那些本着小步试错的理念上线了的功能，就总是没有机会进行优化和验证。功能似乎是越多越好，但是因此牺牲了体验和产品的稳定性，产品的定位和品牌形象可能也会随着这样的快速迭代而走偏了方向。