原则一：不要让用户选择

对于某一功能，首先考虑清楚设计的目标是什么：是想要让用户付费还是不付费？是想要用户确认还是取消？是想要用户前进还是返回？

当确定了这一流程的『理想化』走向时，就把产品本身或用户所期待的那一个方向重点剥离出来，作为备用或与意愿违背的操作则尽量隐藏或弱化。

原则实例

某餐饮外卖第三方派送平台，因为众包的派送性质，现金支付使得资金难以管理，且安全性没有保障，产品设计为只能接受在线支付（微信、支付宝等）。考虑到可能会有很多用户坚持或习惯使用现金支付，我在第一版本的设计时，给用户端设置了两个选项，分别是『立即支付』和『稍后支付』，前者对应的是无线支付，而后者则是指用户在稍晚一些的时候再使用无线支付（当前可能支付不便），如果用户选择了『稍后支付』，则用户在完成支付前无法进行新的下单和点餐。

但是仔细考虑之后就会发现，『稍后支付』完全是多余的一个操作，设计者只要给用户留出『立即支付』的按钮，而用户由于各种原因无法支付时，只要关闭 App 或返回到其他页面，就相当于是默认的『稍后支付』了。而当用户想要进行新动作时，页面又会回到这个支付页面，提醒用户完成之前未支付的订单。

相似的设计还有嘀嘀、快的等打车产品，当当前网络不佳或余额不足时，依然有很多司机允许乘客晚一些再进行付款。

原则二：在不造成新麻烦的前提下，解决任何一个小的旧麻烦，都是一种提升

想要解决一个用户需求，往往有两种手段，第一是从一个新角度完全创造一种新的流程和做法，第二则是对原有的模式进行优化更新。无论选择哪一种，都应该明白，对原始模式的任何一点点提升，只要不造成新的麻烦，就都是可取的。

原则实例

某快递刷卡签单系统，采用员工或学生信息匹配，直接刷工卡来验证身份，以替代原本手写签字的不稳定性和不方便性。

最初设计这个功能的时候，收到了很多反对和质疑的意见，包括工卡丢失怎么领取快递、有人盗用他人工卡领取、增加了硬件和信息录入的成本等。乍看一眼似乎这些都是潜在的问题，但是仔细考虑，和原始的手写签名相比，我们造成的便利更多，还是麻烦更多？

工卡丢失的情况下，依然可以使用手写签单的方式，这相当于回到原始做法；有人盗用他人工卡领取，反而可以根据摄像头和刷卡信息确认盗领的时间和人员情况，相比原始模式下胡乱手写、冒牌签名等情况，反而更有利于管理；硬件成本可控，信息在获取完全数据库的前提下录入并不复杂。

所有领过快递的人都知道，签单的时候自己写下的字可能自己都不认得，冒领的风险不可避免。那么采用刷卡确认签单的方式，也许是会存在一些问题，但是并没有引入新的麻烦，同时又解决了想当多的问题，那么这种设计就是可取的。

原则三：尽可能地将面向用户的流程精简，采用相对烦琐的技术或隐性流程来替代

最初设计产品的时候，总是会把整个流程给梳理出来，而这些流程往往又是混杂了用户流程和产品自身流程——换言之，有很多东西用户是不需要知道的。为了面向用户的一侧更加简洁和可靠，更多的技术细节和流程都可以隐性地完成，或者使用技术复杂度来替代用户流程复杂度，这都是划算的。

原则实例

某社交产品，在进行发布状态、评论状态或点赞等动作时，无论当前网络状态是否通常，都可以直接反馈用户已经完成或成功的信息，而不要拖累用户陪系统一起等待数据传输或验证等烦琐的『产品自身流程』。这种做法可以极大低提升用户体验，给人一种快速、流畅的感觉，当然如果后续因为网络等其他原因没有操作成功，可以通过别的途径再进行通知。

在我设计的第三方物流派送平台中，任务发起者输入订单后，系统就将订单推送给所有派送员进行抢单。如果此后发起者又输入了某一个订单，而这个订单因为起始点接近，可以和另一个前续订单进行合并，系统将会自动完成这个合并动作，并打包发送给派送员。这一系列的过程对于用户来说，都是隐性的，但却是方便和自然的。

原则四：快速上线、模式验证、可用性测试都十分重要，不要立即花费大量的时间做开发与设计，而应该落脚到产品的根本

这是最近最大的一个收获和心得。尤其对于产品经理来说，很多需求和模式可能在前期都无法得到百分百的确定，某一个产品的实际效果真的之后上线推广测试之后才能有真实的反馈，再进行调整和迭代。对于这样的情况，请使用所有传统、粗劣、暴力的方式尽快将新模式或新功能推到线上测试，获取模式验证的反馈。与之相对的，不要在前期花费大量的时间去做开发和设计，一旦模式验证不通过，这些工作很可能会白费。

原则实例

第三方众包派送在国外已有成功案例，但是在国内或者某些特定的细分市场中（如 CBD 商圈或高校市场）却不一定有现成的例子可供参考。对于这样的新模式，光靠调研和论证很难得到确切的反馈。因此在产品设计初期，应当直接使用纸笔记录、短信电话通知、雇佣全职派送人员等来模拟整个产品过程，以期获取第一手的可用性测试资料。如果模式验证可行性较高，再投入资源进行开发设计，反之则尽快调整产品方向。

倘若前期直接投入大量资源打造产品，希望凭借一个完成品去测试，成本真的过于高昂。

原则五：设计者本身往往不是典型用户，不要对自己的认知和设计过份认同，也不要立即对别人的意见提出反对

我认为产品经理入门的第一个要点就是认清：自己不是典型用户。你认为这是需求，这未必是真正的用户需求；我认为不需要这个功能，也不代表没有人需要这个功能。刚开始接触产品的时候，喜欢固执己见，在听到别人的创意时，第一时间都是去寻找各种各样的反驳的理由。但是在有了一定的经验和阅历之后，我们常常发现自己的感觉往往是不准确的，而产品经理的一大职责，就是采用各种用研手段去论证这个需求是否真实存在。

原则实例

最初做物流集散中心项目时，我根据几个盈利点分析，认为这个项目基本不可能盈利。但实际上当你垄断了一个区域的所有快递之后，就会有足够多的之前没有想到过的盈利点出现。如果现在世界上没有『快递』这个行业，让我第一个去做，我依然可能会认为这种人工成本高昂的模式难以盈利，但事实早已证明了一切。

原则六：考虑所有极限情况，这包含在功能逻辑、视觉设计、交互设计的每一个环节

极限情况有助于完善产品的方方面面。无论是功能逻辑上（超高并发量、或初期零基础用户阶段），还是视觉设计上（空白内容页的展示、大量内容的处理），或是交互设计上（断网、系统卡死反馈），都需要考虑每一个极限情况。

原则实例

某拼车产品，对于这样多用户协同的需求，基础用户数量就非常重要，试想如果前期只有零星的几个用户在使用产品，势必难以在段时间内达成自己拼车的目标，同样的情况海辉发生在论坛社区、二手市场等产品中。

对应的解决方案可以是发起落地活动，段时间内引入大量种子用户，或者采取运营手段投放一些『托』用户，以激活整个产品模式与流程。

本文系作者 @窒息红Leon投稿发布，转载请注明来源于人人都是产品经理，并保留本文链接 。