作为一款热门产品，知乎的设计是如何做到为业务赋能，平衡设计的职能与边界，并不断进阶的呢？

“有问题上知乎”，这句话大家耳熟能详，在信息庞杂的互联网世界，知乎不仅营造了一个洁净友好的社区环境，激起有学之士的分享欲望，还能够给有问题的人提供高质量答案，给回答问题的人充分的尊重与认可。

那么作为一款热门产品，知乎的设计是如何做到为业务赋能，平衡设计的职能与边界，并不断进阶的呢？

一、为什么是产品设计师

通识里互联网职位名称，产品和设计是两种不同的职能，面对产品设计师这个称呼，有人或许会抱有一丝疑问，到底是产品还是设计呢？

其实产品设计师和产品经理的能力要求本身是有部分重合的，称呼并不重要，重要的是产生了什么样的价值。设计就是解决问题，为商业和用户服务的，当职位称呼越笼统，产生权责不明的灰色地带就会越多，从而对人的要求越高，发挥才能的空间和面临的挑战也越大。

二、工作流程职能范围

在知乎，产品设计的工作流程一般分为：需求阶段、设计研究、解决方案、设计输出、设计验收、效果评估，这六个阶段。在流程的前三个阶段是整个项目的发源地，花费的时间最多也是最核心的部分，其中有两个关键节点如下图所示。

Checkpoint1对应的是方案规划期，设计师需要参与进来讨论、评估方案，其目的在于确定方向正确性和可行性，同时制定目标；

Checkpoint2对应的是方案完善期，需要确定具体时间进度和上线计划，如果评审不过的话还需要复盘检查。如果审核都通过了以后，就可以进行Kickoff，明确项目相关方，合理分配任务了。说到这里，不难发现设计这个阶段的周期，其实也是产品也周期，因此设计和产品的目标是一致的，同样都是在解决问题。

现在我们分别对需求阶段，解决方案和效果评估这三个关键点展开细讲：

1. 需求阶段

在需求阶段，产品经理提出需求，设计师将产品需求解构成设计需求。以一个编辑资料的页面为例，产品背后的目标是收集用户信息，完善用户画像，调整算法精准推荐，而设计的需求是使编辑资料页更加方便快捷，以达到让更多人完成资料页的目的。

在这个步骤里，建议产品去提产品需求，而不是设计需求。就像福特公司的创始人亨利说过的话“如果我当年去问顾客他们想要什么，他们肯定会告诉我：一匹更快的马”，假如产品提的需求是更快的马，那对应的设计解决方案可能就是如何造一个更快的马。因此我们需要做的是引导产品，让他们提产品需求。因为用更短的时间、更快地到达目的地的办法，有非常多种解决方案，而不是限制在一个思维里。

设计师可以根据下面四个步骤将是产品需求转化为设计需求。

1. 需求challenge、求证、为什么会有这个需求、是否是伪需求；
2. 了解需求的背景、目标、可达成手段；
3. 了解产品、业务目标和用户目标之间的冲突；
4. 需求的拆解：把产品与业务需求拆解成设计需求。

2. 解决方案

说解决方案之前，先来认识一下直觉与洞察，这里柴柴老师引入了认知脑成像博士研究院杨滢的一段话：直觉是在多层面上的一种统计模式识别，有一种统计上的模式，你的大脑已经意识到了，但你还无法用语言把这个统计学模式，用语言，或逻辑符号，数学公式等方法精确表达出来，这就是直觉。

人的大脑其实是个很强大的统计规律的机器，这种天生的统计学模式要转变成一两句话能够概况的规律其实是很难的，就像我们天生知道苹果要掉在地上，但是牛顿定律却很久之后才被总结，所以直觉是一种天赋，是大脑反馈给你的外部世界的统计识别模式。

直觉模型可以总结如上图所示，中间蓝色信息处理的过程，即决策过程是不能被总结归纳的个人宝藏，如果希望输出的更加准确精确output时，就需要增加input，把目光拉远，锻炼吸收看到不同的东西。

因此我们要善于利用直觉去洞察设计需要解决的问题，按照下方解决方案的一般步骤，从而判断不同设计方案的优劣。

1. 围绕设计目标，提出可能的达成方式；
2. 评估不同的方案优劣（性价比/扩展性/学习成本/友好度等）；
3. 选定设计需求，输出方案。有时候会选定好几个设计方案，上线做AB测。

3. 效果评估

