追逐我们的星辰大海：2021年总结（上篇）

2021-12-29 05:13:00

编辑导语：到了年尾，是时候开始对2021这一年来的工作进行总体复盘了。在这一年中，你获得了哪些经验或教训？达成了什么成果？你对产品、项目等，又有哪些新的感受？本篇文章里，作者从设计的角度出发，对自己在产品设计方面所得到的经验做了总结，一起来看一下吧。

不论是在任何年纪，我们都是最好的我们。虽然有失落，但不要放弃，你会成为自己喜欢的样子。愿我们都能用最好的状态，迎接那个昂扬向上的自己，因此，阶段性总结很有意义，让我们一起奔跑起来吧~

2021年马上就要结束了，这一整年经历了很多，有失意也有收获。但对未来的自己来说，不论收获了什么，仅仅只是开始，任重道远，Fighting~

今天，我总结了一些印象深刻的点，和大家分享下。

一、客户第一的坚持

从业B端领域的小伙伴并不陌生「客户」一词，时常可以听到老板们说：“将客户第一放在心中，及时满足客户需求，才能实现销售增长，利润翻翻。”在阿里巴巴内部，也总是谈到将“客户第一”始终放在第一位，只有帮助客户实现成功，我们才能成功。

今年，我也深深感受到了客户第一的重要性。

这一年，很多产品方案和设计方案是自己亲自和客户沟通的，在沟通中我发现，如果在方案开发完成前，我们是有提前与客户就方案达成一致的，那么客户认可与使用该方案的可能性将更大。

这大概是因为客户感受到了尊重，感受到了哪怕是一个很小的需求，我们也能给出及时地回应。当整个团队持续坚持客户第一时，我们团队满意度比去年得到了很大的提升。

虽然说，客户也会有提不合理需求的时候，但我们始终要考虑「如何帮助客户获得价值」。在产品设计上，多和客户探讨；在客户不理解我们时，多多保持微笑，积极解决问题；站在客户立项思考问题，争取满足客户也成就公司与团队。

二、以用户为中心

以用户为中心是一种服务理念，也是一种设计思路。不论是B端，还是G端，还是C端产品，现在都越来越强调采用以用户为中心的体验设计策略。不考虑用户的产品，在这个竞争激烈的市场已经越来越难以生存下去。

我们今年服务了企业级DevOps产品。在设计支持的过程中，我们一方面要考虑客户诉求，另一方面我们也不可忽视用户需求。

一次，由于我们遗漏了用户的某个需求，导致直接被用户吐槽设计不行，要是不把这个问题改好，就不使用了。企业内部用户这么说，我们还有补救的机会，对于推广给外部使用的产品来说，也许用户（员工）就会直接反馈给购买部门，该产品不好用，建议换软件、换厂商。

以用户为中心并不是说什么都要听用户的，而是说需要用我们的专业能力帮助用户解决问题。如果我们可以帮助用户解决问题，用户就会越发依赖我们的产品；如果我们忽视了他们，他们可以选择不使用。

三、功能与美的理解

如何在产品设计中平衡功能与视觉美感，是一个永恒的话题。我自己感觉，office的三件套（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端设计师会跟进多个产品，很难做到非常了解一个产品的业务，因此设计师经常被产品团队吐槽不懂业务已经是常态了。但是要想设计出好的方案，就不得不理解业务。

这一年，我们团队支持的产品不计其数，大多都是逻辑复杂、业务复杂的中后台系统，例如数据中台、低码平台、监控运维系统、云原生系统、实时数仓等。我们在服务这些产品的时候，发现了一些规律：如果我们只听从产品经理说的，那设计结果基本和原型、竞品没有太大区别；如果我们可以多了解一些业务，输出更好用的设计是存在可能的。

举个日期选择器的例子。

很多组件库都会提供带快捷方式的日期选择器，一般设计师会直接拿默认提供的日期选择器给产品用，但在特殊情况下，默认组件并不合适产品。在平均周活统计模块中，就会有特殊快捷选项要求，例如近一个月、近两个月、近半年等，默认的日期选择器组件并不适用，因此，设计师需要挖掘业务需求，对默认组件进行合理改造。

设计师了解业务是一个不断学习，不断思考，不断总结的过程。我们不要做个只会搭建界面的设计师，而要做个懂业务，从业务出发思考设计方案的设计师。