文章概半年前就写完了...这半年发生了很多变动，分享五个最常见的设计思维错误，一直在解决，小编特意将相关的解决方法附上了，最近搞的差不多了，即刻改变，有点时间就整理下发出来吧，现在开始咯。总监是管理、设计双人才，之后争取坚持更新。
最近经人推荐读了一本书，她的好文总结：曾经发表过多篇关于管理、设计和产品团队运作相关文章的 Facebook 产品设计总监 Julie Zhuo，名字是《用户体验要素》，最近发表了一篇文章 〈The 5 Most Common Design Mistakes〉，业内一直视本书为经典。刚拿到它在手上，直译虽然是「五个最常见的设计错误」，很小很薄的一本，不过仔细读文章，并且是英文版翻译成中文，会发现，语句略微晦涩，其实Julie指的应是设计思维，导致读的兴趣不是很高，泛泛的翻了一下，结果发现书中的观点和诠释直白有效，架构分层清晰易懂，对于做产品来说，在树立正确的产品观和培养产品感方面帮助很。所以有感而发写下这篇文章以供个人记录和学，由于篇幅有些长，所以本文分为上下两篇，上篇约5000多字。
内容上讲分为两分：
一、对于《用户体验要素》这本书各个章节的记录和我读完整本书之后的收获，可以理解为读书笔记+读后感。
二、从用户体验出发，谈谈我对于生活和工作中的交互和设计的看法。
水平有限，发表一些浅显的见解当是抛砖引玉，如文章有幸被看到，希望您不吝赐教。
现在是2020年6月，距离这本书第一次出版已经过去了接近20年，这20年中，互联网领域的变化翻天覆地，国内的互联网环境经历了从无到有的过程。从QQ号到腾讯帝国，从用网银的淘宝到现在的阿里王朝，这里面贯穿的商业逻辑无比复杂，各种产品形态变化多端，但最终下发到用户--这个互联网世界中最小的使用单位，对于他们而言，所有的产品几乎都绕不开一个问题：用户体验。
用户体验究竟是什么？有无方？为了好的体验我们能做什么？我想这本书给出了一个很好的诠释。
首先关于这本书的骨骼，上一张图足矣：
本书将用户体验分为了五个层级，这五层也是我重点分析的地方，每个章节我都会提炼书中的观点并转化为自己的理解，应用到所熟悉的产品领域中总结出来。
层
产品目标和用户需求
层定义
成功的用户体验，其核心是一个被明确描述的“”。知道企业和用户对彼此的期许和目标，有助于促进用户体验各方面的确立和制定。然而，回答这些看似简单的问题却不如说起来那么容易。
我们通过这个产品能得到什么？---产品目标
我们的用户通过这个产品能得到什么？---用户需求
关键词--明确，越是明确，越能贴近事实，越能满足双方的诉求
产品目标
1.商业目标
为了表述不宽泛又不狭隘，可以理解为“产品目标”。我们做出的每一个决定，都需要建立在确切的了解它的影响力的基础之上的。要明确定义“成功的条件”，而不是成功的路径。通俗的理解就是想清楚成功需要什么，而不是成功应该怎么做，在这个阶段不要具体到执行层面，专注思考本身，切忌欲速则不达。
2.品牌识别
网站需要描述的一个基础目标就是“品牌识别”。在用户看到某个APP或者网站时，产生的第一印象就会形成“品牌效应”，这是一种情绪，一种潜意识。导致这一切的因素有很多，到布、排版、色调，小到logo，slogan，字体，按钮等页面元素...总之，用户在产生交互的过程中，需要网站去跟他无声的讲述，公司的品牌价值和理念。
3.成功标准
类似于制定OKR，为产品目制定一个标准，即“成功标准”。标准的制定尽量：可落地，可，可度量，可明确的与用户行为绑定。多说一句，关于OKR：是英文Objectives and Key Results缩写，是一套明确和目标及其完成情况的管理方法。按照我的理解，OKR的概念与“成功标准”有着异曲同工之妙，放在这里方便家理解。只不过如果套用在互联网产品上，这个标准可能代表着：
直接影响：PV（访问量），UV（独立访问），点击率（click/view），转化率等等。
间接影响：提高了工作效率，反馈电话减少，订单量激增等等。
但这只是标准，无论哪个都不能决定性的代表着什么，公司的新闻，对手的疯狂推广，都可能影响数据，有时候要退一步，以数据为手段，争取看清楚事情的全貌，辅助决策。
用户需求
用户调研很重要，打仗之前，要看清楚敌人是谁，敌人在哪
1.用户细分
用户是需求方，满足需求的前提是找准我们的目标用户，那么随之而来一个问题：面对庞的用户群体，如何分类？
这个问题的本质是弄明白我们“为谁而战”，从而更好的制定计划。在营销眼里，人口统计学通常作为判断的依据，简单粗暴并且有一定效果，根据实际需要可以调整划分的粒度，比如：“男性，18~35岁”、“男性，20~25岁，白领，互联网行业，收入20k“。但一般情况下，个人比较倾向于基于"消费心态"为主区分用户群体，在这个维度下，相同的消费心态被划分为同一群体，这样可以减少性别、年龄、职业带来的影响。但还有一点不可忽略，即用户群体的专业度，是否熟悉互联网？偏向于技术性产品还是功能型产品？在互联网上花费的时间占生活时间的比例？所以，产品的设计要尽可能的包容，考虑到不同用户群体的诉求。
如果一个中年男性卡车司机喜欢看快手抖音，那么对于快手和抖音的目标用户群体来讲，他和那些20岁的女学生是可以划分到一起的，我想表达的是，在实际划分用户群体的时候，无需拘泥于以上这些维度，最好让规则随着维度动态的变化。还是那个原则：用户细分是手段不是目的。
用户分类完成之后，我们会发现类别和领域可能会很多，但通常情况下，我们的产品无法满足所有人，此时我们就要做出选择，是为单一的群体提供深度的服务还是针对不同的群体提供不同的使用方式，选择哪一种取决于产品目标和公司，结果不重要，重要的是在取舍的过程中，面对可能的风险要“想清楚”，因为此时的策略会直接决定日后用户体验的方方面面。
2.可用性和用户研究
可用性是衡量产品的一项重要指标，它决定了产品是否足够易用，通俗的说，代表了产品使用的舒适程度。对于不同岗位的人，可用性代表着不同的含义。例如我是出身，可用性对于我来讲味着鲁棒性、可拓展、可复用等，是的方法。对于测试来讲，可用性的作用在于以此为目标，去设计case，是一种标准。
用户研究致力于收集信息来达成共识，目的是为了了解用户的想法，行为，动作，预期，反馈，吐槽，建议等等，方式不限于用户访谈，调查问卷，提供原型给用户试用等等。
3.创建人物角色
现在我们通常叫做创建用户模型，通过了解用户的各种特征使其形象更为饱满，在迭代的过程中保持方向的正确，有助于优化整体的用户体验。
范围层
功能规格和内容需求
明确我们和用户想要什么，才能将功能和内容设计的更精准。需求转变为具体的功能，这个过程中，就变成了范围。
范围层定义
关于“为”和“不为”。
原因#1：这样你才知道你在什么
团队在干什么，每个人都以为自己知道，但在没形成文档之前，这些认知都不准确。用现在的语言定义，需求文档就是这个阶段的输出物。他会让产品，，运营，老板等各个方面知道我们在干什么，应该怎么干。明确的文档和详细的计划，有助于各种角色知晓自己的职责范围，这样有助于项目的推进，也一定程度的预防出现问题之后的甩锅和扯皮现象。
原因#2：这样你才知道你不需要什么
需求收集阶段过后，面对海量的需求，产品经理不该迷失，找准痛点和痒点，要敢于将不符合产品长期价值的，不利于公司利益的需求果断砍掉，将剩下的需求划分优先级，结合成本和人力还有市场需求等方面合理设计产品，掌握迭代的节奏。对于这一点我深有体会，做系统之前一般会先收集需求，之后评审，但是通常情况下，评审团队屁股所在位置不同，评审的结果参考意义不，导致做出的需求使用频率，重要程度都不是很符合预期，这就是无效的需求--只解决一小分人，在某种特殊情境下遇到的问题，虽然在某些时候他们很需要这个功能，但对比功能的成本来讲，就显得微不足道。所以个人觉得产品要学会取舍，在茫茫需求中穿针引线，保证核心功能又考虑到成本、紧急程度、重要性等因素，准确的安排迭代计划，这其中的尺度拿捏，才是产品经理能力的体现。
功能和内容
这个分先上一张图（手机拍摄，渣画质见谅）：
从图中我们可以得知，在范围层，一般将产品分为“功能性产品”和“信息型产品”。
通常来讲，这两种产品的目的是不同的，但在“范围层”，他们的概念可以通用。一个功能性产品，往往伴随着内容型产品的特性，比如说“设置”中，是否应该加入说明，告诉用户在这里能做什么，在用户操作出错的时候，是否应该使用模态框或者高亮来提示用户，这也是一个有深度的问题。在使用各种系统和软件的过程中，我有时会看到“对不起，您的输入有误”，或者在一个概有20项的表单辛辛苦苦写完之后，告诉我“信息有误”...这样会让用户产生疑问：到底哪里有问题？我应该怎么做？通常试了几次之后用户就会失去耐心从而关掉页面，这种情况在注册app的时候同理，所以在针对各种异常和边界情况的时候，应该有个信息提示，这个信息不该是简单的文本描述，而是应该有共情的思维，考虑到身为用户他们希望得到哪些指示，把这些揉进交互的流程中，才能得到良好的用户体验。
定义需求
在定义需求时，切忌“坐井观天”。时刻记住：“需求的源泉永远是用户”。这个源泉取之不尽用之不竭，但是实际情况中，比较小的项目需求却主要来自于与项目强相关的同事，这是很危险的情况，不要让别人影响产品的走向，除了用户。上面提到了解需求最有效的方式就是直接询问，用户调研有很多方式，但面谈永远是最直接有效的，在工作中针对那些核心需求我也是这么做的。还有我想说，想法，意见，描述的东西，想要的东西，需求，和最后落地的功能，永远是6个东西...很多情况下，解决问题的方法并不是线性的。如果按照：用户提出想法---产品规划对应的功能---让技术去功能这个路线的话，那么产品就会随时间愈发臃肿且不治本。还有一种情况，我用一个被举烂的例子说明：用户想要一匹更快的马，但其实他们想要一辆车。这个例子说明两个问题：
1.用户并不知道他具体想要什么
2.好产品的目的始终是更好的满足需求
用户的想法很简单，为了解决两点之间的交通问题，他们想出来的解决方式是“更快的马”，但作为产品，应该透过用户的反馈看到最核心的诉求：如何更快的从A到达B。那么针对这个诉求，用车显然更好。
还有上文提到的用户画像，也是定义需求阶段常用的方式，从功能设计者瞬间变为小白，换个角度去看待需求，往往会有新的启发，即“同理心”。
功能规格说明
这个说明可以理解为需求文档，接口文档等等，总之完整的描述各种功能是文档的目的所在。那么问题来了，很多同学觉得在实际工作中文档是最不可靠的，任何变化都可能导致之前的努力付之东流，想必的同学都懂。确实，文档并不能解决根本性问题，但定义可以。文档的作用不是记录所有细节，而是准确清楚的呈现定义。我所理解的文档是定义的载体，不是功能说明书，能避免发生一切模棱两可的问题，这个文档的任务就完成了。
在写文档的过程中注意三点：
1.解决方案避免简单粗暴
“不允许未注册用户登录”换成“如果用户未注册，引导跳转到注册页面”。
2.明确定义
“最受欢迎的网站，放在top10展示”换成“点击率的网站，放在top10展示”。
3.理性
"网站风格要简约"换成“UI减少按钮乱用，功能模块使用卡片区分，使用低饱和度的配色”。
内容需求
内容不仅包括文本，还有图像、音频、视频等，很多时候他们的作用要比文字重要，不同的内容形式可以相互配合，协作完成某一需求。例如新闻报道和视频网站。内容多的网站让人看起来不那么疲劳，是一个提升体验的有效方式。内容容易让用户接受，一篇好的内容板块，可以显著提升访问量等指标，但在决定使用内容之前，要尽早的确定对应内容元素的负责团队，以确保内容一直是被维护的状态。内容维护不易，设计产品时要注意成本，谨慎使用。
确定需求优先级
需求收集应集思广益，而且指点别人总是很容易的事情，所以日常中我并不担心收到的需求会很少，其实更应该担心需求的质量。上文简单提了一下和需求的关系，需求应该紧贴，这无可厚非，但通常他们并不是一一对应的关系。需求可以满足多个，一个也可能通过多个需求才能满足，这时候优先级的重要性就体现出来。常见的被列为低优先级的情况：技术限制、成本限制、资源限制、时间限制、影响范围太等。偷偷告诉家，在常见的解决方案中，分版本迭代通常可以解决分的问题，原理类似于重启电脑可以解决分的windows问题...其他的因素结合情况考虑，例如申请资源支持、拉通门推进、更新系统技术架构等等。
当然，这一切都要建立在已经砍掉了不合规的需求之后，剩下的需求符合公司并且理论可行的基础上。
结构层
交互设计与信息架构
结构层定义
上图：
说完了以上两层范围和决策问题，我们就需要关注具体的实现方式层面。结构层的粗略分类也是分为功能性产品和信息型产品两种，在本书中对结构层的定义主要包括交互设计和信息架构，虽然我认为在现在的时间点，做一个产品需要考虑的东西不止这些，但我们暂时不扩展，先按照书中的思路去理解就好。
需要说的是，交互设计和信息架构都在强调一个东西：确定所有呈现给用户的元素的“模式”和“顺序”。
...
免责声明：文中图片均来源于网络，如有版权问题请联系我们进行删除！
