找到目标用户：人群、场景与具体问题

“帮助独立开发者写英文”范围太宽，无法告诉你今天去找谁。这一篇把ClearCopy的第一批使用者缩到一个可联系的人群：正在准备英文App介绍、手里已有功能事实和英文草稿、希望尽快提交的人。最后你会有一份筛选说明、一段不会诱导答案的访谈开场，以及一张从原稿到提交的任务图。

先看填好的任务句：

我正在提交离线行李清单App，希望把一段生硬的英文变成可直接使用的介绍，保留行程、勾选、复用、离线四项事实，不需要生成不存在的云同步卖点。

它具体到输入、时刻和结果。相比“25至35岁、爱技术、喜欢效率”的画像，这句话更能帮你决定该问什么、该做哪个页面。

从真实工作步骤里找到接触点

打开fastlane的deliver文档，定位Usage部分。官方说明可以把App的metadata存到本地目录，并展示文件夹与预览的工作方式。这是一个可以实际查看的发布流程，不是本书编造的用户访谈。它说明英文介绍往往处在“准备元数据、修改、上传”这段工作里，而非无时间限制的自由写作。

先不运行上传命令，也不用连接任何App Store账号。只观察这个工作流，把ClearCopy插在上传之前：开发者提供自己有权分享的介绍，处理完成后把结果放回原来的文档或元数据文件。这样你不必第一版就索要App Store权限，也不用承诺代用户提交审核。

接触点随之变得具体。你可以从自己认识、且最近在准备英文发布资料的人开始；也可以在允许研究邀请的开发者社区说明任务。不要向整片社区群发“有人对AI工具感兴趣吗”，也不要私自收集成员联系方式。你要找的是正在做这项工作的人。

把下面的问题发给愿意参与的人，或在约访时询问：

筛选结果可以填成下面这样的研究计划。它是本书的招募条件，不是已经找到的三位受访者。

GOV.UK研究计划指南把“我们认为用户需要什么”转为研究问题。对ClearCopy，研究问题应是“他如何确认改写没增加功能”，而不是在招募前就写成结论“所有开发者都需要事实校验”。

准备30分钟，不必从一小时大访谈开始。开始前说明你在研究英文介绍流程，允许对方跳过问题；是否录音单独征得同意，不录音也可以用匿名笔记。不要让对方分享后台密码、未发布商业信息或他无权提供的材料。

你可以照着下面的开场说：

今天先不看我的工具。我想了解你最近一次修改英文介绍的过程。你可以打开愿意分享的草稿，也可以口头讲。请从发现需要修改的那一刻开始，当时你先做了什么？

顺着他的过程追问：“这句话原来怎么写？”“后来改成什么？”“谁决定采用？”“如果不改，会影响哪一步？”不要急着问愿不愿意付钱。先找到他已经为任务付出的动作，例如自己反复改、请朋友读、借助通用写作工具。对方说某个步骤很麻烦时，再请他展示具体例子。

GOV.UK深度访谈指南强调了解使用者的情况和实际工作。在这里，最有用的内容不是“用户喜欢简单工具”，而是你能复述出他的一次原稿、采用版和判断过程。若对方只谈未来设想，把问题拉回“上次真的发生时怎样处理”。没有发生过就记为尚未观察，不替他编一段经历。

下面这张是依据本书固定输入制作的假设流程，用来准备观察；真实访谈后应改成对方实际经历。

阶段	手里的材料	此时要完成什么	ClearCopy可能帮助的位置
准备	中文功能事实	说清App已经能做什么	提醒补齐必要事实
起草	生硬英文段落	表达完整而且能读懂	改写并解释用词
核对	改写结果	发现是否夸大或遗漏	对照功能逐项解释
采用	最终英文介绍	放回发布材料	清楚复制，不改原提交渠道

配图来自GOV.UK体验地图指南。图中不同阶段和行动沿时间排列，可以帮助你看出问题发生在哪里；本篇把方法缩成上面的四阶段草图。官方建议建立完整体验地图前收集多位用户的经历，所以这张教学假设图不能被称为“已经研究出的用户旅程”。

观察后如果发现对方最费时的是挑选截图，英文介绍一次就能写好，ClearCopy并没有抓住他当前最急的任务。反过来，如果他停在核对环节，就把下一次试用集中到“改写与功能事实同时展示”，不必为了完善画像追加年龄、收入等不影响设计的信息。

现在你有了可筛选的人群、能使用的开场和已填任务图。约访时只说明这一次要观察的工作；会后把图中的假设换成真实步骤，并写一句“下次改哪一处”。人群不是先在文档里画得越细越好，而是经过这一次接触，终于知道下一版要服务谁的哪项工作。