TopicForge

如何构建真正能赢得 RFP 的设计案例研究

了解四部分案例研究框架,通过展示您的设计决策如何解决业务问题,与采购人员建立信任并赢得 RFP 竞标。

由 TopicForge 生成

阅读其他语言版本:ENESFRDEJAZH

一叠 RFP(征求意见书)响应文件堆在采购人员的办公桌上。大多数看起来都一模一样——在等距空间中漂浮的精美、高保真网站模型,配以“以人为中心的设计”等模糊承诺。评审人员在不到三十秒的时间内快速翻阅,寻找任何能表明该机构真正懂得如何解决业务问题的迹象。他们一无所获,于是那些漂亮的 PDF 文件直接被扔进了垃圾桶。

这就是 RFP 流程的现实。当客户寻找设计合作伙伴时,他们不是在购买艺术品。他们想要降低风险。他们需要知道,如果交给你一个复杂的产品、紧张的期限和一堆混乱的需求,你能交付一个行之解决方案。

为了赢得这些竞标,你的作品集不能只是一个自我陶醉的漂亮像素画廊。它需要成为一系列结构高度严谨、叙事驱动的销售工具。

为什么漂亮的模型不足以赢得竞标

大多数设计作品集都是为其他设计师制作的。我们喜欢在 Figma 中展示自定义过渡、完美的字体搭配和干净的网格。但是,阅读你 RFP 响应的营销领导和采购人员并不会像设计师那样购买设计。他们购买的是结果。

漂亮的模型只能说明你懂得如何使用设计软件。它无法证明你能诊断转化率下降、协调利益相关者的分歧或构建可扩展的系统。当你只展示最终打磨好的资产时,你隐藏了客户最想购买的东西——你的思考过程。

一个优秀的案例研究是一场关于决策的叙事。它解释了为什么一个按钮被放在特定的角落,为什么放弃了某种用户流程,以及最终的设计如何直接服务于客户的底线。如果你的案例研究没有解释“为什么”,读者就会认为你只是凭感觉碰巧做出了一个漂亮的界面。

四部分框架:问题、限制条件、过程和结果

要写出能够建立信任的案例研究,你需要一个可预测的结构。我们使用一个简单的四部分框架,它镜像了经典的戏剧性弧线:

  • 问题(The Problem): 什么地方坏了,为什么它对业务很重要?
  • 限制条件(The Constraints): 阻碍简单解决方案的因素是什么?
  • 过程(The Process): 团队如何克服这些障碍并找到正确的路径?
  • 结果(The Outcome): 设计取得了什么成就,我们如何衡量它?

跳过这四个要素中的任何一个都会让叙事变得平淡。如果你忽略了限制条件,项目看起来就太容易了。如果你忽略了过程,解决方案就显得来得太容易。通过在你的作品集中保持这种结构的一致性,你就能给潜在客户一个令人安心、结构化的视角,展示你的团队是如何运作的。

铺垫舞台:定义问题和限制条件

每个伟大的故事都需要冲突。在设计案例研究中,这个冲突就是业务问题。首先要准确定义在你的团队介入之前,什么地方出了问题。

不要使用“品牌感觉过时了”这样模糊的语言。相反,要将问题植根于运营现实中。例如,一个假设的 B2B SaaS 客户可能拥有一个功能强大的平台,但他们的自助式新手引导流程非常混乱,以至于用户在完成个人资料之前就放弃了产品。

一旦问题明确,就引入限制条件。限制条件不是借口——它们是为你的设计决策提供背景和分量的护栏。每个项目都有限制条件,无论是老旧的技术栈、严格的品牌指南,还是硬性的截止日期。

让我们来看一个现实的、假设的例子,说明如何构建这个框架:

问题: 我们的假设客户(一个物流 SaaS 平台)在初始设置阶段流失了用户。例如,数据显示在其新手引导向导的第三步,流失率达到了 45%(说明性数字)。

限制条件: 我们必须在客户公开上线前仅有的六周紧张窗口期内重新设计新手引导流程。此外,我们不能更改底层数据库模式——这意味着我们必须完全在现有的数据字段内工作。

