Want to make a great developer tool UI? Follow this fundamental rule!

Top-down flow

Tabs in IDEs, browsers, and many other applications exemplify top-down control flow. When the user switches a tab, it changes the entire content of the primary window. On desktop and web platforms, tabs are typically placed at the top of the UI.

This rule is widely followed and adhered to at all levels: you can find smaller tabs within panels in almost any professional app, from XCode to Figma; these tab bars are placed at the top and determine the panel’s content.

The rule is even followed at the micro level! For example, in the Play app, the selection in the Direction property hides and shows subsequent properties based on which ones are relevant.

Irina Nazarova CEO at Evil Martians

Schedule call

Left to right flow

Accessibility note: the following rule primarily makes sense for Western audiences—people who read and write from left to right. If you’re designing and developing for right-to-left cultures, you’ll likely need to adapt the horizontal flow in your UI!

Here’s a common example of left-to-right control flow: a navigation panel on the left and the content of the selected item in the main area to the right.

In VSCode, the user’s choice in the navigation panel determines the content that is displayed in the main area; if the user selects another file, its content will be shown.

The same pattern applies to various design editors in different contexts. If an element in the scene is selected, its properties are displayed in the Properties panel, usually on the right.

Similar to the top-down flow, the left-to-right flow also works in an inline context. For example, in query builder UIs, the leftmost selection in a condition line determines the subsequent UI elements.

In the video above, if the condition is “From,” a function selector is revealed (called “contains”) and an input field with an email address also appears. However, “contains” condition and the email field aren’t relevant for the “Data sent” condition, so it replaces the entire line with its own set of options instead. The same applies to “Account.”

To understand the importance of this ordering system, try to imagine using a UI where the main selection is on the right!

Combining flows

Now that we’ve outlined top-bottom and left-right flows, let’s discuss how both flows can be combined multiple times.

To illustrate, let’s dissect an example from XCode. Take a look at the following image, then check the description below.

Let’s move through the screenshot above:

• The micro-sized icon tab in the left panel determines the content the panel below it will display (1).
• The file navigator is selected, and the user’s choice in that navigation area determines the content that will be displayed in the primary area (2).
• From these selections, the tab bar determines which file’s content is actually shown in the main area (3).
• Finally, a combination of the selection within the ContentView (4) and the active tab (5) determines the properties displayed in the right panel.

Notice that the entire control flow proceeds step by step, top-down, and from left to right. This also leads up to another important point: the overall flow usually reflects the app’s internal hierarchy. XCode’s UI follows the project hierarchy: the files contain code, and objects in the code contain their properties.

What about the opposite flows?

For controls placed at the bottom and/or on the right, we usually expect them to transform or modify the content of the view—rather than changing it completely. For instance, XCode’s navigation area contains a field that filters the file tree. Here, the properties panels we mentioned earlier only changes properties for selected values but it doesn’t actually switch the content in the view.

Breaking the rules

Scientifically speaking, this all relates to the STEARC effect: the Spatial Temporal Association of Response Codes. This is a cognitive phenomenon where people associate temporal concepts, like the past and the future (or cause and effect), with spatial positions.

Simply put, people from cultures where readers interpret text from left-to-right expect logical flows and sequential steps (such as timelines or process flows) to be likewise be presented from left to right. When designing for right-to-left reading cultures, it’s important to reverse the horizontal flow to match their natural reading direction.

All of that said, this rule is not absolute. Managing screen real estate is challenging, especially when dealing with developer tools, so it’s acceptable if a UI occasionally breaks these rules. For instance, some IDEs have bottom file tabs, and that doesn’t bother anyone!

So, try to follow this principle—but don’t be afraid to break it if you have a good reason for doing so—and happy building!