I used to think constraints were the enemy of good design. Give me unlimited time, budget, and technical resources, and I’ll build something amazing. Right?
Wrong.
Some of my best work has come from projects with the tightest constraints. Limited time forces prioritization. Limited budget forces creative problem-solving. Limited technical capabilities force simplicity.
The Paradox of Choice
Barry Schwartz’s book The Paradox of Choice argues that too many options lead to decision paralysis and dissatisfaction. The same applies to design projects.
When everything is possible, nothing is necessary.
Without constraints, you spend weeks debating whether to use React or Vue, whether to build a custom CMS or use a headless solution, whether to implement feature A or feature B. The project stalls in endless deliberation.
But when you have constraints—“We need to launch in 4 weeks,” “Our budget is $5,000,” “It needs to run on legacy browsers”—decisions become clearer. You focus on what matters.
Three Types of Productive Constraints
1. Technical Constraints
Working on a project with no backend access taught me more about information architecture than any course could. I couldn’t build complex filtering or search—so I had to structure content so intuitively that users didn’t need those features.
The result? A simpler, faster experience that worked better for everyone.
Lesson: Technical limitations often push you toward simpler, more maintainable solutions.
2. Time Constraints
I once had two weeks to redesign a checkout flow that typically takes 6-8 weeks. Instead of building a comprehensive design system and high-fidelity prototypes, I focused on the three screens with the highest drop-off rates.
We shipped faster and saw immediate impact. The other screens could wait.
Lesson: Time pressure forces ruthless prioritization. Ship the 20% that delivers 80% of value.
3. Budget Constraints
On a nonprofit project with a $0 design budget, I used free tools (Figma Community files, open-source illustrations, Google Fonts) and got creative with constraints.
The design wasn’t flashy, but it was thoughtful. It solved the problem. And the client loved it.
Lesson: Constraints force you to focus on solving the problem rather than showcasing your tools.
How to Embrace Constraints
Here’s how I approach constrained projects now:
1. List Your Constraints First
Before ideating, write down every limitation:
- Time available
- Budget
- Technical stack
- Browser/device support
- Accessibility requirements
- Team size and skills
These aren’t obstacles—they’re your design brief.
2. Identify the Core Problem
With constraints clear, ask: “What’s the ONE problem we absolutely must solve?”
Everything else is negotiable.
3. Design the Minimum Viable Experience
What’s the simplest version that solves the core problem?
Build that first. Then iterate if time/budget allows.
4. Use Constraints as Decision Filters
When debating features or approaches, ask: “Does this fit within our constraints?”
If no, kill it or defer it.
A Real Example
Last year I redesigned a student portal with these constraints:
- 12-week timeline
- No backend access (frontend-only changes)
- Must integrate with 15 legacy systems
- Mobile-first (68% of traffic)
These constraints forced me to:
- Focus on information architecture over visual design
- Build a comprehensive design system for consistency
- Prioritize mobile experience from day one
- Design for integration rather than replacement
The result was better than if I’d had unlimited resources. The constraints gave the project focus.
The Takeaway
Constraints aren’t limitations—they’re guardrails. They keep you focused on what matters. They force creativity. They prevent over-engineering.
Next time you feel frustrated by a project’s constraints, try reframing them as opportunities. What can you learn? What simpler solution might emerge?
You might be surprised.
What constraints have you encountered in your projects? How did they shape your approach? I’d love to hear your stories—reach out on LinkedIn or via the contact page.