來源:Hacker News查看原文 ↗
原文著作權歸來源方所有,本站僅作收錄、翻譯或格式整理。
來源摘要
Article URL: https://unsung.aresluna.org/solving-a-largely-imaginary-user-goal/ Comments URL: https://news.ycombinator.com/item?id=49300411 Points: 9 Comments: 4
來源:Hacker News查看原文 ↗
原文著作權歸來源方所有,本站僅作收錄、翻譯或格式整理。
使用社群帳號登入
这篇文章发布于 2026 年 8 月 14 日,标题为《Solving a largely imaginary user goal》,发布在 unsung.aresluna.org。文章在 Hacker News 上获得 9 个积分和 4 条评论。
文章主题围绕产品开发中"解决一个很大程度上虚构的用户目标"的现象展开,即开发者或产品团队投入资源去解决一个可能并不真实存在的用户需求。原文的具体论据、案例和作者身份在素材中未提供。
这篇文章触及了产品开发中的一个常见问题:团队在缺乏充分用户验证的情况下,围绕一个假设或想象出来的需求进行开发。这类"虚构用户目标"往往源于开发者自身的直觉、技术热情或对市场的过度推断,而非来自真实的用户反馈。
从同一时间 HN 上的其他投稿可以观察到这一话题的现实语境。例如 Show HN: Online SNMP MIB database 这类工具型产品,以及 Graft – Claude Code hooks 这类面向特定技术场景的优化,都涉及"目标用户是否真实存在、需求是否足够普遍"的判断。文章的价值在于提醒开发者在投入资源前验证需求的真实性,避免为想象中的用户构建功能。
该文章在 HN 上积分不高(9 分),但评论数相对积分比例尚可,说明话题本身引发了一定讨论,只是传播范围有限。
On her blog, Lea Verou makes a case that each user-facing website dark-mode toggle should only ever show two options, but in a smart way.
The challenge is that any dark mode toggle needs to actually accommodate three options: dark, light, and the default “whatever the system says” (which can be always dark, always light, or change with the time of day). Many toggles simply pass that complexity onto the user:
= 2x) and (width >= 700px)" src="media/solving-a-largely-imaginary-user-goal/1.2096w.mp4" type="video/mp4"> = 3x) or (width >= 700px)" src="media/solving-a-largely-imaginary-user-goal/1.1600w.mp4" type="video/mp4">
I want to get something out of the way: I don’t think Verou’s article as an article is fully successful. I feel like it spends a great amount of words to explain something not entirely as complex, and even the interactive playgrounds felt slightly too rigid and altogether confusing. If you care about (interactive) explainers, it might be an interesting case study in and of itself.
But I am very much much on board with the proposal and the line of thinking it represents. Verou suggests a “smart” dual state toggle, which still allows the website to follow the system, but shoves the complexity of the “whatever the system says” branch into the crevices between visible UI. Here’s how I understand it:
The smart toggle only has two options: light and dark. Mechanically, clicking or tapping the toggle brings you to the opposite option. Simple.
If your new option is the opposite of system (e.g. you switch the page to dark mode if your system is in light mode), it will stay in that theme forever, no matter what the system does in the future.
If your new option is one that currently matches the system, it will then continue following the system in perpetuity (e.g. it’s back to the default behaviour).
= 2x) and (width >= 700px)" src="media/solving-a-largely-imaginary-user-goal/2.2096w.mp4" type="video/mp4"> = 3x) or (width >= 700px)" src="media/solving-a-largely-imaginary-user-goal/2.1600w.mp4" type="video/mp4">
This toggle will feel compromised, and you might immediately find some rare use case it doesn’t fully support – maybe attached to an imaginary user, or even an internal user giving you feedback in person. But Verou is absolutely correct in her insistence to fight through that:
Tri-state toggles are implementation-driven UI. One of the most common UX mistakes is designing UI around the underlying data model instead of user goals. Good interfaces abstract away the underlying model and expose a model that aligns with user goals (unless of course these happen to coincide, which is rare).
Now, it’s just a dark mode toggle. It might not seem like a difference between a smart dual state toggle and an explicit tri-state toggle is that much. But:
“Whatever the system says” is not just one extra option. It’s also one extra weird option. It doesn’t feel like the other two. It’s seemingly repetitive. It’s often unclear what it does before clicking. It’s not obvious where to put it in order. Verou doesn’t mention this in her post, but even just seeing the word System next to Light and Dark feels complicated. (Auto is slightly better.) The cognitive load here might be larger than it seems.
What is an interface if not a collection of a million challenges, each one seemingly insignificant on its own? Trivial things add up. One compromise here and one cheap decision there, and soon you’re talking real money.
Thinking deeply about something like this gives one practice for dealing with complexity elsewhere, and facing even more difficult challenges where the stakes are higher and the compromises larger.
A similar example might be that of PC keyboards in the late 1990s, which also exposed system complexity and pestered people with Power/Sleep/Wake keys:
= 2x) and (width >= 700px)" srcset="media/solving-a-largely-imaginary-user-goal/3.2096w.avif" type="image/avif"> = 3x) or (width >= 700px)" srcset="media/solving-a-largely-imaginary-user-goal/3.1600w.avif" type="image/avif">
图片
Computers do not do that anymore, simply having a smarter singular power button, piped to a more sophisticated logic underneath.