原创分享：我的六大产品设计原则.pdfVIP

原创分享 ：我的六大产品设计原则 原则一 ：不要让用户选择 对于某一功能 ，首先考虑清楚设计的目标是什 ：是想要让用户付费还是不付费 ？是想要用户确认 还是取消 ？是想要用户前进还是返回 ？ 当确定了这一流程的 『理想化』走向时 ，就把产品本身或用户所期待的那一个方向重点剥离出来 ， 作为备用或与意愿违背的操作则尽量隐藏或弱化。 原则实例 某餐饮外卖第三方派送平台 ，因为众包的派送性质 ，现金支付使得资金难以管理 ，且安全性 没有保障 ，产品设计为只能接受在线支付 （微信、支付宝等 ）。考虑到可能会有很多用户坚 持或习惯使用现金支付 ，我在第一版本的设计时 ，给用户端设置了两个选项 ，分别是 『立即 支付』和 『稍后支付』 ，前者对应的是无线支付 ，而后者则是指用户在稍晚一些的时候再使 用无线支付 （当前可能支付不便 ），如果用户选择了 『稍后支付』 ，则用户在完成支付前无 法进行新的下单和点餐。 但是仔细考虑之后就会发现 ，『稍后支付』完全是多余的一个操作 ，设计者只要给用户留 出 『立即支付』的按钮 ，而用户由于各种原因无法支付时 ，只要关闭 A pp 或返回到其他页面 ，就相当于是默认的 『稍后支付』了。而当用户想要进行新动作时 ，页面又会回到这个支付 页面 ，提醒用户完成之前未支付的订单。 相似的设计还有嘀嘀、快的等打车产品 ，当当前网络不佳或余额不足时 ，依然有很多司机允 许乘客晚一些再进行付款。 原则二 ：在不造成新麻烦的前提下 ，解决任何一个小的旧麻烦 ，都 一种提升 想要解决一个用户需求 ，往往有两种手段 ，第一是从一个新角度完全创造一种新的流程和做法 ，第 二则是对原有的模式进行优化更新。无论选择哪一种 ，都应该明白 ，对原始模式的任何一点点提升 ，只要不造成新的麻烦 ，就都是可取的。 原则实例 某快递刷卡签单系统 ，采用员工或学生信息匹配 ，直接刷工卡来验证身份 ，以替代原本手写 签字的不稳定性和不方便性。 最初设计这个功能的时候 ，收到了很多反对和质疑的意见 ，包括工卡丢失怎 领取快递、有 人盗用他人工卡领取、增加了硬件和信息录入的成本等。乍看一眼似乎这些都是潜在的问题 ，但是仔细考虑 ，和原始的手写签名相比 ，我们造成的便利更多 ，还是麻烦更多 ？ 工卡丢失的情况下 ，依然可以使用手写签单的方式 ，这相当于回到原始做法 ；有人盗用他人 工卡领取 ，反而可以根据摄像头和刷卡信息确认盗领的时间和人员情况 ，相比原始模式下胡 乱手写、冒牌签名等情况 ，反而更有利于管理 ；硬件成本可控 ，信息在获取完全数据库的前 提下录入并不复杂。 所有领过快递的人都知道 ，签单的时候自己写下的字可能自己都不认得 ，冒领的风险不可 避免。那 采用刷卡确认签单的方式 ，也许是会存在一些问题 ，但是并没有引入新的麻烦 ， 同时又解决了想当多的问题 ，那 这种设计就是可取的。 原则三 ：尽可能地将面向用户的流程精简 ，采用相对烦琐的技术或隐性流程来替代 最初设计产品的时候 ，总是会把整个流程给梳理出来 ，而这些流程往往又是混杂了用户流程和产品 自身流程——换言之 ，有很多东西用户是不需要知道的。为了面向用户的一侧更加简洁和可靠 ，更 多的技术细节和流程都可以隐性地完成 ，或者使用技术复杂度来替代用户流程复杂度 ，这都是划 算的。 原则实例 某社交产品 ，在进行发布状态、评论状态或点赞等动作时 ，无论当前网络状态是否通常 ，都 可以直接反馈用户已经完成或成功的信息 ，而不要拖累用户陪系统一起等待数据传输或验证 等烦琐的 『产品自身流程』。这种做法可以极大低提升用户体验 ，给人一种快速、流畅的 感觉 ，当然如果后续因为网络等其他原因没有操作成功 ，可以通过别的途径再进行通知。 在我设计的第三方物流派送平台中 ，任务发起者输入订单后 ，系统就将订单推送给所有派送 员进行抢单。如果此后发起者又输入了某一个订单 ，而这个订单因为起始点接近 ，可以和另 一个前续订单进行合并 ，系统将会自动完成这个合并动作 ，并打包发送给派送员。这一系列 的过程对于用户来说 ，都是隐性的 ，但却是方便和自然的。 原则四 ：快速上线、模式验证、可用性测试都十分重要 ，不要立即花费大量的时间做开发与设计 ， 而应该落脚到产品的根本 这是最近最大的一个收获和心得。尤其对于产品经理来说 ，很多需求和模式可能在前期都无法得到