Complex systems are a separate genre of product design. The principles developed for mobile applications and landing pages do not work here. The user does not "come for five minutes" — they spend the entire working day in the system. They are not a beginner — they are a specialist who wants to work quickly. And they do not forgive the interface for condescending attitude towards their expertise.

At the same time, design errors in such systems repeat from project to project. Not because designers are incompetent, but because the complexity of this class of products is deceptive — it seems that if the function works, then the interface is "normal".

A classic trap: the team wants to make the system "understandable for everyone", and as a result makes it inconvenient for those who work with it every day.

The expert does not want to be led by the hand. They want to complete a task quickly — with a minimum of clicks, with clear navigation, and with access to advanced settings when needed. Simplifying the interface "for clarity" often means hiding the necessary tools behind additional steps.

Solution: design for the expert scenario as the main one, not as an exception. Onboarding and hints — not in the main flow, but next to it, available on request.

In analytical and operational systems, data is the main object of interaction. The interface does not just "display" data — it determines how the user perceives it, what they notice, and what decisions they make.

A common mistake: a table with 40 columns without prioritization, a dashboard where "everything is important", graphs without context — without a baseline, without historical comparison, without the ability to understand whether it's good or bad.

Data without an interpretive layer is raw numbers, not information. The designer is responsible for ensuring that the interface helps the user make a decision, not just provides data for it.

While working on a number of projects in the ROOT CODE ecosystem, we repeatedly encountered situations where the data was technically correct, but users systematically made incorrect conclusions — because the interface did not provide the necessary context. Adding benchmarks, trends, and annotations to key metrics radically changed the quality of working with the system.

Development teams often say: "Let's show this to the user — let them decide whether they need it or not." This sounds like respect for the user. In reality — it's shifting the designer's work onto the user.

Every element on the screen requires cognitive resources. When the screen is overloaded — the user spends time filtering out the excess before getting to what they need. In a workday, when the system is opened hundreds of times, this accumulates into noticeable fatigue.

A good interface is the result of editing, not addition. The decision of what not to show is as much a design decision as the decision of what to show.

Empty states, errors, long loading times, data conflicts, unconfirmed actions — these are not "rare cases". In complex systems with large amounts of data and teamwork, they happen constantly.

If an empty screen looks like a broken interface — the user thinks the system is not working. If the error message is written in the spirit of "Error 422" — the user does not know what to do next and calls support. If there is no confirmation of an irreversible action — sooner or later someone will delete what should not have been deleted.

Edge states are not details. They are part of the core user experience.

Often the design is approved without direct contact with real users. "We ourselves know how it should work" — a position that costs dearly after release.

Just a few sessions with 3–5 users before finalizing key screens is enough to identify critical misunderstandings. This is not a large study — it is a minimal hypothesis test before they are locked into code.

• Conduct an audit of "edge states" — go through each scenario and make sure the system correctly handles errors, empty data, and long waits

• Prioritize content by importance: what the user should notice first — this is a design decision, not a given

• Test with real users before, not after, finalizing the solution

• Ask not "what to show", but "what to remove" — complex system interfaces more often suffer from excess than from deficiency

Errors in complex systems rarely arise from incompetence. More often — from accumulated compromises, time pressure, and lack of systematic verification of solutions. The design of a complex product is a discipline, not a one-time project. It requires constant attention to details and a willingness to redo what "already works".