Showing constraints and trade-offs

Real design always happens within limits: time, budget, technology, regulation, team skills and organisational politics. Showing how you worked within constraints is one of the strongest signals of seniority.

Common constraints

• Time: a fixed launch date.
• Technology: legacy systems, platform limits, existing components.
• Regulation: legal wording, accessibility law, data protection.
• Business: budget, priorities, stakeholder demands.
• Users: devices, skills, contexts of use.

Describing trade-offs

For each important decision, explain: the options, what you chose, why, what you gave up and how you reduced the downside. "We could not change the payment provider, so instead of a custom checkout we improved the page before it to set expectations. It reduced surprise, though the provider's page remained clunky."

Avoid blaming

Describe constraints neutrally. "Engineering would not let us" sounds like blame; "the API only returned data once a day, so we designed around a daily update" shows problem solving.

Hiring managers know that perfect designs rarely ship. They want designers who can make smart compromises, communicate them and still improve things for users. Showing trade-offs proves you can operate in real organisations, not just in idealised exercises.

A case study on an internal HR tool explains: "We wanted to rebuild the leave request form entirely, but the team had three weeks and the back end could not change. We focused on the two fields that caused 80% of errors, adding clearer labels and inline validation. Errors fell, but the outdated layout remained; we documented a full redesign for the next quarter."