参数传成形容词,中间隔了三道手
一个桌面小风扇的卖点,在公司内部传了三道手,最后变成了一个用户会回来投诉的说法。追这件事的时候我们才发现,每一棒都在做加法,没有一棒负责确认前一句还站不站得住。
·
一个桌面小风扇的卖点,在公司内部传了三道手,最后变成了一个用户会回来投诉的说法。追这件事的时候我们才发现,每一棒都在做加法,没有一棒负责确认前一句还站不站得住。
第一棒:立项文档写的是参数
立项文档里写得很具体:单次充电续航六小时,机身净重一百八十克,风速三档,噪音低于某个值。
这些数字都能测。我做产品开发有个习惯,写进立项文档的卖点必须可验证,写不成可验证句的就换成参数。
参数写完就锁了。它在那份文档里的样子是六小时和一百八十克。
第二棒:设计转手抄成了形容词
设计转手的时候拿的是那份文档。他要的是页面上的说法,把"续航六小时"写成"超长续航",把"一百八十克"写成"轻若无物"。
这个改写本身不算错,页面上确实不能放一串数字。但"超长"是一个没有边界的词,"轻若无物"这个说法用户没办法拿来比较。
标准做法是给一个参照:续航等于三部电影的长度,重量比一瓶矿泉水还轻。这两句话用户自己能判断。这个改写在多数项目里都会发生,问题不在这里。
第三棒:图片脚本再加一层
图片脚本在设计稿的基础上又加了一层。加的是场景:"户外也能带""一整天不愁"。
这两句都不是从立项文档来的。它们来自同期另一个项目的手提小风扇,那个产品的卖点就是便携。我们做的是桌面款,不是一个能挂在包上的东西。
这一步开始出问题。加进来的句子不是被改错了,是被加进来了。
第四棒:成片和文案叠在一起
最后落到页面上的是四层:一层参数、层形容词、一层场景、一层是从别人那借来的。
四层叠上去之后,没有一层能被用户验证
上架两周,第一条差评写的是续航没有六小时。这条差评本身是误判,我们测过是够的。但差评那句话是从哪来的——是页面上那句"一整天不愁"。
用户把一整天理解成了不插电,而不是插一次电。
三道手各自加了什么
| 环节 | 做了加法的动作 | 加进来的是什么 |
|---|---|---|
| 立项到设计 | 参数改成可感的说法 | 从"六小时"到"超长续航" |
| 设计到脚本 | 补一层场景 | "户外也能带" |
| 脚本到成片 | 补一层情绪 | "一整天不愁" |
三棒都不是恶意。三棒的问题是每个人都在解决自己那一段的问题——设计要让页面好读,脚本要让画面有场景,成片要让人有感觉。没有一棒的任务是回头确认第一句还站不站得住。
我加了一个动作
现在卖点在立项之后不许再改写,只能在结构上做扩展:参数句必须保留,形容词只能跟在参数后面用,不能替代它。
立项文档里的每个参数,我会给它编号。往下传的每一版卖点表上都带着这个编号,编号对不上的句子直接删。
这个动作挡住的是那两句凭空加进来的话。"户外也能带"如果写成编号外的句子,在脚本评审那一步就会被打回。
三道交接里,真正需要人管的是接上,不是接口。把编号带过去这件事只花十分钟,但它要求收件的人真的看一眼。
现在我还会做一件更笨的事:上线前找两个没用过这款产品的人读一遍文案,问他们觉得这是不是一款需要插电的产品。答错的人占比超过三成,文案就得改。
登录后可点赞
← 返回产品开发板块