Legacy Tech vs. Poor Design: Untangling UX Issues

1. The Two Types of Debt: Design vs. Technical

When you audit an existing product, you are primarily looking for "debt"—shortcuts and compromises made over time that now degrade the user experience. This debt comes in two main flavors.

In short:

• Design Debt: Inconsistencies in the UI, confusing flows, and outdated patterns that accumulate over time. These are often the result of shipping features quickly without a strong design system or consistent oversight. This is primarily a UX problem.
• Technical Debt: Compromises in the underlying code and architecture that make the product difficult to update. This is often invisible to the user until it manifests as slow performance, bugs, or an inability to implement new features. This is an engineering problem that creates UX consequences.

Your job as an auditor is to figure out which is which. A messy interface might be a simple case of design debt (easy to fix with a UI cleanup) or a symptom of deep technical debt (very hard to fix without significant engineering work).

2. Spotting the Signs of Legacy Tech Constraints

You don't need to be a developer to spot the warning signs of technical debt. You just need to know what to look for and what questions to ask. Legacy systems have a distinct "feel" and present common patterns of failure.

Based on this reading, here are the key signals to watch for during your audit:

• Fragile Architecture: You suggest moving a button, and the client's product manager looks terrified. You hear phrases like, "We can't touch that part of the code" or "That would take a month." This signals a brittle system where UI and business logic are tangled together.
• Outdated Frameworks: The UI looks and feels ancient (e.g., styles from the early 2010s, non-responsive layouts on a web app). This suggests the app is built on old technology that may not support modern UI patterns.
• Hidden Dependencies: A simple-looking feature (like a data export) is talked about with extreme caution. This often means it's connected to other systems in undocumented ways, and changing it could have unforeseen consequences.
• "Functional Anchors": Parts of the UI that the team insists cannot be changed. For example, a specific table layout might be required because an external system reads data from it in a fixed format.

Your Most Powerful Tactic:
The single most effective way to identify technical constraints is to talk to an engineer on the client's team. They know where the "bodies are buried." Ask direct questions:

• "Which part of the product are you most afraid to work on?"
• "If we wanted to change X, what would be the realistic level of effort?"
• "Are there any parts of the UI that are tied to critical backend logic?"

This conversation is non-negotiable for a high-value audit. It prevents you from making naive recommendations.

3. Your Deliverable: The Finding Classification Matrix

Now, let's create the tool to put this knowledge into practice. Instead of just listing UX problems, you will classify each one based on its implementation reality. This immediately demonstrates your strategic value to the client.

We will use the practical framework suggested in the Eleken article.

Task (30 minutes): Build the Matrix in Figma

1. Open your Figma Project: Navigate to the Sales Assets page you created in the last lesson. We're adding another core asset to your toolkit.
2. Create a New Frame: Title it Audit Finding Classification Matrix.
3. Build the Matrix Structure: Create a table with three main rows and four columns.
   • Rows (Issue Type):
     1. Safe to Fix (Pure Design Debt)
     2. Requires Backend (Moderate Tech Debt)
     3. Tied to Architecture (High Tech Debt)
   • Columns:
     1. Issue Type
     2. Description (What it is)
     3. Examples (What it looks like in a product)
     4. My Recommended Action (How you'll approach it)
4. Populate the Matrix: Fill in the Description and Examples columns based on the Eleken article and your own understanding. For the My Recommended Action column, define your strategic approach. See the example below for guidance.

Example of a completed matrix row in Figma:

This matrix is now a part of your audit deliverable. When you present your findings, you won't just show a list of problems; you'll show a prioritized, technically-aware plan of action. This is how you transition from "designer" to "consultant."

Conclusion

You have now reached the end of this intensive course. By completing this final lesson, you've acquired one of the most crucial skills for a six-figure consultant: technical pragmatism. You understand that not all UX problems are created equal and that credible recommendations must be grounded in reality.

Key Takeaways:

• Distinguish Debt: Your first job in an audit is to determine if a UX issue stems from design debt (easier to fix) or technical debt (harder to fix).
• Look for Red Flags: Learn to spot the signs of legacy systems—fragility, outdated UIs, and "functional anchors" that cannot be changed.
• Talk to Engineers: The fastest way to understand technical constraints is to ask the developers who live with them every day.
• Use the Classification Matrix: Your new Figma asset is a powerful tool for categorizing findings, managing client expectations, and making realistic, high-impact recommendations.

By mastering the tactics in this course—from financial analysis and client acquisition to crafting high-value reports and making technically-aware recommendations—you have built a complete toolkit. You are no longer just a designer; you are a business problem-solver, ready to deliver immense value and command the fees that reflect it. The path to your first $5k client is now clear.