效果评估是流程最后的一个步骤，也是推动产品进步的循环，这个步骤看似简单其实工作量大，一般上线后可以根据如下五个常用评估方法综合考虑，对产品进行下一步调整。

1. AB测试
2. 小流量/灰度测试
3. 用户满意度调研
4. 数据分析报告
5. 用户反馈

但是当某一个数据反馈上比较好，怎么去舍弃在你看来其他方面有很大提升的方案呢？

我们来看下面真实的例子：

• 方案一很大程度上促进了零回答，少回答的用户回答问题。
• 方案二在底部给用户推荐问题，如果感兴趣上划查看更多问题，可以进行稍后回答、关注问题等操作，解决了一些时效问题。

在结合了公司目标以及下一步方向后，最终选择了方案二，因为首日和七日解答率能得到很大程度的提升，用户只要关注问题，在空白时间去回答问题的可能性也增大了。

三、可视化/结构化沟通

1735年俄罗斯的哥尼斯堡有七座桥，方便人们往来于河畔岛上，有人提出这样一个问题：能不能一次走遍所有的七座桥，而每座桥只准经过一次？

很多人对此感兴趣并纷纷试验，却没有结果，直到数学家欧拉想出一个巧妙的办法，用图形表示求解的问题，开启了一项数学分支：图论，一步就证明了该路径并不存在。

因此有时候复杂的问题不取决于我们寻找路径的能力，而是取决于图的性质。图论也就是现在的可视化，文字是非常抽象的，但是人们生来就会看图，图是拉通讨论基础的最有效形式。

我们来比较设计WIKI和产品RFC，这两个文档都会描述项目，但是WIKI是设计师设计的产物，有结构、有主次、有图形、有动效，便于阅读与理解，能够很轻易让不同职能获得信息。因此开发大多不喜欢看RFC，现在我们通常在WIKI里给出RFC链接，做策略的补充说明，帮助所有职能去快速了解项目的全貌。

另外设计师和不同的人沟通同的媒介也不一样，跟工程师用的是WIKI，跟产品经理用SKTECH，跟听众用PPT，跟用户是INTERFACE，这是设计师独有的能力。

四、怎么衡量设计产出

衡量设计产出是一个行业难题，但是我们可以先了解一下其他业务团队的产出是怎么被衡量的。公司的目标一般是个大的愿景，每个愿景里面会拆出一些关键节点，每个节点又会对应不同的动作。按理说所有的小动作加起来应当等于公司大的愿景，但这只是个理想状态，当手头目标太小的时候，就会造成失去目标焦点，当大家都把精力放在小目标实现上，大目标反而无法实现。

拿KPI考核来说，如果按项目数完成考核，这个季度50个项目，下个季度就可能会写到100个；如果按照合作方的评价考核，那下个季度大家就可能就变成舔狗。

考核什么就能获得什么，不考核的东西可能就会在看不见的地方坍塌。太复杂的考核会让员工的动机退化，目标太遥远又会导致我们不知道关键步骤是什么。

回过头来说，产品产出更多是内部视角，以业务为维度为主，更多关注逻辑、流程、结构、投入产出比、收益等；设计师的角度是从用户维度出发的外部视角去看，关注品牌、感受、反馈、用户满意度等。

另外产品的工作一般是以项目为主，一个项目跟进的非常细，深入业务，而设计可能是多个项目并行的状态。“如果都像工厂一样量化，那就不存在好的设计和不好设计”，甚至丧失创意。设计是感性与理性并存的领域，交叉环境非常多，很难单独去做量化。

因而目前设计的考核机制多少都会存在一些问题，这个行业难题等待着所有人去解决。

五、设计的价值

虽然设计产出很难被量化，但是设计师会将设计价值的图表做的非常漂亮，也会花大量的时间去找到自己在团队中的位置，有时还会抱怨自己的付出不被重视，因为我们总觉得用户体验是商业的核心，并且要把这个理念可视化表明这一点——这可能是我们觉得自己价值难以被衡量的一种体现。

其实不一定是身处核心才有价值，我们是好的合作者、链接者，是解决问题的，我们能上能下能文能武能屈能伸，这都是设计师的价值。在现有的OKR体系中，我们不背负具体的业务指标，因此设计作为一个更加中立的存在，发现不合理的地方并与之博弈，也是我们的价值所在。

下面这个图说明设计的独特之处，设计师具备业务广度，会给不同的职能做反馈和能力的补充。产品业务比较纵深，当他太聚焦于某一个模块的时候，设计师就会提醒他关注一些其他的地方。包括在推动一些没有归属的具体项目的时候，都是设计师自己在做全流程跟进，因此设计的价值就在于解决问题，不用太纠结于职能。

