做工具设计的一些观点

各位兔年吉祥！假期结束，打起精神，开始更新啦！

2023 年在工作上是一整年的创业状态，做与身份相关面向开发者的开源 + SaaS 产品，目前 All in 海外市场，感兴趣请戳 👉  logto.io。

前半年我们从 0-1 搭起第一版产品 demo，7月中旬推出市场。在几乎零成本的推广下 ，目前开源版本 6个月内 star 数积累到 5.3k，社区人数接近 400。

我的工作内容是产品和设计，但后续大家其实都已经快忘了自己是谁，哪里有需求，就跑去哪里。

在这个过程中，每天团队里都会发生这样那样的决策。我有很多理性的逻辑判断，也有被抽象原则引领的判断。在团队讨论的时候，我发现这些抽象的原则很难被快速表达出来，以至于在产品价值观层面（aka 哲学问题），我时常显得比较霸道 LOL。所以呢，我想把这些观点总结一下，这些观点塑造了我理解的“好产品”，也塑造了我是一个怎样的产品设计师。

以下内容不是什么成功经验，更多是关于一些我做工具设计的一些出发点和对特别大的问题的思考，全是形而上的观点，没有事实 lol。其实很多东西只要辩证得去分析，正说反说都可以，我也相信每个人都会有自己的答案，也欢迎大家与我探讨你做工具的哲学 👏

文章约 4300 字，阅读需要 13 分钟。

哈哈，这个问题的确是一个让人翻白眼的问题，不知从何下手 🤷‍♀️。

其实大家在谈论产品好与不好的时候，我们并没有开诚布公地去探讨标准。一个稍微有些潜在共识的判断标准是“好用”。但成为一个创业者之后，我的要求更高了，它不仅要好用，还要能够被更多的人使用，并兼具一定的“内涵”。所以我心目中的好产品有几个最重要的特征：产品内核优秀、市场准确、有自己的愿景。

• 产品内核代表着做事的态度和方法，这个是“人力”最大程度可以自己掌控的

• 市场准确代表这个团队是不是在战略上足够重视，对用户有谦卑之心，符合产品可以规模化的本质

• 有自己的愿景意味着能看到产品一脉相承的理念和故事，可以看到它不断创新的源头

做出优秀品质的工具产品，分为两层，第一层为洞察，第二层为创造。只创造不洞察，或者只洞察不创造都会让产品陷入瓶颈期。

洞察的前提是 regardless of tools，在最初不要做预设。一定是先有人，再有工具。以人的视角去抽象化用户的操作流程，其实有点儿类似于常说的 know-how。know-how 的建立一定基于对于当下行业和用户的深刻理解，再加入对行业未来的预判。在这一点上，除非是初创团队，成熟公司的产研团队因为忙于日常的执行和研发，缺少环境的敏感，对于用户的了解一般弱于销售和市场。对于强业务属性的工具，例如 CRM，广告，OA，在进入产品设计之前储备好足够的业务知识，我们才能真正意义上做出好的产品体验。

创造力是把产品推向革命和伟大的唯一方式，能把创新和易于接受结合起来的产品很难得，大部分成了“自己玩”。Airtable，Notion 这类行业属性不明显的生产力工具，在工具交互层面的拓展一波又一波。这一层的目标就是在功能设计上做到“有壁”，不然在企业级市场拓展上，缺乏对行业理解产生的瓶颈会抵消掉功能上的进步。

Airtable 最近的战略从 PLG 转化成了 SLG，在 LinkedIn 看到了各种被裁的 researcher 和 PMM 。可以猜测到它转变方向，开始想要靠行业最佳实践去赚钱了。另外一个路子不太一样的例子是 Notion，它在产品功能上不断创新，和同类型的协作产品产生了无法跨越的壁垒。他们不可超越的点在于对于概念模型的坚持（来源于早期 Ivan Zhao 对计算机科学的理解)，方向明确，还有贯穿一切的逻辑。这些或许也算是生产力工具上的 know-how。

当我们看了太多产品，知道太多现成的解决方案之后，我们会想当然地去拼，去套 —— 这样做其实都两个层面的思考都没有照顾到，更像是稀里糊涂地去模仿。

在创造力上我也在训练（虽然这玩意儿有点儿靠天赋。。。），并有意识地去稍稍排斥一些竞品或通用方案，因为经验会把你送入安全区，也会束缚你永远走不出来。

不要 over design

