跳到正文
docai.cc

DOCAI · 课程 · L1 · 24 分钟 · 日常工作和生活应用

Claude 助力设计师:创意辅助与文案撰写实战指南

设计稿归 Figma,文字工作归模型:用研提纲、访谈整理、设计说明、界面文案、评审行动清单,都能按固定结构快速起草。

Claude 入门 · 创意与研究

你将学会

  • 能把一份访谈记录提炼成需求、痛点与金句
  • 能写出开发不用追问的设计说明文档
  • 能把评审反馈整理成带优先级和负责人的清单

画图之外,时间都去哪了

设计工作里真正画界面只是一部分,其余时间花在需求梳理、访谈记录、写说明、改文案、准备汇报上。这些恰好是模型擅长的文字活。它不碰像素,也不替你判断美丑,但能把这些环节从几小时压到几十分钟。

把它放在「设计助理」的位置:你决定方向和取舍,它负责把想法整理成别人读得懂的文字。想让它稳定输出,提示词里至少写清四件事:给谁看、要解决什么、输出什么格式、哪些内容不能编。

用研:提纲、记录、竞品评论

访谈提纲最怕问题太空。让它按研究目标生成十个左右开放问题,并补上方法建议、招募标准和样本量理由:

我们要验证新版结算页是否易用。目标用户是每月下单三次以上的小商家。请设计 12 个开放问题,覆盖下单流程、出错场景、替代方案;再推荐两种合适的研究方法,说明招募标准与建议样本量,并解释理由。问题不要问「你喜欢吗」,要问「上一次你怎么做的」。

访谈结束后,把转写交给它做结构化提炼:需求按提及次数排序、痛点按严重程度分级、挑出可直接引用的原话、标出预料之外的反馈,最后给三条设计建议。竞品应用商店的差评也能同样处理,先看抱怨分类,再看有没有我们自己也可能踩的坑。

一次完整的用研整理:从录音到三条设计动作

假设刚做完五场访谈,转写一共两万字。整段丢进去让它「总结一下」,得到的多半是一段正确的废话。拆成三步,每步只问一件事,中间还能纠错。

第一步,只提事实,不做判断:

下面是一份访谈转写。请只提取三类信息,逐条列出并标注原话位置:
1. 用户描述的具体行为(做了什么、多久一次)
2. 用户遇到的阻碍(在哪一步卡住、卡了多久)
3. 用户自己说出的期望(引用原话,不要改写)
不要给建议,不要归纳原因。
[粘贴转写]

第二步,按频次和严重程度两轴排队:

基于上一步的结果做一张表:问题 / 提到的人数 / 出现场景 / 用户现在的绕行办法 / 严重程度(高/中/低)。
严重程度按是否导致放弃任务判断:导致放弃记高,多花时间记中,只是抱怨记低。
只有一人提到的问题单独放一栏,标注「待验证」。

第三步,才让它给设计动作,并限制数量:

基于上面的表格给出三条设计动作。每条写清:解决哪个问题、改哪个界面、怎么验证有效。
只针对高严重度且两人以上提到的问题;证据不足的写「需要补充研究」,不要硬给方案。

三步分开的价值在于每一步都可检查:第一步如果出现了你没听到的内容,说明转写或摘要有问题;第二步排序不对,你在给第三步之前就能改表。一次问完,中间错了只能整段重来。

发散可以借力,定稿不行

让模型陪你做创意发散很划算。给它产品定位、目标用户和三个品牌关键词,要求十条方向互不重复,再挑三条说明理由和落地方式。它擅长把常见套路铺开,正好帮你确认哪些方案已经被想烂了。

设计原则则是另一回事。模型给的清单通常是行业通行说法,可以拿来当对照,但每一条都要追问:我们产品真的会为了这条原则放弃什么?答不上来的,说明还没想清楚,先别写进文档。

下面这些活,也不该整包交出去:

  • 像素与布局判断:间距、层级、品牌一致性要在设计工具里看真实渲染,文字描述会丢信息。
  • 用户隐私:转写里有姓名、联系方式、公司名,先匿名化再贴;原始录音不要上传。
  • 无障碍与合规的最终结论:它能列检查项,但「是否达标」要按规范实测,必要时请专业人员确认。
  • 对外发布的定稿文案:品牌语气、法律措辞、宣传合规,模型只适合给草稿,签发前必须有人过目。

提示词写得越具体,产出越稳;把它当决策者,出错时你连责任人都找不到。想系统补提示词写法,可以看提示词写作基础。

设计说明:让开发不用追问

开发最怕拿到一张图,不知道点了之后发生什么。设计说明按五块写:三句话概述、交互逻辑与触发条件、边界状态、动效说明、技术注意点。

状态 触发条件 界面表现
空状态 用户还没有任何项目 插画 + 一句引导 + 主按钮
加载中 数据请求未返回 骨架屏,超过 3 秒显示文字提示
出错 接口失败或断网 说明原因 + 重试按钮
无权限 角色不具备操作资格 说明所需角色 + 申请入口

把上面的方案写成给前端工程师的说明。每个状态列触发条件、展示元素、可点击项;文案用中文并给出精确措辞;不确定的交互标注「待确认」,不要自行补充业务规则。

最后一句能防止它替产品做决定。

界面文案:十字以内,说人话

界面文案的目标是让用户知道发生了什么、下一步点哪里。让它一次写一组,附上场景约束:

写五处界面文案:空状态、删除确认、发布成功、网络错误、新手引导。按钮类文案不超过 10 个字,说明类文案不超过 20 个字,语气像同事提醒,不用「操作失败,请稍后重试」这种机器腔。

对照一下差别:删除确认写「删除后无法恢复,确定删除这个项目?」比「您确定要执行删除操作吗?」清楚得多。产品更新弹窗则先写价值再写功能,标题五到八字,正文控制在一两句。

评审反馈:分类、定级、落到人

评审会开完,记录往往是一团散沙。让它做三件事:把反馈归到体验、功能、策略三类;标出三档——非改不可、可以优化、留待讨论;对有争议的点给出可选方向。最后生成行动清单。

下面是评审记录。请分类并标优先级,争议项列出两三种解决方向及代价。最后输出表格:问题 / 类型 / 优先级 / 负责人 / 截止时间。负责人和日期留空由我填,不要替我指派。

给管理层的方案汇报也用得上:先讲现状问题并给数据,再讲设计原则而不是细节,然后说业务价值、所需资源、风险应对。语气自信,别写成自我欣赏。

自测

  1. 访谈提纲为什么避免问「你喜欢这个功能吗」?
  2. 设计说明里边界状态要写到什么程度?
  3. 评审行动清单缺了哪一列就没法跟踪?

想继续把文字能力用在增长侧,下一节是 SEO 内容创作:用 Claude 做 SEO 内容。

自测

先自己回答,再展开对照;答不上来就回到对应小节。
  1. 01为什么访谈记录整理时要区分「有痛点」和「很痛」?看答案

    两类需求的设计优先级不同,只有高频且影响大的痛点才值得优先投入方案。

  2. 02设计说明里为什么要单独写空状态、错误状态和加载状态?看答案

    开发实现时最容易遗漏这些边界情况,提前写明可减少返工和上线后的缺陷。

  3. 03评审反馈整理成行动清单时,至少要包含哪三列?看答案

    问题、负责人、完成时间,缺一项清单就无法执行和跟踪。

查看 Markdown

涉及的概念

在知识树上