如何设计人们真正会使用的送礼功能：来自58款应用程序的实证数据

研究中的四个应用程序早在几年前就已经确定了其中六列的内容，然后不自觉地在自己的用户界面中展示了这些信息。

PostgreSQL会按照以下结构生成数据库表，其中每个非显而易见的列名都会标注出对应的应用程序名称，因此读者可以通过这些列名来对照上面的截图。如果跳过SQL代码，读者只会错过这些列名而已；但实际上这十七列包含了所有必要的信息。

CREATE TABLE gifts (
  id            uuid PRIMARY KEY,
  status        text NOT NULL,   -- 上述九种状态之一

  -- 发送者和接收者的身份信息。Uber Eats要求发送者输入自己的名字，
  -- 而不是从账户信息中自动推断出来。
  sender_id     uuid NOT NULL REFERENCES users(id),
  sender_name   text NOT NULL,
  hide_sender   boolean NOT NULL DEFAULT false,   -- Telegram提供了这个选项

  -- 在领取之前，这些字段可以是空值。Thrive Market、Blank Street和Uber Eats
  -- 接受仅包含电子邮件或电话号码的信息，之后再创建相应的接收者账户。
  recipient_id    uuid REFERENCES users(id),
  recipient_email text,
  recipient_phone text,

  -- 同意意愿的相关信息。DoorDash会在发送信息之前确认接收者的同意，
  -- 根据TCPA法规，同意的文字内容也会被作为证据保存。
  consent_copy_version text,
  consent_at           timestamptz,

  -- 配送相关的信息。Revolut会承诺在接收者所在时区的08:00进行配送，
  -- 而各国的时间规则可能会发生变化。
  deliver_on    date NOT NULL,
  deliver_tz    text NOT NULL,

  -- 有效期的规定因对象而异：Binance的红包有效期为45秒，
  -- 根据美国CARD法案，存储型礼物的最低有效期为五年。
  expires_at    timestamptz,
  claimed_at    timestamptz,
  refunded_at   timestamptz,

  amount_minor  bigint NOT NULL,
  currency      char(3) NOT NULL,

  CONSTRAINT recipient_reachable CHECK (
    recipient_id IS NOT NULL OR recipient_email IS NOT NULL
                             OR recipient_phone IS NOT NULL)
);

Thrive Market、Blank Street以及Uber Eats会在之后根据地址来创建相应的账户。礼物可能在它的接收者出现之前已经存在了好几天，而可为空的recipient_id字段正是用来记录这一时间差别的；同时，底部的检查机制可以确保某一行数据不会在所有方向上都被视为“无法到达”的状态。

Revolut承诺会在早上八点发送礼物，而deliver_on与deliver_tz这两个参数则确保了礼物会按照接收者所在时区的时间来送达。如果使用固定的时间戳，就可能会完全错过八点的送达时间。不过，调度系统只需一次查询就能确定哪些礼物应该被发送。

-- 现在应该发送的礼物，按接收者而不是按服务器来处理。
SELECT id FROM gifts
 WHERE status = 'scheduled'
   AND (deliver_on + time '08:00') AT TIME ZONE deliver_tz <= now();

每隔几分钟就会运行一次这个查询的程序：悉尼的礼物会在悉尼当地的早上被发送出去，而伦敦的礼物则会在九小时后被发送；这样，每一条记录都会被正确地处理。即使政府在礼物购买时间和接收者生日之间调整了时间规则，同一条记录的处理结果也不会受到影响，数据库中的数据也不会被修改。

完成领取操作的整个流程只需要一条SQL语句，而WHERE子句的作用就替代了原本可能需要使用的锁定机制。

UPDATE gifts
   SET status = 'claimed', claimed_at = now(), recipient_id = $2
 WHERE id = $1
   AND status = 'delivered'
   AND (expires_at IS NULL OR expires_at > now());

第二次点击会执行同样的SQL语句，但会发现该记录已经被标记为“已领取”，因此系统会显示没有记录被修改；过期的礼物也会导致同样的结果。要区分这两种情况，只需要再查看一次status和claimed_at字段的值即可。

领取界面只能显示查询结果所反映的信息。如果接收者在礼物发送一个月后才点击链接，系统会向他们说明礼物已于3月12日被领取，或者礼物已经过期，钱款已退还给发送者；而对于那些从未保存过claimed_at字段的礼物，系统则会显示“出现了一些问题”，并引导用户联系客服。这些提示文本是由设计师编写的，而数据库的结构则限制了这些提示信息能够有多真实。

如何为产品选择合适的处理方案

尽管存在九种不同的处理方案，但实际上一个产品很少需要使用其中多种。下图展示了构建每种方案所需消耗的屏幕资源数量。

在所测量的六种赠送流程中，‘货币包装’功能所需的屏幕操作次数最多，中位数达到了12次；而GoPay平台在提供主题信封、名人语音留言、推荐祝福语以及未开启礼物的追踪功能时，同样需要16次屏幕操作。Telegram的整个赠送流程只需4次屏幕操作，Duolingo也需要3次，因为这两种平台的操作都是从接收者已经出现在屏幕上这一状态开始的，而且所需金额也只需要轻轻一点即可输入。

对于那些需要结账功能的产品来说，应该首先开发‘结账附加销售’环节。有12款应用实现了这一功能。具体实现方式包括一个切换按钮、一个消息输入框以及订单页面上的一列信息，这些设计都是针对那些已经准备好赠送礼物的发送者而言的。

与特定文化节日或场景相关的赠送功能，通常由19款应用提供。这一功能比其他任何场景都更受应用开发者重视，因为预先写好的祝福语在转化用户购买决策方面起到了关键作用。因此，开发这类功能的成本更多被用于编写信息内容，而非工程开发上。

对于订阅制产品来说，应该首先设计‘订阅推广’环节，并且要为此付出一定的成本来激励发送者参与。Thrive Market会为新会员提供30美元的商店积分作为奖励，而且从不投放任何广告。

用户之间的实时互动为社交赠送功能提供了可能性。Telegram和Twitch都推出了相关的活动。要实现这一功能，需要设计一种货币系统、设置充值流程以及制定管理规则，之后才能让设计师开始制作礼物图案。

当人们有共同的目标或正在坚持做某件事时，‘分享进度’功能的赠送环节就显得非常合适。在58款应用中，有2款应用实现了这一功能，平均需要5次屏幕操作。对于任何已经拥有好友列表的应用来说，这个需求都是可以满足的。当应用程序知道有人落后于进度时，一份实用的礼物往往比单纯的通知更能起到激励作用。

对于其他所有的赠送场景来说，礼品卡仍然是一种非常有效的工具，前提是设计师能够为它设计出合适的呈现方式。‘存储价值’功能的实现所需屏幕操作次数从Urban Outfitters的3次到Shopee的17次不等，这一差异充分体现了设计师在流程设计中的重要作用——他们可以大幅改变整个操作流程的长度。