Most design conversations begin with a request for simplicity. Make it cleaner, easier to use, and remove the friction. Most of the time, that’s exactly the right instinct. But every so often, a project arrives where simplicity isn’t available as a starting point, because the thing being designed is genuinely, structurally complex.
Some projects are shaped by regulated workflows, multi-stakeholder platforms, or systems built up over years of operational, technical, and compliance requirements. In those cases, complexity is a part of the reality that the product must support. This is particularly true in enterprise software, B2B SaaS platforms, and other digital products centred on business requirements rather than consumer convenience. So, when simplicity isn’t an option, the design approach needs to adapt.
That was the premise behind a talk one of our designers gave recently at Unlock conference on Rab: when complexity is the brief, the job isn’t to hide it but to understand it well enough that it stops feeling complicated to the people who use it every day.
The constraints are the product
In regulated industries, especially those building compliance-heavy products and operational systems, this tension becomes impossible to ignore.
A fintech platform built around compliance checks, an insurance workflow involving multiple approvals, an industrial system coordinating operators, equipment, and safety protocols; these products can’t simply be streamlined into consumer-style simplicity, because their complexity exists for a reason.
The challenge is building something that lets users navigate that complexity confidently, without having to carry its full weight themselves. That’s where design becomes less about screens and more about understanding systems.
Complexity is rarely the enemy. More often, it’s evidence that a product is solving a real-world problem with real-world constraints.
Complexity can’t be simplified before it’s understood
Teams often rush toward solutions, sketching screens, discussing features, and debating layouts. In digital product design, that tendency can be expensive, particularly when product discovery has been compressed or skipped altogether. But in complex environments, the biggest design mistakes usually happen before a single interface is created, which is why understanding has to come first.
Research isn’t just about user expectations. It’s about regulations, operational realities, technical limitations, existing processes, and the points where they collide. User analysis brings another layer, because enterprise software rarely serves a single audience; different users often enter the same system with completely different goals, permissions, responsibilities, and pressures.
Then comes ideation, where assumptions are tested. Some constraints are non-negotiable; others persist because they’ve gone unquestioned and knowing the difference matters. Solving complexity is about both accommodating necessary constraints and questioning outdated ones.
Structure matters more than screens
One of the biggest misconceptions about digital product design is that the most important decisions happen during visual design. The same misconception often appears in UX for enterprise applications, in which stakeholders tend to focus on screens long before the underlying workflows have been validated. In reality, the critical decisions usually happen much earlier.
Concept design creates the first version of the solution that stakeholders may react to, not polished, but concrete enough to test direction before significant effort is invested. User flows then expose the system’s real complexity: what looks straightforward for one user may become impossible for another, and what looks efficient in isolation may create friction elsewhere in the workflow. Mapping those relationships is often where complexity gets either managed or multiplied.
Wireframes turn those decisions into structure. Without colours, animations, or visual polish, they reveal whether the underlying logic actually works, forcing attention onto the thing that matters most: helping users move through the system successfully. If the structure is wrong, no amount of visual refinement can fix it later.
| Stage | What we’re actually trying to understand |
| Research | Regulatory, operational and technical constraints |
| User Analysis | Different goals, permissions and responsibilities |
| Ideation | Which constraints are real and which are assumptions |
| Concept Design | Viable directions worth exploring |
| User Flows | How complexity moves through the system |
| Wireframes | Whether the structure actually works |
| Prototyping | How users behave in realistic scenarios |
| UI Design | How to reduce cognitive effort |
| Proof of Concept | Whether the solution is viable before investment |
Visual design isn’t where complexity gets solved
By the time UI design begins, most of the difficult decisions should already be made. The architecture exists, the flows have been tested, and the logic has been validated. Visual design still plays a crucial role, but its purpose is different here: to create clarity, establish hierarchy, and reduce cognitive effort, helping users understand where they are, what they can do next, and how the system responds to their actions.
Prototyping is what makes that reality visible. The moment people start interacting with something clickable, entirely new insights emerge: confusing pathways appear, assumptions get challenged, and opportunities for improvement become obvious. That’s why prototypes are often where confidence starts to build, not because they’re finished, but because they’re real enough to expose what static documents cannot.
Proof comes before confidence
Complex projects don’t involve just design risk, but also:
- business risk,
- technical risk,
- operational risk,
- and compliance risk.
That’s why proof of concept matters: it provides evidence before commitment, allowing teams to valida
te assumptions, test workflows, and identify issues while changes are still inexpensive. In highly regulated or operationally strict environments, that validation isn’t a luxury. It’s often the difference between a product that succeeds and one that struggles after launch.
Complexity is the material
None of these activities is unique to complex projects. What changes is how much weight they have to carry. In a simple product, a weak user flow might create a slightly frustrating experience; in a complex platform, the same mistake can break a workflow, create operational bottlenecks, or introduce compliance issues.
Whether you’re building enterprise software, operational systems, or compliance-heavy digital products, the intent remains the same: understand the complexity before attempting to simplify it.
The role of design is to understand complexity deeply enough to transform it into something usable. When done properly, complexity turns into the reason the product works, not a barrier.
FAQ
Not always. The goal is to make complexity understandable and manageable for the people using it.
Because user needs are only one part of the equation. Compliance requirements, operational processes, and technical restrictions all influence the final product.
A prototype tests usability and interaction. A proof of concept validates whether a solution is viable from a business, technical, or operational perspective.
By understanding workflows, user roles, permissions, and decision-making processes before visual design begins.
If you want to see this process play out on real projects, take a look at our case studies.
Complexity doesn’t disappear on its own. It gets understood, structured, tested, and refined until people can work with it confidently.
If you’re building a product shaped by regulation, operations, or multiple stakeholder groups, that’s where we can help.