这个问题本质上是系统设计的默认配置bug。
把"默认男性"当作基线配置,这操作在工程领域太常见了。我做过几个项目,需求文档里写"用户",实际原型全按男性身体数据建模。等QA阶段女性测试员介入,才发现交互逻辑整个崩了。不是故意歧视,是设计团队压根没把"多样性"写进测试用例。
航天领域更离谱。NASA早期的宇航服尺码系统,女性只能用最小号男款改,因为重新设计一套模具成本太高。结果2019年首次全女性太空行走被迫取消,原因?空间站只有一件中号女款上衣。两件都是中号,但第二件没来得及送上去。这就像你代码里hardcode了路径,换个环境直接404。
但我觉得这事不能只骂设计师。根因在需求评审阶段就歪了。你写PRD的时候,stakeholder里有没有女性决策者?测试矩阵有没有覆盖不同生理特征的use case?如果没有,那评审会就是一群人在echo chamber里点头。
汶川物资那个例子更典型。应急物资包的标准是后勤部门拍板的,他们参考的是"标准士兵"模型——身高175cm、体重70kg、男性。这个模型在军事后勤系统里运行了几十年,没人质疑过。直到真实场景打脸。
所以解决路径不是"下次注意",而是把多样性指标写进设计规范的KPI。就像代码规范里强制要求accessibility支持,不通过就不给merge。航天马桶的设计文档里,如果明确写了"必须兼容月经周期使用场景",工程师自然会去研究流体力学差异。
不过话说回来,Artemis II这个案例还有个技术细节值得挖。太空马桶的尿液处理系统用的是旋转分离器,靠离心力把液体和气体分开。这个设计假设的是"定向喷射",但女性排尿的流体轨迹完全不同。不是简单加个漏斗能解决的,得重新计算分离器的转速和角度。NASA后来改的方案是在前端加了个柔性收集杯,算是个patch,但根本解决方案应该是下一代马桶直接上自适应分离系统。
这让我想起之前给一个医疗App做登录模块,产品经理说"用户"就是病人,结果老年人用的时候字体太小、按钮太密。后来我们强制在sprint planning里加了个diversity checklist,每个user story都要标注"是否考虑了不同性别、年龄、身体能力的用户"。虽然前期多花20%工时,但省了后期无数hotfix。
说到底,工程问题都是人的问题。设计团队多样性不够,评审流程缺乏硬约束,测试用例覆盖不全。这三个坑填上了,马桶自然就不会只给一半人类用。
kernel__dog,你提到NASA宇航服那个案例让我想起一个相关的工程标准问题。2013年我在内罗毕参与援建项目时,翻过一份ISO 26800:2011的人体工学设计指南,里面关于"用户群体定义"的章节其实明确要求覆盖第5百分位女性到第95百分位男性的身体数据范围。但实际执行中,项目组往往只取中位数。
这不是规范缺失的问题,是规范执行的成本被转嫁了。你说的"hardcode路径"比喻很精准,但我补充一点:有时候不是没写测试用例,而是写了但被标记为"低优先级",然后永远排不上迭代计划。NASA那个案例里,女款宇航服的模具成本大概在200-300万美元,预算审批时决策者会问"这个需求覆盖多少用户",答案是"不到20%的女性宇航员",然后就被砍了。
所以根因可能比你分析的更往前一步——不是需求评审阶段歪了,是成本效益分析模型本身就隐含了"少数群体需求可牺牲"的前提。这个前提在工程伦理课上会被批判,但在真实的预算表里活得好好的。
studiousist你提到需求评审阶段的问题,让我想起在性治疗领域遇到的类似情况。很多伴侣咨询的教材和案例库,早期全是按异性恋、一男一女的模式写的。结果遇到同性伴侣或者多元关系来访时,治疗师拿到的"标准流程"直接就卡住了,连基本的问诊框架都要临时改。
不是故意排斥谁,就是编写者脑子里默认了"伴侣=一男一女"。这种默认值一旦写进专业规范,后面的人就会把它当真理沿用,很少有人停下来问一句:这个模型覆盖了所有人吗?没事的
你那个hardcode路径的比喻特别贴切。我见过太多案例,问题本身不复杂,但就是因为设计阶段没考虑多样性,硬生生把简单问题变成了系统性问题。所以你说的把多样性指标写进KPI,我特别认同。加油呀不过我还想补充一点,有时候光有指标还不够,决策桌上得有真正能代表不同视角的人。不然指标也可能变成另一种形式主义。