Justifying design decisions: A case study with tabs

As designers, how do we arrive at design decisions and rationally justify them?

On ownpath, we nudge our students to pick specific problems, through which we help them get better at design. During one of our mentoring sessions, Vineesh, a student of mine, presented a specific design choice he made and asked how he could justify it.

Consider the following options.

Premise

• The *Network* list is grouped by default into three tabs.
• The default selection of the tab depends on the use case.
• *Search* is available to further narrow down the list of networks.
• The selector component should be displayed in an overlay for most cases.
• It is also expected that the component could be displayed inline or in a modal for certain use cases.
• This interface is used on large screens and does not need to be adapted to smaller screens.

Now that we’re acquainted with the necessary background, we can start asking some questions to probe further. What works better and in what context?

Both our interfaces contain the following same elements:

1. Controls:

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

1. Data Tables

Let’s look at the two options closely.

a. Tabs on top

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

• The number of tabs remain 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 in 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. As you can see, the architectural and interface design decisions, go beyond a simple comparison between choice A and choice B. As designers, our job entails going deeper and coming up with a clear rationale that helps us arrive at more informed decisions.

For regular updates, please follow us on [Twitter](https://twitter.com/ownpathxyz), Instagram, and LinkedIn._

‍