设计小比设计大更难
TL;DR · AI 摘要
在敏捷开发中，设计师面临的真正挑战不是加快速度，而是学会设计更小、独立且能立即交付价值的功能模块，而非完整的系统。
核心要点
- 敏捷团队要求的不是设计师更快，而是设计更小、可独立交付的价值单元。
- 设计师习惯于整体思维，但在敏捷中需克制这种本能，聚焦最小可行体验。
- 通过‘切片式设计’将大功能拆解为可迭代的小块，是提升协作效率的关键。
结构提纲
按章节快速跳转。
设计师常误以为敏捷需要提速，实则需设计更小。
整体设计是优势，但在敏捷中易造成交付阻力。
团队需要的是可快速构建并独立运行的小功能。
从浏览到申请，逐步拆解功能以适应迭代节奏。
定义每个小块必须具备的核心用户体验。
在限制中创造价值，是现代设计师的核心能力。
思维导图
用一张图看清主题之间的关系。
查看大纲文本（无障碍 / 无 JS 友好）
- 敏捷中的小设计挑战
- 核心矛盾
- 系统思维 vs 迭代现实
- 完整设计 vs 小块交付
- 关键能力
- 拆解功能为独立单元
- 定义最小可行体验
- 实践案例
- 求职功能分步实现
- 从浏览到申请的切片
金句 / Highlights
值得收藏与分享的关键句。
Agile teams don’t want the whole cathedral; they want one brick that delivers real value now.
Most designers are trained to think in systems, but agile doesn’t usually start with the full system. It starts with a slice of it.
Designing only a small portion can feel incomplete, even risky. But that’s exactly where agile teams operate.
The far less obvious skill of designing smaller, not faster.
Each piece has to stand on its own and deliver value right away.
After 10+ years working in Agile marketing teams... I realized I’d been looking at it from the wrong angle.
设计小比设计大更难 - UX 杂志
我们与乌克兰及来自乌克兰的团队成员同在。你可以通过这些方式提供帮助
一个超过百万人的社区
[](https://twitter.com/uxmag)[](https://www.linkedin.com/company/ux-magazine)[](https://www.facebook.com/uxmag)
获取独家访问权限，阅读发人深省的文章、额外播客内容以及前沿白皮书。[立即加入 UX 杂志社区！](http://uxmag.com/articles/designing-small-is-harder-than-designing-big#membership_popup)
设计小比设计大更难
5 分钟阅读
- 2026 年 5 月 7 日
分享此文章到
推文
分享
发布
分享
邮件
打印
保存
你只有真正开始在敏捷环境中进行设计时，才会意识到自己是否真的理解了敏捷。关键在于：比起“更快”，更不明显的技能其实是“更小”地设计。大多数设计师习惯于从完整系统的角度思考，但敏捷团队并不需要整座大教堂；他们只需要一块能立刻带来实际价值的砖头。理解这种区别至关重要。
在敏捷营销团队工作了十多年后，我以为我已经理解了敏捷。直到我开始学习用户体验设计，才意识到我一直从错误的角度看待它。
当人们谈论在敏捷团队中工作时，通常会把挑战描述为速度问题。一切都变得更快了。冲刺周期很短。工程师随时准备开发。产品经理将大想法拆分成需要立即处理的任务单。
大家普遍认为，设计师只需跟上节奏即可。
但我在参加Laura Klein主讲的课程中学到的第一件事就是：这种看法是错误的。敏捷团队并不要求设计师做得更快。
他们要求的是设计得更小，而对设计师来说，这反而出乎意料地困难。
设计师的本能：整体性思维
大多数设计师都受过系统化思维训练。当我们面对一个问题时，自然会拉远视角。我们希望理解完整的体验、交互生态以及能够支撑未来发展的长期结构。
这种本能是一种优势。正是它让设计师避免碎片化的体验，并预判产品随时间演进的可能性。但同样的本能也让敏捷工作变得令人不适，因为敏捷通常不会从整个系统开始，而是从其中的一个切片入手。
你可能不会被要求设计完整的解决方案，而是只设计一个小部分，这个部分可以在一两个冲刺周期内完成并发布。即使这部分属于更大的愿景，它也必须独立存在，并立即交付价值。
矛盾由此产生。
设计完整的体验在智力上令人满足，感觉负责且周全。而仅设计其中一小部分则可能显得不完整，甚至有风险。但这正是敏捷团队的工作方式。
一个思想实验：构建求职功能
课程中的一个例子有助于更清晰地看到这种矛盾。
假设你正在设计一项功能，帮助求职者查找并申请工作。乍一看，这似乎是一个简单的产品功能，但一旦开始梳理，范围就会迅速扩大。
求职者需要一个页面来浏览开放职位列表。他们很可能还需要搜索或筛选功能，以便找到最相关的岗位。每个职位都需要一个详细页面，展示具体信息。最终，还需要一个申请流程，让用户真正提交申请。
而这还远未结束。用户可能还想收藏感兴趣的职位、比较不同岗位，或发现类似职位。很快，原本看似单一的功能就变成了一套庞大且相互关联的系统。
许多设计师的本能反应是退后一步，一次性设计整个体验。毕竟，各个部分彼此影响。搜索功能依赖于职位列表中的信息内容，申请流程又取决于职位的结构方式。整体设计看起来合乎逻辑。但在敏捷团队中，这几乎不现实。
没有任何团队会在一次冲刺中设计并构建出全部体验，而且他们甚至不应该尝试这样做。
水平切分的陷阱
将大型功能拆分为更小部分时，一个常见的诱惑是按技术层级来划分工作。例如，团队可能会决定先构建搜索引擎，这意味着要首先设计搜索字段、筛选器和算法。
表面上看，这似乎是在尽早解决最困难的技术问题。但实际上它并未为用户创造任何价值。如果还没有职位列表，那便无物可搜。更糟糕的是，由于产品中尚未存在核心内容——也就是职位本身——我们甚至难以测试搜索体验是否有效。
这个系统在技术上令人印象深刻，但在实际使用中却毫无用处。
这正是 Laura Klein 所描述的水平切分（horizontal slicing）的问题所在。当你按照功能层级而非完整的用户价值来划分工作时，最终常常会构建出无法独立运作的部分。而如果某个工作片段无法为用户带来价值，那么发布它也几乎无法让我们获得任何收获。
寻找最小但有用的功能切片
究竟应该先构建什么？
在求职搜索的例子中，最有价值的第一个切片可能出人意料地简单：一个列出可用职位的页面，包含足够让用户判断是否感兴趣的信息即可。
“申请”按钮无需构建复杂的应用系统，可以只是发送一封邮件，或允许用户通过一个简单的表单上传简历。显然，这不是最终体验，但它完成了一件重要的事：让用户发现职位并迈出申请的第一步。更重要的是，它使团队能够快速发布某些东西，并开始学习。
也许用户关心的职位细节与预期不同；也许雇主提供的信息不足；也许人们希望按一些没人预料到的标准进行筛选。
这些洞察极为宝贵，只有当真实用户开始与产品互动时才会浮现。设计更小的功能切片，才能让这种快速学习的循环成为可能。
真正的挑战
从这门课程中我逐渐意识到，设计“小”并不仅仅是缩小范围。设计师不应再问：“完整的解决方案会是什么样？” 而应转而思考：“这个想法的最小版本是什么，仍能为用户提供真实价值？”
回答这个问题并没有通用法则。它取决于产品本身、用户群体、公司所处阶段，以及团队试图验证的假设。
但一旦你开始以这种方式思考，有趣的事情就会发生。有时你会发现，你设想的功能其实比想象中小得多；有时你会意识到，用户真正需要的东西，与你最初计划构建的略有不同。
在敏捷环境中，你很少被要求去设计整座大教堂。你只需要设计其中一块砖。
_本文最初发表于 Substack。_
封面图片致谢：Marvin Meyer。
[](https://uxmag.com/podcasts)
[](https://invisiblemachines.ai/?utm_source=uxmag&utm_medium=referral&utm_campaign=article_consciousAImodels?&utm_content=ad2)
[](https://uxmag.com/contributors/paivi-salminen)
Päivi Salminen，理学硕士，是一位由数字健康创新者转型为研究者的专业人士，拥有十余年推动初创企业及国际研发项目增长与创新的经验。在行业深耕多年后，她近期转入学术界，致力于探索用户体验与设计思维如何创造出更加公平且具影响力的医疗解决方案。她的工作连接商业战略、技术与同理心，旨在将患者和临床医生的洞察转化为真正产生影响的可持续创新。
Tweet
Share
Post
Share
简要观点
- 本文指出，敏捷设计的重点不在于快速开发，而在于更难掌握的设计“小”能力：抵制完整规划系统的诱惑，避免陷入水平切分的陷阱，并深入探究一个想法的最小迭代版本——即仍能为用户带来真实价值的那个版本。
#### 相关文章
[你的设计团队精疲力竭的真正原因（以及如何解决）](https://uxmag.com/articles/the-real-reason-your-design-team-burns-out-and-how-to-fix-it)
- DesignOPS, 同理心, 未来工作, 领导力
了解为何团队会精疲力竭、创新停滞、领导者未能产生影响，却未意识到根本原因。
作者：Pavel Bukengolts
你的设计团队精疲力竭的真正原因（以及如何解决）
- 该文指出，设计团队并非因工作过多而精疲力竭，而是因为文件丢失、需求频繁变更、决策未被记录等事务导致耗尽精力。DesignOps 是解决方案：将重复性问题视为信号，在工作流中加入导师机制，并用能力数据代替凭直觉的领导方式。
[在推特上分享](https://twitter.com/share?text=文章指出，设计团队的倦怠并非源于工作过多；而是源于文件丢失、需求频繁变更以及未书面记录的决策等问题。DesignOps 是解决方案：将重复性工作视为信号，将导师制融入工作流程，并用能力数据取代凭直觉的领导方式。&url=https://uxmag.com/articles/the-real-reason-your-design-team-burns-out-and-how-to-fix-it)
[在领英上分享](https://www.linkedin.com/shareArticle?mini=true&url=https://uxmag.com/articles/the-real-reason-your-design-team-burns-out-and-how-to-fix-it&title=&summary=文章指出，设计团队的倦怠并非源于工作过多；而是源于文件丢失、需求频繁变更以及未书面记录的决策等问题。DesignOps 是解决方案：将重复性工作视为信号，将导师制融入工作流程，并用能力数据取代凭直觉的领导方式。)
[在脸书上分享](https://www.facebook.com/sharer/sharer.php?u=https://uxmag.com/articles/the-real-reason-your-design-team-burns-out-and-how-to-fix-it"e=文章指出，设计团队的倦怠并非源于工作过多；而是源于文件丢失、需求频繁变更以及未书面记录的决策等问题。DesignOps 是解决方案：将重复性工作视为信号，将导师制融入工作流程，并用能力数据取代凭直觉的领导方式。)
[通过邮件分享](mailto:?body=链接:https://uxmag.com/articles/the-real-reason-your-design-team-burns-out-and-how-to-fix-it%20文章指出，设计团队的倦怠并非源于工作过多；而是源于文件丢失、需求频繁变更以及未书面记录的决策等问题。DesignOps 是解决方案：将重复性工作视为信号，将导师制融入工作流程，并用能力数据取代凭直觉的领导方式。)
分享：你的设计团队为何精疲力尽（以及如何解决）
[在推特上分享](https://twitter.com/share?text=文章指出，设计团队的倦怠并非源于工作过多；而是源于文件丢失、需求频繁变更以及未书面记录的决策等问题。DesignOps 是解决方案：将重复性工作视为信号，将导师制融入工作流程，并用能力数据取代凭直觉的领导方式。&url=https://uxmag.com/articles/the-real-reason-your-design-team-burns-out-and-how-to-fix-it)
[在领英上分享](https://www.linkedin.com/shareArticle?mini=true&url=https://uxmag.com/articles/the-real-reason-your-design-team-burns-out-and-how-to-fix-it&title=&summary=文章指出，设计团队的倦怠并非源于工作过多；而是源于文件丢失、需求频繁变更以及未书面记录的决策等问题。DesignOps 是解决方案：将重复性工作视为信号，将导师制融入工作流程，并用能力数据取代凭直觉的领导方式。)
[在脸书上分享](https://www.facebook.com/sharer/sharer.php?u=https://uxmag.com/articles/the-real-reason-your-design-team-burns-out-and-how-to-fix-it"e=文章指出，设计团队的倦怠并非源于工作过多；而是源于文件丢失、需求频繁变更以及未书面记录的决策等问题。DesignOps 是解决方案：将重复性工作视为信号，将导师制融入工作流程，并用能力数据取代凭直觉的领导方式。)
[通过邮件分享](mailto:?body=链接:https://uxmag.com/articles/the-real-reason-your-design-team-burns-out-and-how-to-fix-it%20文章指出，设计团队的倦怠并非源于工作过多；而是源于文件丢失、需求频繁变更以及未书面记录的决策等问题。DesignOps 是解决方案：将重复性工作视为信号，将导师制融入工作流程，并用能力数据取代凭直觉的领导方式。)