在生活和产品设计中，让你挠头而不挠头。 、空、0？

众所周知，空和无不是同一个概念，在生活中随意使用是没有问题的。然而，在产品设计中，这种不严谨的操作有时会带来很大的误解。

如果明天周末，你要开车带家人去旅游，希望提前加满汽油。当你开车去一个看起来像加油站的地方，你希望充满汽油。 95# 汽油：

1、假如这里没有加油站，也没有汽油销售，那就是-“无”

" hi，伙计！我们这边不卖汽油。他不能说他所有的汽油都卖完了(空)或者 95# 油为 0 (也许你要找的这个加油站其实是个新能源充电站，或者是个新能源充电站， cng 加气站）

2、假如这是加油站，但是今天 95# 所有的油都卖完了，那就是现在， 95# 汽油为 0 了

" hi，伙计！没有 95# 汽油了"。

但是你一定还想弄清楚，到底是这里根本没有什么。 95# 汽油销售清单：95# 油品 - 空） 还是卖完了(95)#- 有销售，目前已售完，库存为 0）。

这个问题有点抽象，但在我们的生活中很常见。相信你一定经历过被这些意思忽悠或者用这些意思忽悠别人的事情。

� � 儿童拥有比成人更清晰的世界。

2024 春节期间，我在重庆鸿恩寺玩耍，在去鸿恩阁的路上，偶尔闻到一个小姑娘对妈妈说:回家给你捶背，收费。 0 元。妈妈问：0 多少钱啊，小姑娘说， 0 人民币就是不要钱。

你看，其实孩子对世界的理解还是很清楚的。如果他们不收钱，他们会明确地给出价格。 0 元，而不是不告诉你(也就是给你“空”)让你自己猜。虽然他们可以在语言世界里说“不收钱”，但他们对世界的理解是明确的，有交易，但金额是 0 元。

� � 成年人挠头，可怕的自以为是。

随后 2024 2008年春节返修后，投入到一个正在进行的项目中，继续与三方对接，中间出现了一个特别尴尬的问题。API 在对接清单中，我们需要指定一些属性值参与，并调用三方系统来创建订单。如果有些属性值没有或者不满意(比如某个。 sku 规格值)，对方系统会感觉自己没有某种属性值信息，直接阻断报告错误，all wrong，订单创建失败。

但是，上述情况的前提是，对方有其他表示，允许调用方指定特征。 / 属性值，并且允许缺货下单，那么我们对现实世界的理解是，既然你允许我要，也允许你不要，那么你就没有时间报错，阻止锤子！

至少可以提交订单，但是没有的产品创建订单不包括在内，并且可以返回到缺货的产品。 list。然而，对方对缺货订单的理解是，商品档案库中的一些商品必须允许缺货订单。如果包括没有的商品，整个订单会直接出错。看看这些理解，真是太棒了。

(如何识别这个问题？面对对方文档信息的不完善，对接沟通时也没有识别这种情况，几次失败后，团队成员拿着开发捞起的错误消息才意识到问题，对方突然意识到自己得到了这个信息。)

� � ♂️事实上，这里已经出现了严重的概念偏差：

其实对方定义的允许缺货下单并不是“没有”，换句话说，不可能没有这种商品。在允许缺货下单的前提下，一定要有这个商品档案，其实对应的是“有”。➕“非空”的需求，然后与他们当前的商品可用库存值进行比较。

对于接收者来说，理解断货下单应该是“无”的。换句话说，在申请超出经营范围的商品时，不能影响其他商品的正常订单和业务数据流通，因为商品没有经营。对方的处理偏向程序思维，但脱离了业务实际。但是聪明的你说，商品和技术不能为商业服务吗？

� � ♀️千里之行，始于足下：

另一方面，在当时我们团队的商品实践中，我们自己的业务经常会遇到空虚、无、0 定义问题。就团队连锁店店员的操作而言，有时我们不能提交空数据，以便让店员清楚地了解自己的系统输入动作。如果不能执行，请输入。 0 这意味着你“注意到了，无法执行”。0 表示你的清晰表达，但“空”是未知的。

� �️因此你说，0 和空，究竟有区别吗？

空气当然代表着不确定性，是否有故障，所以没有回应？

从顾客的情绪出发，此时是恐慌，是不确定的。

0，这是一个确定的结果导出，我做了一个动作，你给了我一个反应，这是一个闭环信息流。

在生活中想一想，也是如此，我们问别人一件事，他不能因为不知道，所以不吱声吧，那到底知道还是不知道？

靠 猜测！不要，每个人都累了。

本文由 @Kris_3zzz 每个人都是原创产品经理。未经作者许可，禁止转载。

题图来自 Unsplash，基于 CC0 协议

这篇文章的观点只代表作者本人，每个人都是产品经理平台，只提供信息存储空间服务

本文仅代表作者观点，版权归原创者所有，如需转载请在文中注明来源及作者名字。

免责声明：本文系转载编辑文章，仅作分享之用。如分享内容、图片侵犯到您的版权或非授权发布，请及时与我们联系进行审核处理或删除，您可以发送材料至邮箱：service@tojoy.com