Execution constraints set the frame for design
The design is limited by what the client’s team can build and afford: frontend capacity, font licences, deadlines.
Designs that ignore these limits get simplified during implementation.
Table of Contents
Summarize with:
Key facts
- Constraints typically include frontend capacity, font licences and deadlines.
- Constraints often come up in review and are missing from the brief.
- Feasibility discovered after handoff leads to simplification during implementation.
- Designing within the component library the team can maintain keeps the design buildable.
- Designing beyond them sets a direction and risks a partial implementation.
Why it happens
Constraints arrive late. They come up in review and are missing from the brief.
Design separated from engineering. Feasibility is discovered after handoff.
Not collected as inputs. Build-side constraints were never collected as design inputs.
Project constraints
Decisions about working within or extending technical constraints depend on the specific project.
How it shows up
- Designs are simplified during implementation
- Developers ask for something simpler
- Only free fonts are allowed
- Decisions have one- or two-day windows
- The built product differs from the approved design in ways nobody decided
Options and trade-offs
What helps:
- Ask for build constraints before designing
- Design within the component library the team can maintain
- Review feasibility with developers early
- Agree what must survive implementation
Implementation
Build within the team’s constraints
The tension: designing within constraints ships reliably, with less ambition. A design that goes beyond them sets a direction and risks being only partly built.
Common mistakes
- Leaving build constraints out of the brief
- Choosing a commercial font before checking the licence budget
- Designing custom components the team cannot maintain
- Handing off without agreeing what must survive implementation