1. States That Are “Just Slightly Different”

“This is basically the same, just a different color and text.”

To a designer, this feels like a simple variation.
To a developer, it can be an entirely new state.

Examples:

• A disabled button that is still clickable

• Empty state A and empty state B with different icons and copy

• Error states that have slightly different layouts from success states

📌 The problem:
Every “slight difference” introduces more conditions, more test cases, and more potential bugs.

👉 Designer considerations:

• Ask yourself: Can this reuse the same state?

• If it’s different, is it for a real UX reason — or just because it “looks nicer”?

(You can illustrate this with a diagram: one component → multiple states → increasing logic branches.)

2. Components Without Clear Boundaries

“This card can be used everywhere.”

That may be true — but:

• What is the maximum number of text lines?

• Is the icon mandatory or optional?

• What happens when data is missing?

📌 The problem:
A component with “unlimited flexibility” forces developers to guess.

👉 Designer considerations:

• Define clear boundaries for each component

• Accept that no single component needs to cover every possible scenario

(Illustration idea: a clearly constrained card vs. a constantly shape-shifting one.)

3. Beautiful Animations Without Rules

Animation brings life to an interface.
But animation without rules creates friction for development.

Examples:

• Different durations across screens

• Different easing for the same type of motion

• Some screens animated, others not

📌 The problem:
Developers end up custom-building each case, which is hard to maintain and hard to reuse.

👉 Designer considerations:

• Define motion rules, not individual animations

• Fewer animations, applied consistently

4. “Flexible” Layouts Without Responsive Logic

“This will just work responsively.”

Nothing works “naturally” in responsive design.

📌 Common issues:

• Spacing that changes without a clear system

• Unclear breakpoints

• Elements that resize unpredictably across screens

👉 Designer considerations:

• Treat responsive design as a system, not manual adjustments per screen

• Be explicit about what is fixed and what is fluid

5. Diagrams Missing Inputs and Outputs

Flows exist — but:

• Where does the input come from?

• Which screens are affected by the output?

• Is the state persisted or lost when navigating back?

📌 The problem:
Developers have to infer the logic, which easily leads to misunderstandings.

👉 Designer considerations:

• Diagrams don’t need to be beautiful

• But they must clearly communicate data flow

(Illustration idea: diagram with vs. without defined inputs and outputs.)

The Most Important Lesson I’ve Learned

Design is not only for users to interact with —
it is also for developers to build.

A “good” UI is one where:

• Users understand it easily

• Developers can implement it confidently

• The team can maintain it over time

And very often, removing a little from the design
helps the product go much further.

Final Thought

If there’s one question I always ask before finalizing a UI, it’s this:

“Is this decision helping developers — or forcing them to guess?”

When designers and developers understand the same thing in the same way,
that’s when design truly gets shipped.