Complex applications — like those used in specialized domains such as healthcare, finance, or logistics — support nonlinear workflows, expert users, and high-stakes decisions. Designing them introduces new challenges for conventional UX methods, which remain valuable but often require thoughtful adaptation. Effective UX in complex domains depends on subtle, deliberate adjustments throughout the design process.
The Design Lifecycle: A Quick Overview
The design-thinking process organizes product work into three high-level phases. Though these stages are cyclical and often overlapping, they provide a helpful structure for understanding where and how to adapt UX for complex applications:
- Understand: Investigate the problem space. Empathize with users, observe their environment, and define their needs within context.
- Explore: Generate ideas and translate them into early solutions. Brainstorm potential approaches and prototype quickly to test assumptions.
- Materialize: Refine and implement the best ideas. Test with users, iterate based on feedback, and guide the solution into real-world use.
This article examines each phase through the lens of complex systems and specialized domains, offering practical strategies and examples to help teams design usable, resilient tools in high-stakes environments.
Understand Phase: Researching the Work, Not Just the User
In this first phase, we aim to empathize with users and define their needs. That goal becomes more complex when users are experts working within layered systems — where their decisions are shaped not only by personal goals but by institutional policies, specialized tools, and domain-specific reasoning. One of the central challenges is developing a deep understanding of the domain itself, not just the people in it.
Many UX practitioners are trained to study users’ goals and behaviors, but in specialized domains, those behaviors are shaped by layers of jargon, constraints, and institutional logic. These factors, combined with limited access to expert users in regulated or high-pressure environments, make it difficult to form a complete picture through conventional research alone. A richer understanding of the work itself is required, which requires time, contextual immersion, and partnerships.
Understand Phase: Strategies and Examples
1. Study the domain independent of the application or tasks.
Before investigating how users interact with a particular system, step back and understand the broader domain in which that system operates. In complex environments, tools don’t exist in isolation. They support nuanced, often recursive decision making that’s deeply embedded in professional practice. Getting a handle on the goals, terminology, roles, and constraints of the domain creates a foundation for meaningful insights.
For example, a practitioner designing software for hospital staff could incorporate discovery research centered on learning about hospital operations, clinical workflows, and medical protocols, before designing any specific features or flows. This might include shadowing nurses or attending clinical team meetings to understand how care decisions are made, what documentation is prioritized, and how people navigate institutional rules.
2. Conduct studies in the work environment.
Understanding how users interact with a tool in isolation can leave important contextual gaps. Real-world conditions — such as environmental constraints, interruptions, shared equipment, or cross-team coordination — shape how systems are actually used. Observing work in its natural setting reveals these contextual factors and uncovers design considerations that might otherwise go unnoticed.
For example, a practitioner designing a warehouse-management system could observe operations during active shifts to understand how workers move through space, operate handheld devices on the go, and coordinate across teams in loud, fast-paced environments. These details may directly influence design choices such as interface layout, notification timing, or visibility in variable lighting, that are difficult to anticipate from lab-based testing.
3. Combine multiple methods and involve additional key actors.
In complex systems, no single person has the full picture. Effective research in these domains requires triangulating insight across methods (e.g., interviews, workflow mapping, observations) and roles (e.g., frontline users, supervisors, adjacent teams). This approach reveals not only how individuals interact with a system but also how work moves across people, tools, and organizational boundaries.
For example, a designer working on a logistics platform might interview drivers to uncover field-level challenges and survey dispatchers to understand coordination workflows. They might also run a journey-mapping workshop with operations managers to visualize systemic pain points. Each role contributes a distinct view, and layering these perspectives helps uncover insights that might otherwise remain hidden.
Explore Phase: Generating and Prototyping Ideas Within Constraints
In the Explore phase, we begin to generate and shape design ideas. But for UX practitioners working on complex applications, this creative process can be unusually constrained. Unlike consumer-facing tools, complex systems often require compliance and deep integration with additional tools and domain-specific workflows.
This makes ideation more difficult: Teams may hesitate to think broadly for fear of proposing something infeasible or unsafe. Prototyping is also more difficult: it’s rarely possible to simulate a real environment or build interactive models of full data-rich systems on a short timeline. And aligning stakeholders — especially when domain experts, product owners, and designers speak different languages — requires extra nuance.
Strategies and Examples
1. Frame ideation with real-world constraints.
Creative thinking is still critical in complex domains, but it thrives best when grounded in reality. Instead of treating constraints as obstacles, bring them into the ideation process as generative boundaries. Explicitly define what makes a solution viable (e.g., regulatory considerations, workflow integration, risk tolerance, and data needs) so teams can focus their creativity in the right direction.
For example, a team designing a clinical decision-support tool might begin a design workshop by outlining key constraints drawn from medical guidelines, patient-privacy regulations, and documentation workflows. Framing the session this way helps generate ideas that are both creative and feasible, such as ways to surface critical alerts without causing alarm fatigue or to visualize diagnostic options without overwhelming the interface.
2. Prototype at the right level of fidelity.
High-fidelity prototypes are often impractical during early concepting in complex systems. Instead, choose prototype forms that help answer your current questions without overcommitting to pixel-perfect designs. Sketches, storyboards, and clickable wireframes can be just as effective (or more so) for testing early assumptions.
For example, when designing a dashboard for cybersecurity analysts, it may not be feasible to prototype live-data interactions early in the process. Instead, low-fidelity mockups can be used to simulate alert-escalation paths or triage workflows, allowing domain experts to walk through hypothetical scenarios. This approach helps refine how system signals are interpreted and how decisions are made without requiring a fully functional product or prototype.
3. Cocreate with domain experts.
Bring domain experts into the design process. Domain experts can evaluate early ideas, spot gaps in logic, and validate whether proposed solutions support real tasks. Cocreation builds mutual understanding and helps ensure that your designs support the actual complexities of the work.
For example, during the redesign of a supply-chain analytics tool, a team might hold a collaborative sketching session with a senior planner. The planner could be asked to diagram their current process, highlight points of friction, and respond to early design concepts. Their feedback might reveal, for instance, that a minor tweak to a data visualization could significantly reduce decision time.
Materialize Phase: Testing and Refining in the Real World
In the Materialize phase, we test our designs and begin implementation. But for complex applications, this step often reveals a gap between how we evaluate usability in theory and how systems are used in practice.
One key challenge is recognizing domain-specific usability issues. Subtleties in how expert users interact with a system can be difficult to recognize without deep domain knowledge, even when issues appear during testing. Compounding this, traditional evaluation methods (like task-based usability testing) weren’t built for the complex, highly variable, cognitively demanding work of expert users. It can be difficult to both observe and understand the work.
Finally, recruiting expert users for testing is a consistent barrier, as these users are often in high-demand roles and have limited availability.
Strategies and Examples
1. Adapt existing evaluation methods.
Methods like task-based usability testing are still valuable, but they may need small adaptations. In complex domains, evaluations may benefit from methods that uncover reasoning and judgment, such as enhanced discussion between the researcher and user, scenario-based interviews, or longer contextual-observation sessions. The goal is to assess not just usability but usefulness and alignment with domain expectations.
For example, a team working on a financial-risk-analysis tool might present users with a real-world scenario — such as evaluating a high-risk loan or responding to market volatility — and ask them to walk through how they would interpret and act on the data presented. Rather than focusing on whether users complete a task correctly, the team observes how the users reason through the decision, what cues they rely on, and whether the interface supports that thinking. This approach can uncover mismatches between the system’s structure and how domain experts actually make decisions.
2. Elicit domain expertise through collaboration.
Practitioners don’t need to become domain experts, but they do need partners bringing domain expertise into the process. Expert users and domain partners can collaborate in cocreation and evaluation, helping interpret edge cases, flag unseen risks, or point out opportunities. This doesn't always mean formal testing; it could involve review sessions, workshops, or informal feedback loops.
For example, when testing a scientific modeling interface, the team might invite a principal investigator to review how workflows are represented in the prototype. They may highlight crucial steps that are underrepresented or point out how their team’s mental models differ from what the UI assumes. Even short conversations with domain experts can prevent flawed assumptions from reaching production.
3. Break traditional testing rules when necessary.
When recruiting expert users is difficult, be pragmatic. While standard usability guidance cautions against testing with internal staff or people who are overly knowledgeable about the system, these participants can provide valuable early-stage input, so long as their limitations are acknowledged and their feedback is later validated with actual end users when possible.
For example, when building a command-line interface for DevOps engineers, a team might begin testing with internal technical staff who share relevant experience. Alternatively, a training session can double as an opportunity for structured feedback. These approaches may not offer perfect fidelity, but they can reveal foundational issues and opportunities for iteration.
Conclusion
Working on complex applications doesn’t require inventing a new UX process; it just requires refining the one you already have. Across all phases of the design lifecycle, the most effective teams adapt familiar methods to suit the realities of their domain by:
- Grounding research in real-world work
- Generating and shaping ideas within meaningful constraints
- Tailoring evaluation methods to reveal expert needs and reasoning
Small but strategic shifts can help practitioners create usable, valuable, and trusted tools in even the most demanding environments.
