我不是创业者，而是设计师

王俊煜

7月专栏的结尾，我提到了在我们邀请几百位创始读者进入阅览室后发现的新问题，即“先锋读者”和“读者”在产品中的“地位”差别过大。这个问题纠缠了我们两个多月的时间，直到7月底我们发布了一个新的版本，才算暂时告一段落。

回顾整个过程，其实“设计”花的时间远远比“开发”要多。我想可以借这个过程，来讲讲我对“设计”的理解。

我不喜欢自称创业者、企业家，但我喜欢叫自己设计师。2007年本科毕业，我放弃成为一名物理学家的职业路径，而是选择加入Google，成为一名用户体验设计师。家人虽然尊重我的决定，但也多有不解，因为在一般人看来，“设计师”对口的是美术专业，物理专业的毕业生不应该去从事这份工作。

经过15年的发展，今天的主流看法……我想依然如此。甚至，像老罗这样的宣传，可能会让更多的人觉得判断设计师好坏的标准就是画出来的拟物图标好不好看。这当然是设计师工作的一部分，但远远不是全部。

我其实也不太会画画。好在，当年Google的设计师也不怎么需要会画画。在Google时有机会和世界一流的设计团队一起工作，也开阔了我的眼界，让我坚定地认为设计师是我可以终身从事的职业。今天，我认为设计师的工作职责是“创造性地解决问题”，这几个字听起来很抽象，可能也很宽泛，但经过这么多年的反复推敲，我想是准确表达了我的意思的。

所以，在工作中遇到这样一个需要创造力来解决的问题，就是一个发挥设计师专长的机会了。

解决问题的第一步是确定目标—我们为何要解决这个问题？一般来说，就是业务当下面临的某个挑战。

我们辅导其他团队完成这个过程时，业务挑战一般需要业务的负责人给出。设计师可以用一些工具框架来引导决策者给出更准确的挑战，但许多人会很容易脱口而出一个“本质上”的答案，可能是因为领导们都要显示自己高屋建瓴、很有深度。但“本质上”的答案往往过于宽泛，对解决具体的问题没有什么帮助。比如，假如说一个公司的本质是更好地创造价值，所有的公司都会度量利润，然后我们开一个会讨论“如何更好地创造价值”，那很难有什么有用的结果。互联网上很多人喜欢指导别人如何做企业，往往说的就是一些永远正确但没有实际价值的道理。

每一个商业都应该有自己独特的挑战，做商业策略的乐趣本来就在于如何将宏大的目标落到具体的机会点上，一步一步解题，知道每一步应该做什么、不做什么。

对阅览室来说，在那个时候的业务挑战是希望提升读者的满意度。阅览室是个小生意，作为一个商业，我们知道最终衡量的也是收入。实现收入的道路有很多种，我的策略是依靠口碑来增长，所以已有读者的口碑就非常重要。创始读者进入后，我们的感受是他们没有什么特别不满意的地方，但可能也没有什么超出预期的地方，这样是不足以实现通过口碑来传播的。这是我们将业务挑战定在这里的原因。

人是善变的。我非常讨厌每次给指示都不一样的老板。所以当我们确定了业务挑战，我会找块白板写下来，主要是防止自己明天说的不一样。

确定挑战目标后，就要寻找可以去解决的具体问题。不知道和我们接受的教育有没有关系，大多数人的思维惯性是试图直接给出问题的答案，也就是解决方案。读者给我们反馈的时候，多数情况下也会直接提出要求，而不是告诉我们他们遇到的问题。

举个例子，我们的一个设计是在阅读文章时会显示其他人的笔记。之前常有读者抱怨，觉得这干扰了阅读，因此会要求我们增加一个选项，可以在阅读时隐藏笔记。

但我们一直强调，比解决问题更重要的，是找到正确的问题。问题等于机会点。退一步来看问题，而不是直接深入到某个答案，能给我们更多的角度和视角。拿这个例子来说，经过进一步了解，大多数读者抱怨是因为在阅读时看到了低质量的笔记。后来，我们调整了笔记筛选的规则，只显示来自读者自己关注的人的笔记。这样子，所有显示出来的笔记都是读者的自主选择;在这之后，就基本没再收到抱怨了。

寻找具体问题的过程依赖于团队的洞察。用户反馈是其中的一个方式，但一般来说，只有非常非常不满意或者特别特别爱你的读者才会愿意花时间来给你写反馈，所以如果要寻找改进的机会，还需要更主动一些。在早期创新产品中，定性的判断远远比定量的数据更有用。我们之前几年积累了几百个用户访谈，也会不断观察用户行为和使用数据，还会发放传统的问卷。更重要的，我们会和读者一对一聊天。我们自己的使用感受也是洞察的来源。

通过上面这些方法，我们理解，读者隐含的不滿意和我们的“社区机制”有关。阅览室的核心机制是通过“先锋读者”来推荐值得一读的长文章、贡献自己的阅读经验、围绕内容和其他读者展开严肃认真的交流。“先锋读者”现在都是创作者、媒体人，我们不需要他们有很高的知名度;在构思产品的时候，我们也没有认为“先锋读者”需要像其他产品中的“大V”“KOL”一样高人一等，供人“仰视”。合适的感受上，他们该是比自己早两年踏入社会的师兄师姐。但执行的偏差是，在之前的产品包装、设计的具体交流机制中，我们又将读者和先锋读者的差距拉得很大，导致读者事实上是需要“仰视”先锋读者的。这就背离了我们最初的设想。

