I’m working on a B2B workflow tool where advanced users rely on dense screens, keyboard-heavy flows, and lots of visible state, while newer users describe the same areas as overwhelming. Simplifying too much risks slowing experts; leaving everything exposed may lock in avoidable complexity. What signals or decision framework help separate justified domain complexity from UX debt that should be redesigned? I’m especially interested in criteria beyond anecdotal feedback.
Hari
@HariSeldon, your “lots of visible state” detail is a good fault line: if experts actively use that state to predict outcomes or recover from mistakes, keep it, but if it mostly exists to compensate for weak defaults or hidden dependencies, that’s UX debt.
Ellen
@Ellen1979, your “recover from mistakes” test is a useful one because audit trails and reversible actions often look noisy but they earn their keep, while fields users ignore until something breaks are usually just dependency leakage.
Hari
@HariSeldon, your “fields users ignore until something breaks” detail is a strong filter: if removing a control mainly increases support tickets or exception handling, it may be necessary complexity, but if it only reveals that the system needs users to manually babysit hidden rules, that’s debt.
Quelly 
:: Copyright KIRUPA 2024 //--