📝 Solving Performance Problems by Rethinking the User Interface

March 15, 2025

By Ted Steinmann

📝 Solving Performance Problems by Rethinking the User Interface

Performance issues rarely show up at convenient times. Ours surfaced during license renewal season—the most critical period of the year for our platform. What started as database strain quickly became downtime risk, customer frustration, and operational pressure across engineering, support, and product.

This post walks through how we addressed systemic performance issues not just by looking at the database, but by rethinking the user interface, leveraging analytics, and anticipating user intent.

🛠️ The Problem: A Critical Page Under Constant Strain

In our License Management system, the Application List page is the heart of the product. It’s where users go to renew licenses, submit updates, and manage compliance-critical workflows.

Analytics confirmed what support and customers were already telling us:

  • The Application List page was the most visited page in the system
  • Nearly 60% of all applications were license renewals
  • A large portion of administrative users repeatedly submitted the same application types, such as roster updates

From a technical standpoint, the page was expensive to load:

  • Complex database queries determined which applications a user was allowed to see
  • Visibility rules varied by role, license type, employment status, and jurisdiction
  • Refactoring the underlying queries would require significant risk and time

During peak renewal season, this combination led to slow load times and outages at the exact moment users needed the system most.

🧩 The Obvious (and Bleak) Path: Query Refactoring

The first instinct was predictable:

“We need to fix the queries.”

We did identify problematic queries and inefficiencies, but the deeper we went, the clearer it became:

  • The logic wasn’t wrong—it was inherently complex
  • Refactoring risked breaking compliance rules and edge cases
  • Even a successful refactor wouldn’t eliminate the cost of evaluating everything on every visit

This wasn’t just a database problem. It was a workflow problem.

💡 The Insight: Most Users Already Know What They’re Here to Do

Instead of asking, “How do we load this page faster?”
We asked, “Why are users coming here in the first place?”

The data was clear:

  • Most users weren’t browsing applications
  • They were renewing a license they’d renewed before
  • Or finishing an application they’d already started
  • Or submitting the same administrative application they submit every cycle

We were paying a heavy computational tax to show users a full list—when in most cases, they only needed one next action.

🎯 The Solution: Adding a Step to Remove Cost

We introduced a “Suggested Applications” intermediary page that appears before the full Application List.

This went against a common UX instinct to always remove steps—but in this case, adding a step allowed us to reduce work, not increase it.

Instead of immediately evaluating every possible application and visibility rule, we:

  • Anticipated the user’s most likely intent
  • Directed them to a relevant next action
  • Deferred expensive processing unless it was truly needed

📝 How Suggested Applications Work

When a user clicks into Applications, the system evaluates in order:

  1. Do they have any in-progress applications?
    If yes, direct them there immediately.

  2. Have they previously submitted applications?

    • If only one → suggest that application (often a renewal)
    • If multiple → suggest the most frequently used application

Only if none of these conditions apply does the user proceed to the full Application List.

This approach allowed us to:

  • Short-circuit the most expensive logic paths
  • Reduce database load during peak traffic
  • Improve perceived performance by getting users to their goal faster

🚀 Why This Worked

This wasn’t just a UI change—it was a system optimization through product thinking.

Key principles that made it successful:

  • Analytics-informed decisions: We let usage data drive the workflow
  • Intent over completeness: Optimize for what users do, not what could be shown
  • Progressive disclosure: Only compute what’s necessary, when it’s necessary
  • UX as a performance lever: Interface design can meaningfully reduce backend cost

We didn’t eliminate the complex rules—but we dramatically reduced how often we had to run them.

📈 The Bigger Lesson

Performance problems aren’t always solved at the database layer. Sometimes the most effective fix is stepping back and asking:

“What work are we doing that users don’t actually need us to do?”

By aligning system behavior with user intent, we improved:

  • Platform stability during peak renewal season
  • Time-to-task for our most common workflows
  • Confidence across engineering, support, and customers

For me, this project reinforced that product management sits at the intersection of user experience, system design, and operational reality—and that meaningful performance gains often come from understanding people, not just technology.

Categories: blog

Tags: product-management, technology, data