大多数改名建议止步于选新名字。那是容易的一半。难的一半，是迁移成千上万个已经认识你产品的人——他们把它加进了书签，跟同事提起过它，还把你的旧名字写进了自己的文档。这件事做砸了，你就不只是花了钱——你还在教你的用户：你的名字是不可靠的信息，而这对你最希望记住你的那群人来说，是件很奇怪的教育。
所以在你生成一个候选之前，先回答那个真正主宰整个项目的问题：这次改名，值不值得它将带来的混乱？有时它明摆着值。但更多时候，它是一个虚荣项目，悄悄烧掉你花了多年建立起来的认知度。
什么时候改名是站得住脚的
只有当现有名字在主动造成伤害时，一次改名才对得起它带来的扰动，而不是仅仅因为团队里有人腻了它。有四种情形能过这道杠。
商标冲突或法律要求是最清楚的情形——你没有投票权，拖延只会抬高代价。其次是一次真正的品类转型：如果你当初以“InvoiceNest”上线，而如今业务已是一个完整的会计平台，那名字就成了天花板，每一个读到它的潜在客户都会低估你做的事。合并或收购会在两个名字无法同时活在一款产品上时逼出这个问题。最后，一个主动误导的名字——暗示一个你已移除的功能、一个你已离开的市场，或一个你从未有过的规模——值得替换，因为它每周都在客服工单和预期错配上让你付出代价。
注意哪些不在那份清单上。“创始人从来没喜欢过它”、“竞争对手有个更酷的名字”、“我们把网站重做了，名字显得旧了”——这些都是虚荣式改名。它们拿真实的、已经存进账的认知度去换一种感觉。如果人们已经会把你的名字敲进搜索框并找到你，那这个习惯就是资产负债表上的一项资产。只有当名字作为负债，大过这个习惯作为资产时，才越过它去改名。
选一个从设计上就减少混乱的继任名字
这里有一个大多数团队都错过的杠杆：新名字本身就能替你完成很多过渡的活儿。一个和旧名字共享某个声音、某个形状或某个首字母的继任名字，能让用户把已有的记忆往前带，而不是从零开始。
假设你在给一个消息工具换掉“Postmark”。“Parcel”保住了那个 P 和两个音节的节奏，于是一个只记得半个旧名字的人，仍然会落在离新名字不远处。“Zephyra”抽象来看是个好名字，但作为继任名字，它和之前的一切毫无共享——每一丝认知度都归零，你要为知名度重新付全价。保住首字母还能护住那些你会忘掉的小东西：favicon 上的字形、应用图标上的字母花押，以及人们凭记忆去够的那个 @ 账号。
这不是一条要硬套的规矩——一次品类转型有时恰恰需要一次干净的决裂，正因为你想甩掉旧的联想。但当你的目标是连续性时，就把语音或视觉上的重叠当作一个要去挑选的特性，而不是一个巧合。如果你在权衡候选，与其信任房间里的热情，不如让它们过一遍对好记程度和拼写风险的中肯点评；而这恰恰是一个好的产品起名工具被造出来要施加的那种压力检验。
在一座“桥”上进行过渡
改名中最有用的一个机制，就是这座桥：“新名字（原名旧名字）”。它出现在名字出现的每一个地方——网站页眉、应用商店的列表、登录界面、发票页脚、邮件发件人名称。它唯一的任务，就是接住那个在找旧名字的人，让他放心自己没走错地方。
把这座桥留得比你觉得有必要的更久些。一个粗略的参照：头三个月把“原名旧名字”显眼地留着，第六到十二个月用更低调的形式保留它（页脚、帮助中心、商店副标题），只有当你自己的分析显示对旧名字的搜索和客服提及已经安静下来时，才把它撤掉。撤掉这座桥是改名的最后一步，而不是第一步——那些因为新名字“内部感觉已经定了”就早早把它扯掉的团队，忘了“内部”恰恰是那个从来不需要它的受众。
护住管道：跳转、搜索与记录
用户或搜索引擎过去能到达的一切，现在都必须仍然解析得通。用永久（301）跳转把旧域名指向新域名，把每一条旧路径映射到它对应的那条具体新路径，而不是把所有人一股脑丢到首页——路径对路径的跳转，会把你已经挣来的搜索权重传递过去，并把人们送到他们本想去的地方。
在那些你掌控、却很少想到的地方，更新产品名字的权威记录：应用商店的标题和副标题、OAuth 授权界面、客户信用卡账单上的计费描述符（不匹配的描述符会触发拒付）、交易类邮件的发件人名称，以及 API 文档。然后处理那些你无法完全掌控的欠债——那些仍在用旧名字的教程、论坛回答和第三方评测。你不会把它们全都修好，而这恰恰是桥和跳转要紧的原因：它们覆盖了那条你没法亲自逐一重写的长尾。
清清楚楚地宣布一次，并选好时机
在用户偶然发现这个变化之前就告诉他们。一条简短的应用内横幅，或下次登录时一个一次性的弹窗——“我们现在叫新名字了。产品不变，登录不变，数据不变”——会消灭最常见的那条改名工单，那条工单不是“你们为什么改名”，而是“我是不是被钓鱼了／你们是被收购了吗／我的账户还安全吗”。先回答安全问题；名字背后的故事是个脚注，大多数用户并不需要。
在时机上，把改名和你其他有风险的事件解耦。别在同一周里发一个大版本、一次价格调整和一次改名——如果出了岔子，你会不知道该怪哪个变化，而用户会怪那个最显眼的，也就是新名字。挑一段安静的时段，避开一次大发布前后那几天，并在任何东西上线之前，给客服一套备好的说辞和一个提前的通气。
那个引以为戒的模式
有一个老套的失败模式，值得点出来、却不必点名道姓：在短时间里反复改名的那种产品。一家在三年里改了两次名字的数据库公司，每次不只是花了钱——它还教会了自己的用户不要再去学它的名字，因为那名字一次次被证明是临时的。认知度只有在你让它安坐时才会复利增长。每一次改名都会把那只钟拨回去，所以目标不是“把名字改得好、改得勤”；而是“很少改名，并让每一次都黏得住”。
把一次改名当作一场迁移，而不是一次发布。对着你正在花掉的认知度为它辩护，选一个把旧记忆往前带的继任名字，在一座看得见的桥上进行，护住跳转和记录，并在一开始就把安全问题答好，然后清清楚楚地宣布一次。做到这些，大多数用户就会在脑子里更新那个标签，然后继续过日子——而对一次改名来说，这就是能有的最好结果了。