# Notes on software quality # 关于软件质量的思考 *Author: Anthony Hobday (a seasoned interface designer who frequently shares insights on UI/UX and product craftsmanship).* *作者：安东尼·霍布迪（Anthony Hobday，一位资深的界面设计师，经常分享关于 UI/UX 和产品打磨工艺的见解）。* ## How I think about quality ## 我如何看待质量 ### Quality is the absence of problems ### 质量就是“没有问题” “The absence of problems” is the best definition I can come up with for quality. “没有问题”是我能想到的关于“质量”的最好定义。 The most practical way to measure quality is to test with many different people, and have many experts take a look. If thorough testing and 100 experts can’t find a problem, the thing is probably perfect. 衡量质量最实用的方法，就是让许多不同的人去测试，并请众多专家来审查。如果经过彻底的测试和 100 位专家的挑剔，依然找不到任何问题，那这件作品可能就称得上完美了。 ### Quality is a spectrum up to “perfection” ### 质量是一个逼近“完美”的连续谱系 Perfection is impossible. The agreed-upon best-designed software in the industry has noticeable problems. But the closer you can get, the better. 绝对的完美是不可能的。即便是业内公认设计最顶尖的软件，也会有显而易见的问题。但你能越接近完美，就越好。 The closer you try to get to perfection, the harder it is. This is the same “diminishing returns” effect you’ll see anywhere quality is involved. 你越想接近完美，难度就越大。这是在任何涉及质量的领域都会出现的“边际收益递减”效应。 ### Quality relies on the organisation ### 质量依赖于整个组织 Leadership and culture both define and allow quality. Even if they don’t believe they do. Even if they haven’t thought about it. Their actions and beliefs will either enable or limit quality. 领导层和企业文化共同决定了质量的上限。哪怕他们自己不这么认为，哪怕他们根本没思考过这个问题。他们的行为和信念，要么在赋能质量，要么在限制质量。 Quality is a result of ability and appetite. Does the organisation have people who can produce high quality (ability)? And does the organisation allow quality to be achieved (appetite)? 质量是“能力”和“意愿”的共同产物。组织里是否有能产出高质量工作的人（能力）？组织是否允许去追求并实现高质量（意愿）？ ~100% of the time I’ve seen an organisation make high quality software, it is because the leaders wanted it. If the leaders don’t want quality, it will be much harder. 根据我的观察，几乎 100% 的情况下，一个组织之所以能打造出高质量的软件，是因为领导者想要它。如果领导者不在乎质量，那一切都会举步维艰。 But don’t forget that whatever you work on, there is an amount of quality you personally can achieve. Even in the most rigid design-system-controlled interface, there are still higher quality and lower quality choices you can make. 但别忘了，无论你在做什么项目，你个人都能在一定程度上决定其质量。即便是面对最死板的、完全受设计系统约束的界面，你依然可以在“高质量”和“低质量”的做法之间做出选择。 An organisation can set objective measures of quality (e.g. bugs reported). Hopefully those objective measures don’t blind the organisation to the subjective measures (e.g. “does an expert think this is high quality?”). 组织可以设定客观的质量衡量标准（比如用户提交的 bug 数量）。但希望这些客观指标不要让组织忽视了主观维度的标准（比如“专家认为这件作品质量高吗？”）。 ### Quality gets harder with scale ### 规模越大，质量越难保证 The larger the organisation or software, the harder quality is. High quality is impossible past a certain point of scale. Some organisations are incapable of making high quality software. 组织规模或软件体量越大，保证质量就越困难。当规模超过某个临界点后，想要保持高标准几乎是不可能的。有些组织由于其自身的庞大，注定无法做出高质量的软件。 Importantly, this is a natural result of scale. It’s not a complaint or a problem to be solved. It cannot be solved. It’s a trade-off, like almost everything else in software. 重要的是，这是规模化带来的自然结果。这并不是一句抱怨，也不是一个有待解决的问题——因为它根本无法解决。就像软件工程中的几乎所有事情一样，这只是一个权衡取舍（Trade-off）。 ### Quality is not necessary, but ideal ### 质量并非必须，但它是理想状态 I wish every organisation cared about quality. It’s clear that many of them don’t, and don’t need to. Many commercially successful organisations don’t prioritise quality. 我真希望每个组织都在乎质量。但显然，很多组织并不在乎，而且他们也不需要去在乎。许多在商业上极为成功的公司，并没有把质量放在首位。 But quality is ideal. Everyone wants to live in a higher-quality world. It feels good to create quality. Things last longer if they’re higher quality. And over the long term, commercial success is harder if people realise your brand doesn’t represent quality. 但高质量是一种理想状态。每个人都想生活在一个更高质量的世界里。创造出高质量的产品会让人感到愉悦。高质量的东西寿命更长。而且从长远来看，如果人们意识到你的品牌与“低劣”挂钩，商业上的成功就会变得更加困难。 ## Universal signals of quality ## 质量的普适标志 These are the signals of quality that I’ve found apply to everything. People and artefacts. 以下是我发现的适用于任何事物（无论人还是产品）的四个质量标志： 1. **Appearance:** In (over)simple terms, the more beautiful something is, the higher quality we think it is. I assume this is because beauty requires effort, and so does quality in general. Any evidence that we have put care into something is evidence of further care. **外观（Appearance）：** 简单粗暴地说，一样东西越漂亮，我们就越觉得它质量高。我认为这是因为创造美需要付出心血，而打造质量同样如此。任何能证明我们在某物上倾注了心思的细节，都在暗示这件作品得到了全面的关照。 2. **Association:** We judge whether something is high quality by what it is associated with. A common approach to this is social proof, where someone or something is associated with other someones or somethings. We judge a thing by the company it keeps. **关联性（Association）：** 我们会通过一个事物与什么的关联来判断它的质量。这通常体现在“社会认同（Social Proof）”上，也就是看它和哪些人或哪些事物绑定在一起。正所谓“观其友，知其人”。 3. **Cost:** If someone or something costs more, we might assume that is because it is worth more. But “cost” does not have to mean “money”. If something takes more time, for example, we might assume it is of higher quality. **成本（Cost）：** 如果某人或某物要价更高，我们可能会理所当然地认为它更有价值。但这里的“成本”不一定是指“金钱”。例如，如果某件事耗费了更多的时间去打磨，我们可能会认为它的质量更高。 4. **Performance:** Performance could be quantitative like “top speed”, or qualitative like “how does it make me feel”. It could be results-focused like “did it help me complete my task”. In simple terms, if appearance is “how it looks”, performance is “how it does”. **表现/性能（Performance）：** 表现可以是量化的（比如“最高运行速度”），也可以是定性的（比如“它给我带来什么感受”）。它可以是以结果为导向的（比如“它帮我完成任务了吗”）。简而言之，如果外观代表“它看起来怎样”，表现就代表“它实际上做得怎样”。 ## The six signals of quality in software ## 软件质量的六个标志 1. **Reliability:** Does the software technically perform as expected, all of the time? This means no bugs, no downtime, no errors, and so on. **可靠性：** 软件在技术层面是否始终能按照预期运行？这意味着没有 Bug、没有宕机、没有报错等等。 2. **Speed:** Does the software react to input instantly, or as near as practically possible? For those tasks that must take longer, are they as fast as possible? **速度：** 软件对输入的响应是否是瞬间的，或者在实际可行的情况下尽可能接近瞬间？对于那些注定耗时的任务，它们是否做到了尽可能快？ 3. **Clarity:** Does the person using the software understand everything? **清晰度：** 使用软件的人能理解界面上的一切吗？ 4. **Efficacy:** Can the person do what they need to do with the software? **效用：** 用户能用这款软件完成他们需要做的事情吗？ 5. **Efficiency:** Can the person do what they need to do with the software as easily as possible? **效率：** 用户在用软件完成任务时，是否尽可能地轻松省力？ 6. **Beauty:** Is the software as aesthetically pleasing as possible? **美感：** 这款软件在视觉审美上是否做到了尽可能的赏心悦目？ ## The benefits of software quality ## 软件质量的好处 Some might argue that quality is an obvious good. That the reasons quality is important are naturally understood by everyone. But we’ve still got a lot of crap software, so 🤷. 有人可能会争辩说，质量好本身就是理所当然的好事，大家都心知肚明。但现实是我们依然面对着一堆垃圾软件，所以这事儿还真不好说 🤷。 1. **Attract employees:** People want to work for companies that care about quality. **吸引人才：** 人们总是希望能为在乎质量的公司工作。 2. **Satisfaction as creators:** Everyone involved will feel better about themselves. **创作者的满足感：** 参与其中的每个人都会对自己的工作成果感到自豪。 3. **Fight fewer fires:** Higher quality means fewer problems to fix afterwards. Fewer bugs, fewer reliability issues, etc. **减少“救火”次数：** 高质量意味着后期需要修复的问题更少。Bug 更少，可靠性问题更少等。 4. **Fight software entropy:** All software suffers as it grows. It becomes bloated, harder to use and look at. A commitment to quality pushes back against entropy. **对抗软件熵增：** 所有软件在不断迭代中都会不可避免地走向混乱（熵增）。它会变得臃肿、难以使用且界面丑陋。对质量的执着是对抗这种熵增的有力武器。 5. **Less employee churn:** Care for software generally means care for the people who make it. It encourages skill growth. **降低员工流失率：** 关注软件质量，通常也意味着关注开发软件的人。这能激发员工的技能成长。 6. **Easier to sell:** If quality is part of your company identity, the product is easier to sell. Word of mouth will do some of the marketing for you. **更容易销售：** 如果“质量”构成了你公司品牌形象的一部分，产品自然更好卖。口碑本身就是一种免费的市场营销。 7. **Attract users:** Quality attracts people. They’re more likely to use your software. **吸引用户：** 好的质感自带吸引力。人们会更愿意使用你的软件。 8. **Users become fans:** Usable, effective, satisfying software turns users into fans. Fans want to support the company, forgive it more easily, and are happy to help it improve. **让用户成为铁粉：** 好用、高效、令人愉悦的软件能把普通用户转化为死忠粉。粉丝愿意支持公司，对失误更宽容，并且乐于帮助公司改进产品。 9. **A competitive moat:** Quality is hard. Your competitors probably won’t put the effort in. **竞争护城河：** 做好质量很难。你的竞争对手很可能不愿意在这上面下苦功夫。 10. **Make more money:** People universally pay more for quality. **赚更多钱：** 全世界的人都愿意为好质量买单。 11. **Beauty improves society:** Beautiful artefacts universally improve how we live. **美能改善社会：** 优美的作品能普遍提升我们的生活体验。 12. **Inspire quality in others:** Other people and companies will be inspired by your work. **激发同行追求质量：** 其他人和其他公司会被你的优质作品所启发。 13. **Leave a legacy:** No product lasts forever. But people talk about good software for decades. **留下遗产：** 没有哪款产品能永存。但人们会把优秀的软件津津乐道数十年。 ## Beliefs about quality I want to disprove ## 我想反驳的一些关于质量的刻板印象 I’ve had software interface quality on my mind for most of my career. Here are some things I believe are true. I would prefer that they are not. 在我的职业生涯中，我大半时间都在思考软件界面的质量问题。以下是我发现的几个“悲惨但真实”的事实。我个人非常希望它们不是真的（即我希望我能反驳它们，但现实很残酷）。 1. Quality is easiest when one person can keep the whole interface in their head. 当一个人能把整个界面的逻辑全装进脑子里时，保证质量是最容易的。 2. The more people who work on some software, the harder high quality is. 开发一款软件的人数越多，想保持高质量就越难。 3. The more high quality things you have in your life, the better your life is. 你生活中高质量的东西越多，你的生活体验就越好。 4. The lower the quality of your product, the more people will abandon it. 产品质量越低，放弃它的用户就越多。 5. More people will talk about your product if quality is high. 只要质量过硬，自发谈论你产品的人就会更多。 6. Quality depends on permission from whoever is most powerful at an organisation. 质量好坏取决于组织内最有权势的那个人的“许可”或态度。 7. Quality cannot be a bottom-up effort, driven only by the people who do the work. 追求质量不能仅仅靠干活的员工进行自下而上的努力。 8. High quality always requires a sacrifice of something, e.g. scope, money, growth, or time. 高质量必然意味着要在某方面做出牺牲，比如缩减功能范围、投入更多金钱、牺牲增长速度或花费更多时间。 9. High quality always requires someone to have a strong personal interest/obsession with it. 高质量始终需要有人对其抱有强烈的个人兴趣，甚至达到偏执的程度。 10. A focus on quality means a sacrifice of growth. 专注于质量，往往意味着牺牲业务增长。 11. Quality is both harder and more important for software that is used often. 对于高频使用的软件来说，质量变得更加重要，但也更难把控。 12. Quality is a competitive moat because so few organisations focus on it. 正因为极少有组织真正关注质量，所以它才能成为竞争护城河。 13. You should ideally hire good people if you want high quality. 如果想要高质量，理想状态下你必须招到最优秀的人。 14. If you cannot hire good people you should be willing to iterate a lot. 如果你招不到顶尖人才，你就得做好疯狂迭代试错的准备。 15. You need to iterate a lot more than expected to get high quality. 为了达到高质量，你需要进行的迭代次数远远超出预期。 16. Some organisational cultures are incapable of high quality. 某些组织的文化注定了它们根本做不出高质量的产品。 17. The larger the organisation, the harder quality becomes. At a certain size of organisation high quality is impossible. 组织规模越大，质量把控越难。当组织大到一定程度，就不可能产出高质量。 18. The larger the software, the harder quality becomes. At a certain size of software high quality is impossible. 软件体量越大，质量把控越难。当软件复杂到一定程度，高质量就不复存在。 19. If something is low quality in some software, it’s usually a reliable sign that other things are low quality. 如果你发现软件里的某个细节质量很差，那这通常是一个可靠的信号：里面其他东西的质量也很烂（破窗效应）。 20. Some types of quality are not always immediately obvious. 有些维度的质量并不总是一眼就能看出来的。 21. Perfection is impossible. 绝对完美是不存在的。 22. Products and companies can fail because they focused on quality at the expense of other things. 有时候产品和公司之所以失败，恰恰是因为他们为了死磕质量而牺牲了其他更紧迫的东西。 23. Quality requires that everything be given a lot of attention. 质量要求你必须对所有的细节都倾注大量的心血。 24. Even though everyone agrees quality is positive, it is hard to convince people to focus on it. 尽管人人都认同“质量是好东西”，但要在实际工作中说服人们去重视它，却极其困难。 25. Some people want high quality in their personal lives, but don’t care enough about it in their professional lives. 有些人私下生活里追求高品质，但在职场工作中却对产出的质量漠不关心。 26. Many commercial goals hurt quality, e.g. growth. 许多商业目标（比如业务增长）往往会伤害产品质量。 27. Quality is a constant effort. Problems can slip in quietly, especially as changes are made. 维持质量是一场持久战。问题往往会在你修改代码/设计时悄然溜进系统。 28. The only reliable way to measure quality is to have lots of experts look at the software. 唯一可靠的衡量软件质量的方法，就是让大量专家来进行审查。 29. Focus on quality has diminishing returns. It takes much more effort to achieve “90%” quality than it did to achieve “80%” quality. 追求质量存在边际收益递减规律。从 80 分提升到 90 分所耗费的精力，远大于从 0 提升到 80 分。 30. The systems in place to help create software (e.g. design systems) can also hurt efforts to focus on quality. 那些本意是辅助开发软件的系统（比如 UI 设计系统），有时反而会阻碍人们对极致质量的追求。 31. People associate expressive visual styles with visual quality. They may expect expressive visual styles in high quality software even when it’s not needed. 人们很容易把“富有表现力的视觉风格”和“视觉质量高”画等号。他们甚至会期望高质量软件都要有张扬的视觉效果，哪怕根本没必要。 32. People associate high cost with quality. 人们常常把高昂的成本（价格或时间）与高质量关联起来。 33. People associate hype/community interest with quality. 人们会把前期的营销炒作或社区狂热等同于软件质量好。 34. There are many ways to compete that cost less than quality, e.g. features, price, sales experience. 市面上有太多比“死磕质量”成本更低的竞争手段了，比如堆叠功能、打价格战或优化销售体验。 35. People may leave a company because they cannot focus on quality as much as they’d like to. 一些人离职的原因，仅仅是因为在公司里他们无法随心所欲地去打磨产品质量。 36. Novelty is more immediately attractive to people than high quality. 比起过硬的质量，“新奇感”往往能在第一时间更有效地吸引人们的眼球。 37. High quality is often not noticed until later. 高质量通常在产品使用一段时间后才能被真正感知到。 38. Organisations and people will almost never tell the truth about the low quality of their products. 无论组织还是个人，几乎永远不会坦承自家产品的质量有多糟糕。 ## Quality is impossible at scale ## 规模化意味着无法保证质量 Good interface design becomes harder as software grows. Eventually, world-class interface design is impossible. Here’s are some thoughts. 随着软件体量的增长，优秀的界面设计会变得越来越难。最终，想做到“世界级”的界面设计几乎是不可能的。以下是我的一些想法： ### There are too many relationships to manage ### 界面和人际关系变得过于复杂 Good interface design is coherent. “Coherent” means the relationships between all of the things in the interface work well. But as the number of things goes up, the number of relationships goes up even faster. Eventually it’s impossible for people to properly consider all of those relationships. 优秀的界面设计是连贯一致（Coherent）的。“连贯”意味着界面上所有元素之间的关系都配合得天衣无缝。但随着元素数量的增加，元素之间关联关系的增长速度甚至呈指数级。到最后，人类的大脑根本无法全盘把控这些盘根错节的关系。 This principle also applies to people. The more people who work on software, the harder it is to manage the relationships between all of them. Things are lost in translation. People disagree on the goal, and pull in different directions. 这个原则同样适用于人。开发软件的人越多，管理他们之间关系的难度就越大。信息在传递过程中会失真，人们会对目标产生分歧，并开始朝不同的方向使劲。 You can manage this with stricter processes. But eventually you’ll spend more time on process than on design. 你当然可以通过引入更严格的流程来管理，但最终你会发现，你花在“走流程”上的时间比花在真正“搞设计”上的时间还要多。 ### Some people don’t care enough ### 并不是所有人都对质量充满执念 The more people you hire, the more likely you are to hire people who don’t care enough about good interface design. Good interface design needs to be valued by everyone who can affect the work. That includes developers, designers, product managers, and often the CEO. 你招的人越多，招到那些对优秀界面设计“满不在乎”的人的概率就越大。而好的界面设计需要每一个能对产品产生影响的人共同去重视——这包括开发工程师、设计师、产品经理，通常还包括 CEO。 ### Some commercial goals hurt good design ### 商业目标往往会反噬优秀的设计 If a company wants some numbers to go up for commercial reasons, this often hurts interface design quality. For example, adding more advertising to a website can help a company to become profitable. But it can also make the interface worse. 如果一家公司出于商业目的想要提升某些数据指标，这往往会损害界面设计的质量。例如，在网站上塞满广告确实能帮公司实现盈利，但这绝对会让界面体验变得糟糕透顶。 One way to grow is to add features that people request. But often each added feature makes the interface worse. This is hard to avoid, because of the first point above. 实现增长的一种方式是满足用户请求，不断添加新功能。但往往每一个新功能的加入，都在让界面变得更臃肿。由于上述提到的“关系复杂化”问题，这点很难避免。 ## Anecdotal evidence that quality is impossible at scale ## 关于规模化无法保证质量的传闻与业界证据 Patrick McKenzie (a well-known tech commentator and former Stripe executive) [tweeted about the culture of quality at Stripe](https://twitter.com/patio11/status/1176866754682707969?s=20&t=7ov-AYTrfpj1_yvA8U33LQ). Patrick ended with “none of it is sufficient. We are actively dissatisfied with where quality is at the moment”. 知名科技评论员、前支付巨头 Stripe 高管 Patrick McKenzie 曾在推特上[谈到 Stripe 内部对质量的文化态度](https://twitter.com/patio11/status/1176866754682707969?s=20&t=7ov-AYTrfpj1_yvA8U33LQ)。他最后总结道：“做的这些依然不够。我们对目前的质量状态仍然极其不满意。” Benji Taylor of Family and Honk (social and messaging apps) [said that](https://twitter.com/benjitaylor/status/1571994317014863872?s=20&t=O9yvjV9aHuuddP6PU55xpw) “big corporate software seems to be getting buggier each year, while indie software [seems] to be getting smoother and more reliable”. 开发了社交应用 Family 和 Honk 的 Benji Taylor [曾表示](https://twitter.com/benjitaylor/status/1571994317014863872?s=20&t=O9yvjV9aHuuddP6PU55xpw)：“大公司的企业级软件似乎一年比一年 Bug 多，而独立开发者做的软件反而变得越来越流畅和可靠。” Some notable people replied to Benji’s tweet: 一些业内知名人士对 Benji 的推文做出了回复： > “the attention to detail is inversely proportional to the size of the team” ([Jordan Singer](https://twitter.com/jsngr/status/1572000440086044672?s=20&t=O9yvjV9aHuuddP6PU55xpw)) > “对细节的关注程度，与团队规模成反比。”（[Jordan Singer](https://twitter.com/jsngr/status/1572000440086044672?s=20&t=O9yvjV9aHuuddP6PU55xpw)） > “details are best cared for when they can be thought about holistically from a macro point of view. large organizations, by design, don’t allow for that.” ([Brandon Jacoby](https://twitter.com/JacobyBrandon/status/1572005307966189571?s=20&t=O9yvjV9aHuuddP6PU55xpw)) > “只有当你能在宏观层面上进行整体思考时，细节才能得到最好的照顾。而大型组织在架构设计上，天生就不允许你这么做。”（[Brandon Jacoby](https://twitter.com/JacobyBrandon/status/1572005307966189571?s=20&t=O9yvjV9aHuuddP6PU55xpw)） > “craft just becomes more and more expensive the bigger your product/team is” ([George Kedenburg III](https://twitter.com/GK3/status/1572003630034874368?s=20&t=O9yvjV9aHuuddP6PU55xpw)) > “你的产品或团队越大，打磨工艺（Craft）的成本就变得极其高昂。”（[George Kedenburg III](https://twitter.com/GK3/status/1572003630034874368?s=20&t=O9yvjV9aHuuddP6PU55xpw)） > “I wholeheartedly agree high craft is excruciatingly hard to scale” ([Kurt Varner](https://twitter.com/kurtvarner/status/1572058966754033665?s=20&t=O9yvjV9aHuuddP6PU55xpw)) > “我完全同意，高水准的工艺极难进行规模化复制。”（[Kurt Varner](https://twitter.com/kurtvarner/status/1572058966754033665?s=20&t=O9yvjV9aHuuddP6PU55xpw)） > “craft was impossible to maintain at Twitter as we rapidly grew” ([Sean Thompson](https://twitter.com/cyanhex/status/1572046586267729920?s=20&t=O9yvjV9aHuuddP6PU55xpw)) > “在 Twitter（现 X）快速扩张的过程中，保持打磨细节的工匠精神是不可能的。”（[Sean Thompson](https://twitter.com/cyanhex/status/1572046586267729920?s=20&t=O9yvjV9aHuuddP6PU55xpw)） In their article [Optimizing For Feelings](https://browsercompany.substack.com/p/optimizing-for-feelings), The Browser company (creators of the Arc browser) says that “as our everyday software tools and media became global for the first time, the hand of the artist gave way to the whims of the algorithm. And our software became one-size-fits-all in a world full of so many different people. All our opinions, beliefs, and ideas got averaged out”. 在打造了网红浏览器 Arc 的开发商 The Browser Company 发布的文章《[为感觉而优化（Optimizing For Feelings）](https://browsercompany.substack.com/p/optimizing-for-feelings)》中，他们提到：“随着我们日常的软件工具和媒体首次走向全球化，艺术家的直觉被迫让位于算法的冷酷。在这个充满多样性人群的世界里，我们的软件变成了一刀切的流水线产品。我们所有的主见、信仰和独特创意，都被‘取了平均值’。” David Khourshid, founder of Stately (a state machine engineering tool), [says that](https://twitter.com/DavidKPiano/status/1571838435656192000?s=20&t=oGG_OH9QyU3LGB2hCo6eew) “adding even a single ‘feature’ (new states + transitions) to an app can introduce an exponentially greater number of ways the app can be used”. 状态机工程平台 Stately 的创始人 David Khourshid [指出](https://twitter.com/DavidKPiano/status/1571838435656192000?s=20&t=oGG_OH9QyU3LGB2hCo6eew)：“仅仅在应用中添加哪怕一个微小的‘新功能’（这意味着新增的状态+转换节点），也会成指数级地增加该应用被调用的方式和复杂度。” Benji Taylor [tweeted that](https://twitter.com/benjitaylor/status/1509242039262593025?s=20&t=3T3ZkLvoiLYyMCmOhGEb5A) “something all these products have in common is that they are … built by small teams… Too often products lose their soul once they reach a certain scale”. Benji Taylor [发推表示](https://twitter.com/benjitaylor/status/1509242039262593025?s=20&t=3T3ZkLvoiLYyMCmOhGEb5A)：“那些优秀产品的共同点是……它们都是由小团队打造的。一旦达到某种规模，产品往往就会失去它的‘灵魂’。” Paul Stamatiou (a designer formerly at Twitter and Stripe) [said that](https://twitter.com/Stammy/status/1558122812988088322?s=20&t=c3YScLRvsv7fZqZf3vR0Mg) “responses here so far confirm my theory that… high-quality software products are only made by small teams”. 曾任职于 Twitter 和 Stripe 的设计师 Paul Stamatiou [表示](https://twitter.com/Stammy/status/1558122812988088322?s=20&t=c3YScLRvsv7fZqZf3vR0Mg)：“从目前的反馈来看，进一步证实了我的理论……只有小团队才能打造出高质量的软件产品。” Nathan A. Curtis [said](https://twitter.com/nathanacurtis/status/1517194393836560388?s=20&t=fk5JnUuHPGvuvgSYhHlWsQ) “I love Figma and value the experimentation they’re doing to add more and more. But I can sense it… their UI is ‘Adobe Creative Suite’ing. And that carries a usability cost.” Note that he said this in April of 2022, months before Adobe acquired Figma (a leading collaborative design tool). 设计系统专家 Nathan A. Curtis [说](https://twitter.com/nathanacurtis/status/1517194393836560388?s=20&t=fk5JnUuHPGvuvgSYhHlWsQ)：“我喜欢 Figma（一款主流设计协作工具），也很欣赏他们为了扩展功能所做的尝试。但我能明显感觉到……他们的界面 UI 正在变得越来越像‘Adobe 全家桶’那样臃肿。这必然会带来可用性层面的代价。”值得注意的是，他发表这番言论是在 2022 年 4 月，即 Adobe 宣布收购 Figma 的几个月前。 Repeating an argument Steve Jobs made, Marty Cagan (a renowned product management expert) [said](https://twitter.com/lennysan/status/1561876506548113408?s=20&t=mR4WJOPNyNR0oRQrVSBxHg), “as a company gets bigger, product historically became less important… Good product people don’t want to work there anymore… They go to a company that values product. I think that’s a better explanation than any other I’ve heard.” 知名产品管理专家 Marty Cagan 重复了当年乔布斯的论点，他[说](https://twitter.com/lennysan/status/1561876506548113408?s=20&t=mR4WJOPNyNR0oRQrVSBxHg)：“随着一家公司变得庞大，‘产品’在历史惯性上变得越来越不重要……优秀的产品人不想再待在那儿了……他们会跳槽去真正重视产品的公司。我认为这是我听过的关于大公司平庸化最合理的解释。” Steve Ruiz (creator of the drawing tool tldraw) [said](https://twitter.com/steveruizok/status/1571559529350942721?s=20&t=2Qm-i57bcMFxiOTZTOIi9w), “unfortunately taste doesn’t scale”. 白板工具 tldraw 的创始人 Steve Ruiz [表示](https://twitter.com/steveruizok/status/1571559529350942721?s=20&t=2Qm-i57bcMFxiOTZTOIi9w)：“不幸的是，好品味是无法规模化复制的。” Packy McCormick (author of the Not Boring newsletter) [wrote about this](https://www.notboring.co/p/indistinguishable-from-magic). Here are some good bits: 知名商业通讯 Not Boring 的作者 Packy McCormick 也曾[撰文讨论过此事](https://www.notboring.co/p/indistinguishable-from-magic)。以下是一些精辟的片段： > “Magic can, even must, be a strategy for startups. It’s something they can uniquely create, that incumbents often can’t.” > “创造‘魔法般’的体验不仅可以是初创公司的策略，甚至必须是。这是他们能独创的东西，而大厂通常做不到。” > “Figma was able to choose … sufficiently advanced technologies at that moment in time without worrying about two decades’ worth of technical debt. As a young startup, it could focus on creating magic and ride that magic until, one day, it, too, had too much technical debt… until the demands of the public markets forced it to make the kinds of practical business-driven decisions that kill the magic.” > “Figma 当年能够选择在那个时间点足够先进的技术，而不用担心背负过去二十年的技术债。作为一家初创公司，它能专注于创造魔法，并乘着这种魔法扶摇直上；直到有一天，它自己也积累了太多的技术债……直到公开市场的增长需求迫使它做出那些务实但会‘杀死魔法’的商业化妥协。” > “whether Adobe accelerates the downfall or not … the magic would have, eventually, degraded anyway.” > “不管 Adobe 有没有加速它的堕落……它身上的魔法光环最终都会不可避免地褪去。” > “A startup, if it’s lucky, creates magic, turns that magic into dollars, and transitions to life as a successful Big Muggle Company, capable of enormous profits and power but no longer able to conjure magic.” > “如果一家初创公司足够幸运，它创造出魔法，将魔法变现，然后平稳过渡为一家成功的‘大型麻瓜公司’（Muggle指《哈利波特》中不懂魔法的普通人），拥有着庞大的利润和权力，但却再也无法施展任何魔法了。” > “I was planning to bemoan the loss of magic in the products I once loved and try to figure out why the technology I use isn’t as magical as it once was. But that’s not what’s happening. What’s happening is more fascinating. The last generation of magical products has matured, turned into Muggles, and in so doing, has cleared space for a new cohort of Magicians.” > “我原本打算哀叹我曾经喜爱的产品失去了魔力，并试图弄清楚为什么我使用的技术不再像以前那样神奇。但现实并非如此。正在发生的事情其实更加令人着迷——上一代创造出魔法的产品已经成熟，变成了失去魔力的麻瓜，但也正因如此，它们为新一批初出茅庐的魔法师们腾出了发挥的空间。” > “Blame familiarity. Blame business models. Blame technical debt. Blame multivariate testing and optimization. Blame the cruel coldness of the market. Blame the hedonic treadmill. Blame our unending pursuit of shiny new things. Blame human nature.” > “怪就怪我们习以为常，怪商业模式，怪技术债。怪没完没了的 A/B 测试和数据优化。怪市场的冷酷无情。怪享乐适应效应（Hedonic treadmill）。怪我们对新鲜事物永无止境的追逐。甚至怪人类的本性吧。” Paul Graham (co-founder of Y Combinator) [said](https://twitter.com/paulg/status/1560349112922279936?s=20&t=_2skSuvZBzNGHx2c3ehEGg), “One theme I’ve noticed talking to people in Silicon Valley this trip is that Google has become terminally bureaucratic”. 硅谷著名孵化器 YC 的联合创始人 Paul Graham [提到](https://twitter.com/paulg/status/1560349112922279936?s=20&t=_2skSuvZBzNGHx2c3ehEGg)：“这次硅谷之行，我在与人们交谈中发现的一个共性主题就是：谷歌已经患上了‘晚期官僚主义’绝症。” [On the Tim Feriss show](https://tim.blog/2018/12/24/the-tim-ferriss-show-patrick-collison/) (a popular podcast), Stripe co-founder Patrick Collison said “Just think of any big, major company … for whatever reason, they can’t turn capital into good software. And it would be immensely valuable for them if they could. But they can’t. Or at least, they don’t. And I don’t think it’s for lack of trying or lack of realizing this. And so I think actually, small companies don’t realize how much of an upper hand they have here where if they can create a product that is so much better … it’s going to be really freaking hard for a big company to effectively compete because, again, this organizational transformation into being good at software is just so profoundly hard.” 在知名播客《[Tim Feriss 秀](https://tim.blog/2018/12/24/the-tim-ferriss-show-patrick-collison/)》上，Stripe 联合创始人 Patrick Collison 说：“想想任何一家大型科技巨头……无论出于什么原因，它们就是无法将手里的资本转化为出色的软件。如果它们能做到，将产生无法估量的价值。但它们就是做不到，或者至少它们没有做到。我认为这不是因为它们没有尝试，也不是因为它们没有意识到这一点。所以，实际上小公司常常没有意识到自己在这方面握有多么巨大的优势——只要你打造出一款体验出类拔萃的产品……大公司就极难与你进行有效竞争，因为让一个臃肿的组织‘基因突变’去做出好软件，实在是太难太难了。” Dan Luu (a widely respected software engineer and blogger) [has said](https://danluu.com/culture/) that “while it’s not exactly common, there are plenty of small firms out there with a culture of excellence that generally persists without heavyweight processes or big incentives”, but that “this doesn’t work at big tech companies since they’ve all gone through a hypergrowth period where it’s impossible to maintain such extreme (by mainstream standards) cultural values.” 受人尊敬的软件工程师、博主 Dan Luu [曾说过](https://danluu.com/culture/)：“虽然不算极其普遍，但在没有沉重流程和巨额激励机制的情况下，有许多小公司依然能将追求卓越的文化保持下来”，但是，“这在大型科技公司（Big Tech）是不管用的，因为它们都经历过指数级的狂飙突进期，在那期间要维持这种极端（以主流标准看）的文化价值观是不可能的。” Kevin Yien [says that](https://twitter.com/kevinyien/status/1577102698062962689?s=20&t=ZfcKRVc-DyHKIVCIIvG1MQ) “you know you are no longer a startup when your [organisational] structure prevents well-intentioned people from fixing problems”. 产品高管 Kevin Yien [说](https://twitter.com/kevinyien/status/1577102698062962689?s=20&t=ZfcKRVc-DyHKIVCIIvG1MQ)：“当你公司的组织架构开始阻碍有心人去解决问题时，你就该知道，你已经不再是一家初创公司了。” Cemre Güngör, a product manager at Instagram, [says that](https://twitter.com/gem_ray/status/1412915293274329094?s=20&t=iK3Zb15dzlafbFB5eGbAVg) “Big tech companies hire expensive senior designers but still end up with poor design because it’s much harder to make structural changes to incentives and slavish metric chasing. There’s great talent in most companies already. They’re just stifled by the organization around them.” Instagram 的产品经理 Cemre Güngör [表示](https://twitter.com/gem_ray/status/1412915293274329094?s=20&t=iK3Zb15dzlafbFB5eGbAVg)：“大厂花重金聘用资深设计师，但最终依然产出糟糕的设计，这是因为要想改变底层的绩效激励机制和病态的指标崇拜，难度太大了。大多数公司内部本来就有很多优秀的人才，只是周围僵化的组织体系扼杀了他们。” Craig Mod (a writer and designer) [said](https://craigmod.com/essays/software_slump/) “… the three primary pieces of software on macOS are probably Finder, Safari, and Mail. To have two of these show signs of instability is … just weird. It shouldn’t happen, especially when these are new, critical bugs in decades-old programs. It makes you wonder … what’s broken with the development cycle to allow for these bugs to ship… we’re seeing once-reliable applications suffer from feature creep and bloat. Perhaps this is endemic to the very nature of public companies and their conflation of features with user growth? For example: Dropbox has gone from a svelte, hyper-reliable file syncing service to a bloated curiosity that pegs the cpu at 200% for unclear reasons.” 作家兼设计师 Craig Mod [指出](https://craigmod.com/essays/software_slump/)：“……macOS（苹果电脑系统）上最核心的三个软件恐怕就是访达（Finder）、Safari 浏览器和系统邮件了。这三款软件中有两款出现明显的不稳定情况……简直匪夷所思。这是不该发生的，尤其是这些几十年老旧程序中竟然还会冒出致命的新 Bug。这不禁让你怀疑……他们的开发周期到底出了什么毛病，才会把这种满是 Bug 的版本发布出来……我们正在目睹曾经稳定可靠的应用饱受功能蔓延和臃肿之苦。这或许是上市公司的通病？它们总是把‘塞新功能’跟‘用户增长’混为一谈。再举个例子：Dropbox 已经从最初那款轻巧、极致可靠的文件同步服务，变成了一个由于不明原因动不动就让 CPU 占用率飙到 200% 的臃肿怪物。” The Financial Times’ Tim Bradshaw [said](https://www.ft.com/content/9ab775cc-d596-4e0b-aa3e-34e9111ec431) “… developers that respond by bundling ever more features into a super app risk frustrating users. Single-purpose apps are faster and easier to navigate. By contrast, the super-app approach involves cramming as many features as possible into one bloated piece of software… Spotify’s interface, for instance, has become cluttered and confusing since it added podcasts… This is my real issue with super apps: most solve a problem for the company, not the customer.” 《金融时报》的 Tim Bradshaw [表示](https://www.ft.com/content/9ab775cc-d596-4e0b-aa3e-34e9111ec431)：“……那些通过把越来越多功能打包成一个‘超级 App’的开发者们，面临着激怒用户的风险。单一用途的 App 速度更快，导航更清晰。相比之下，超级 App 就是硬把尽可能多的功能塞进一个臃肿的软件里……比如，Spotify（知名音乐流媒体）自从加入了播客之后，界面就变得杂乱无章且令人困惑……这正是超级 App 让我反感的地方：大多数时候，它们解决的是公司的商业诉求，而不是客户的问题。” Adam Michela, on the topic of Airbnb’s misleading pricing design, [says](https://twitter.com/soopa/status/1579596501424406528?s=12&t=n8XUHFkK4bjsMYR47rZq2w) “the problem is that Airbnb’s chief metric is Nights Booked (units sold) and manipulating users with basic pricing psychology moves units. It takes a Jobs-like chief to prioritize user experience over business performance.” 在讨论 Airbnb（爱彼迎）具有误导性的价格展示设计时，设计师 Adam Michela [评价道](https://twitter.com/soopa/status/1579596501424406528?s=12&t=n8XUHFkK4bjsMYR47rZq2w)：“问题在于，Airbnb 的核心考核指标是‘预订夜数（即售出单位）’，而利用基础的定价心理学去操纵用户，确实能带来订单转化。只有当公司有一位乔布斯式的领导者时，才能把用户体验置于商业绩效之上。” Adam Michela also [said that](https://twitter.com/soopa/status/1583476515634716673?s=20&t=ELkal_-ek_OLKknqVggVwg) “We’ve helped hundreds of 2-200 person startups build products … I can confidently agree that the ~30 person moment (5-10 engineers and 2 designers) is the quality sweet spot.” Adam Michela 还[表示](https://twitter.com/soopa/status/1583476515634716673?s=20&t=ELkal_-ek_OLKknqVggVwg)：“我们帮助过上百家 2-200 人规模的初创公司打造产品……我可以满怀信心地同意这一点：公司规模在大概 30 人左右（5-10 个工程师配 2 个设计师）时，是产出高质量产品的最佳甜点期。” Dennis Brotzky, coufounder of Fey, [says that](https://twitter.com/brotzky_/status/1580943383841083392?s=20&t=NZ36_x9Bq2CaFaDshl8qqw) “the smallest and most focused teams deliver the best results. Keep your team small and give them time and freedom.” 金融工具 Fey 的联合创始人 Dennis Brotzky [说](https://twitter.com/brotzky_/status/1580943383841083392?s=20&t=NZ36_x9Bq2CaFaDshl8qqw)：“最小、最专注的团队能交出最完美的答卷。保持团队的小巧，给他们时间和自由。” Michael Karnjanaprakorn, who founded Skillshare (an online learning community), [says that](https://twitter.com/mikekarnj/status/1581287479436488705?s=20&t=-0LxZk9WVOMnKNoVU-uFgQ) “quality and speed goes down as team size gets bigger”. Skillshare（在线教育平台）创始人 Michael Karnjanaprakorn [表示](https://twitter.com/mikekarnj/status/1581287479436488705?s=20&t=-0LxZk9WVOMnKNoVU-uFgQ)：“随着团队规模的扩大，质量和速度都会不可逆转地下降。” Rasmus Andersson [says that](https://twitter.com/rsms/status/1583335925056086016?s=20&t=ELkal_-ek_OLKknqVggVwg) “I’m convinced that—generally speaking—there’s an inverse correlation between number of people working on a software product and its quality (from end-user perspective)”. 设计师 Rasmus Andersson [表示](https://twitter.com/rsms/status/1583335925056086016?s=20&t=ELkal_-ek_OLKknqVggVwg)：“我深信，总体而言，开发一款软件的人数与该软件的质量（从终端用户体验角度来看）呈反比关系。” Kyle Rubenok, a PM at Microsoft, [says that](https://twitter.com/krubenok/status/1583210021068103680?s=20&t=ELkal_-ek_OLKknqVggVwg) “the best iOS design is exclusively in indie/small team apps today.” 微软的产品经理 Kyle Rubenok [说](https://twitter.com/krubenok/status/1583210021068103680?s=20&t=ELkal_-ek_OLKknqVggVwg)：“放眼今天的生态，最棒的 iOS 软件设计全都出自独立开发者或小团队之手。” Cameron Moll [says](https://twitter.com/cameronmoll/status/1584908753274634242?s=20&t=g63b7MWNAJ0C8wBA4k7SZg) “quality and craft don’t seem to scale as well as headcount.” 设计领导者 Cameron Moll [说](https://twitter.com/cameronmoll/status/1584908753274634242?s=20&t=g63b7MWNAJ0C8wBA4k7SZg)：“质量和工艺根本无法像人员扩编那样轻松实现规模化。” Box Baxley [says](https://twitter.com/ThisIsBobBaxley/status/1584923766244589570?s=20&t=g63b7MWNAJ0C8wBA4k7SZg) “Nothing about creativity scales—and it never has. Production scales. Creativity doesn’t.” 设计高管 Bob Baxley [指出](https://twitter.com/ThisIsBobBaxley/status/1584923766244589570?s=20&t=g63b7MWNAJ0C8wBA4k7SZg)：“与创造力有关的东西都无法规模化——从来都没有过。只有生产力可以规模化，创造力不行。” Hardik Pandya [says](https://twitter.com/hvpandya/status/1587676031921504257?s=20&t=ByQQTnB-jFJd2OXKjMj-3Q), “Don’t be afraid of large teams. Be afraid of small & determined teams.” 设计师 Hardik Pandya [说](https://twitter.com/hvpandya/status/1587676031921504257?s=20&t=ByQQTnB-jFJd2OXKjMj-3Q)：“别害怕几千人的大团队。你该畏惧的是小巧但目标极度笃定的团队。” Packy McCormick [says](https://www.notboring.co/p/capital-and-taste) “taste is a fickle thing on which to hang the fate of a company. At some point, growth pressures can get in the way of making sure that every detail is perfect, that every hire is great. Taste, like trust, takes a lifetime to build and minutes to destroy.” Packy McCormick [指出](https://www.notboring.co/p/capital-and-taste)：“把公司的命运押在‘好品味’这种虚无缥缈的东西上是很危险的。在某个时间节点，业务增长的压力一定会阻碍你确保每个细节都完美无瑕、确保每次招人都极其出色。品味就像信任，需要一辈子去建立，但只需几分钟就能被摧毁。” Jasmine Friedl [said](https://uxdesign.cc/measuring-design-quality-with-heuristics-44857efa514) “while these [measures of quality] worked for us, we acknowledged that it wouldn’t scale much past our small team; for example, a team with hundreds of designers shipping daily wouldn’t likely have the bandwidth for manual reviews.” 设计总监 Jasmine Friedl [说](https://uxdesign.cc/measuring-design-quality-with-heuristics-44857efa514)：“虽然这些（衡量质量的标准）对我们行之有效，但我们承认，当团队变大时，它根本无法扩展；比如，一个有数百名设计师每天不断发布更新的团队，是不可能有精力进行人工设计评审的。” Paul Stamatiou wrote an [article about craft](https://paulstamatiou.com/craft/) which has some gems in it: Paul Stamatiou 写了一篇[探讨打磨工艺（Craft）的文章](https://paulstamatiou.com/craft/)，里面字字珠玑： > “That’s where the challenge of building quality products starts to creep in. The constant tension of shipping faster versus shipping better. Falling into a cycle of “Ship, then iterate” is a trap. … Things happen and that “fast-follow” V1.1 release or V2.0 you had imagined probably won’t. There’s always a new shiny initiative, re-org or new leadership hire that throws a wrench into things and changes all plans. Don’t rely on a future release to clean up today’s mess.” > “打造高质量产品面临的挑战正源于此：‘发布得更快’与‘做得更好’之间存在永恒的拉扯。陷入所谓的‘先发布，后迭代’（小步快跑）的循环通常是个陷阱……因为意外总会发生，你幻想中所谓的‘马上跟进’的 V1.1 或 V2.0 修复版通常永远不会到来。总会有更新奇的战略计划、团队重组或空降的高管把水搅浑，打乱之前的所有计划。永远不要指望靠未来的更新来清理今天留下的烂摊子。” > “If support for quality does not come from the top, it’s far too easy for ICs to skirt over issues and pay a little less attention to details they think their reporting chain won’t notice.” > “如果顶层不支持对质量的追求，基层的一线员工（ICs）就会顺水推舟地跳过那些复杂问题，并在那些‘汇报线上的领导看不见’的细节上偷工减料。” In a 1995 interview for TV show “Triumph of the Nerds”, Steve jobs said “It turns out the same thing can happen in technology companies that get monopolies, like IBM or Xerox. If you were a product person at IBM or Xerox, so you make a better copier or computer. So what? When you have monopoly market share, the company’s not any more successful. So the people that can make the company more successful are sales and marketing people, and they end up running the companies. And the product people get driven out of the decision making forums, and the companies forget what it means to make great products. The product sensibility and the product genius that brought them to that monopolistic position gets rotted out by people running these companies that have no conception of a good product versus a bad product. They have no conception of the craftsmanship that’s required to take a good idea and turn it into a good product. And they really have no feeling in their hearts, usually, about wanting to really help the customers.” 在 1995 年电视节目《书呆子的胜利（Triumph of the Nerds）》的采访中，史蒂夫·乔布斯说：“事实证明，任何获得垄断地位的科技公司都会重蹈覆辙，比如当年的 IBM 或施乐。如果你是 IBM 或施乐的产品人，你费尽心血做了一台更好的复印机或电脑，那又怎样？既然公司已经垄断了市场，把产品做得再好也不能让公司获得更多利润。所以，真正能让公司赚更多钱的人是销售和营销人员，最终也是这群人掌控了公司。于是做产品的人被赶出了决策层，公司彻底忘记了什么叫‘做优秀的产品’。当初让公司爬上垄断宝座的‘产品直觉’和‘产品天才’，就这样被那群只懂营销、分不清好产品和烂产品的高管们腐蚀殆尽了。他们根本不懂，要把一个好点子变成好产品需要怎样的工匠精神。而且在他们的内心深处，通常也根本不在乎要如何真正去帮助用户。” Gergely Orosz [says](https://twitter.com/GergelyOrosz/status/1504366157805101056?s=20&t=YZt87iLR2ApRlrm_WdCEZw) “Very few if any people and teams [at a large tech company] get rewarded for fixing low impact issues impacting 0.002% of users. Also few get punished by not doing so. At any Big Tech, incentives that drive promotions and performance reviews end up driving a surprisingly large amount of decisions. Most of these incentives are impact, revenue generation at scale & savings at scale. Fixing small issues fits none of these. In fact, fixing one-off issues is one of the most expensive things to do. It would - and does! - pull profits down. This is bad for business.” 科技博主 Gergely Orosz [指出](https://twitter.com/GergelyOrosz/status/1504366157805101056?s=20&t=YZt87iLR2ApRlrm_WdCEZw)：“在大型科技公司，极少有个人或团队会因为修复了一个只影响 0.002% 用户的微小瑕疵而获得嘉奖，同样地，不修复它也不会受罚。在任何大厂，决定员工升职加薪的绩效考核机制，在很大程度上支配了团队的决策。这些指标通常是：可量化的影响力、大规模创收或大规模削减成本。修复小瑕疵哪一条都沾不上。事实上，修复边缘的长尾 Bug 是成本极其高昂的举动。它会拖累公司的利润表现——事实也确实如此！这对追求利益的商业机器来说是不划算的。” Dan Luu [says](https://danluu.com/nothing-works/) “The pervasiveness of … technical decisions made without serious technical consideration, is a major reason that the selection pressure on companies to make good products is so weak. There is some pressure, but it’s noisy enough that successful companies often route around making a product that works, like in the Mongo example from above, where Mongo’s decision to loudly repeat demonstrably bogus performance claims and making demonstrably false correctness claims was, from a business standpoint, superior to focusing on actual correctness and performance; by focusing their resources where it mattered for the business, they managed to outcompete companies that made the mistake of devoting serious resources to performance and correctness.” Dan Luu [指出](https://danluu.com/nothing-works/)：“……在没有经过严肃技术论证的情况下便草率做出技术决策，这种现象如此普遍，这也是为什么公司根本感受不到必须做出‘好产品’的市场竞争压力的主要原因。即便有压力，市场信号也充满了噪音，以至于那些所谓‘成功’的公司往往会绕开‘打造有效产品’的本质。以 Mongo（一种数据库）为例，从商业角度看，Mongo 公司决定大肆宣传那些明显夸大的性能数据，甚至做出了虚假的数据一致性承诺，这反而比老老实实去解决底层的数据正确性和性能要有效得多；通过把资源倾斜在‘对拉升估值有用的包装’上，他们成功地干掉了那些傻傻地把核心资源花在提升底座性能和数据正确性上的竞争对手。” Arvind Narayanan [says](https://twitter.com/random_walker/status/1182636136843354112?s=20&t=60rPs-IIdDOu3lip-R5O6A) “some products are sold directly to the end user, and are forced to prioritize usability. Other products are sold to an intermediary whose concerns are typically different from the user’s needs. Such products don’t HAVE to end up as unusable garbage, but usually do.” 普林斯顿大学计算机科学教授 Arvind Narayanan [表示](https://twitter.com/random_walker/status/1182636136843354112?s=20&t=60rPs-IIdDOu3lip-R5O6A)：“有些产品直接卖给终端用户，所以他们被迫把可用性放在第一位。而另一些产品卖给的是采购方（中间人），而采购方的关注点与真实用户的痛点通常截然不同。这类（to B 端）产品其实没必要沦为难用的垃圾，但现实中它们往往难逃此劫。” Nick Lockwood [says](https://twitter.com/nicklockwood/status/1534827111877312513?s=20&t=LfjcGQG9Ze9IYd5E1hWLUQ) “development is like Zeno's paradox, where effort rises exponentially. You never actually reach completion, you just get ever nearer to it, with each unit of effort getting you fractionally closer… this fact applies *fractally*, to every feature. At any point in a product's lifecycle, it will be the same (or more) effort to fix a small bug or papercut than to implement a major new feature (or rather, to implement 80% of it, minus the last few bugs and papercuts).” 开发者 Nick Lockwood [说](https://twitter.com/nicklockwood/status/1534827111877312513?s=20&t=LfjcGQG9Ze9IYd5E1hWLUQ)：“开发软件就像‘芝诺悖论’（永远追不上的乌龟），付出的努力呈指数级增长。你永远达不到100%的完美完成，你只能无限逼近它，每投入一分心血，只让你离它进了一丝一毫……这个残酷的事实在产品开发的每一个细枝末节上都像分形几何一样应验。在产品生命周期的任何节点，去修复一个小 Bug 或是打磨一个粗糙边缘所花费的精力，可能跟开发一个全新的大功能（准确地说，是开发出一个没经修饰的 80% 的大功能框架）所付出的精力一样多，甚至更多。” Alexandr Wang (CEO of Scale AI) [says](https://twitter.com/alexandr_wang/status/1594062781673721856?s=20&t=00CKJLccHetOTmKZ5Ql2uA) “Unintuitive fact of engineering: Big teams (>8 people) ship less than small teams. Not only less per capita—less overall!” AI 独角兽 Scale AI 的创始人 Alexandr Wang [说](https://twitter.com/alexandr_wang/status/1594062781673721856?s=20&t=00CKJLccHetOTmKZ5Ql2uA)：“软件工程中一个极其反直觉的事实：大团队（超过8人）最终交付的代码和功能，往往比小团队还要少。不仅仅是人均产出少——是总体加起来都更少！” On Twitter, Dan Luu [said](https://twitter.com/danluu/status/1603952302897131520?s=20&t=n52BQUC33hjl3FkryTUpGg) “… a sentiment I’ve heard from literally all of the highest impact/most effective people I’ve talked to at large companies: You can make a big difference, but you’re constantly fighting a self-sabotaging organization”. 在 Twitter 上，Dan Luu [提到](https://twitter.com/danluu/status/1603952302897131520?s=20&t=n52BQUC33hjl3FkryTUpGg)：“……我在大厂接触过的几乎所有高绩效、高影响力的牛人都表达过类似这样的无奈：你在个人层面上确实能做出巨大贡献，但你感觉自己每时每刻都在跟一个疯狂搞内耗、自我毁坏的臃肿组织对抗。” In his article [Tiktok’s enshittification](https://pluralistic.net/2023/01/21/potemkin-ai/#hey-guys), Cory Doctorow (a prominent technology activist and science fiction author) said “here is how platforms die: first, they are good to their users; then they abuse their users to make things better for their business customers; finally, they abuse those business customers to claw back all the value for themselves. Then, they die”. 在《[TikTok 的平台衰败（enshittification）](https://pluralistic.net/2023/01/21/potemkin-ai/#hey-guys)》一文中，著名科幻作家、技术活动家 Cory Doctorow 首次提出了“平台衰败（enshittification）”的概念，他说：“所有的互联网平台都是这样走向死亡的：起初，他们疯狂讨好用户（烧钱补贴）；接着，他们开始压榨用户，好在广告商和企业客户面前粉饰太平；最后，他们开始收割企业客户，把所有的价值榨干踹进自己的腰包。再然后，他们就在被骂声中死掉。” George Kedenburg III wrote an article, “[The Cost of Craft](https://gk3fyi.substack.com/p/the-cost-of-craft)”, on this topic: 设计师 George Kedenburg III 撰写了一篇名为《[打磨工艺的成本（The Cost of Craft）](https://gk3fyi.substack.com/p/the-cost-of-craft)》的文章，探讨了这一话题： > “Over time Instagram continued to grow and evolve. The product got bigger and more complicated as it accumulated more competitors and employees. Three years went by and I noticed that it was starting to feel more and more like the environment I left Facebook to escape — a place where metrics and growth mattered more than creating experiences that people love.” > “随着时间的推移，Instagram 不断发展壮大。随着竞争对手和员工数量的激增，产品变得越来越庞大复杂。三年过去了，我发现这里越来越像当初那个让我选择逃离的 Facebook——在这里，冷冰冰的数据指标和用户增长，比为用户创造他们热爱的体验重要得多。” > “It appears inevitable that all digital products must eventually trade craft for scale.” > “看来，所有数字产品最终都不可避免地要为了业务规模而牺牲掉工艺打磨。” > “The cost of craft rises with each additional person.” > “每一个新员工的加入，都在推高维系工匠精神的成本。” > “The secret sauce I was searching for was really just a perfect blend of size and talent… It’s simply so much easier to keep 10 people in sync than 10,000. Each additional person makes it harder for everyone to stay focused and in sync.” > “我苦苦寻觅的‘完美配方’，其实就是公司规模和顶尖人才的绝佳平衡……让 10 个人保持信息同频，比让 10000 个人同频简单太多了。每增加一个人，就让所有人保持专注和同频变得难上一分。” Patrick McKenzie [wrote that](https://twitter.com/patio11/status/1648716242885435392?s=20) “… as software companies get larger … they increasingly make it difficult to get relatively simple software done, which leads to surprising results … You just need a landing page, but the process of getting a landing page done requires three quarters of lead time and sixteen reviews, and the Landing Page as a Service fits on a purchasing card and takes two hours…” Patrick McKenzie [写道](https://twitter.com/patio11/status/1648716242885435392?s=20)：“……随着软件公司变得越来越庞大……它们反而把开发相对简单的软件这事儿搞得异常困难，这导致了荒谬的结果……你明明只需要建一个简单的落地页（Landing page），但在大公司走完流程，需要排期三个季度、经过 16 道审批；而如果你在外面找个第三方 SaaS 建站工具绑定信用卡，只要 2 个小时就能搞定……” Adam Stoddard [wrote about craft at scale](https://aaadaaam.com/notes/craft-at-scale/), and said that “Funded startups and public tech companies need to keep the high-growth engine running, which inevitably leads progressively larger and more complex product offerings that attempt to attract more and more users. No single team can deliver on that, which leads directly to disjointed and/or competing teams, and a steady erosion of vision that’s backfilled by process.” 设计师 Adam Stoddard 在[谈到规模化与工艺的文章](https://aaadaaam.com/notes/craft-at-scale/)中写道：“拿了风投的初创公司和上市科技巨头必须维持住高增长引擎的轰鸣，这就不可避免地导致他们试图打造越来越庞大、越来越复杂的功能矩阵，以圈住更多用户。没有任何单一团队能独立消化这种庞大的工作量，这直接导致了各自为战甚至是内部赛马竞争的团队出现。于是，产品最初的清晰愿景被一点点蚕食，取而代之的是冰冷僵硬的流程规范。” Joel Beukelman [said](https://twitter.com/_bklmn/status/1664279030861017088?s=20), “After ~8 years at Google I have a deep respect for product at scale, but my $.02 is there’s some sparkle lost when a team gets too big.” 设计总监 Joel Beukelman [说](https://twitter.com/_bklmn/status/1664279030861017088?s=20)：“在谷歌待了大约 8 年后，我深刻理解了什么是大规模的产品运作，但我的浅见是：当一个团队变得太大时，某些不可言喻的‘灵气’就随之消散了。” Chief Product and Engineering Officer Claire Vo [wrote a post](https://x.com/clairevo/status/1705637278226506135?s=20) on this topic. Some excerpts: 首席产品与工程官 Claire Vo [发布了关于这个话题的帖子](https://x.com/clairevo/status/1705637278226506135?s=20)。部分摘录如下： > “Almost everything about growing the size and scale of your team has immediate and detrimental impacts to the thing that matters the most: building awesome products.” > “扩大团队规模几乎在所有维度上都会产生立竿见影的负面影响，最终反噬那件最核心的任务：打造牛逼的产品。” > “… meetings, process, policy and operating models are necessary for high scale and trusted delivery AND YET teams that forget to actively and aggressively prune the worst effects of these things out of their company will soon regret it.” > “……各种会议、审批流程、公司政策和管理模型确实是大规模运作和确保安全交付的必要条件。但即便如此，如果团队忘记了‘定期且强硬地剪除’这些官僚主义带来的毒瘤，他们很快就会追悔莫及。” Karri Saarinen, co-founder of Linear (a popular issue tracking tool for software teams), [wrote a post about quality](https://x.com/karrisaarinen/status/1710331542369914903?s=20) and said, “As companies grow, they often have a hard time with quality, and usually just give up on it. [The] main reason is that quality is something which cannot be easily measured or defined. As the companies scale, the way they operate or make decisions [is] based more on measurements.” 极客项目管理工具 Linear 的联合创始人 Karri Saarinen 写了一篇[关于产品质量的帖子](https://x.com/karrisaarinen/status/1710331542369914903?s=20)，他表示：“随着公司的扩张，他们往往在保持质量这件事上苦苦挣扎，最终通常选择干脆摆烂。最核心的原因在于，‘质量’和‘品味’是很难被量化和精准定义的东西。而当公司做大后，所有的运营机制和拍板决策，都是围着能被量化的 KPI 数据转的。” In [a conversation with Linear about quality](https://linear.app/quality/01), Dick Costolo (former CEO of Twitter) said, “The best product teams will stay as small as possible, as long as possible. It just becomes too difficult for the product to look and feel like the outcome of a singular simple vision for what the future could be as you layer more and more and more people into the thing.” 在[一场与 Linear 关于质量的对话](https://linear.app/quality/01)中，Twitter 前 CEO Dick Costolo 说：“最顶级的团队应该尽可能长时间地保持在极小的规模。因为当你在项目中不断增加人员、叠床架屋时，想要让产品看起来依然保持当初那种简单且纯粹的愿景，就会变得难如登天。” ## Companies with dedicated quality efforts ## 致力于提升质量的公司 Many companies say they care about quality, but don’t have specific efforts dedicated to it. Here are some that do. 许多公司把“我们在乎质量”挂在嘴边，但并没有任何实际行动来保障它。以下是几个言行一致、设立了专门机制的公司： ### Automattic ### Automattic（WordPress 母公司） Automattic employs a Chief Quality Officer. Here’s what Lance Willett told me about the role: Automattic 设立了“首席质量官（Chief Quality Officer）”。以下是该职位的负责人 Lance Willett 告诉我的内容： > [I pay] attention to both the big picture (strategy: culture, mindset, consistency) and oversee the day-to-day details (execution: bug fixing, automated testing, and quality metrics). I sit in the C-suite to help drive culture change for technical quality, reporting on key quality metrics to the CEO and our board (think: Core 4) while also leading a hands-on QualityOps team. I approach my role as a “full-stack leader”, able to ship software changes myself in any product/app while keeping an eye on the entire landscape. > [我需要]兼顾宏观大局（如战略层面的：文化、思维模式、产品一致性），又要死盯日常细节（如执行层面的：Bug 修复、自动化测试以及监控质量指标）。我身处最高管理层（C-suite），负责推动技术质量方面的文化变革，向 CEO 和董事会汇报关键质量指标，同时我还带领着一个亲自下场实干的 QualityOps 团队。我把自己定位为一个“全栈领导者”——既能纵览全局，又能亲自在任何项目代码里提交更改。 > > You can read more about Lance’s role [here](https://fullstackleader.blog/2025/07/14/head-of-quality/). 你可以在[这里](https://fullstackleader.blog/2025/07/14/head-of-quality/)阅读更多关于 Lance 这一角色的介绍。 ### GitLab ### GitLab GitLab has a “UX Paper Cuts” team, which they describe this way: GitLab 设立了一个名为“UX Paper Cuts（专治用户体验‘纸划伤’的小痛点）”的团队，他们是这样描述的： > The UX Paper Cuts team has a unique scope; we are responsible for identifying and fixing small yet impactful usability issues across the GitLab product… By default, the UX Paper Cuts team does not take on new feature work, nor is the team used as a resource for another Group. Instead, the team focuses on usability and accessibility issues, design inconsistencies, and out-of-date UI across the entire product. > UX Paper Cuts 团队的职责范围很独特；我们专门负责识别并修复 GitLab 全局产品中那些“微小但让人极不舒服”的可用性问题……在默认情况下，本团队绝不承担任何新功能的开发工作，也不允许被借调给其他项目组当苦力。相反，我们只专注于全系产品的可用性、无障碍访问问题、设计不一致性以及旧版 UI 的翻新。 > ### HubSpot ### HubSpot（领先的 CRM 营销平台） HubSpot created a “Cohesion Studio”, which they describe this way: HubSpot 成立了一个“一致性工作室（Cohesion Studio）”，他们的描述如下： > Cohesion Studio is focused on improving user experience across HubSpot, making our products faster and easier to use. This team operates as a horizontal layer between the design system team and our product teams. The job of this team is to assess, track, and unify HubSpot’s end-to-end journeys. > 一致性工作室致力于改善 HubSpot 全局的用户体验，让产品更快、更好用。该团队作为横向支持部门，介于底层设计系统团队和一线业务团队之间。他们的核心任务是评估、追踪并统一 HubSpot 产品的端到端交互旅程。 > ### Linear ### Linear（极简主义项目管理工具） In 2022, [Linear had a month dedicated](https://linear.app/changelog/2022-12-01-polishing-season-2022) to interface design polish: “For the rest of the year, polishing will be our sole focus. No new feature work, just quality of life improvements.” 在 2022 年底，Linear [拿出了一整月时间专门打磨界面细节](https://linear.app/changelog/2022-12-01-polishing-season-2022)：“在今年剩下的日子里，精雕细琢将是我们唯一的重点。禁止任何新功能的开发，全员致力于提升用户体验（QoL）的细节改进。” They also have a permanent policy related to bug fixes: 不仅如此，他们在对待 Bug 修复上还有一条雷打不动的铁律： > A few months ago, we changed the way we address bugs at Linear. We prioritized bugs over everything else. If you have bugs assigned when you wake up in the morning, you don't do anything else before they are addressed. > 几个月前，我们改变了 Linear 处理 Bug 的方式。我们将 Bug 提到了最高的优先级。如果你早上醒来发现身上指派了未处理的 Bug，在彻底消灭它们之前，你不准干任何其他事情。 > Finally, for changes that aren’t bugs, they have “Quality Wednesdays”: 最后，针对那些虽然不是 Bug、但体验很别扭的设计，他们设立了“质量星期三”： > We have a separate ongoing process for things that could work slightly better. We have quality Wednesdays where each team member shows off at least one thing that they’ve slightly improved in the product in the previous week. > 对于那些“本可以做得更好一点”的事情，我们有一套持续运转的机制。每周三是我们的“质量日”，每个团队成员都要向大家展示他们在过去一周里对产品哪怕微不足道的体验提升。 > ### Meta ### Meta（原 Facebook） Ron Goldin and some other people at Meta introduced quality metrics: 设计师 Ron Goldin 和 Meta 的其他同僚曾引入过一种质量评分机制： > When I was at Meta, some colleagues and I went so far as to set up a “Quality” program where we attempted to define, quantify, measure and report, among others things, a numerical Craft score for our key journeys. > 当我在 Meta 工作时，我和几位同事甚至牵头建立了一个“质量”项目组，我们试图在内部对核心的产品交互链路进行定义、量化、测量，并打出直观的“工艺跑分（Craft score）”。 > ### Microsoft ### 微软 After public outcry about the quality of Windows 11, Microsoft announced a dedicated effort to improve: 在公众对 Windows 11 拉胯的质量进行猛烈抨击之后，微软宣布将投入专门的精力进行整改： > What follows is our plan to raise the bar on Windows 11 quality this year, with a focus on performance, reliability and well-crafted experiences. These areas have meaningful impact on how you experience Windows: how fast it starts and responds, how stable it is under real workloads, and how consistent and thoughtful the experience feels. > 接下来是我们今年提高 Windows 11 质量标准的计划，重点关注性能、可靠性和精细打磨的体验。这些领域会对你体验 Windows 的方式产生深远影响：系统启动和响应的速度、在真实工作负载下的稳定性，以及交互体验是否足够一致和贴心。 > ### Operate ### Operate（一家注重设计的初创科技公司） > We just started the Give a Damn™ initiative at Operate — dedicated time to sweat the details. > 我们刚刚在 Operate 启动了“死磕到底（Give a Damn™）”倡议——专门留出时间去给魔鬼细节死磕。 > ### Shopify ### Shopify（知名电商建站平台） Shopify started a team to focus on quality: Shopify 也组建了一支专注于把控质量的队伍： > … sometimes you need space for specific focus on quality. That’s precisely what a new team at Shopify is doing. Our team is focused on looking horizontally across Shopify admin… We’re addressing quality issues from adjusting visual design details to fundamentally restructuring pages or components. > ……有时，你必须留出空间专门用来狠抓质量。这也正是 Shopify 新团队正在做的事。我们的团队主要负责横向审视整个 Shopify 的后台管理系统……我们正在解决各种质量问题，小到调整视觉设计的像素细节，大到从根本上重构页面或组件体系。 > ### Sonos ### Sonos（高端智能音响品牌） Sonos has appointed a “quality ombudsman”. Sonos 设立了一个名为“质量监察专员（Quality Ombudsperson）”的独特职位。 > We are creating a new role: Quality Ombudsperson. This person will ensure employees have a clear path to raise concerns regarding quality and customer experience. The ombudsperson will report directly to executive leadership, publish reports twice a year, and present regularly to the Sonos board of directors. > 我们正在创建一个全新职位：质量监察专员。这个人将确保所有员工在发现有关产品质量或客户体验的隐患时，有一条顺畅的内部举报/反馈通道。该专员将直接向最高执行层汇报，每年发布两次质量报告，并定期向 Sonos 董事会作陈述。 > ### Stripe ### Stripe Stripe hired Malthe Sigurdsson as “Head of Craft”: Stripe 聘请了 Malthe Sigurdsson 担任“工艺总监（Head of Craft）”： > I’m coming back to Stripe as “Head of Craft” on Katie Dill’s team to help drive our continued focus on craft, beauty, and quality. > 我回到 Stripe，在 Katie Dill 的团队里担任“工艺总监”，以此来协助公司继续保持在产品工艺、美感和质量上的极高专注度。 > ### Zed ### Zed（一款高性能、多人协作代码编辑器） [Twice a year](https://x.com/zeddotdev/status/2001008164301627903?s=20), Zed has a “quality week”. Here’s how they describe it on their website: [每年有两次](https://x.com/zeddotdev/status/2001008164301627903?s=20)，开发代码编辑器 Zed 的团队会举办“质量周”。以下是他们在官网上对此的描述： > … periodically, we conduct what we refer to as "Quality Week." During this time, we halt work on feature additions and pivot to working solely on user pain points within Zed … We focus on finding issues that try to balance a small amount of work with a potentially large impact. We prioritize reducing cases where Zed can panic. The overall goal of Quality Week is to ship a more stable, refined Zed. > ……我们会定期开展名为“质量周”的活动。在这期间，我们彻底停止新增功能的开发，将所有精力投入到解决 Zed 中让用户难受的痛点上……我们重点寻找那些“改动工作量小、但能极大提升体验”的四两拨千斤的改进点。并优先消灭那些会导致 Zed 崩溃的边缘 Bug。质量周的终极目标，就是向用户交付一个更加稳定、更为精致的软件本体。 > ## Interface quality of life improvements ## 提升界面体验的细节改进（QoL 优化） Here are some quality of life improvements you can make to an interface. 以下是你可以在界面设计中加入的一些“生活质量改进（Quality of Life，即能显著提升用户幸福感和操作流畅度的微小体验优化）”： 1. Generous mouse paths in nested menus, where the menu doesn’t close if the mouse isn’t always within its boundaries. 在嵌套的多级菜单中预留**宽容的鼠标移动路径（Generous mouse paths）**：在光标滑向子菜单时，即使暂时移出了菜单边缘，菜单也不会立刻关闭（这避免了“手一抖菜单就没了”的烦恼）。 2. Coyote time for keyboard shortcuts, where a multi-key shortcut isn’t cancelled as soon as you release the wrong key first. 为组合快捷键引入**“土狼时间”缓冲（Coyote time）**：即便你手指失误先松开了某个修饰键，快捷键组合指令也不会被立刻打断（注：“土狼时间”源自经典动画《兔八哥》中，土狼跑出悬崖边还未掉落的短暂滞空时间，在游戏和交互设计中引申为一种防失误的容错机制）。 3. Stretch/bounce motion effects in scrolling list views, to help show that someone has reached the end of the list. 在滚动列表中添加**拉伸/回弹（Stretch/bounce）的物理动效**，这能直观地暗示用户已经滑到了列表的最顶端或最底端（比如苹果 iOS 中的橡皮筋回弹效果）。 4. Smooth and fast expand and collapse animations for all elements that expand and collapse (as opposed to no animation). 为所有折叠/展开的元素提供**丝滑且极速的过渡动画**（坚决抵制生硬的瞬间切图）。 5. Starting expansion and collapse animations from the direction of the element that triggered the animation, so that it feels as if it’s expanding away from that element. 展开和折叠动画的**原点应该顺应触发该动作的元素方向**，这样在视觉上会有“内容是从那个元素里延伸出来的”连贯错觉。 6. Smooth and fast animated movement for elements that move from one place to another (as opposed to no animation). 当任何界面元素从一处转移到另一处时，务必加上**丝滑且极速的移动补间动画**（而不是直接瞬移）。 7. Animation to let you know that elements in the edge of your vision have appeared or changed. 当用户视觉边缘（非中心视区）的元素出现或发生改变时，**利用微动画来温和地引起用户的注意**。 8. Menus and other pop-up elements open ~instantly but take slightly longer to fade away. 菜单和其他弹出式面板应当**近乎瞬间地弹出，但在消失时加入极其短暂的淡出时间**。 9. Optical adjustment of visually unbalanced elements so they look properly aligned. 对那些受字体或形状影响而导致视觉失衡的元素，进行人工的**光学微调（Optical adjustment）**，以确保它们在人眼中看起来是绝对对齐的（机器居中不等于视觉居中）。 10. If an element that contains text is changed to an “edit” mode, keep the text in the same place as the mode changes. 当包含文本的卡片/区块切换到“编辑”模式时，**绝对不要让文本在切换瞬间发生位置跳动**。 11. Don’t move elements as the result of an interaction near or with that element, unless that’s the interaction’s purpose. **除非交互的核心目的就是移动元素，否则不要因为附近的某个误操作而引发元素的突然移位**（拒绝恼人的排版错位）。 12. If elements are added or removed to a list, maintain the subjective scroll position so that elements visually stay in the same place. 如果在长列表中动态插入或移除了新项目，**系统应自动补偿并维持用户当前的视觉相对滚动位置**，确保当前阅读的元素停在原位不乱跳。 13. Open context menus so that the menu actions are always in the same place relative to the cursor. 打开右键上下文菜单时，**确保菜单项相对于光标弹出的位置始终保持一致**（培养用户的肌肉记忆）。 14. On mobiles open the correct type of keyboard for the field selected. 在移动设备上，根据用户点击的输入框属性，**智能唤起正确类型的软键盘**（比如邮箱键盘、数字小键盘）。 15. If clicking something opens a new interface where the mouse is, don’t put something risky under the current mouse cursor position, in case the person clicks again by accident. 如果点击某个按钮后，会在鼠标当前位置弹出新界面，**切记不要把“危险操作（如删除、支付确认）”正好放在此时的鼠标下方**，以防用户手抖连击酿成惨剧。 16. Object permanence: elements that feature in more than one view persist throughout transitions from one view to another, even if they move or change shape/size. **客体永久性（Object permanence）：** 对于横跨多个视图的通用元素，即使在切换视图时改变了大小和位置，也要通过平滑过渡让用户感知到“它还是原来那个元素”（共享元素动画）。 17. Unless explicitly requested, information entered by a person is never lost if that person leaves the screen. **除非用户明确点击了放弃，否则只要用户输入了信息，哪怕意外退出了当前屏幕，这些未保存的数据也绝不能丢失**。 18. If a moveable element (e.g. a scrollable horizontal stack of containers) has natural positions, snap it into those positions. 如果一个可滑动的元素（例如水平滚动的卡片组）有其“自然停靠点”，应当使用**磁吸效果（Snap）让它完美停靠在边缘**，而不是让卡片停在卡住一半的尴尬位置。 19. Show changes to something in real time, or if the thing is not visible, show a preview of the changes as options are changed. **实时反馈更改结果**；如果在调节参数时主控体不可见，也要在调节滑块的旁边提供迷你预览图。 20. Delay opening e.g. a tooltip, but if the mouse then moves to a neighbouring element which also has a tooltip, show the new tooltip instantly. **对工具提示（Tooltip）的首次触发设置微小延迟**（防止鼠标扫过时引发弹窗乱飞）；但如果工具提示已经显示，且鼠标接着移向了旁边另一个同样带有提示的元素，**新的提示应该瞬间显示，不带任何延迟**。