从产品内核延伸出的一个观点，我觉得很重要也很容易发生，所以单独提一下，不过度设计。

在体验一些产品的时候，你能感受到它的产品态度极其认真，各种场景考虑得很全面，每一个小逻辑都有严谨的解决方案，但是又有一些小别扭，因为他们并不是最自然的方案。透过这些功能设计，你能看出设计师和产品经理在这个过程中的求生欲：我不想出错，我都考虑到了，我不想被 challenge。

这样的产品其实不是好产品，一些典型的偷懒并 over design 的设计思路：

1. A 和 B 都无法做选择时 👉 加一个开关可配

2. 做不出比较好的展示效果，用户总找不到 👉 增加搜索

3. 一个新功能来了，第一直觉 👉 能不能复用之前的 pattern

4. 创造一个新概念  👉 通过引导和教学让用户 onboard

去年做产品的时候，我和团队也在 over design 的话题上讨论过。我现在的底线是，

1. 能在上一层解决的问题就不在下一层解决。这个说起来比较抽象，以上面第二个例子举例，我会优先做好信息的展示工作，不轻易靠兜底解决。如果真的无法做到让用户找到，是不是意味着信息过于冗余，需要删减呢？

2. 每一个新的 feature，先了解流程和任务，再去评估是否因考虑一致性而复用交互。不强行塞进去已有的框架，如果有更好的解决方式，一致性可以打破。

3. 不因追求 use case 的全面性，而去大规模推广人工制造出的很多不自然的概念和产品逻辑。工具设计中不可避免会出现很多自创的交互概念，但是它需要是自然的，且可被类比和迁移的 —— innovation is never new。所以好的方案一定是 obvious 的，可以靠直觉判断，而非逻辑。

理性可以让你做出一个不出错的产品，但是直觉可以让你做出一个优秀的产品，保护好直觉！

市场自洽

如果一个产品的定位就是做小众市场，即使 market size 不大，我也会对它有一份敬重。只要有一份 self-awareness 的自洽在，它就是一个好产品。如果将来想做更大规模的市场拓展，后续也容易水到渠成。

比较被动的是市场本身很小，但是产品却很贪婪，忽略 PMF 的验证，妄图教育市场。许多产品号称教育和引领市场，这个出发点在我看来，极少一部分真的是对未来有着真知灼见的预测，大部分是对用户和需求场景理解的懒惰和傲慢。这个其实也反映了很多创业者的心态的区别，是趋向于个人成就型，即通过产品实现并验证个人对于世界的判断；还是通过产品更多地了解世界，并以提供价值收获成就感。以结果评判并无对错，因为都有实例证明他们都可以到达相同的终点。

愿景可以帮助 storytelling

我曾经怀疑过愿景在中国本土是否具有意义，是否真如画饼一样虚无，但是目前的结论是，它有意义，并且很重要。

到底什么是愿景呢，product vision statement is all about aspirations and bringing people together —— 一个好的愿景是当下产品的延伸，和当下有关联系而非另起炉灶，他是产品发展的北极星，能够最大程度地将独立的功能们聚合在一起。

这种 storytelling 不仅创作者内部可以高效达成一致，往一个目标前进，关键还能够让用户和客户理解产品的 positioning，这个简直是产品 GTM 的指南针。与此同时，他还是创新的源泉：当解决的问题从单一的问题拓展到整个领域，会有更多的机会和场景。

互联网人的思维僵化的表现：你的场景是什么，核心用户是谁，解决的问题是什么？我们太容易产生需求，也太容易去计划一个功能了！！

所以很多时候，得停下来花些时间去认真思考“做还是不做”的问题。这里不仅仅指的是优先级，往往还是是决断性的“Yes”or “No”的规划问题。我们需要有一些 say no 的勇气和观点。

职业打工人的我们，训练出常见的 mindset：先做竞品分析，然后撰写场景，和 stakeholder 以及用户开展调研。如果有数据支撑的团队的话，就做做 opportunity sizing，没有的话就是 PM 筹备功能和流程，设计师还原并优化竞品体验，剩下的工作就是 PM + UX + Eng 抽丝剥茧地讨论逻辑，打磨体验和品质。

这个执行流程没有问题，往往的确会诞生出很多口碑还不错的 feature。但是这个流程中，有几个看起来很自洽的陷阱，

1. 逻辑推演发现场景存在 👉 功能值得做

