作为产品经理的你需要了解这三点交互设计原则

　　如何才能设计一款优秀的产品呢？当我们在设计产品的时候，遵循哪些原则能够帮助我们更好的设计产品？本文作者总结了三点交互设计原则，作为产品经理的你，非常有必要了解这三点交互设计原则。
　　1. 没有人愿意停留在新手级别
　　观点：我们的用户是小白
　　工作中和PD沟通的时候偶尔会遇到这个尴尬的问题。PD希望需求里的某个点能设计地＂细致到不能再细分出任何一道步骤＂，理由是＂用户是小白＂。（抱歉，为了不影响兄弟团队的和谐就不举具体例子了；同时声明一下本文所有论点都不带有＂个人针对＂色彩。）
　　那么用户真的是小白吗？他们到底有多＂白＂？
　　如果将用户对互联网产品的认知作为衡量标准，我们可以将用户分为新手（=小白用户）、中间用户和专家。那么只要我们分清我们的主流用户是谁，问题就会迎刃而解。请看图：
　　图片来源：《About Face 3：交互设计精髓》
　　互联网产品的用户群分布状况，与大多数人口分布一样遵循着经典的正态分布统计曲线。我们的主流用户既不是新手小白，也不是专家用户；大多数用户属于中间用户。同时不要忽视，新手用户发展很快，会随着时间发展慢慢成长为中间用户；这也就是说我们的小白用户不会永远是小白。
　　通常用户群主体是中间用户。所以在整个产品设计的初期，我们主要考虑的对象应是中间用户，同时根据具体情况考虑是否要完全满足小白用户的需求，并适当听取一下专家用户的建议。大多数中间用户其实是不需要我们＂极具耐心地介绍与展示＂，他们其实比我们想象得聪明；＂极具耐心地介绍与展示＂反而会拉长用户体验的时间过程。
　　总结
　　所以我们的主要目标是让新手小白用户愉悦快速地成为中间中户；让中间用户感受到持续不断地愉悦。当然也不为想成为专家的那些用户设置障碍。
　　2. 从用户心理模型出发，而不是产品的实现模型
　　观点：开发这样实现比较容易，所以不能按你说的那样做
　　这是我在工作中遇到的最尴尬地问题了。大概自己带有＂完美主义＂倾向，所以非常注重最终呈现到用户眼前的界面和与用户直接互动的用户体验感受，总是希望在开发可行的基础上，辛苦程序员哥哥稍微再费多一点点的心思。
　　当然，大的项目开发成本很高，出于多种因素的综合考量，需要舍弃一点用户体验，以避免开发成本太高，给后期维护造成多余的人力成本和时间。这一点我也十分肯定并理解。
　　但在整个产品设计过程中，我认为用户的心理模型应该大于产品的实现模型。这是我从事产品设计以来最坚定的立场之一；并认为这是产品设计师的common knowledge之一。但沮丧的是，仍是有愿意为节省开发成本选择牺牲用户体验的情况发生（我所指的是比较小的需求处理时）。那么在实际情况中到底该如何取舍，需要我们好好斟酌一番。也许大家坐在一起喝喝咖啡，愉快地互相理解一番，一切就完美解决了也不是没可能~^_^
　　最后老生常谈地解释一下这两个概念：
　　用户的心理模型，是指用户在和我们的产品交互的过程中，如何感觉到要做的操作，以及产品如何帮助用户来完成这些操作。
　　产品的实现模型，简单地说就是就是开发的具体实现。
　　总结
　　我们的产品应该反应用户的心理模型；实现模型尽量与用户心理模型去靠，让用户看不出背后的技术。（设计的最高境界大概就是用户在我们的产品里沉浸地无法自拔，而对背后的技术实现手段毫无察觉。同事想到日本一位大师的一句真理：＂最好的设计是虚无。＂）
　　3. PRD更新要及时，沟通要快、准、勤
　　观点：这个需求点/这个解释/这个业务要求的依据找不到耶
　　沟通在工作中有极其重要的作用，有时甚至决定一个项目的成败和项目组成员之间的关系。互联网大概是这个时代发展变快最快的行业了，所以我们的需求迭代很频繁。甚至会在搞定了一个需求之后，又因为环境所变将其推翻重来。
　　沟通是如此地重要，一旦不及时，或将会导致需求变形不说，还会引起责任归咎的尴尬局面。所以时刻保持一颗不耐其烦的心，做一个耐撕的人。（意思就是，尽量不要在沟通中带有激动的情绪，不要慌、不要慌~一切好商量~）
　　如果说PD是整个项目的核心人物，那么PRD就是他们最有力的武器了。更新及时的PRD让我们有依据可寻，降低了沟通成本。
　　这一点大家都很了解，在此不多做解释。
　　总结
　　同理心不单单是针对用户，也是对我们身边的可爱的搭档们。让我们一起愉快地做更好的产品吧。
　　以上我说的全都是错的。不喜勿喷。