In our previous article, we introduced six types of UX complexity that can make a SaaS product harder to use: Feature, Workflow, Navigation, Information, Interaction, and Product Structure Complexity. But identifying these categories is only the starting point. When a real UX problem appears, the harder question is: which type of complexity is actually causing it?
A real symptom rarely announces its root cause. “Users keep asking support the same question” doesn’t tell you whether they can’t find the setting, don’t understand what happened after an action, or are struggling with too many competing options. Several complexity types can produce the same symptom.
This article focuses on that next step: how to move from an ambiguous UX symptom to a specific, validated complexity type using a practical sequence — Symptom → Evidence → Investigation → Root Cause → Validation → Action.
The Chain as an Investigation Tool
The chain only earns its keep if each evidence source is used to rule things in or out, not just to confirm whatever you already suspected.
In practice, that means treating the first piece of evidence as a hypothesis generator and the second as a check on that hypothesis. Ideally, the second source should be capable of disagreeing with the first.
The three cases below are constructed from patterns common across SaaS products — not client data, since no verified YesOrYes project findings are referenced here — but each is deliberately realistic enough to show the reasoning in full.
Case One: A Bulk-Action Feature Nobody Uses
Symptom: A team ships a bulk-edit capability — updating dozens of records at once instead of one at a time. Adoption analytics show almost nobody uses it three months after launch.
First-pass hypothesis: The instinct is Feature Complexity. Maybe the bulk-edit controls are one option among too many, competing for attention with everything else on the screen, and users simply never register that it exists.
Evidence gathering: Analytics confirm the location of the problem — the feature’s entry point has near-zero click-through, consistent with something invisible in a crowded interface.
That’s consistent with the first-pass hypothesis.
But a second, independent source — five short user conversations plus a look at the navigation path users actually take when they need to make multiple edits — tells a different story.
Users aren’t failing to notice the bulk-edit control. They’re not navigating to the screen it lives on at all.
The feature was added to a settings-adjacent view, while the mental model users have for “edit several things at once” points them toward the main records list, where they’ve always worked one at a time.
Investigation: This is the moment the hypothesis has to be allowed to change.
Low click-through on a control isn’t only explained by clutter. It’s equally explained by the control living somewhere users don’t go for that task.
The qualitative evidence specifically favors the second explanation: users aren’t overwhelmed once they arrive. They never arrive.
Root cause: Navigation Complexity — the structure doesn’t match where users expect this capability to live, not a clutter problem on the screen itself.
Validation: Before committing to relocating the feature, the team runs a quick first-click test.
Given the task, “edit multiple records at once,” where do users click first?
If the majority click toward the main records list rather than the settings-adjacent area where the feature actually lives, that’s independent confirmation — a different method, same conclusion.
Action: The fix isn’t decluttering the existing screen, which would have been the fix under the Feature Complexity theory.
It’s relocating the entry point to where users’ existing mental model already points — a navigation and information-architecture change, not simply a visual simplification.
Case Two: “It Didn’t Work” Tickets on a Routine Action
Symptom: Support sees a recurring ticket type: users report that a routine action — archiving a completed item — “isn’t working,” even though backend logs confirm the action succeeded every time.
First-pass hypothesis: This looks like Interaction Complexity.
Probably missing system feedback. The action completes, but nothing on screen confirms it, so users assume failure and try again, sometimes generating duplicate actions in the process.
Evidence gathering: Session recordings support this reading almost completely.
Users click archive, see no visible change, wait a moment, then click again, sometimes a third time, before giving up and contacting support.
On its own, that’s a strong case for Interaction Complexity. It would be reasonable to stop here and ship a confirmation toast or a visible state change.
But there’s another question worth asking:
Why does archiving specifically lack feedback when other actions in the product don’t?
Investigation: A quick look at how “archived” is represented in the product’s data model reveals the deeper issue.
Archived items aren’t visually distinguished from active ones anywhere in the interface because, structurally, the product never built a separate visual state for that status.
It isn’t that the confirmation was forgotten on one screen.
The concept of “archived” was never given a clear place in the product’s information model, so no screen shows it — not the list, not the detail view, nowhere.
Root cause: This starts as Interaction Complexity, but the deeper cause is Product Structure Complexity.
The underlying object model doesn’t have a well-defined representation for “archived,” so no amount of screen-level feedback fully resolves the problem. There is no stable state for the interface to reflect back to the user.
Validation: The team checks whether the same absence of visual state appears anywhere archived items are referenced — in search results, exports, and related records.
It does.
That confirms this isn’t a one-screen oversight but a structural gap running through the product.
Action: A confirmation toast can be added as an immediate, low-cost interim fix.
But the team should also scope a larger piece of work: defining “archived” as a first-class, visually consistent state across every surface that shows the object.
The first fix addresses the ticket.
The second addresses the cause.
Case Three: When Two Hypotheses Genuinely Tie
Not every investigation resolves cleanly, and it’s worth showing what happens when it doesn’t.
Symptom:A configuration step in onboarding has a significant drop-off rate, and it has remained stable for two quarters.
Analytics show users spend a long time on the step before abandoning.
That creates two plausible explanations.
Hypothesis A — Information Complexity: The step presents too many configuration options at once, without enough hierarchy, so users stall while trying to evaluate everything.
Hypothesis B — Workflow Complexity: The step requires information the user doesn’t have yet at this point in their setup. For example, details that a colleague needs to provide.
In that case, the pause isn’t necessarily confusion. It could be a genuine blocker.
Both explanations fit the same analytics pattern.
This is exactly where teams often choose whichever hypothesis matches their existing assumption and move forward — usually the one that suggests a smaller design change.
Validation as the tiebreaker: Instead of choosing, the team checks something the initial analytics can’t show:
Of the users who abandon at this step, how many return later and complete it, versus how many never come back?
If most abandoners return within a few days and complete the step once they have what they need, that supports the Workflow Complexity explanation.
The pause is about missing input rather than overwhelming choice.
If most never return, Information Complexity becomes the stronger explanation, because an external blocker would more often result in delayed completion rather than permanent abandonment.
In this case, the return-rate data shows the majority coming back within a week — supporting Workflow Complexity.
Action: Instead of simplifying the options on the step, the team restructures the workflow.
Users should be able to complete the parts they can finish immediately and defer the parts requiring outside input, rather than blocking all progress on a single all-or-nothing step.
What Changes Once You Know the Type
The three cases share a pattern worth naming directly:
The symptom underdetermined the answer.
The complexity type teams would have guessed first wasn’t necessarily the type that held up after investigation.
This is where the six types become operationally useful, not just descriptive.
Feature and Information Complexity may call for prioritization and hierarchy work.
Navigation Complexity may require structural but bounded changes — reorganizing rather than rebuilding.
Interaction Complexity can often be addressed with focused interface changes once correctly identified.
Workflow Complexity usually means redesigning a sequence rather than a single screen.
Product Structure Complexity can be much larger than the original support ticket suggests because the problem isn’t sitting on one screen. It’s sitting underneath several of them.
Knowing which type you’re facing doesn’t just tell you what to build.
It tells you how much to commit before you’ve validated that you’re building the right thing.
That’s the difference between an audit that changes an outcome and a redesign that simply repeats the same guess with better visuals.
Closing
Blog 1 gave you six ways to name what’s making your product harder to use.
The harder, more valuable skill is investigating a real, messy symptom until you can say — with evidence rather than intuition — which one you’re actually looking at, and how confident you are in that answer before committing engineering time to it.
If your team is sitting on a symptom right now and has more than one plausible explanation for what’s causing it, that disagreement is useful information.
It means the problem needs investigation before intervention.
Request a UX Audit with YesOrYes and get a validated diagnosis instead of another opinion.