设计案例研究模板:如何写出真正能拿到项目的案例研究
一份真正能转化的设计案例研究实战模板。招聘经理会读的八个部分、你必须展示的数据,以及如何呈现过程而不让读者昏昏欲睡。
此刻,每位招聘经理的浏览器标签页里都开着一堆设计作品集。每一个只看三十秒。如果首屏够给力,也许六十秒。胜出的案例研究,是在这个时间窗口内回答了经理真正关心的问题的那一个,而不是样机最好看的那一个。
这就是这份实战模板。八个固定顺序的部分、真正重要的数据,以及真正有分量的过程图。如果你现在的作品集读起来像学校作业,这就是改写的范式。
招聘经理真正会读什么
招聘经理在扫描的是证据:你交付过某个东西,并且让某个数字动了起来。 其余都是背景。过程图、情绪板和“我的心路历程”段落都排在后面,而不是前面。失败的案例研究以心路历程开场,胜出的案例研究以成果开场。
凭直觉明白这一点的设计师,作品集能转化。不明白的设计师,作品集“收到了不错的反馈”,却没有面试。差别在结构,而不在艺术。
八个部分的模板
这八个部分按此顺序,涵盖了设计师需要写的所有案例研究。支柱型项目用完整版本,较小的项目用压缩版本。部分始终不变。
第一部分:一句话成果
先说结果,不要先铺垫。 一句话。设计交付了什么,改变了什么。
“为一家 B2B SaaS 重新设计结账流程,第一个季度转化率提升 32%。”这才是案例研究的开头。“我很兴奋能参与这个金融科技领域隐身模式初创公司的项目”,这样的案例研究五秒钟就会被关掉。
招聘经理会拿这句开头去和页面其余内容对照。如果后面能支撑它,他们就继续读。如果开头含糊(改变了体验、重新构想了旅程、创造了一种全新的思考方式),他们会认为数据缺失是因为数据不好看。把成果写得像商业报纸的标题一样直白。
第二部分:一段话讲清问题
问题部分是大多数作品集丢掉读者的地方。它读起来像一篇关于企业的文献综述。招聘经理不需要公司历史,他们需要的是造成这个设计挑战的那个约束。
最多两到四句话。什么坏了。伤害了谁。为什么一直没修好。这就是问题。
一段好的问题描述:
企业版结账流程的放弃率高达 63%,因为采购团队没法在不截图的情况下把报价分享给财务。现有流程假设的是一个带信用卡的单一买家。要修好它,就意味着要为账期 60 天发票的委员会式采购重新设计。
没有背景故事。没有“客户找到了我们”。直奔约束。落地页设计原则那篇文章谈的是营销文案中的同一种纪律。案例研究也是同样的规则。
第三部分:约束
没有约束的案例研究读起来像小说。每个真实项目都有约束(时间线、团队、平台、合规、预算、现有系统)。列出它们能赢得信任,因为它们证明设计师是在真实世界中工作,而不是在给某个财富 500 强品牌做个人品牌重塑。
五到七个要点。保持具体。
- 团队:两名设计师、一名工程师、一名 PM
- 从启动到上线共六周
- 现有设计系统锁定,只能新增,不能覆盖
- 仅限企业版,消费者结账流程保持不动
- 必须与现有 SAP 采购流程集成
- 第一天就要达到 WCAG AA 无障碍目标
- 没有全新的后端工作,仅限前端和集成
约束不是抱怨。它们证明设计师在框里作画之前,先弄懂了这个框。
第四部分:压缩后的过程
大多数作品集案例研究在过程上投入过多。它们塞进每一张发散草图、每一个工作坊产物、每一块情绪板。招聘经理不读这些。他们在找三件事:设计师有没有界定问题,有没有验证方案,有没有把设计出来的东西交付出去。
每一项展示一次证据。
界定证据: 一张图表、流程或决策矩阵,展示范围是如何确定的。可以是用户旅程图、服务蓝图、竞品拆解摘要、决策日志截图。一个产物,标注它回答了什么。
验证证据: 一个研究或测试产物。带两条引述的可用性测试总结、A/B 测试结果、展示改版前状态的分析截图、带注释变更的原型迭代。一个产物,标注它改变了什么。
交付证据: 真正上线的设计。不是最终的 Figma 稿。是线上 URL、App Store 截图、录制的流程。只展示 Figma 稿而从不展示已交付产品的案例研究,读起来就像纸上设计。
第五部分:决策日志
这是大多数设计师跳过的部分,也是招聘经理会读两遍的部分。
决策日志是一份简短的清单,列出项目期间做出的非显而易见的决定,以及取舍和结果。它证明设计师的观点经受过现实的检验,这是作品集所能携带的最值得录用的信号。
三到五条。每条的模板:
- 决策: 选了什么
- 备选: 否掉了什么
- 理由: 推动这个决定的约束或洞察
- 结果: 上线后发生了什么
示例:
- 决策: 报价分享被重建为只读的公开链接,而不是原生的抄送财务流程。
- 备选: 产品内抄送财务,但需要创建账号。
- 理由: 采购和财务团队往往属于不同的系统,采购方不会等待账号创建流程。
- 结果: 71% 的企业报价在生成后 24 小时内被分享,改版前仅为 12%。
决策日志是作品集最接近真实面试的东西。先写它们,再围绕它们写案例研究的其余部分。
第六部分:成果与数据
成果部分是案例研究的薪水。之前的一切都是铺垫。这里的数据必须真实、具体、可归因。
有三类数据有效。
业务数据。 收入、转化、留存、激活、价值实现时间、CAC、LTV。招聘经理最先想看的就是这些,因为它们直接对应设计团队存在的理由。
产品数据。 任务完成率、错误率、客服工单量、任务耗时、功能采用率。它们证明设计改变了用户行为,也就证明设计是好的。
质量数据。 无障碍审计得分、核心网页指标改善、设计系统采用率、节省的交接时间。这些是第二梯队的数据,当业务和产品数据拿不到时(受 NDA 限制、测量为时过早)很有用。
每类各一个就够了。每个案例研究三个数据胜过十个,因为三个具体数据读起来诚实,十个读起来像凑数。
如果项目受 NDA 限制,直说。用可验证的区间代替确切数字(“转化率提升了低两位数”“激活翻倍”)。不要编造。招聘经理在每家公司都有朋友,他们会去问。
第七部分:你的角色,直截了当
每个案例研究都需要清楚回答招聘经理脑子里真正在想的那个问题:这位设计师本人到底做了什么。
两到三句话。独自完成时用“我”,团队合作时用“我们四人的团队”,无论哪种都要列出具体贡献。
好的写法:
我主导了交互设计,并负责决策日志。我在结账流程上与一名工程师结对,在范围界定上与一名 PM 结对。团队里另一位设计师负责视觉系统,我应用了它,但没有设计它。
含糊的写法:
我主导了端到端的设计流程,并与跨职能伙伴紧密协作,交付了令人愉悦的用户体验。
含糊的版本读起来像烟幕弹。它总会引发更多面试问题,而不是更少。写直白的版本,把面试留给你真正想聊的对话。
第八部分:反思
一小段话。如果重新做这个项目,你会有哪些不同的做法。
这是资历的试金石。初级设计师的反思泛泛而谈(“我会更早与用户多做迭代”)。资深设计师的反思则具体入微(“我把采购集成的时间线低估了四周,第一天就该把它作为独立的工作流来界定,而不是塞进结账项目里”)。
过于正面的反思(“一切都很棒”)会被视为可信度的警示。过于负面的反思(“我失败了”)显得不专业。具体而有战术性的反思,读起来像是从项目中学到了东西、也会从下一个项目中学到东西的人。
大多数案例研究该砍掉什么
大多数作品集案例研究都比需要的更长,这就是招聘经理只会略读的原因。砍掉以下内容:
“关于客户”的段落。 如果客户很有名,招聘经理早就知道了。如果不出名,背景应放进问题陈述,而不是单独一块。
情绪板。 几乎与录用决策无关。把情绪板留给内部工作文件和客户演示,在那里它们才有价值。
发散构思网格。 一页上九个概念,其中八个被否掉,这是工作坊产物,不是作品集产物。展示最终方向,以及那个真正有竞争力的备选方案。
未上线的设计稿合集。 漂亮但从未上线的设计稿,会告诉招聘经理这位设计师也许不会交付。这是错误的信号。永远以已交付的作品开场。
个人风格散文。 “我的设计理念”部分会被跳过。如果理念是真的,案例研究会在不宣告的情况下把它展现出来。
按资历划分的案例研究篇幅
案例研究的篇幅随资历而变,但结构不变。八个部分保留,变化的是各部分内部的深度。
| 资历 | 问题 | 约束 | 过程 | 决策 | 成果 | 角色 | 反思 | 总篇幅 |
|---|---|---|---|---|---|---|---|---|
| 初级 | 3 句 | 5 条 | 3 个产物 | 3 个决策 | 2 个数据 | 3 句 | 3 句 | 800 到 1200 词 |
| 中级 | 1 段 | 6 条 | 3 个产物 | 4 个决策 | 3 个数据 | 3 句 | 1 段 | 1200 到 1800 词 |
| 高级 | 1 段 | 7 条 | 3 个产物 | 5 个决策 | 3 到 5 个数据 | 3 句 | 1 段 | 1500 到 2200 词 |
| 资深专家 | 2 段 | 7 条 | 3 个产物 | 5 个涉及组织层面取舍的决策 | 5 个带归因的数据 | 3 句 | 1 段 | 1800 到 2500 词 |
超过 2500 词的案例研究没人读得完。对高级和资深专家岗位而言,规则是密度,而不是长度。每段有更多判断,而不是更多段落。
如何写初稿
通向可发布案例研究的最快方式,是按这个顺序写,而这并不是读者看到的顺序。
- 先写决策日志。三到五条。这是最难的部分,也是其他一切的支点。
- 第二步写成果部分。先把数据拿出来,再围绕它们写。
- 第三步写问题和约束。现在你知道哪些约束重要了,因为你知道哪些决策是由它们驱动的。
- 第四步写过程部分。挑出三个配得上位置的产物。
- 最后写角色和反思部分。简短、诚实、完事。
- 最后重写顶部的一句话成果,在其他一切写完之后。它是最后起草的一句,也是最先被读到的一句。
这个顺序会把艰难的思考提前。按阅读顺序写作的设计师,往往最后得到漂亮的文字,却缺少实质。
如何呈现过程而不让读者无聊
过程部分是大多数作品集被略读至死的地方。解法是提高密度,而不是删除。
每个产物一张带注释的截图。 不是整个工作文件的图库。一张截图,配三个标注,解释这个产物回答了什么。
一段原型视频,不超过 30 秒。 跳过未经剪辑的屏幕录制。把原型视频剪成紧凑的循环,展示关键交互,并加上标注。
每次都做前后对比。 任何包含“之前”的对比,都比不包含的更有力。即使是铅笔草图放在已上线产品旁边,也读得出进步。线框图词条介绍了哪类早期产物有分量。
用体素、草图或低保真画面,代替又一张精修稿。 低保真思考与高保真交付之间的对比,证明设计师是在解决问题,而不是把样式包装成方案。
如果你想要一个审核作品集、并在招聘经理参与下重写案例研究的团队,聘请 Brainy。作品集评审是我们为求职中的高级和资深专家设计师提供的见效最快的服务之一。
案例研究通过/不通过测试
在案例研究放上作品集之前,先用五项检查过一遍。
扫描测试。 读者能否只看标题和每段第一句话,就get到问题、方法和成果。如果不能,可扫描性就坏了。视觉层级设计那篇文章讲了结构上的修复方法。
数据测试。 页面上是否至少有两个真实数据。如果没有,这个案例研究就是一个没有笑点的故事。
角色测试。 读者能否在不到 10 秒的阅读内回答“这位设计师本人做了什么”。如果不能,角色部分就太含糊了。
决策测试。 案例研究是否展示了至少三个非显而易见、并点明取舍的决策。如果没有,这位设计师看起来像执行者,而不是思考者。
交付测试。 是否有证据表明作品真的上线了。URL、真实设备上的截图、App Store 链接、生产代码截图。如果没有,这个案例研究就是一篇推测性的作品,而不是专业作品。
五项检查。五分钟。每个案例研究,每一次。
FAQ
设计案例研究应该多长?
依资历而定,在 800 到 2500 词之间。初级案例研究 800 到 1200 词,中级 1200 到 1800 词。
高级 1500 到 2200 词。如果决策和数据足以支撑,资深专家和首席级案例研究可以延伸到 2500 词。再长就会失去读者。
每个设计案例研究应该包含什么?
按顺序八个部分:一句话成果、问题段落、约束、压缩的过程部分、决策日志、可衡量的成果、对个人角色的直白陈述,以及简短的反思。每个案例研究都需要这八项齐全,哪怕有些只有两句话。
如何在不违反 NDA 的前提下写案例研究?
用可验证的区间代替具体数字(“转化率提升了低两位数”),用行业描述代替具名品牌(“一家拥有 100 多家企业客户的金融科技公司”)。在案例研究顶部清楚声明 NDA。不要编造数字或品牌。招聘经理会核查,编造的案例研究会毁掉职业生涯。
如何展示过程而不让读者昏昏欲睡?
限制在三个产物(一个用于界定,一个用于验证,一个用于交付)。给每个产物标注它回答了什么。用 30 秒的关键交互剪辑代替冗长的原型视频。始终包含前后对比。在每一次作品集评审中,密度都胜过数量。
设计师在案例研究中犯的最大错误是什么?
以铺垫而不是成果开场。案例研究的第一行应该是项目的结果,而不是开工时的兴奋。招聘经理是自上而下扫描的。如果成果被埋在第二页,这个案例研究就已经输了。
如果项目还没上线,我该怎么写案例研究?
先交付点东西。未上线的案例研究读起来像推测,招聘经理会打折扣。如果项目必须在上线前出现,就清楚标注为“开发中”,并聚焦在决策日志和研究部分。绝不要把未上线的设计稿当作真实成果展示。
作品集就是一个销售页
每个案例研究都是写它的设计师的销售页。产品是设计师。买家是招聘经理。价格是一场四十分钟的面试。
能赢的销售页直接、具体、诚实。它们以成果开场,用约束和决策来证明,用数据来支撑,并以对卖家是谁的清晰陈述收尾。会输的销售页把成果藏在过程背后,用背景把故事灌水,让读者搞不清自己到底买了什么。
写完这八个部分。砍掉臃肿。发布案例研究。然后为下一个项目再做一遍,再下一个,直到作品集读起来是一组押中的已交付赌注,而不是一组你乐在其中的旅程。
如果你想要一个审核、重写并交付能转化为面试的作品集的团队,聘请 Brainy。我们已经把这个模板用在产品、品牌和 UX 作品集上,这套结构次次奏效。
相关阅读
Need a portfolio that lands interviews instead of silence? Brainy runs portfolio audits and rewrites with hiring managers in the loop.
Get Started
