The aggregate of all underpinning conceptual relationships of a user interface defines its structure. When UI structural designs are not properly engineered and monitored, structural debt follows. UI structural debt “represents the implied cost of structural inefficiency and additional rework caused by either a lack of expertise or choosing a simplified approach over a better approach to save time.” This article will discuss the importance of addressing UI structural debt, how it’s measured, and examples.

Why structural debt should not be ignored?

As structural debt accumulates, teams become less capable of focusing on growth and new features, implementing short-term solutions to longstanding, foundational issues.

Structural debt often causes a chain reaction that affects other departments. Gaps in conceptual alignment about a target domain–a precursor to structural debt–will affect system users, and the processes and people who perform design and technical development. It also impacts core business functions, such as operations, marketing & sales, and product development. The consequence is always lower efficiency, constant iteration, slower time-to-market, revenue impact, increased total cost of ownership, and impaired usability and user adoption. It exists in backlogs but never recognized, evaluated, and measured.

It is natural and healthy to incur structural debt. In some cases, intentionally incurring debt is acceptable. For example, a team might decide that it is worth incurring if a project needs to be completed quickly to meet a deadline or if a problem cannot be solved immediately. Teams must balance tradeoffs between quick decisions and high quality and account for these decisions when they are made.

What types of structural debt exist?

Structural debt is not always a bad thing. There are two types of structural debt:

• Planned. This is the result of taking shortcuts with an awareness of and accountability for the consequences. The debt remains visible to the team taking it on. The business actively chooses to forgo certain tasks and take debt on intentionally.
• Unplanned. Unplanned structural debt is when problems go unaccounted for and spiral into bigger problems that lead to poor usability and delays of desired outcomes. This is the result of taking shortcuts with less thought to the consequences. It becomes apparent when the consequences start to cascade an affect users and the working teams that manage the system.

Planned structural debt is useful–and in some cases necessary. Sometimes projects require a faster time to market that requires them to make the quick decision instead of the most optimized decision. For example, if a business wants to fast-track a certain technology or establish itself in a new market, it could be worth it to hurry a project along. The key to managing structural debt correctly is to measure it and establish accountability for the parts of the process that are intentionally skipped. This way, structural debt remains manageable and can be incorporated into a business’s overall plan.

What are causes and symptoms of unplanned structural debt?

Because the structural design of user interfaces is often distributed without a single owner, there are many case that can lead to structural debt:

• Lack of shared understanding. All UI components that are expressed in a user interface should trace to the parties that are attempting to communicate. If the exchange is misaligned, outcomes will be less predictable or beneficial for everyone involved.
• Unclear project requirements. If teams alter or redefine requirements well into the project, it can force them to go back into the code and rework it to include new components that conform to the new requirements.
• Bad structural design. 
• Limited proficiency. A lack of information architecture training can lead to poor structural design.
• Poor tools. Teams lack the ability to engineer UI structure leaving designs disconnected across multiple sources and applications.
• Lack of documentation. Missing or inaccurate documentation can make revisiting or updating the structural design difficult, as team members are required to reacquaint themselves with the underlying structural design.
• Poor technical insight. Ignoring information sources and technical naming conventions can complicate technical alignment.
• Lack of testing. Teams have little to no ability to measure the impact of structural changes that link to design and business decisions.
• Information silos. Information and data silos can cause teams to duplicate efforts or miscommunicate. This might occur when teams choose not to communicate if it slows them down.
• Prioritization constraints. Prioritizing business needs might put pressure on design teams to cut corners, resulting in structural debt.
• Ignoring governance. Letting legacy structural designs and components changes proceed without clear workflows that maintain a single source of truth and conceptual provenance.

In each of these examples, the structural debt is the list of problems that teams need to address so that the project functions as intended.

How to measure UI structural debt

With proper measurement, structural debt can be managed and used to inform design and business roadmaps with greater confidence in regards to business value. Measuring it is difficult. You must first understand how to assess structural durability. Fortunately, Methodbrain has developed proprietary software to assist with

One example is structural debt ratio (TDR). TDR is a way to estimate the future cost of structural debt. An ideal TDR is 5%.

Structural 

debt ratio compares the cost of a fix against the total cost of the project.

Other metrics include the following:

• defect ratios, or the number of new defects compared with old ones;
• code quality;
• completion time; and
• code reworking or refactoring.

To stay ahead of and remain accountable for structural  debt, teams need to track it through  change management.

One way to do this is by creating a structural debt registry. This is a document that lists all existing issues, explains the consequences that result from these issues, suggests resources to fix the problems and categorizes them by severity. As new problems arise and decisions are made, changes can be logged using a ticket or tracking system and prioritized in the registry. Some  project management tools include features to  improve code quality and manage backlog.

Examples of structural debt

One basic  example of structural  debt is the Southwest Airlines cancellation debacle of 2023. A massive storm system caused tens of thousands of flight cancellations during the 2022-23 holiday season. Although all airlines were affected, Southwest canceled a disproportionately large number of flights. Southwest was uniquely affected due to its outdated IT infrastructure — namely, its flight scheduling model and internal management system. For example, Southwest did not have an efficient way to communicate to crew members that they’d been reassigned and to shift them where they were needed most.

The airline had experienced problems with the system that resulted in smaller-scale meltdowns in the past, but never invested in improving its systems before the avalanche of cancellations in 2023. This is an example of a company forgoing needed structural maintenance, accruing debt and eventually having to repay it when an emergency happens. An update to Southwest’s 20-year-old routing system would have been costly, but it would have given the airline enough resilience to withstand the storm that caused the meltdown.

The real-life example from 2023 somewhat resembles a fictional example detailed in Gene Kim’s IT novel  The Phoenix Project. In the  book, IT manager Bill is tasked with saving the Phoenix Project — the implementation of a software suite that integrates retail and manufacturing at Bill’s company, Parts Unlimited. The project is already late and over budget when Bill is tasked with saving it. Bill saves the project by eliminating information silos and implementing better processes, but not before a failure due to structural debt that catches the public eye. The fictional software project misses a deadline by a wide margin due to a database conversion gone wrong, and the team is left resolving a series of problems with short-term fixes just to keep the whole operation from collapsing.

As one character puts it in the novel, “Left unchecked, structural debt will ensure the only work that gets done is unplanned work. When you spend all your time firefighting, there’s little time or energy left for planning. It’s the IT capacity death spiral.”