最后设计还有一点独有的价值：经久不衰的诱惑——品牌护城河。

例如Apple TV作为一个观看视频的设备，最被用户认可的是它屏保图案，这就好比一家餐厅不是以菜著称，而是以菜单上的字体好看著称。这是一件非常好的事情，公司本身就需要多个壁垒，而品牌如果能够作为自己公司的护城河，就说明这家公司的设计非常厉害，这也是所有设计师为之努力的一件事情。品牌是最难被打破的一条护城河。

六、设计为业务赋能

设计作为跨多业务、多部门的支持，在不同业务的交叉点处，能发现很多问题，因此我们要经常站在业务方的角度去考虑，解决这些问题。这就要求设计师有一定的数据分析能力，拿结果、有数据、有说服力，做的好才能上，做的不好就胎死腹中了。

不仅是设计，在知乎所有职能，数据分析师，技术们主动去推动业务的例子也不在少数。下面这些就是设计师去主导推动业务的成果，包括个人页改版、提问流程优化、换新计划、编辑器插入外链等。

七、进阶的设计师

一个好的设计师，对于业务能力要求非常多，在这里柴柴老师说的是思路上的进阶，跳出职能的束缚，看需求之外更多的那一部分。由此再看直觉模型，这个过程最重要的就是大脑对信息的处理，处理结果有的人准，有的人不准，因人而异。

除了个人能力之外，思想进阶还包括input的量，所以希望大家在工作之余，多去看一下外部的世界。比如设计相关的AI人工智能，交互变革，未来界面；再向外圈延展到互联网进程，5G对公司形态和劳动关系的影响；一层层推展出去到全球经济形势，科技树走向等，都需要设计师时不时的把目光拉远看，不仅要低头走路，也要抬头看天，保持一个成长进化的心态。

Q＆A

有没有实用的涨粉方法？

这个其实是知乎下半年的重点，因为现在知乎的流量分发、曝光主要都是依赖于算法推荐的，在近期的大改版中，会把关注流做一次重构。假如说把算法的推荐做为公域流量，关注流的推荐这种稳定的、可预期的曝光其实是一种私域流量，因此下半年可能会花很大时间在私域流量的打造上，让用户更能知道怎么样才能获得更多曝光，更多粉丝。

不光光是依赖于算法，因为算法的维度更多是以问题维度去做内容的分发，根据用户画像去做一个精准推荐。很多人在吐槽在知乎的粉丝没没什么用，不能换钱，知乎涨粉实在太难了，但是目前还没有一个玩转知乎的方法论。

设计师是怎么推动项目的，以及在推动过程中遇到阻力，知乎是怎么解决的？

项目的推动不是产品经理说了算，产品是我们的上游而不是上级，知乎有一个产品评审委员会，主要的工作就是看看项目能不能通过上文中提到的Checkpoint1和Checkpoint2，至于推动这个项目的是谁，什么职能，委员会并不关心，这对于设计和其他职能的人是有一个很好的发挥空间。

当推动项目的时候，一些简单的管理能力是要具备的，比如推开发进程的能力，数据分析能力。早期就需要去明确指标数据，也可以让数据分析师去帮你定，但是指标的方向是需要自己去把控的，同样要通过委员会的检验。

根据知乎的用户画像，在策略上是怎么迎合用户群体呢？

调性和规模经常是鱼和熊掌不可兼得一种状态，尤其是知乎规模扩大了这么多倍之后，会有一些老用户觉得现在知乎的用户现在都是一群小朋友，只知道看无聊段子的一群人。因为知乎是一个大社区，几乎所都是内容都是用户自己贡献的，投票也都是自发的，所以在产品这一块，没有专门的迎合，但是运营上会有一些。

如何选择效果评估的手段呢？

会有一些比较常规的操作方法，有些项目的决策模型很简单，比如“推荐”的消费决策模型，通过标题就可以做内容相关性的判断，通过概要就可以做内容预判，通过它的数据去做内容质量的判断，这种类型的项目我们再去做AB测试就非常合适。而像“关注”这种，决策模型就非常复杂，信息非常多，决策模型在浏览过程中也会变来变去，因此可以去做一些用户访谈去辅助评估。

作者：柴柴

本文来源于人人都是产品经理合作媒体@58用户体验设计中心（微信公众号@58UXD），作者@柴柴

题图来自 Unsplash，基于CC0协议。