Introduction
A climate modelling dashboard, an energy management platform, an ESG vendor-sourcing tool like Vested Futures — these products carry real weight. They support decisions with financial and environmental consequences. Yet the instinct to expose every filter, metric, and configuration option at once often makes them harder to use, not more powerful.
Simplifying complex UX doesn't mean deleting functionality. It means clarifying priorities, reducing unnecessary effort, and letting users learn the system progressively. Expert users shouldn't be treated like beginners, and beginners shouldn't be buried under options they don't yet need.
This guide covers five practical steps:
- Diagnosing why an application feels complex
- Designing for different expertise levels
- Structuring the design process itself
- Applying interface patterns that scale with depth
- Validating decisions under realistic conditions
Key Takeaways
- Reduce cognitive load, friction, and ambiguity — without stripping out domain depth
- Study the entire work system: roles, handoffs, risks, terminology, and real environments
- Combine progressive disclosure, strong defaults, and customisable views for mixed-skill audiences
- Test with realistic data and domain experts before calling a workflow finished
What Makes an Application Complex?
Complexity isn't about screen count or feature volume. A simple app can have dozens of screens; a genuinely complex one might have five, each loaded with nonlinear goals, specialised knowledge, and consequential decisions.
Nielsen Norman Group's five-layer framework offers a useful diagnostic lens:
| Layer | What it describes |
|---|---|
| Integrative | Interconnected or legacy systems feeding the application |
| Information | Large datasets requiring filtering, zooming, or modelling |
| Intention | Broad, variable goals instead of one fixed task |
| Environmental | The physical context where people actually use the tool |
| Institutional | Organisational norms, roles, and power dynamics |
According to NN/g's complex-application framework, these layers often combine, and their example — a GIS tool scientists use to predict sea-level rise — isn't far from the climate and deep-tech products we work on at What if Design.
These layers show up constantly in climate tech:
- Fragmented data sources from sensors and third-party APIs
- Technical models non-experts must interpret
- Regulatory thresholds
- Field conditions with patchy connectivity
- Cross-functional sign-offs before anything becomes official
A Single Workstream, Four Decisions
Consider a grid interconnection engineer reviewing a utility's capacity data. She has to interpret voltage fluctuation patterns, judge whether a proposed project exceeds a regulatory threshold, loop in a compliance officer for sign-off, and log the final decision with a timestamp and rationale for audit purposes.
Four decisions, one screen, zero room for ambiguity.
Design Principles for Simplifying Without Dumbing Down
Set a Complexity Budget
Before adding a control, label, or data point to the primary view, ask: does this specific user need this right now? If not, it doesn't disappear. It moves to a secondary layer, still reachable, just not competing for attention.
Design Around Intent, Not the Database
Group information by what users need to decide or do next, not by how your backend tables are structured. A field technician doesn't think in foreign keys; she thinks in "what's broken" and "what do I fix first."
Use Progressive Disclosure Deliberately
Show essential context up front. Reveal advanced filters, calculations, and configuration only when the user signals they need it, clearly labelled and never hidden behind guesswork. This protects both first-time users and specialists from unnecessary scanning.
Support Multiple Expertise Levels in One Product
- Strong, sensible defaults for occasional users
- Guided entry points for first-time workflows
- Shortcuts, bulk actions, and saved views for specialists
- Customisation that doesn't fork the product into two experiences
Preserve Trust While Cutting Friction
Research on construction-industry dashboards found that cognitive load during visual search varied significantly based on how information density interacted with a user's cognitive style, with field-independent users navigating dense layouts more efficiently than field-dependent ones.
The design implication is direct: don't assume one dense view serves everyone equally. Build in grouping, whitespace, and clear visual anchors so the same data supports multiple scanning strategies, rather than privileging whichever cognitive style happens to match your own.
A Practical UX Process for Complex Applications
Complex systems can't be designed from a single interview or a single stakeholder's mental model. The process has to match the system's layers.
- Start with domain and workflow discovery. Interview and observe different roles, map handoffs and exceptions, and document terminology exactly as the team uses it, not how a style guide wishes they would.
- Triangulate across participants. Frontline operators, analysts, managers, administrators, and technical stakeholders each hold a different slice of the picture. No single persona captures the full workflow.
- Align with technical constraints early. Review data models, integrations, performance limits, permissions, and regulatory requirements before a single screen gets drawn.
- Prototype the riskiest decisions first. Use storyboards and realistic data rather than polished mockups nobody has stress-tested.
- Work in short loops with engineering. Review components and edge cases continuously instead of a single handoff at the finish line.
This is the approach Tejas Mahajan, What if Design's UX lead, brings to platforms spanning battery management, fleet logistics, and ESG reporting. Every screen is treated as a business decision. Paired with rapid prototyping and turnaround times as fast as 48 hours, the process fits teams that can't afford a six-month discovery phase before shipping anything testable.
Interface Patterns That Preserve Depth and Usability
Orient Without Oversimplifying
Role-based entry points and task-oriented navigation let people find their lane quickly, without hiding what the application can actually do.
Useful patterns include:
- Home screens tuned to role (operator, analyst, admin)
- Task-first nav that mirrors real jobs, not org charts
- Progressive disclosure of advanced modules after the core path is clear
Make Data-Dense Views Navigable
Filtering, sorting, search, grouping, comparison, drill-down, and saved views all serve different moments:
- Filtering and search narrow a dataset to what's relevant right now
- Sorting surfaces priority or urgency
- Grouping clusters related records so patterns show up faster
- Comparison puts two or more records side by side without leaving the view
- Drill-down moves from summary to detail without losing context
- Saved views let returning users skip repetitive setup
Design Components, Not Just Screens
Every data table or form needs defined states. Skipping them is where polished demos fall apart in production:
- Loading
- Empty
- Partial data
- Error
- Permission-restricted
- Validation failure
Keep Expert Workflows Fast
Daily users need speed. New users still need a way in. Build for both:
- Keyboard navigation with visible cues, not hidden only in docs
- Bulk actions for repeat work across many records
- Reusable configurations that save setup between sessions
- Reversible actions so experts move fast without fear of irreversible mistakes
A Compact Before-and-After
We saw this while shaping an enterprise asset-management platform for a national health ministry. The early version listed every preventive and corrective maintenance task in one undifferentiated feed.
After restructuring:
- Preventive maintenance split into 45 new, 32 in-progress, 7 overdue, 9 needing reassignment
- Corrective maintenance shown separately as 15 new, 13 overdue
Nothing was removed. The underlying task data and controls stayed intact. They were organised around what a maintenance manager needed to triage first, instead of a flat chronological list.
Validate Usability Without Flattening Expert Workflows
Validation should prove the product still works for experts under real pressure—not that a simplified path scores well in a lab.
Test Judgement, Not Just Task Completion
Realistic scenarios ask users to interpret ambiguous information, recover from errors, switch context mid-task, and collaborate, not just click through a scripted happy path.
Evaluate in Context
Field operations, control rooms, shared workstations, and variable connectivity all change how an interface performs. A dashboard that tests beautifully in a quiet office can fail under glare on a tablet in the field.
Measure Both Ends of the Skill Spectrum
Choose metrics that match how the product is actually used:
- Time to a meaningful decision, not just first click
- Error recovery rate after a failed or partial action
- Adoption of advanced features by experienced users
- Recurring themes in support tickets and escalations
- Successful completion of high-risk or irreversible tasks
Treat Domain Experts as Partners, Not Oracles
Separate feedback about domain correctness from feedback about usability, policy, or personal preference. They're not the same thing, and conflating them leads to redesigns that satisfy one loud voice instead of the actual user base.
A documented case from UC Davis's Campus Energy Education Dashboard shows the cost of mixing those signals. Expert interviewees warned that a four-colour energy-intensity scale implied "green buildings are good, orange ones are bad," an oversimplification that ignored other performance factors. The team redesigned it so circle size encoded energy intensity while colour encoded building type instead.
A later comparison found the new map more enjoyable to use, but less accurately interpreted than a simple bar chart. Redesigns rarely erase every trade-off; they move you to a better one.
Build a Validation Loop That Doesn't End at Launch
Combine analytics, support themes, usability sessions, and accessibility checks on a recurring schedule. Complex applications accumulate new edge cases as workflows evolve — validation has to keep pace.
Frequently Asked Questions
What is UX for complex applications?
UX for complex applications serves specialised users working with nonlinear workflows, large or interconnected datasets, multiple roles, and high-stakes decisions. The goal is usable depth, not surface-level simplicity.
How do you simplify a complex application without removing important functionality?
Prioritise what each user needs in the moment, use progressive disclosure for advanced options, and set strong defaults. Keep expert controls accessible outside the primary path rather than deleting them.
What is progressive disclosure in UX design?
Show essential information first; reveal advanced filters or configuration only when needed. A reporting tool might default to summary metrics and keep custom calculations behind a labelled "Advanced" option.
How should designers work with expert users?
Through contextual research and genuine domain partnership, not just interviews. Test with realistic scenarios, and learn to separate an expert's stated preference from an actual, demonstrated user need.
Which UX patterns work well for data-heavy applications?
Filtering, sorting, search, drill-down, saved views, and strong defaults all help. Equally important: well-designed empty states, clear error messages, and visible data provenance.
How do you measure UX improvements in a complex application?
Track task success, error recovery, time to meaningful outcome, and expert efficiency alongside learnability for newcomers. Choose the measures that map to your product's actual goals, not a generic checklist.
