Curious to know more?

This project started due to the need to add a new table to an interface that already had an existing table. This meant that the users would either have to see both tables on the same page (one above the other) or that they would need to have the ability to alternate the view between the two tables. 

Having one table above the other meant that the interface would be visually noisier and would create additional cognitive effort for the users to process the information. Also, there was no real business case where users would need to look at the two tables at the same time.  

After this first conclusion, I started to research on the second option: alternating view of the two tables. 

My first thought was to have one tab per table. However, looking at the existing structure of the interface, which already contained a main tab navigation, this idea quickly fell through, as the research suggests that a tab navigation should not have a sub-navigation because it may create doubts on information architecture level. 

The image below is a simple draft created at the time to visualize how a tab navigation with sub-navigation would look – and the conclusion was that indeed it does not work in providing a good user experience. 

Moving from that thought, I started to design something between a tab navigation and a folder structure. As the image below shows, I encountered new challenges, now related with the IA and the fact that the “Email” and “Users” tabs give the idea that they are more relevant than the actual main navigation above.

After these initial ideas failed, I looked into quite a different perspective: a toggle.

The main problem with the toggle is that it does not create the visual impact needed, meaning that it was not apparent enough to users, which could potentially lead to discoverability issues. 

While researching different toggle designs, I came across the switch button. The main advantage of this solution vs the toggle is that we can add proper labels to each view, which not only takes up more space in the UI (and therefore makes an impact in the IA) but because it mimics the behavior of buttons, the users would already have an idea on what to expect upon clicking it. 

This seemed like the solution to my problem! 

Since the design system did not have any switch component, it was my responsibility to create it. 

The main challenge with designing the switch component was taking into consideration the following: 

• It obviously had to follow the design system principles and rules. 

• There are two different interfaces that will use this component, both having grey backgrounds. 

• Different customers will use different primary brand colors on the selected state. 

• Selected state vs not selected state. 

Below are some of the different options I designed.