Design Constraints

Design constraints are the explicit limits that shaped what you could actually build. Timeline, team size, existing systems, compliance rules, locked design systems, platform restrictions. Listing them early proves you solved a real problem instead of redesigning a Fortune 500 brand in your spare time. They exist because case studies without them read like fiction.

Five to seven bullets. Concrete. No complaints, just facts. This section builds trust before you show any pixels.

Design constraints are not excuses or limitations you secretly hated. They are not the client is difficult or stakeholders were slow. Those read as amateur hour. The common confusion is treating constraints as negative instead of the defining structure that made the solution smart.

Another mixup is burying them or mentioning them vaguely in process paragraphs. They deserve their own section right after the problem so the reader understands the difficulty level of what you solved.

The article example lists seven constraints for the enterprise checkout project. Team of two designers one engineer one PM. Six week timeline. Existing design system locked. Enterprise tier only. Must integrate with SAP. WCAG AA from day one. No backend work. Those bullets instantly tell a hiring manager this was not a greenfield personal project.

When Miro updated their infinite canvas in 2022 they listed similar constraints publicly. Locked API performance budgets, backward compatibility with three years of customer boards, and strict WCAG requirements. The resulting interaction patterns became industry standard precisely because they solved inside those real limits instead of ignoring them.

Use design constraints on every case study aimed at product design roles. They earn their keep when you need to prove you can ship inside reality instead of theoretical perfection. Do not use them in pure brand identity projects where the constraint set is usually different. The tradeoff is that listing real constraints makes your wins more impressive but requires you to have actually worked inside them. Fake constraints read as obvious padding.

Avoid listing constraints on speculative redesigns or school projects. They do not carry the same weight and the section exposes that the work was never tested by reality. Also skip if every constraint is trivial. That tells the reader the project had no teeth.

Constraints written well make the rest of the case study click. The decisions later make sense only because you showed the box first. Without this section the decision log loses its power.

Senior portfolios lean heavier on constraints. Staff level studies often list seven or eight with clear org and tech implications. Junior studies can list five and focus more on execution inside them.

The best constraint sections read like a mission briefing. Here is the terrain. Here are the resources. Now watch what we built anyway. That tone separates professionals from students.

Constraints turn your case study from a victory lap into proof you understand how real work actually gets done.