Every design lands on machinery someone else built. Databases with a fixed shape, an API written for a different purpose, a release cycle measured in weeks. These are not obstacles engineering invents to slow you down — they are the actual conditions of the product.
Find them early. A constraint discovered in week one is a design input. The same constraint discovered in week six is a rewrite, usually yours. Ask what the system already does before you draw what you want it to do.
The goal is not to design timidly inside the limits. It is to know which limits are walls and which are somebody's preference, and to spend your arguments on the walls.
Stack & Platform Constraints
The stack decides what is cheap and what is expensive. A gesture that costs an afternoon in native iOS can cost a fortnight on the web. A component your framework already ships — a date picker, a sheet, a segmented control — is nearly free, and a bespoke version of the same thing is not.
Platforms also disagree with each other. iOS and Android have different navigation models, different keyboard behaviour, different back gestures. Draw one screen, hand it to both, and one of them will feel wrong to everyone who uses it.
Ask which components already exist before you invent one. A custom control has to survive every OS update, every accessibility fix, every new screen size. A bespoke component is a standing bill that somebody else pays.
- Architecture as a Product: Why Your Tech Stack is Your Biggest UX Constraint — article
- Design Constraints: 7 Types Every UX Team Faces and How to Overcome Them — article
API & Data Limitations
Your interface can only show what the system can actually hand it. That sounds obvious until you have designed a table that sorts across the whole dataset when the API returns fifty records a page, or a filter on a field nobody stores.
Ask four things before you design any data-heavy screen. Which fields exist. How many records a single call returns. How fresh the data is — live, cached for five minutes, or rebuilt by an overnight batch. And what each call costs you, in rate limits or in money.
The classic failure is a live label on a number that updates nightly. The design is fine. The promise it makes is false, and support gets the complaint.
- Everything I know about good API design — article
- Understanding Data Design: The Key to Effective User Experiences — article
Performance Constraints
Speed is a design decision, not an engineering afterthought. The full-bleed hero, the custom typeface, the animated illustration — you chose them, and the phone pays for each on a train with two bars of signal.
Design for the worst device your users hold — a four-year-old Android on a bad connection, not the laptop your mockup lives on. A frame gets about sixteen milliseconds on a sixty-hertz screen and half that on a faster one; stacked blurs and shadows blow through it and the stutter shows.
Then design the wait. A skeleton screen makes the delay legible; progressive loading puts something readable on screen early; an optimistic update skips the wait by showing the result before the server has agreed — so you must also design the moment it is taken back. None of it makes the system faster. The wait is the part still yours to design.