Creating user interfaces for expert users, such as engineers or administrators, often requires additional principles on top of universal ones.

One reason is that, as a designer, your mindset is typically further removed from the end-user compared to your team’s other stakeholders, such as developers and product managers, who often have a background in engineering or other relevant industries. This can make articulating design decisions and convincing the rest of your team trickier since they are often either your potential users or industry experts.

Still, there are certain principles worth following to avoid overly complex and unintuitive interfaces. These principles can also help designers articulate and discuss their design decisions, ultimately swaying other stakeholders’ opinions.

New button is the last refuge of the incompetent

There are few things as tempting in user interface design as solving an issue by simply adding another ‘button’.

Particularly when dealing with a B2B web app’s continuous development.

However, a few sprints later, you may end up with an oversaturated user interface where a multitude of buttons and other UI elements compete for the user’s attention. While on paper everything looks fine — all use cases and user stories are met, and the user can complete the tasks — in reality, the user gets overwhelmed and lost.

To prevent this, it’s essential to first consider whether the design issue can be addressed by reusing existing functionality or solving a higher-level problem. In systemic design this is referred to as dissolving.

As an example, if an app has more than one settings page caused by a legacy, and the design task asks to fix it by adding buttons to navigate between them, it might be a good time to take a step back and merge settings into a single page.

Adding new buttons, features, settings, or any other controllers should be the last resort.

In a way, this is similar to the boiling frog metaphor, where if the water is heated slowly, the frog won’t notice and will eventually boil. Similarly, by adding additional buttons and UI elements as quick or easy fixes (focusing on details), one may not notice how the entire user interface becomes too complex for users until it’s too late.

Thus, the goal is to anticipate and mitigate the creation of an overly complex user interface. While some complexity may be inevitable over time due to the growing scope of the web app, whether from adding more features or merging with other apps, this complexity should never stem from minor UI fixes.

If a feature can be added, it doesn’t mean it should be

Similar to the previous UI principle, this concept is particularly relevant in the product design process when designing for other experts, especially engineers, who prefer more control and data density than average users.

It can be challenging for designers to argue against adding features, especially since they often bring some value to at least some users and might even be requested during individual customer calls. Moreover, if the feature is already developed, why hide it, right?

The key question to ask yourself and the rest of the stakeholders is:

Does the value this new feature brings outweigh the increase in complexity?

If the complexity is greater than the value, it is better to either make the feature less discoverable or refrain from adding it altogether.

In general, the best approach is to add new features only when there is clear evidence that users need them. Otherwise, it is better to keep them hidden to avoid confusing users or overwhelming them with too many options.

Additionally, this helps avoid adding both user interface and technological complexity that might hinder and slow down further product development.

Design user flows, not individual pages

It is very tempting to focus on designing a single page at a time with all the variety of use cases, features and states. Moreover, it is also easier to collaborate with other stakeholders, e.g. developers or product managers, by discussing a single page at a time.

However, users rarely interact with a “single page” with all its features and possibilities; instead, they navigate through a flow to accomplish a certain task. This task flow should correspond to a real-world experience, and the UI flow should follow that experience. The design hierarchy should be:

1. How would a user perform this task in the real world?

2. What should be the sequence of pages or UI elements to facilitate this task?

3. What exact content and its states should be on each page or UI element?

Bonus principle: Write the text and then halve it

A simple and common UI principle that makes the life of a web or design team without a copywriter easier is. When writing a copy for a page or UI component, first write it as you understand it, and then make it half as long.

People don’t read long texts in web interfaces; they scan them. The goal is not to let them enjoy the beauty and literary correctness, but to convey the message.

Therefore, the shorter and more concise the text is, the more likely people are to read it through, hence get the message.

This principle, doesn’t always apply to documentation and knowledge base.

More common UI principles, rules and guidelines

• Nielsen and Molich’s Ten User Interface Design Guidelines
• The Eight Golden Rules of Interface Design

Other UI principles for B2B web apps was originally published in UX Planet on Medium, where people are continuing the conversation by highlighting and responding to this story.