Even the best design and development teams can fall into the same traps:
- A product that looks great in Figma but not in production.
- Endless debates over colors and layouts.
- Patterns that multiply faster than they’re governed.
If any of this sounds familiar, you might be dealing with a UX–Dev imbalance.
Let’s diagnose some common symptoms, understand their causes, and prescribe ways to get your design health back on track — drawing on proven practices from Morgan Stanley Tech Excellence playbook.
Symptom 1: The Design Lacks a Sense of Purpose (and Has Too Many Patterns)
Diagnosis: You’ve got screens that look individually stunning — yet when users flow through the experience, they feel lost. Components feel overdesigned, inconsistent, or disconnected.
Example: A dashboard uses five different card styles across pages — all technically correct, but each subtly different in layout and spacing. Users (and developers) spend more time guessing than understanding.
Prescription:
- Define your design principles early. Every pattern should serve a purpose tied to user and business goals.
- Benefit: Gives teams a shared north star for consistent decisions.
- Audit and consolidate. Run quarterly design audits to merge or retire redundant patterns.
- Benefit: Reduces redundancy and speeds up both design and development.
- Design for clarity, not decoration. Ask: What job is this component doing?
- Benefit: Users understand intent instantly and navigate with confidence.
Symptom 2: The Developed Product Doesn’t Match the Design
Diagnosis: What was pixel-perfect in Figma comes out distorted in production — buttons shifted, fonts mismatched, responsiveness broken.
Example: You hand over a form with crisp spacing and labeled states; developers implement it, but error messages stack awkwardly and alignment breaks at smaller breakpoints.
Prescription:
- Use design tokens and component libraries. Shared design systems bridge the gap.
- Benefit: Ensures design fidelity across screens, teams, and codebases.
- Pair during handoff. Designers should review builds early in QA — not after launch.
- Benefit: Catches mismatches early, reducing costly rework later.
- Close the feedback loop. Encourage devs to flag unclear specs or missing states.
- Benefit: Builds trust and speeds up iteration on both sides.
Symptom 3: “Everyone is a Designer”
Diagnosis: Stakeholders, PMs, and even engineers weigh in on button colors and layout tweaks. Feedback becomes subjective: “Make it pop” or “I liked the old version better.”
Example: A senior stakeholder insists the dashboard table should be “denser” because “more data looks smarter,” ignoring user feedback about readability.
Prescription:
- Ground discussions in data. User insights > opinions.
- Benefit: Removes opinion wars and drives objective decisions.
- Build trust through transparency. Share your design rationale and testing outcomes.
- Benefit: Stakeholders align faster when they understand design choices.
- Create structured feedback rituals. Not every review needs 10 voices — define who decides.
- Benefit: Reduces noise and speeds up approvals.
Symptom 4: UX Debt Keeps Piling Up
Diagnosis: You keep patching features on top of existing ones without revisiting the foundation. Old patterns coexist with new ones, and technical debt slowly turns into UX debt.
Example: Each sprint introduces a new variant of the same dropdown — slightly different logic, slightly different look. Months later, maintaining consistency becomes impossible.
Prescription:
- Treat UX debt like tech debt. Track it, prioritize it, and pay it off regularly.
- Benefit: Prevents small issues from becoming system-wide inconsistencies.
- Refactor design, not just code. Schedule design cleanup cycles.
- Benefit: Keeps the experience clean, scalable, and maintainable.
- Create a “sunset plan.” Retire old components when new ones replace them.
- Benefit: Simplifies the ecosystem and makes component adoption smoother.
Symptom 5: Design Decisions Don’t Scale
Diagnosis: Your design works great for one product, but the moment another team adopts it, it breaks. Each implementation needs tweaks, exceptions, and one-off fixes.
Example: A reporting module built for one region doesn’t adapt when rolled out globally — terminology, data density, and layouts all need rework.
Prescription:
- Design for flexibility, not perfection. Anticipate variations early.
- Benefit: Reduces future redesign work and improves reuse.
- Document intent, not just visuals. Developers and other designers should know why something works.
- Benefit: Helps teams apply designs correctly even in new contexts.
- Pilot before scaling. Test across teams, devices, and contexts before rolling out universally.
- Benefit: Identifies breakpoints before full rollout, saving cycles.
Symptom 6: The Dev Team Needs Too Much Hand-Holding (Have You Hired Rookies?)
Diagnosis: You find yourself constantly clarifying specs, redlining pixels, and explaining basic design principles. Development slows down because the team needs constant guidance instead of interpreting design intent.
Example: You deliver a simple modal design, and a developer pings you five times asking about padding, font size, hover states, and spacing — all clearly defined in the design system.
Underlying cause:
- Lack of design literacy among developers.
- Weak onboarding to the design system.
- No shared understanding of design intent and rationale.
Prescription:
- Educate, don’t just hand off. Run short design system walkthroughs for new devs.
- Benefit: Empowers developers to make confident design-aligned decisions.
- Document interaction intent, not just visuals. “How it should feel” matters as much as how it looks.
- Benefit: Minimizes clarification cycles and reduces design churn.
- Encourage autonomy through clarity. Build trust by giving devs context — not step-by-step supervision.
- Benefit: Developers move faster with fewer blockers.
- Pair design reviews with code reviews. Collaboration fosters learning on both sides.
- Benefit: Reinforces good habits and builds shared ownership.
Symptom 7: The Team Measures Output, Not Outcomes
Diagnosis: You’re shipping features at lightning speed — but no one’s sure if they actually improve the user experience.
Example: The team proudly releases a new dashboard filter system, but users still export data to Excel to get their real work done.
Prescription:
- Shift success metrics. Focus on adoption, task completion, satisfaction.
- Benefit: Ensures you’re designing features that truly matter to users.
- Loop in analytics. Track how real users behave after each release.
- Benefit: Turns user behavior into actionable design decisions.
- Celebrate impact, not volume. Fewer features, better experiences.
- Benefit: Teams stay focused on meaningful outcomes, not feature churn.
Final Thoughts
Design and development aren’t separate functions — they’re two halves of a single craft. When teams align on purpose, process, and principles, design systems thrive, delivery accelerates, and users actually feel the difference.
In short: don’t just fix pixels. Fix the connection between why you design and how you build.