Designing Small Is Harder than Designing Big
TL;DR · AI Summary
In agile development, the real challenge for designers isn't speed—it's learning to design smaller, self-contained features that deliver immediate value, not complete systems.
Key Takeaways
- Agile teams don’t need designers to move faster—they need them to design smaller
- Designers’ holistic instincts must be tempered to focus on minimal viable experi
- Breaking down features through 'slicing' is key to aligning design with iterativ
Outline
Jump quickly between sections.
设计师常误以为敏捷需要提速，实则需设计更小。
整体设计是优势，但在敏捷中易造成交付阻力。
团队需要的是可快速构建并独立运行的小功能。
从浏览到申请，逐步拆解功能以适应迭代节奏。
定义每个小块必须具备的核心用户体验。
在限制中创造价值，是现代设计师的核心能力。
Mindmap
See how the topics connect at a glance.
查看大纲文本（无障碍 / 无 JS 友好）
- 敏捷中的小设计挑战
- 核心矛盾
- 系统思维 vs 迭代现实
- 完整设计 vs 小块交付
- 关键能力
- 拆解功能为独立单元
- 定义最小可行体验
- 实践案例
- 求职功能分步实现
- 从浏览到申请的切片
Highlights
Key sentences worth saving and sharing.
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.
Designing Small Is Harder than Designing Big - UX Magazine
We stand with Ukraine and our team members from Ukraine. Here are ways you can help
A community of over 1 million
[](https://twitter.com/uxmag)[](https://www.linkedin.com/company/ux-magazine)[](https://www.facebook.com/uxmag)
Get exclusive access to thought-provoking articles, bonus podcast content, and cutting-edge whitepapers. [Become a member of the UX Magazine community today!](http://uxmag.com/articles/designing-small-is-harder-than-designing-big#membership_popup)
Home ›› UX Design ›› Designing Small Is Harder than Designing Big
Designing Small Is Harder than Designing Big
5 min read
- May 7, 2026
Share this post on
Tweet
Share
Post
Share
Save
You think you know agile until you really have to design in agile. And that’s the trick: the far less obvious skill of designing smaller, not faster. Most designers are trained to think in full systems, but agile teams don’t want the whole cathedral; they want one brick that delivers real value now. Understanding the difference is everything.
After 10+ years working in Agile marketing teams, I thought I understood Agile. Then I started studying UX and realized I’d been looking at it from the wrong angle.
When people talk about working on agile teams, they often describe the challenge as a matter of speed. Everything moves faster. Sprints are short. Engineers are ready to build. Product managers are breaking big ideas into tickets that need to be tackled immediately.
The assumption is that designers simply need to keep up.
But one of the first things I learned inthe course I’ve been takingwithLaura Kleinis that this framing is wrong. Agile teams don’t really ask designers to move faster.
They ask to designsmaller, and for designers, that turns out to be surprisingly difficult.
The designer’s instinct: think holistically
Most designers are trained to think in systems. When we approach a problem, we naturally zoom out. We want to understand the full experience, the ecosystem of interactions, the long-term structure that will support everything that comes later.
That instinct is a strength. It’s what allows designers to prevent fragmented experiences and anticipate how a product might grow over time. But that same instinct can make agile work feel uncomfortable, because agile doesn’t usually start with the full system. It starts with a slice of it.
Instead of designing the entire solution, you might be asked to design just one small piece that can be built and released within a sprint or two. Even if that piece is part of a much larger vision, it has to stand on its own and deliver value right away.
That’s where the tension begins.
Designing the full experience is intellectually satisfying. It feels responsible and thorough. Designing only a small portion of that experience can feel incomplete, even risky. But that’s exactly where agile teams operate.
A thought experiment: building a job search
One example from the course can help to see this tension more clearly.
Imagine you’re designing a feature that allows job seekers to find and apply for jobs. At first glance, it sounds like a straightforward product feature, but once you start mapping it out, the scope expands quickly.
Job seekers will need a page where they can browse open job listings. They’ll likely want ways to search or filter those listings so they can find the most relevant roles. Each listing will need a detailed view with information about the job itself. And eventually, there will need to be an application process so users can actually apply.
Even that isn’t the whole story. People might want to bookmark jobs they’re interested in, compare listings, or discover similar roles. Before long, what looked like a single feature had become a large, interconnected system.
The instinct for many designers is to step back and design the whole experience at once. After all, the pieces affect each other. Search depends on what information exists in the listings. Applications depend on how listings are structured. It feels logical to design everything holistically. But on an agile team, that’s rarely practical.
No team is going to design and build that entire experience in a single sprint, and they probably shouldn’t even try.
The trap of horizontal slicing
One temptation when breaking a large feature into smaller pieces is to divide the work by technical layers. For example, a team might decide to build the search engine first. That means designing search fields, filters, and algorithms before anything else.
On the surface, this might sound like tackling the hardest technical problem early. But it doesn’t actually create value for users. If there are no job listings yet, there’s nothing to search. Even worse, it becomes difficult to test whether the search experience works well, because the core content, the jobs themselves, doesn’t exist in the product yet!
The system is technically impressive, but practically useless.
This is the problem with what Laura Klein describes ashorizontal slicing. When you divide work by layers of functionality rather than by complete user value, you often end up building pieces that can’t stand on their own. And if a slice of work doesn’t deliver value to users, you learn almost nothing from releasing it.
Looking for the smallest useful slice
What should be built first?
In the job search example, the most valuable first slice might be surprisingly simple: a page that lists available jobs with just enough information for users to decide whether they’re interested.
Instead of building a complex application system, the “Apply” button could simply send an email or allow users to upload a CV through a basic form. Obviously, that is not the final experience, but it accomplishes something important. It lets users discover jobs and take the first step toward applying. More importantly, it allows the team to release something quickly and start learning.
Maybe users care about different job details than expected. Maybe employers aren’t providing enough information. Maybe people want to filter by criteria nobody anticipated.
Those insights are incredibly valuable, and they only appear once real people start interacting with the product. Designing smaller slices makes those learning loops possible.
The real challenge
What I’m realizing from this course is that designing small isn’t only about reducing scope. Instead of asking, “What would the full solution look like?” designers have to ask, “What is the smallest version of this idea that still delivers real value?”
There’s no universal rule for answering that question. It depends on the product, the users, the stage of the company, and the assumptions the team is trying to test.
But once you start thinking this way, something interesting happens. Sometimes you discover that the feature you imagined is much smaller than you thought. Sometimes you realize that what users actually need is something slightly different than what you originally planned to build.
In agile environments, you’re rarely asked to design the whole cathedral. You’re asked to design one brick.
_The article originally appeared on Substack.
Featured image courtesy: 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, MSc, is a digital health innovator turned researcher with over a decade of experience driving growth and innovation across start-ups and international R&D projects. After years in the industry, she has recently transitioned into academia to explore how user experience and design thinking can create more equitable and impactful healthcare solutions. Her work bridges business strategy, technology, and empathy, aiming to turn patient and clinician insights into sustainable innovations that truly make a difference.
Tweet
Share
Post
Share
Ideas In Brief
- The article suggests that agile design is not about quick development but rather the more difficult discipline of designing smaller, resisting the temptation to map out complete systems, avoiding the snare of horizontal slicing, and inquiring into what the smallest iteration of an idea is that still provides real value to users.
#### Related Articles
[The Real Reason Your Design Team Burns Out (And How to Fix It)](https://uxmag.com/articles/the-real-reason-your-design-team-burns-out-and-how-to-fix-it)
- DesignOPS, Empathy, Future of Work, Leadership
Learn why teams burn out, innovation stalls, and leaders miss impact without realizing the root cause.
Article by Pavel Bukengolts
The Real Reason Your Design Team Burns Out (And How to Fix It)
- The piece shows that design teams don’t get burned out from working too much; they get burned out from things like lost files, changing briefs, and decisions that aren’t written down. DesignOps is the answer: treating repetition as a sign, adding mentorship to workflows, and using capability data instead of gut-feeling leadership.
[Share on email](mailto:?body=Link:https://uxmag.com/articles/the-real-reason-your-design-team-burns-out-and-how-to-fix-itThe%20piece%20shows%20that%20design%20teams%20don%E2%80%99t%20get%20burned%20out%20from%20working%20too%20much;%20they%20get%20burned%20out%20from%20things%20like%20lost%20files,%20changing%20briefs,%20and%20decisions%20that%20aren%E2%80%99t%20written%20down.%20DesignOps%20is%20the%20answer:%20treating%20repetition%20as%20a%20sign,%20adding%20mentorship%20to%20workflows,%20and%20using%20capability%20data%20instead%20of%20gut-feeling%20leadership.)
Share:The Real Reason Your Design Team Burns Out (And How to Fix It)
[Share on email](mailto:?body=Link:https://uxmag.com/articles/the-real-reason-your-design-team-burns-out-and-how-to-fix-itThe%20piece%20shows%20that%20design%20teams%20don%E2%80%99t%20get%20burned%20out%20from%20working%20too%20much;%20they%20get%20burned%20out%20from%20things%20like%20lost%20files,%20changing%20briefs,%20and%20decisions%20that%20aren%E2%80%99t%20written%20down.%20DesignOps%20is%20the%20answer:%20treating%20repetition%20as%20a%20sign,%20adding%20mentorship%20to%20workflows,%20and%20using%20capability%20data%20instead%20of%20gut-feeling%20leadership.)