产品设计阶段中的设计准则

　　产品设计是与时俱进的，而产品设计的准则也是如此。
　　
　　我目前的团队自去年底组建以来，经历过多次的团队协作迭代，逐渐找到适合自己开发模式。每个开发团队的项目性质不同，或是因为项目初始成员的特质影响，会逐渐形成自己团队的特殊文化与适合产品设计的标准。
　　在Medium上有一篇产品经理写的文章，作者根据自己多年的经验，将产品开发团队分成了下列六种：
　　用户中心团队：例如medium
　　增长型团队：例如booking。com
　　功能型团队：例如Atlassian
　　设计中心团队：例如Apple
　　技术中心团队：例如GoogleAI
　　初始团队：原文指的是具有满腔热血但还没有明确KPI的团队，常见于新创团队或是黑客马拉松项目（HackathonProject）
　　虽然每个团队专注的焦点不同，产品设计的标准也有可能不同，不过产品设计的通用性准则，应该是可以应用到多元的团队上。
　　虽然这几年开发团队不断朝著扁平化发展，一个产品的好坏不再是产品经理的全权责任，但产品经理在产品设计的整个阶段，仍扮演了十分关键的角色。也因此，产品设计的通用准则，对产品经理而言，不仅要熟记于心，更要灵活运用这些准则，培养使其成为一种直觉。
　　探索问题阶段
　　1。想解决人们的什么问题？
　　这是一个一开始也是最后的问题，这个问题的关键角色，永远不会是问题本身，而是使用产品的人。
　　2。为什么这个问题值得被解决？
　　听起来有点玄，但实际上并不是所有问题都值得被解决。
　　跟大家分享个小故事：我们现在使用的键盘叫做“QWERTY键盘”，“QWERTY”就是键盘左上边数来的字母排列顺序。你可能会想，这个键盘的排列方式是希望能帮助打字更快、更有效率，很抱歉，刚好恰恰相反。
　　QWERTY键盘推出时，还是1800年打字机的年代。当时技术发展有限，打字机的响应速度比不上人类打字的速度，因此常常出现打字机故障的情况。QWERTY键盘的设计，其实是为了降低打字效率，特意将最常用的几个字母分开，在当时也成功解决了打字机卡死的问题。
　　随著技术不断进步，许多人想解决QWERTY键盘降低打字效率的问题，也的确推出了更符合人体工学、能提高打字效率的键盘，但一推出到市面上，最终都是以失败收场。因为人们早已习惯QWERTY键盘，甚至有除了键盘输入以外的信息输入方式。也因此，QWERTY键盘降低打字效率的问题，就不是那么值得需要被解决了。
　　3。这个问题是否是一个真正的问题（本质的问题）？
　　我们团队曾遇过一个真实的案例：业务主管跟你说他想要做一个实时监控业务员定位的功能，如果IT团队将这个功能实现了，会发现实时监控不但对于数据传输量的要求相当高，也非常耗费业务员的网路流量，而且业务主管平时工作忙碌，几乎不可能实时监控。
　　其实业务主管提出这个需求的背后，是想了解业务员是否确实执行工作，而实时监控，只是业务主管基于这个本质的问题所提出的一个可能的解决方案，但却不一定是个合适的解决方案。
　　4。这个问题是否简单、清晰，足够被其他人理解？
　　换句话说，如果一开始就无法清楚定义问题，那又怎能产出具体有效的解决方案呢？
　　执行阶段
　　（1）全局在前，细节在后
　　深入一个解决方案之前，确保已经尝试过其他的方案。最快的验证方式，就是当团队其他成员提出怎么不试试XXX建议的时候，就代表想的还不够全面。
　　（2）原型图快速验证方案
　　如果产品已有明确的目标使用者，在进入开发之前，可以通过简单的原型图先让这群使用者进行测试（可用性测试UsabilityTesting），藉此快速验证方案。
　　（3）设定产品的预期结果
　　包括任何质化或量化指标，比方说减少20的操作时间、提升整体使用满意度等等。
　　（4）排序功能开发优先级
　　一个完整的功能里，一定有最重要、次重要以及较不重要的排序（MoSCoW优先级）。过去强调全面、完整功能的瀑布式开发流程，在现代快速迭代的数字世界里已逐渐被敏捷思维所取代。
　　举个例子：当A团队还在为那从90分进步到95分的功能苦恼而迟迟无法推上线时，竞争对手B团队早已将80分的产品推上线，虽然80分的产品让终端使用者不是很满意，也有不少抱怨，但B团队收集到了真实使用者提出的问题，并进行改版。
　　当A好不容易将100分的产品推上线，却发现市场早已被B占据，而且B的产品经历多次改版，更符合使用者的需求，当初A团队坚持的100分产品也不是当今市场的100分了。
　　（5）快速试错，迅速调整
　　以更包容的心态来面对错误的发生，检视个人或是团队在面对错误发生时，是否有足够快速的应变能力，能迅速调整方向，并且记录问题、总结归纳，不再犯同样的错误。
　　（6）阶段性反思总结
　　无论产品成功或失败，团队反思是整个执行阶段中最重要的一个环节。团队反思，绝不是互相抱怨的批斗大会，而是一个阶段性任务完成时，让团队彼此都能够沈淀思考，调整步骤继续迈步向前的机会。
　　尤其在跨功能的团队里（crossfunctionalteam），可以更好了解各个团队成员在协作中遇到的挑战、当下的解决方式，以及未来可以如何调整合作的方式。
　　团队反思的时间可以是在一个大的开发版本上线前后发起，通过12小时的会议，有明确的主持人、会议记录者，分别感性与理性的两个时间段。感性的时间里，让大家说说过去的开发过程中看见好的、不好的以及要感谢的地方；理性的时间里，明确的提出问题点，让团队一同来思考解决方案。
　　验证阶段
　　（1）设定验证指标
　　在产品上线之前，就必须将验证指标设定好，并确保团队每一位成员认同各项指标。
　　（2）设定反效指标
　　这个验证方式是Facebook产品设计副总监（ProductdesignVP）JulieZhou提出的，验证一个指标是否成功，就把不成功的指标条列出来。
　　（3）找出问题比调整方向更重要
　　产品上线后，如果发现偏离指标的情况，无论是好的或是坏的方向，首先厘清问题发生缘由，再来调整策略。