当然，我不是要写一篇文章教大家如何做好一款产品。一来我的积累还没到这个程度，没这个资格；二来我觉得方法论有很多，再长的篇幅也无法穷尽。我只想站在一个软件开发人员和普通用户的角度来谈谈自己的想法。

What

这个世界上，能用的产品很多，好用的很少。行业称 User Experience 为 UX，很多公司都有自己的 UX 设计部，研究怎么把用户体验做好。我没在 UX 部门工作过，也不知道他们是否有高深的理论去支撑整个决策过程，但是以我目前对产品现状的观察，即使有理论支撑似乎也并没有起到什么显著的效果，UX 设计好坏的瓶颈目前来看，可能根本就不在于理论。今天撇开大公司病之部门墙、互相甩锅等不谈，即使 UX、研发、测试一家亲，想他部之所想、急他部之所急、成他部之所愿，共同为产品的成功而努力，产品就一定能做好了吗？我看也未必尽然。
咱就放过内部产品不（忍多）说，把讨论的对象限定在交付给用户的产品上。因为每个公司肯定都是以客户为本，必然要将客户放在首位，内部员工的体验自然比不上用户的体验优先级高（虽然于情于理，我们也是内部产品的「用户」）。以此价值观，交付给用户的必然是综合能力之上限，呈现给内部员工的可能是能（忍）力（耐）值之下限。然而，上限就能让人满意吗？我看也够呛，至于下限之悲惨，就更不必提了。
在大部分时间里，我们每个人的角色都是各种各样产品的用户，只有很少一部分人，能参与到一款产品的开发中。在这里，我不想讨论产品经理要不要把用户当成傻子这类「终极问题」，只以结果导向：用户将产品拿到手之后是否满意。我们今天说的产品并非生产力工具：Photoshop、AutoCAD、Visual Studio 这些，我们讨论的是 Jobs 口中「It just works」的产品。如果谁对产品的设计要求不及至此，那也自动不被列入今天的讨论范围。生产力工具在设计时是可以基于用户具备相关专业知识且可以承受较高的上手成本这两种假设的，生产力工具当然也需要好用，但是对于普通用户来说，几乎是无从感知的。普通用户需要的是近乎零成本上手、不基于产品经理脑袋中的假设就能自由使用的产品。

Why

首先什么是好用？人都是非常懒的，除去那些热衷于破解谜团的人，我想大部分人都希望所用的产品越简单、越直观、越方便越好吧。那为啥我们一群人忙活半天，费了九牛二虎之力搞出来的东西，不尽如人意呢？
我想，我们都基于了一个假设：我们觉得好，用户就觉得好。
一款软件，如同一本书、一首歌或者一部电影一样，是信息基于载体的传递过程。如果我们配合得足够默契，那么生产者和消费者之间是能产生共鸣的：作者构想出的光怪陆离的世界，读者可以仿佛身临其境；音乐创作者的细腻情感，听者也能感同身受；电影主人公的悲欢离合，观众也能为之动容。然而可怕的事实是，发送方与接收方的知识体系、认知层次、思维背景并不对等，信息传递过程常有谬误。
我在这故弄玄虚提出一个公式：UX = f(Design)，用户的真实体验和交付前的产品设计之间存在一个映射，因此 UX 和 Design 显然不可预期是相等的。我们关注 UX，关注的并不是输入（开发者做了什么），而是输出（用户感受到了什么）。你可能觉得这真是句废话，别着急，产品开发人员真的没有几个能做到废话表达的真理。
现在一个常见的问题是：测试这个角色的主要职责是保证工程质量，没有 Bug，对 UX 介入甚少，体验不佳往往算不上 Bug，优先级不高；UX 不懂技术，要参考开发的意见，开发说不能实现，UX 就不再做过多设计，开发的水平和自己的话语权成了 UX 工程师的天花板；而开发，大都有一个毛病，就是只对技术感兴趣，并不关心 UX，功能实现就老子天下第一。这就形成了一个死循环，一个观察不一定对：对于最终用户体验，开发的话语权似乎更大一些，UX 沦为了给开发做界面的。UX 还从何谈起。
作为一个开发，忍不住想多说两句开发这个角色。身边大部分开发人员是缺乏审美能力的，这个固然和我们从小接收到的美学教育有关，这里不再说了。总之，想要求每个研发人员都能 Handle UX 是不现实的，那还要 UX 干啥，不真的成了美工、做界面的了吗。但是，一个有理想，有抱负的程序员，在功能实现之外，还是要关注一下 UX 领域的东西，尤其是大公司的程序员。我觉得，很多独立开发者是我最理想的工作状态，他们往往身兼数职，既做需求规划，又做架构设计，又做 UX 设计，又做程序开发和测试，甚至还能做营销。自己和自己配合自然是最默契的，最后产品的完成度也最高。但是项目复杂度的提升终究会使单人甚至一个小团队应接不暇，这时就出现了分工合作，就和生（人）物（类）进化史一样，我们要在提高合作效率上费尽心力，这是一个逃不开的「固有困难」。我只能说，在挖掘知识深度的同时，拓展知识的广度是同伴间协作的粘合剂，对提高合作质量是非常有帮助的。