通过这样构建项目,你向潜在客户展示了你理解业务指标,并且能够在技术限制内务实地工作。

毫无水分地展示过程

案例研究中的“过程”部分是许多机构失去读者的地方。人们很容易想把每一个 Miro 画板、用户画像和早期线框图都塞进页面里,以证明自己工作有多努力。

抵制这种冲动。你的潜在客户没有时间去看五十张一模一样的便签。只展示直接导向最终解决方案的过程工作。

如果你展示了一个早期草图,解释它为什么失败了,以及它如何启发了下一次迭代。如果你展示了一个用户测试地图,突出改变你设计方向的那一个核心洞察。

例如,你可以展示早期 Figma 原型与最终布局的并排对比。解释在用户测试期间,五分之四的参与者错过了主要行动呼吁(CTA),因为它被放置在了折叠线以下。展示你如何发现错误、调整并纠正它,对潜在客户来说是极其令人安心的。这证明你依赖数据和测试,而不仅仅是美学直觉。

用清晰、诚实的数据证明结果

没有可衡量结果的漂亮设计只是一个艺术项目。要赢得 RFP,你必须证明你的工作解决了你在案例研究开始时定义的问题。

将你的最终设计与以业务为中心的指标联系起来。只要有可能,就使用具体的数据。如果你设计了一个营销网站,谈谈转化率或页面加载速度。如果你构建了一个设计系统,谈谈客户的内部工程团队现在交付新功能的速度提高了多少。

以下是你如何使用说明性指标撰写结果部分:

结果: 重新设计的新手引导流程在上线后的第一个月内,将设置流失率从 45% 降低到仅 12%(说明性数字)。通过简化界面并添加清晰的进度指示器,客户的周活跃用户数增加了 30%(说明性数字)。

如果你的客户由于保密协议(NDA)无法分享确切的收入或用户数字,请专注于相对增长、运营效率或定性反馈。解释新的设计系统如何将他们产品团队的上线时间缩短了一半,或者关于新手引导的客户支持工单如何显著下降。

我们在 Northwind Studio 如何付诸实践

在 Northwind Studio,我们将这种叙事结构应用到我们自己的网页设计和品牌视觉识别项目中。作为一个专注于手艺的小型机构,我们不依赖庞大的销售团队或激进的推广。相反,在建立联系之前,我们让案例研究来承担与 B2B SaaS 和专业服务客户建立信任的重任。

我们像对待客户工作一样用心对待我们的作品集——确保每个案例研究都清晰地展示了我们如何应对复杂的技术限制,以交付高度无障碍、可扩展的设计系统。

如果你想赢得更多 RFP,就不要再把你的作品集当成一个静态的画廊。开始讲述你如何解决棘手问题的故事吧。


我们帮助成长型团队构建清晰、无障碍的网页设计和强大的设计系统,将复杂的产品故事转化为明确的业务成果。如果你想在下一个数字化项目上进行合作,请联系 Northwind Studio。


常见问题

设计案例研究应该多长?

保持简练。一篇优秀的案例研究阅读时间不应超过四到五分钟。使用清晰的标题、项目符号和加粗文本,以便忙碌的营销领导和采购人员在 RFP 评审期间可以轻松浏览叙事。

如果客户不让我们分享指标或受保密协议保护的数据怎么办?

专注于定性结果和相对增长。你可以使用百分比而不是原始数据——例如“注册量增加 40%”——或者专注于运营上的改进,比如新的设计系统如何将他们产品团队的上线时间缩短了一半。

我们应该在案例研究中加入早期草图和线框图吗?

只有在它们有助于解释关键决策时才加入。不要为了证明你做了工作而加入草图——相反,用它们来展示你如何测试了一个假设、遭遇失败并调整到正确的解决方案。

我们如何针对 PDF 格式的 RFP 与我们的网站格式化案例研究?

你的网站应该承载常青的、高度视觉化的故事版本。对于特定的 RFP,导出一个定制的 PDF 版本,突出与潜在客户当前挑战相匹配的具体限制条件和结果。