Justifying design decisions: A case study with tabs

How can designers effectively reach design decisions and provide logical justifications for them?

At ownpath, we nudge our students to pick specific problems, through which we help them get better at design. In a recent mentoring session, Vineesh, one of my students, shared a specific design choice he made and inquired about the methods to rationalize it.

Consider the following options.

Premise

The "Network" list is initially divided into three tabs as a default grouping. The specific tab that is selected by default depends on the particular use case. To refine the network list even further, users have the option to utilize the Search functionality. In most scenarios, the selector component should be presented as an overlay. However, there may be specific use cases where it is displayed inline or in a modal. It's important to note that this interface is designed for larger screens and doesn't require adaptation for smaller screens.

Now that we’re acquainted with the necessary background, we can now begin to explore further by asking questions. Which approach or solution is more effective, and in what specific context does it excel?

Both our interfaces contain the following identical elements:

1. Controls:

• Tabs to navigate through high-level groups for the data-tables
• Filter
• Search bar

2. Data Tables

a. Tabs on top

Of the two interfaces, the tabs on top work very well for the following scenarios:

• The number of tabs remains within a permissible limit. So, they are visible within the window without overflowing. However, it’s important to consider when the number grows. In that case, the designer has to figure out a way to prioritize some tabs and keep the other tabs easily accessible.
• Having the tabs on top gives the interface a single-column structure, which can be optimized for a variety of screen sizes relatively easily.
• The "Controls" are visually grouped together creating two clear distinct areas for "Controls" and "Data". It creates a nested relationship between the `tabs` and `filters + search`, without splitting the hierarchy into Primary and Secondary controls. However, the designer needs to create a better differentiation between different levels of controls and data.
• Users might find it easy to make changes in the controls and see the data change right below.
• Now, let’s look at the other option.

​

b. Tabs on the left

In this version, the designer has clearly established two sections to separate Controls and Data. The separation extends further by splitting the controls into tabs (primary), filters and search (secondary).

Some observations:

• On the positive side, the list of tabs here can increase to a fairly large number without requiring an immediate change in the interface.
• However, the two-column structure will need to be designed separately for smaller screen sizes.
• The Controls are split into two parts; the left panel and the right panel. Since there are few tabs and yet occupy significant space, they assume the more primary role in the hierarchy between the two types of Control groups.
• So, the designer will need to create a visual style to establish an association or lack thereof between these two groups. For example, does changing tabs on the left panel also change the values available in the filters? If yes, the visual association will have to be made clear.

These are just a few important points to consider, to establish a clear context in which design decisions can be made.  It becomes evident that architectural and interface design choices extend beyond a mere comparison between options A and B. As designers, our responsibility is to delve deeper and develop a solid rationale that enables us to make more informed decisions.

If you’re a designer, you can join our Product Design Fellowship. The next cohort begins soon!

For regular updates, please follow us on Twitter, Instagram, and LinkedIn.

‍