Where

嗯哼，Where 有一些强行上镜的意思。
虽然我一直用「产品」这个词，但是说来说去都是软件开发的事情，这当然是因为软件开发是我最熟知的领域。不过我相信，其他领域也肯定是有相似的问题的，这个讨论是具有普适性的。

How

我们被大数据惯坏了，有了大数据，很多问题解决起来似乎简单了不少。我们给按钮加上埋点，灰度测试，仿佛这样就能分析出用户的行为模式，描绘出所谓的用户画像，知道用户的喜好了，还何谈 UX 设计不好？真的是这样吗？
我们也被迭代换坏了，开发迭代固然可以做 Bugfix，但是用户感知的迭代理论上只应该是 Feature 的增加（使其更加好用也勉强算是个 Feature 吧）。迭代不是先把功能糊弄出一版，然后每轮迭代修修补补，逐渐完善，这是需求规划能力、架构能力、开发能力不足的体现。我理解的迭代，是先把核心诉求完成，搭出最基础的框架，然后逐渐往上添加 Feature 的过程，每轮迭代增加的 Feature 都要做到尽善尽美，每一步都走得漂亮，和修修补补完全不是一码事。
用户可以懒，但开发者不能懒。
在我看来，不到万不得已，真的不至于动用大数据和迭代这些手段去解决 UX 的问题，这样给人的感觉更像是拎着锤子找钉子、抱着教材找习题。很多设计上的问题，只要肯动动脑子，就可以解决的。关键在于，无论是专业的 UX 工程师还是程序开发工程师都应该在潜意识中埋下一粒种子：「站在用户的角度思考问题，把自己当成用户去设计产品」。然后再在随后的工程实践中，不断让这颗种子生根发芽。
之前忘记从哪儿看的了（好像是马爸爸说的吧）：「做需求设计的时候不应该考虑工程实现」。当然你可能会觉得这么说有点绝对，工程上实现不了、产品做不出来，需求再 Cool 也毫无意义。但是这句话的意义不在于此。很多时候，开发人员觉得的不能实现其实并不是真的不能实现，不然所谓黑科技是怎么来的？技术壁垒是怎么形成的？我理解这句话真正的指导意义在于，我们在需求设计之初，不应该将自己先框在一个自设的小圈子里。就像架构设计时，要把「核心诉求」和「优化」分离一样，Framework 应该是 Open 的，面向拓展的，而不应该是封闭的，那样路只会越走越窄，最终死路一条。这句话之所以让我记忆犹新，是因为看到这句话之前我也做过几个软件课程设计，姑且也算个小产品吧，可能也是当时水平还不行，做东西要先看自己会啥，再看掌握的这些技术能拼凑出个啥东西，虽然我的课程设计算是同学中做的比较突出的，但是离自己的要求还是差了一截。直到看到这句话，我才茅塞顿开，是我本末倒置了。
现在仍有许多人，会以「这个实现不了」作为搪塞。其实不是「实现不了」，而是「懒得实现」。或许真的也是迫不得已而降低要求，But who cares？产品在妥协的无奈于权衡的艺术之中诞生，能做到什么程度，取决于我们的自我要求。

尾声

一篇写下来，零零碎碎，感觉也没讲明白什么事情。时间有限，先写这么多，就当是发发牢骚，聊聊天吧。

转载自我的公众号 2019-01-22

语雀内容