编辑导语：年底了，是时候开始对2021年的工作进行全面回顾了。这一年你获得了哪些经验或教训？取得了哪些成绩？你对产品、项目等有什么新的感受？在这篇文章中，作者从设计的角度总结了自己在产品设计方面的经验。让我们一起来看看。
不论是在任何年纪，我们都是最好的我们。虽然有失落，但不要放弃，你会成为自己喜欢的样子。愿我们都能用最好的状态，迎接那个昂扬向上的自己，因此，阶段性总结很有意义，让我们一起奔跑起来吧~
2021年即将结束。这一整年经历了很多，有挫折也有收获。但是对未来的自己来说，不管你得到了什么，这只是一个开始，还有很长的路要走，Fighting~.
今天总结了一些印象深刻的点与大家分享。
# 1.坚持顾客至上
B端领域的小伙伴对“客户”这个词并不陌生，老板们常说：“只有把客户放在第一位，及时满足客户的需求，才能实现销量增长，利润翻倍。“在阿里巴巴内部，我们总是说要把“客户第一”放在第一位。
只有帮助客户实现成功，我们才能成功。
这一年，我也深刻感受到了客户至上的重要性。
今年，很多产品方案和设计方案都是亲自和客户沟通的。在沟通过程中，我发现如果我们在方案开发完成之前，就已经提前与客户就方案达成协议，客户认可和使用方案的可能性会更大。
这大概是因为客户觉得尊重甚至是很小的需求，我们都能及时给予回应。当整个团队继续坚持客户至上时，我们的团队满意度相比去年有了很大的提升。
虽然说客户有时候会提出不合理的要求，但我们总要考虑“如何帮助客户获得价值”。
在产品设计上，多和客户探讨；在客户不理解我们时，多多保持微笑，积极解决问题；站在客户立项思考问题，争取满足客户也成就公司与团队。
#二。以用户为中心
以用户为中心不仅是一种服务理念，更是一种设计理念。无论是B端、G端还是C端产品，越来越强调采用以用户为中心的体验设计策略。无论用户的产品如何，在这个竞争激烈的市场中生存越来越困难。
今年，我们为企业级DevOps产品提供服务。在设计支持的过程中，一方面要考虑客户的需求，另一方面也不能忽视用户的需求。
首先，因为我们错过了用户的需求，所以不可能由用户直接设计。如果我们不解决这个问题，我们就不会使用它。内部用户这么说，我们还有机会补救。对于推广外用的产品，可能用户(员工)会直接反馈给采购部门，产品不好用。建议更换软件和制造商。
以用户为中心并不是说什么都要听用户的，而是说需要用我们的专业能力帮助用户解决问题。
如果我们能帮助用户解决问题，用户会越来越依赖我们的产品；如果我们忽视它们，它们可以选择不使用它们。
#三。对功能和美的理解
如何在产品设计中平衡功能与视觉美是一个永恒的话题。感觉办公三件套(ppt、word、excel)整体功能很多，但视觉美感还不错。
不过话说回来，对于普通用户来说，office中80%的功能都是不常用的，而这80%的功能也导致了产品界面视觉的臃肿(这是臃肿了不少，但并不代表界面凌乱)。
对于B端产品来说，恰恰是功能极其丰富。有时，一个配置项目中可能要填写几十个项目。在这种情况下，如何做到功能与美观兼顾，是对设计师设计能力的考验。但是在对客户和用户的调查中，我们发现其实B端用户并不太在意美观，他们更在意界面是否整洁，界面布局是否提高了我的工作效率。
因此，功能和美，在B端有特殊的含义。
它可以功能丰富，但不要全堆在界面上。您可以展示基本功能，并通过引导向用户展示高级或扩展功能，就像包豪斯的“少即是多”原则一样。美观是指界面整洁，信息区分清晰，重点突出，配色不太单调。
#四。推广标准和规则
我接触设计标准和规则的制定有一段时间了，主要是企业级设计标准的制定。所以在标准的制定和推广的道路上，我积累了一些小经验。
从标准思考、标准审核、标准修订到标准推广落地，虽然持续了很长一段时间，经历了无数起起伏伏，但最终锻炼了自己，积累了很多实践经验。
在制定标准的过程中，不可避免地要经过几轮的审查和修订。事实上，当我第一次开始这样做的时候，我相对来说是抵制重复修改的。毕竟还是有很多任务同时在手，反复审核修改非常费时。但是当标准逐渐确定的时候，我很开心。一是标准已经获批，二是标准即将进入下一阶段。
还有一点，对于标准本身来说，最难的不是制定，而是如何落井下石，让每个人都能认可，有序持续地执行。
，这部分也可以专门写篇文章，门道不少。关于标准和规则一事，我最想说的是：如果你的企业允许，并重视标准，你可以提议建立一些标准。
标准确实是一个解决混沌局面的方法，它可以建立最佳秩序，并可以在一定程度上帮助持续提效。
# 五、实践出真知
古人云“读万卷书，不如行万里路”。说的是读的书再多，也不如实实在在去干，从实践中获得道理、知识、学问来得更有价值。
今年，我无数次被这句话深深影响到了。这里举两个例子，第一个例子是“我以为互联网系统多采用表格翻页交互，机构中后台系统也能接受，其实不是”。第二个例子是“我以为面包屑导航是万能导航，其实不是”。
现在来具体说说这两个例子。
第一个例子是我们将表格页设计成了非常常见的翻页交互形式，但方案一拿出去，就被客户否定了，客户认为翻页交互对于操作效率来说是极大的下降，他们更喜欢「预加载+虚拟滚动」的交互模式。
第二个例子是我们采用非常通用的面包屑导航，也被客户当场否定，客户认为面包屑无法支持多页面需要同时切换操作的场景，而标签页很合适。类似的例子，数不胜数。
由此我们可以发现，不论哪种被熟知被较好的设计策略、设计形式、设计模式，遇到不适用的场景都会翻车，实践才出真知。
我们唯有不断经历、不断试错，努力积累经验，让自己在深耕的领域遇到问题处变不惊、游刃有余，其余并不能肯定以及确定什么真理。
# 六、借鉴经验但不盲信
随着我们在某一领域专注越来越久，遇到的事情越来越多，我们便会积累很多可以被复用的知识，这些可以被称之为经验。
我们的绝大部分认知都来自于经验，绝大部分决定都可以见到经验的身影。那经验都是好的吗？
有些时候，经验确实对我们起到了一定的指导作用。例如我们看到发霉的苹果知道不能吃，吃了会拉肚子，于是由于我们没有吃发霉的苹果，使我们规避了生病的风险。但有些时候，经验反而是束缚、是枷锁，它妨碍了我们去突破、去思考、去创新。
在界面设计的时候，遇到文字太长排版不下的情况，我们通常会处理成无法显示的文字用省略号表示，然后配合鼠标移上去出现全部提示的交互。
但这个方法在快速下单场景下不适用，这种看不到关键信息的设计模式会导致用户觉得操作很不便捷，进而降低下单效率。后来我们把它改成了文字折行全显示，虽然展示上不美观，但很实用。
如何摆脱经验的影响，我想，保持质疑、寻根、创新、空杯的心态很重要。 对任何已知的事物依然保持开放的态度，而不盲信经验陷阱。
# 七、依靠基建向上构建
现在越来越多服务B端的大厂，不止步于仅仅完成B端产品，交付给客户这件事。无论从中台打造、数据建设、设计体系探索方面，还是研发流程建设方面，他们都有规划、探索与实践。他们有些还在着手打造B端基建，通过基建赋能业务。
大家最熟悉的莫过于蚂蚁的Ant design了。Ant
design从提效和体验出发，360度全方位打造B端基建，例如UI基础组件库、AntV图表、pro解决方案、kitchen工具集等。
对于小公司来说，基本不会所有B端基建均自研，但这不是说B端设计师完全不需要思考这方面的事情。
例如构建产品/企业基础UI组件库还是可行的，有条件可以再沉淀一些通用模板、区块，这样可以极大提升产研效率。我们公司在B端基建方面做的也不算早，目前实际的产出也不是很丰富，但通过这些基建的搭建，我们还是感受到了提效。
例如有了基础UI组件库后，企业内部产品都可以直接调用，无需每个产品单独开发一遍。再例如从企业级角度，我们梳理了复用性极高区块、页面模板，通过共建、评审、宣讲的方式让设计师都知道怎么用，大大提升了设计师的工作效率。
B端基建是企业级产品向上持续构建的基础。
这一年我们围绕基建做了很多事情，切切实实感受到了建立一套符合企业级需求的基建并不容易，变幻、丰富的业务诉求，是B端基线直线构建上的拦路虎，它让我们的构建变得曲折。不过，这也使得基建更经得起时间推敲。
# 八、理解业务，重塑设计
通常一位B端设计师会跟进多个产品，很难做到非常了解一个产品的业务，因此设计师经常被产品团队吐槽不懂业务已经是常态了。但是要想设计出好的方案，就不得不理解业务。
这一年，我们团队支持的产品不计其数，大多都是逻辑复杂、业务复杂的中后台系统，例如数据中台、低码平台、监控运维系统、云原生系统、实时数仓等。我们在服务这些产品的时候，发现了一些规律：如果我们只听从产品经理说的，那设计结果基本和原型、竞品没有太大区别；如果我们可以多了解一些业务，输出更好用的设计是存在可能的。
举个日期选择器的例子。
很多组件库都会提供带快捷方式的日期选择器，一般设计师会直接拿默认提供的日期选择器给产品用，但在特殊情况下，默认组件并不合适产品。在平均周活统计模块中，就会有特殊快捷选项要求，例如近一个月、近两个月、近半年等，默认的日期选择器组件并不适用，因此，设计师需要挖掘业务需求，对默认组件进行合理改造。
设计师了解业务是一个不断学习，不断思考，不断总结的过程。 我们不要做个只会搭建界面的设计师，而要做个懂业务，从业务出发思考设计方案的设计师。
# 九、建立同理心
同理心指的就是共情的能力，其实也就是我们常说的换位思考。不仅在产品设计上我们要注入同理心，在人际交往过程中也要多体会他人的感受，站在对方的角度考虑问题。
这一年，我们团队与外部的协作更多了，这就非常考验我们的同理心，假如我们只站在本部门的立场考虑问题，与外部协作的难度就会变大。
一次在会议上，我们作为推广方讲述自己的方案，在完成方案讲述后，业务方提出了很多意见。有了之前多次方案推广的经验，我在回复业务方的问题时，不断告诉自己要有同理心，否则很容易让会场变成战场，这样不仅解决不了问题，还伤了和气。多考虑他人的诉求，让方案通过和认可的几率也会变高。
不论我们面对一件事情、一个人的时候是否带有情绪，我们尽量将同理心放在首位，这不仅理解了他人，也帮助了自己。
# 十、找根因，输出解法
根因分析是一种结构化处理问题的方法，使用根因分析的目的是为了找到问题发生的本质原因，从而找出合适的解决办法。
为什么说找出根因很重要，因为如果不找出根因，我们只能用修修补补的方式解决问题，看似一个个问题都被暂时解决了，但其实存在很大隐患。
一次，客户和我们说想要组件上加上快捷键，这样子他们可以用键盘操作，于是我们输出了组件键盘方案，研发团队也实现了，但上线客户方后，客户并不满意。他们指出，不仅要键盘可以操作，还要提效。
于是我们分析现有组件键盘交互的逻辑，从整体使用角度出发做了优化，研发修改落地。
这个事件中，我们没有找到客户需要组件带快捷键的根本原因，导致花了很多本可以节省的时间和人力。
再说一个协作上的事情。我们团队除了支持本部门以外，还会支持其他兄弟部门的设计工作（与其他部门我们会进行费用结算），然后期间发生了一个件不太愉快的事情。
我们费用计算出来后，需求方并不认可此事（原因在于他压根不记得发生过该事情），然后我们的小伙伴一直跟他沟通，是发生过此事的。虽然需求方勉强认可了，但最终走流程时他还是反悔了，这导致流程不得不终止。
随后，我问了多个相关人员一些问题，了解到需求方和设计师之间一直是有个中间方在传达需求的，因此导致需求方忘了此事（其实是对对接的设计师没有印象），于是我们带上了中间方一起去沟通，终于把事情解决了。
在根因分析中，专业人士经常会推荐大家使用5why法则，这是丰田公司的大野耐一首创，从连续至少问5个为什么中去找出解决问题的方法。
打破砂锅问到底，沉下心来思考为什么，不急于先动手，是职场中好用的方法。
# 十一、跑闭环、做验证
常常听产品经理说，做产品要用MVP方法、要采用闭环思维，我想说，做任何事情都可以多考虑「闭环」和「验证」思维。
简单来说， 闭环就是做事有始有终，而不是有开始没结尾。 做事不考虑闭环的人，大多给人做事不够仔细，不够专业的感觉。
我们团队有一名设计师，他不论接到任何需求，都是有始有终的做法。他遇到暂时不能按时完成的任务，会及时进行沟通，随时进行反馈，并给出可以临时替代的一些方案，这让我觉得这个同学很靠谱，安排给他任务很安心。
我们常听说“验证一下设计方案合理不合理、验证一下流程是否可以跑通、验证一下这个测试用例有没有问题、等等”，可见验证的要求在职场随处可见。
验证可以说是闭环的下一步，完成闭环后，我们就要考虑去验证， 验证成功的方式，是我们下次遇到同样问题可以采用的方法。
炒股的小伙伴最喜欢验证，验证自己每一次的炒股方法是否有效，假如有效，就会再次使用。
职场中，「跑闭环、做验证」需要我们一直记在脑海中，不论什么场景，都适用。
## 末：星辰大海
德国哲学家伊曼努尔康德说： “人世间最神圣恒久而又日新月异的，最使我们感到惊奇和震撼的两件东西，是那头顶上的星空和我们心中的道德律。”
是的，即使我们只是渺小的打工人，我们也可以有自己想要去探索与征服的星辰大海。
## #专栏作家#
知果，公众号：知果日记，人人都是产品经理专栏作家。浙江工商大学品牌设计专业硕士，《B端思维-
产品经理的自我修炼》作者。在产品设计流程、产品设计原则、产品设计方法、产品设计规范方面均有丰富经验
本文原创发布于人人都是产品经理，未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
