跳到主要内容

用户第一

“Get closer than ever to your customers. So close that you tell them what they need well before they realize it themselves.”

与你的客户建立比以往更紧密的联系——亲密到在他们自己意识到需求之前，你就已经知道了。

— Steve Jobs

1. 客户意识：最容易被开发者忽视的能力​

写代码靠的是逻辑，理解用户靠的是同理心。这两种能力都可以训练，但大多数开发者只练了前者。

客户意识不是说要做产品经理的工作，而是说：在做每一个技术决策时，你的脑子里有一个真实的用户在场——他在用你的产品，他有时间压力，他可能不懂技术，他遇到问题时会烦躁。

没有这个“虚拟用户”的人，容易写出这样的代码：

  • 错误提示写 “Error: 403 Forbidden”，用户完全不知道怎么办
  • 加载 3 秒没有任何反馈，用户以为卡死了
  • 表单提交失败，页面直接清空，用户重填一遍
  • 功能入口藏在三层菜单里，因为“开发方便”

这不是小问题，这是产品死亡的原因之一。

2. 了解你的用户：RentHub 的核心用户是谁​

在谈方法论之前，先想清楚我们在为谁服务。

RentHub 的核心用户群体有两类：

2.1 商户​

核心诉求：

  • 高效触达可信的租户，尽快完成撮合与履约
  • 减少同时管理多笔订单、多件上架物品的繁琐操作（合同、结算与到期提醒）
  • 出问题时有记录可以查

痛点与行为特征：

  • 时间有限，不希望在应用上花太多时间，希望一件事一步搞定
  • 对数字工具的熟悉程度参差不齐，部分年长用户不喜欢复杂界面
  • 对款项到账极其敏感，任何关于「钱」的操作都需要清晰的确认反馈
  • 不信任平台，担心数据安全和隐私

对开发者的启示：

  • 操作路径越短越好，能一步做的不要两步
  • 涉及财务的操作必须有明确的成功/失败提示
  • 不要在 UI 上堆砌功能，每个页面只需完成一件事

2.2 租户​

核心诉求：

  • 找到合适的在租物品，信息真实可靠
  • 沟通顺畅，合同清晰
  • 付款方便，有记录

痛点与行为特征：

  • 浏览、比对上架信息时不对称，对图文真实性有疑虑
  • 付款时担心无凭证，希望有电子记录
  • 遇到售后、争议或履约问题时希望有反馈，不想反复打电话
  • 年轻群体期望体验接近主流 App，对卡顿和丑陋 UI 容忍度低

对开发者的启示：

  • 信息展示要真实、完整，减少「看起来好，实际不符」的落差
  • 每一笔交易都要有清晰的状态记录
  • 售后/争议等功能不只要能发出去，还要让用户知道「被看到了」

3. YC 的核心方法：与用户对话​

Paul Graham 在 YC 创立之初就确立了一条铁律：

“Talk to your users.”（和你的用户说话）

这句话看起来简单，做起来却有很多人跳过。为什么？

  • “我们已经知道用户要什么了”（假设自己是用户）
  • “先做出来，到时候再看反馈”（推迟验证）
  • “用户反馈很难收集”（借口）

YC 的 Michael Seibel 把这个方法变得更具体：每周至少和 5 个真实用户对话，不是问卷，是真实的对话。

3.1 怎么和用户对话​

不要问“你喜不喜欢这个功能？”

用户会告诉你他喜欢，因为他们不想伤害你的感情。

要问：

  • “上次你遇到 [具体场景] 的时候，你是怎么处理的？”（描述行为，不是意见）
  • “这个过程里，最让你头疼的是哪一步？”（找痛点）
  • “如果这个功能消失了，你会怎么办？”（判断依赖程度）
  • “你有没有给朋友推荐过我们的产品？为什么推荐/为什么没推荐？”（净推荐值的思维方式）

Rob Fitzpatrick 的 The Mom Test 核心原则：

问出“妈妈也无法说谎”的问题——聚焦用户的过去行为，而不是未来意愿。