2. 多数竞品都有这个功能 👉 功能值得做

3. 用户提出了高频反馈 👉 功能值得做

以上这三点，并不是是否做这个功能的决定性因素，在创业过程中，因为我们追求更高维度的产品和商业成功，被逻辑、用户、竞品裹挟会让我们路径甚至整体产品变形。在早期相对自由的创业初期，我们需要有外界的信息反馈，也要有自己的节奏。

对于 SaaS 2B 类的产品，是否增加功能，我目前能够考虑到的有以下几个方面：

1. 如果用户提出了反馈，是否分析并挖掘了用户业务场景的问题，不做表面上的判断

   人之天性，就有教人做事和表达的冲动，为什么用户在喷产品上的热情永远大于赞美。我们应当警惕用户对于功能的建议，他到底遇到了什么问题，是不是我们应该解决的，他有没有找到问题的本质，如果没有，那么就应该退一步重新审视这个问题，直到发现本质，再做下一层的判断。

2. 如果逻辑上场景存在，这个功能

1. 是否符合产品的 positioning，是否和我们构想的产品画像一致

2. 是否有足够的 ROI

3. 是否符合我们当下的发展阶段

不断累积功能，往往出现在资源庞大的大公司，或者发展到一定阶段去讨好大客户，前提是你的产品框架足够有拓展性，可以接得住这些零零散散的需求 （其实大部分复杂的产品后续几乎都要尝试 multi-product 或者等着被革命的状态）。如果没有这个足够大的框架，那就不急于产品化，可以暂时通过底层技术能力例如API 或者人工去解决，产品化和规模化要慎重。

3. 如果竞品有这个功能

   竞品有这个功能是最表面的现象，我们还是要顺着这个现象，去进一步了解，竞品为什么要做，接下来再去按照“逻辑上场景存在”的几个维度去判断。

这一点对于出海产品更为重要，全球市场语境比中国还要高的国家屈指可数，所以更讲究直给的价值传递和共鸣，如果我们自己的产品都无法说清楚，就不要妄想用户自己可以探索明白。其实无论是做到”真正“挖掘新场景，还是革新解决方式，空间都很有限。如果能够从一个独特但是令人疯狂点头的角度切入，展开故事，然后在通用解决方案上做出 tailored 优化，已经是创新了。

产品分析，网上资料调研等等这些都是 secondary research。Talk to people 是不能偷懒且必要一环。对于用户的理解，不是一轮访谈就结束，是持续的动态了解。这种定性的研究比去做一堆竞品分析，然后逻辑揣测，搬运现成方案更适合想做出一个好产品的团队。

我发现大家对于方法论有着很多极端的态度。一部分人觉得方法论是极度务虚的表现，一些不明所以的概念和公式并不能够解决实际问题。一部分人觉得方法论是专业化的建设，将实践抽象化，会增加行业影响力。出现这样极端的趋势，大概是近两年一些妖魔化的方法论被不断拥趸，不断挑战那些真正先做一番实事人的原则底线。以及，学院派天生和实践派在价值观上彼此就有一定的冲突和偏见。

一个方法论的实践成功有很多外在需要保障的因素，例如团队合作，环境现状，资源支持等等，只要缺少一环就容易失败。但是失败就意味着否定么？也不一定。我现在是这样看待方法论的：

1. 方法论必须逻辑严谨，有实操的可能性。如果是一堆不明所以的概念表达，我纯粹理解为这个方法论的创造可能是出于别的目的：例如增加团队行业影响力，获得话语权，并不直接助力业务发展。

2. 方法论必须有足够的信息支持，和广阔的视野。很多方法或者抽象的结论，其实早已有现成的结论或更为简单的方法提炼过。不需要过度复杂化和重复造轮子。

3. 以平和和耐心的心态去看待有过成功经验的方法论，根据实际环境，在实践中调整和反思。并在这个过程中，摸清楚之前成功的原因。

4. 任何一个方法论都不要着急去去推崇或批判，把它当作获得启发的资源和信息，为我所用。

文章结束，欢迎大家与我交流做工具的心得和哲学。We appreaciate more philosoly battles !

相关历史文章

正文结束

---

我是一名在硅谷/北京的产品设计师 - 挂面(年少的我一面试就挂!)，是字节、Dropbox Growth、Yahoo、CMU Alumni。目前在创业，热爱表达，日常喜欢思考抽象和哲学。努力维持理性与感性的平衡中 :)