设计与产品craigmod.com
快的软件，才是最好的软件
Fast Software, the Best Software
2019 — 2022，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇文章主张“快软件才是最好的软件”：速度不只是性能指标，而是让用户与工具融为一体、保持心流的关键，慢软件很少能成为伟大的工具。作者批评日常软件因功能膨胀和频繁改版而变慢，呼吁把响应速度当作产品质量的一部分。
为什么经久不衰：每个时代软件都在变重变慢，这篇文章把“快”从工程指标提升为工具哲学，提醒人们速度本身就是产品品质。
HN 评论精选
速度给用户探索和组合功能的空间，而功能膨胀会拖慢产品和组织。
以人手的速度运行还有一个未明说的好处：用户能自己组合出功能，并且乐在其中。如果每次点击都要等一秒，我就不太会在你的应用里发明新用法，不会探索边界，也不会做超过四五次点击的事，应用就更不合我。若付费，我可能会要求一个六七次点击的组合功能；你实现了它，产品整体可能更慢，开发组织也更慢，因为功能多意味着更多产品经理和协调会。
nateburke查看英文原文
One benefit of performing at the speed of the human hand not explicitly discussed here is the ability for users to _compose_ their own features (and to love doing so!). If I need to wait even a second for a page or app to respond per click, I am a lot less likely to _invent_ in your app. I won't stretch the boundaries, I won't do things that take more than 4 or 5 clicks. The app will _fit_ me less. I will call up and ask for a feature that is a 6-7 click combination, if I am paying. And if you build that feature, now you will likely have a slower product overall. And also a slower product development org. Because more features mean more product managers. And more product managers mean more coordination meetings. And more coordination meetings mean... well you get the picture. Love this post!
企业软件应把即时响应作为发布门槛，优化常能消除漫长等待。
我近几年把这种理念付诸实践。在企业环境里，用户对查询和报表的接受度是几十秒、几分钟甚至几小时。我做的项目尽量极简且极快；新增功能或查询若不能即时响应，我就不发布。很多“几小时”和“近即时”的差别只是简单的查询优化；等超过几秒让我恼火。
overcast查看英文原文
I've been taking this philosophy to heart the past few years. Working in the corporate world, I find users acceptance level to be in the tens of seconds/minutes/HOURS?! for queries and reports. Projects I've worked on have focused on being as minimal and lightning fast as I can possibly make them. If I add a new feature/query, and it's not instant, I don't ship it until it is. I don't know where or when this became norm, but often times the difference between hours and near instant, is a matter of a simple query optimization. Waiting more than a few seconds for something to run is infuriating to me.
速度是保持心流的前提，响应时间存在认知上限。
为什么慢不好？快软件不总是好软件，但慢软件很少能伟大。快软件给用户“融入”工具的机会，不打断心流。Vi 和 Emacs 之争部分就是因为人们强烈偏爱其流畅和融合感。补充硬数据：“八秒规则”是用户平均等待系统交回控制权而不走神的上限；NN/g 认为更像十秒。
jt2190查看英文原文
> But why is slow bad? Fast software is not always good software, but slow software is rarely able to rise to greatness. Fast software gives the user a chance to “meld” with its toolset. That is, not break flow. When the nerds upon Nerd Hill fight to the death over Vi and Emacs, it’s partly because they have such a strong affinity for the flow of the application and its meldiness. They have invested. The Tool Is Good, so they feel. Not breaking flow is an axiom of great tools. To add some hard data to this, the “eight second rule” [1][2] is the maximum amount of time a user, on average, of a system can wait for that system to return control back to the user without the user having some other thought pop into their brain, interrupting their flow. [1] Response Times: 3 Important Limits (2010) https://www.nngroup.com/articles/response-times-3-important-limits/ says it’s more like ten seconds [2] Website Response Times (2010) https://www.nngroup.com/articles/website-response-times/ [3] The Need for Speed, 23 Years Later (2020) https://www.nngroup.com/articles/the-need-for-speed/ Edit: Added reference Edit 2: Additional reference Edit 3: One more reference Edit 4: I think there are still many many opportunities to improve flow in many processes. Top of my list would be keeping compile times in the single-digit seconds.
市场更愿意为功能买单而非速度，使慢软件仍能存活。
我有时想，什么会让软件更快、更少 bug。网站明明有强激励却常难做到，内部研究通常显示提速能改善关键指标；SaaS 也常慢或有 bug。切换很难，性能问题可能太晚才明显；演示不足以评估产品。买家更被功能吸引而非速度，也许他们没错，或需要被教会重视质量与速度，但怎么教？不经过大量试用，又怎么评估软件质量？也许软件价值太大，即使难用也值得且难替换。
dan-robertson查看英文原文
I sometimes wonder what would cause software to be faster (or less buggy). Websites seem to often struggle with this despite overwhelming incentives for speed (and if you browse without an ad blocker things are even slower!) where typically any internal study will show that increased speed improves key metrics. SaaS apps also seem to suffer from often being slow or buggy. I guess part of the reason is that switching is hard and performance problems may not be obvious until it’s too late. How do you even evaluate some product like Jura without using it a bunch? A demo is surely insufficient. I think people buying software are also more drawn to features than speed and maybe they are right or maybe they need to somehow be taught that they are undervaluing quality/speed, but how do you teach that? And how do you even asses software quality – how well it actually solves your problems and whether it is full of bugs – without a significant trial. Maybe there is an argument that the software is so valuable that even awful software that is not fun to use is valuable and quickly becomes hard to cut. One solution might be more heterogeneous services but then you might be paying more per-seat as you still have lots of overlap and it also sucks to have N bug trackers and M wiki/doc systems and so on. So maybe you then want services to be more interoperable but I think that may just force them all to suck.
历次讨论
同类还值得读
贝塞尔曲线入门
A Primer on Bézier Curves
Pomax 编写的贝塞尔曲线在线教程，从基础概念一路讲到曲线求交、投影、曲率等进阶内容，并配有可交互的示例和配套的 bezier.js 库。
设计与产品上首页 7 次 · 2014–2022pomax.github.io编辑精选WebGL 水面模拟
WebGL Water
Evan Wallace 制作的 WebGL Water 演示：在浏览器里实时渲染一片水面，展示折射、反射和焦散等 GPU 图形效果。
设计与产品上首页 6 次 · 2011–2025madebyevan.com设计建议：永远不要使用黑色
Design Tip: Never Use Black
设计随笔提出“永远不要用纯黑”的建议，主张在界面和绘画中改用深灰或带色相的暗色，并借阴影与色彩关系来论证。
设计与产品上首页 5 次 · 2012–2021ianstormtaylor.com用于思考不可想象之物的媒介
Media for Thinking the Unthinkable
Bret Victor 的这个页面围绕《Media for Thinking the Unthinkable》展开，探讨我们用来思考和表达复杂问题的媒介，以及以文字/符号为主的传…
设计与产品上首页 5 次 · 2013–2020worrydream.com编辑精选页面重量很重要
Page Weight Matters
博文讲 YouTube 工程师 Chris Zacharias 的一次页面瘦身实验：团队做了一个更轻量的页面版本，起初从整体平均加载时间看反而更慢；按地理区域分层后才发现，轻量版…
设计与产品上首页 4 次 · 2012–2022blog.chriszacharias.com