“你会用这个功能吗？”= 糟糕的问题（人们总说会）

“上个月你在这件事上花了多少时间/钱？”= 好问题（行为数据不会说谎）

4. 同理心地图：进入用户的世界​

在设计一个功能前，试着填写这张地图（针对你的目标用户）：

┌─────────────────────────────────────────────────────┐
│                  用户：[具体角色]                    │
│                  场景：[具体场景]                    │
├──────────────────┬──────────────────────────────────┤
│   他们在想什么？  │        他们在感受什么？            │
│  （内心担忧、     │       （情绪：焦虑/兴奋/           │
│   隐藏的期望）    │        挫败/满意）                │
├──────────────────┼──────────────────────────────────┤
│   他们在做什么？  │        他们在说什么？             │
│  （实际操作行为） │       （对他人描述的方式）         │
├──────────────────┼──────────────────────────────────┤
│       痛点       │            收益                   │
│  （什么让他们     │       （他们希望得到什么？）       │
│   沮丧/受阻）     │                                  │
└──────────────────┴──────────────────────────────────┘

RentHub 示例（租户—付款场景）：

维度内容
在想什么“这笔款商户收到了吗？平台记账一致吗？”
在感受什么焦虑——怕被认为没付款，影响后续履约
在做什么截图转账记录、发微信确认
在说什么“我已经付了，你那边收到了吗？”
痛点平台没有实时通知，不知道对方有没有确认
收益期望付完立刻有凭证，双方都能看到记录

这张地图直接告诉我们：付款功能不只是一个支付流程，还需要一个双向确认的通知机制。

5. 客户意识的日常训练​

你不需要每天做用户研究，但可以养成以下习惯：

5.1 习惯一：每周用一次自己的产品​

以真实用户的身份打开 RentHub，完成一个完整的操作流程。不要带“我知道这里有 bug”的滤镜，假装你是第一次用。

记录：

  • 哪里不顺？
  • 哪里让你等得不耐烦？
  • 有没有地方你不确定该怎么操作？

5.2 习惯二：看错误日志时想用户​

云函数报错时，通常我们只关心“代码哪里出问题了”。

试着多一个视角：这个报错对应的用户正在经历什么？

他是在付款环节失败了还是在提交表单时卡住了？这个错误发生的时间点是深夜（紧急？）还是上午（可以等待修复）？

5.3 习惯三：在代码里为用户写注释​

当你写一段处理异常的逻辑时，不只是写技术说明，加一行用户视角的注释：

// 技术原因：云函数冷启动超时
// 用户侧：租户在付款时会看到"网络超时"提示，引导他们重试
if (error.code === 'FUNCTION_TIMEOUT') {
  return { success: false, message: '网络超时，请稍后重试' };
}

6. Amazon 的“逆向工作法”​

Amazon 内部有一个著名的产品开发实践：从新闻稿开始（Working Backwards）。

在写任何代码之前，先写一份虚构的新闻稿，假设这个功能已经上线，向用户宣布它：

标题：RentHub 推出「合约续约提醒」，帮商户减少设备空档

正文：
从今天起，RentHub 的商户无需手动盯每一条合约到期时间。
系统会在到期前 3 天自动发送提醒，租户可以直接在小程序内
确认续约意向，整个流程不超过 3 步。

首批测试用户张先生（同时在租出 5 件设备）表示：
"以前快到期要一个个微信对账，现在平台把提醒和意向收齐，省了一大堆时间。"

写这份新闻稿的过程，会迫使你回答：

  • 这个功能对谁有价值？
  • 价值是什么，能用一句话说清楚吗？
  • 用户使用后会有什么感受？

如果你写不出一份有说服力的新闻稿，说明这个功能的价值还没想清楚，不要动手开发。

7. 一个简单的原则​

任何时候你拿不定主意，问自己这一个问题：

“这对租户或商户有直接好处吗？好处是什么？”

如果回答是肯定的，做。如果回答是“也许吧”，先停下来，搞清楚。