这个对问题的判断还不够具体，需要用一些方法来找出更具体的问题。创新虽然不是一个严谨的推导过程，但我也追求无序中的秩序感，并非完全混沌的。我最喜欢用的方法叫“How Might We”（HMW），直接翻译成中文是“我们应该如何……”。我经常说，关于设计思维，如果只掌握一个方法，掌握这个方法就可以。这是一种头脑风暴的方法，只是产生的不是“点子”，而是“问题”。简单地说，大家在听其他同事分享具体的洞察的同时，把听到想到的问题、机会点按“HMW”这个格式写在便签上，然后贴在白板上交流、投票。

说起来很简单，要用好，需要经过长期的练习。阅览室的团队一起工作有10年了，大家彼此都很熟悉。这些在未知中寻找问题、讨论解决方案的方法我们都很熟悉，开会时都会顺手拿起便签纸。我也去一些大公司开过他们的头脑风暴会议，十几个人在会议室坐一整个下午高谈阔论，白板上一个字都没有，效率之差让人咂舌，怪不得要花那么多时间开会。

当时从Google离开自己创业，其实一部分也是希望能把學习到的这些设计方法拿到实际业务中去试试;豌豆荚被收购了以后，除了轻芒我们还做了光涧实验室，也是希望用我们积累下来的方法帮助更多的团队，包括我们投资孵化了一些创业团队，以及为更成熟的公司提供创新咨询服务。

在这个环节，我们最后得出的“HMW”是，如何让普通读者也能在阅览室里被看见？如何能降低读者和先锋读者之间的距离感？这个颗粒度的问题，就比较容易想不同的解决方案了。

真的从找出问题到确定解决方案的过程，花了比较多的时间，部分是因为在做社区产品的时候不容易放开手脚。这个阶段我现在反而不太用传统头脑风暴的做法了，因为头脑风暴虽然能输出很多“点子”，但无法形成系统的“解决方案”。目前摸索出来比较好的方法是，通过头脑风暴来产生灵感，再独自工作，抽象、整合成完整的解决方案。

其实一个人也是可以自己和自己做头脑风暴的。把想到的很多想法放在一起，最后我们重新定义了理想的社区氛围。在阅览室待着，应该是所有人一起阅读和交流的感受。之前在阅览室内的交流，更像是发生在舞台的聚光灯下，有明确的台上、台下的区别，只有先锋读者的发言能被其他人看到，其他人除非也走上台，否则是不被看见的。这并不理想。理想的感受是什么？大学时代我常常参加草坪沙龙，观众在草地上围坐一圈，三五讲者坐在中间侃侃而谈，观众可以随时插话，每个观众都可以被听见、看见。这是理想的讨论感受—我们尊重讲者和观众之间的角色差异，但他们并不是完全隔离的。

按照这一原则，在7月底发布的版本中，我们重新构思设计了所有和“交流”有关的功能。这些改进，都是希望创始读者和未来更多进入阅览室的读者们可以在阅览室中被看到，参与到长文章的阅读和讨论中来。“阅读即交流”，阅览室的特色功能是可以在阅读的同时马克划线、写笔记。过去，只有先锋读者的笔记默认公开给别人看;现在，所有读者的笔记都是默认公开的。为此，我们为每篇文章设计了一个新的“一起读”页面，取代了原本的马克笔记汇总视图，将阅览室中所有读者关于这篇文章的公开交流和讨论汇聚在一处。可以说，我们给每篇文章都开辟了一块小小的草地。

我们也重新考虑了读者和先锋读者的“权利”差别，之前设定了比较多的权限差别。从7月底发布的版本开始，读者和先锋读者除了是否能被关注外，其他功能权限完全一致。

放到互联网公司的语境下，“创造性地解决问题”的确意味着非常宽泛的职责。在今天的大多数公司中，上面这些过程都不是由设计师来完成的，设计师只能在产品经理确定这些决策后，从事一些“美化”的工作。

产品经理当然也很重要。我前阵子花了一个下午的时间，给猫助和多抓鱼的团队介绍我对产品经理、产品设计师两个职位分工的整体想法。设计师是通过产品来解决用户的问题，而产品经理的目标是产品的商业成功。这两个都是专业性很强的工作，而对专业性、系统性的敬畏，是整个行业都欠缺的，仅仅满足于四处分享一些零散的经验。创新、做新产品是很难，但大部分这些方法，并不依赖天赋和经验。今天，大多数的产品经理和设计师似乎都没有意识到这一点，而是相信天赋和灵光一现，以及“大力出奇迹”。

“大力出奇迹”要么是解决确定问题，要么是以低廉的研发成本不断漫无目的地试错，看看运气如何。当我们谈论创新，关心效率，还是需要一些更系统的方法的。设计创新的步骤，简化来说，在给定的目标下，首先要定义问题，然后寻找问题的解决方案，最后验证解决方案的有效性，再不断循环这整个过程。

其实这和科研的过程是很像的。不是完全线性的过程，也不是完全无序的。不像开车从A地到B地，导航说多久就是多久。更像是爬山，明明就是100米的直线距离，你走到前面发现一条水沟，就要花费额外的力气去跨越它，正如我们会遇到意料之外的问题，需要花费额外的几个月时间去解决。